MHI2MQTT
MHI2MQTT copied to clipboard
rjdekker
Room temperature formula
Hi, Thanks for you excellent work. I'm trying to make it work on ESP8266 directly. But in my case, the room temperature seems to be not very accurate. Do you remember why the formula was set to //Calculate current room temperature in degrees Celsius from bitfield 7 using: // (BF7 - 61) / 4 (note: Calibration of temperature needs to be checked further) Is it estimated or is there any "reason" for this formula, especially the "- 61" ? Or does it mean my aircon is not correctly calibrated ?
Best regards.
Hi, did you manage it only with the esp8266? I have problems with current setup, sometimes connection to MQTT failed and then it can't connect again. I don't know why. Hope anyone keeps this project alive (maybe you :-)) For tests, I like to make myself available
Hi,
For now, I have started from scratch. Since SPI slave seems to be quite undocumented on esp8266, I read MOSI data directly from a simple input pin. For now, I get 20 bytes fields with expected signature, checksum and so on. And in my case (SRK35ZMX-S) the room temperature seems to be quite inaccurate, which led to my question about temperature formula. Maybe the temperature field is just a thermistor value which needs to be used with a temperature table, I don't know. Moreover, since the thermistor is inside the aircon, I don't know how it keeps on getting the correct room temperature while heating.
If you're interested, please take care of voltage, I have burned many components. MOSI line is ~5V, which is too high for esp8266. I now use a logic level convertor to 3.3V
Still many work :)
If you want someone to test I have some NodeMCUs and an MHI AC, willing to test if you want to share your code.
Thanks :) For now, since I use software implementation of SPI, I have switched to ESP32 to get 240Mhz. With my ESP8266, even boosted to 160Mhz, I had some frames drop when monitoring CLK rising and falling at the same time. I'm waiting for my RC-E5 and SC-BIKN-E. It seems that RC-E5 can act as a temperature sensor, which means that we could give our own temperature to the MHI unit instead of using its internal sensor which is quite inefficient to my mind. I hope to improve understanding of the protocol.
I have received wired remote and interface. I can now monitor CLK, MOSI and MISO correctly. Next step : analyse MISO temperature from wired remote.
niclet, did you managed to get any additional info about the protocol now that you have wired remote and interface? Which exactly remote do you have?
riov, unfortunately, I had not enough time to work correctly on this project, but I will continue as soon as possible. The remote I use is RC-E5 with interface SC-BIKN-E. I got them from https://www.orionairsales.co.uk, quite expensive that's why I will work on it for sure :)
niclet, unfortunately, you have bought an older wired remote control. It does not support many features like automatic fan speed, control of L/R louvers, hi-power mode and so on. I have created a program, which allows to analyze MHI's communication protocol. If you have Saleae and need some help, you can contact me.
Yes, I have a Saleae with 8 pins (official product). Do you analyse data between MHI and interface without remote or do you have another remote control? All help is welcome :)
niclet, I intercept data between the AC unit and official WiFi module. You can send me data captures from Logic, or you can setup Logic server so that I could connect to it and download the data automatically.
Oh, OK. Do you have a link for the official WiFi module ? Seems I started in wrong direction with the wired remote.
Or http://www.mitsubishi-electric.co.nz/heatpump/i/69744/wi-fi-interface But my MHI seems not to be supported (SRK35ZMX-S)
I have this one, and it does support your AC. I am not sure if you will get much more extra insight in MHI's data protocol by purchasing it. Just as your current wired remote control, it does not support many features. The only hope is the latest wired remote control RC-EX3.
Ok. For now, without Seleae, I already get binary data blocks like this: 6c.80.04.50.00.2a.99.00.00.88.00.ff.ff.ff.ff.ff.00.00.07.86 (from AC to remote, and slightly different from remote to AC) I already identified some parts by changing settings of the AC from remote. But temperature (seems to be 7th byte) is not obvious to decode into real °C or °F
Based on the data you have provided, I can say the following about your AC: power is off, mode: Heat, fan speed is ULo, U/D vanes swing, setpoint temp is 21C, room temp is 23C.
I extract same info from the binary data. For the room temp, do you use (byte_7 - 61) / 4 formula ? In this case, it gives 23C, but in some cases, the formula doesn't give exactly the temp displayed on the remote.
I think I will have to use a hair dryer to create a matching table and try to extract a formula.
Yes, I use the same formula and it looks to be working great in my case. If you can capture a data packet that is giving you a wrong temp, please provide it. I would be interested in getting longer data captures done with Saleae. There is still a lot of unknown left within this protocol.
niclet, do you have any updates? Have you managed to figure out what is wrong with your temp?
I have used an hair dryer and got following data (byte 7 in hex = displayed temp = formula) c5 = 34 = 34.00 c2 = 33 = 33.25 bf = 32 = 32.50 ba = 31 = 31.25 b4 = 30 = 29.75 b3 = 30 = 29.50 b1 = 29 = 29.00 b0 = 29 = 28.75 ae = 29 = 28.25 ad = 28 = 28.00 ab = 28 = 27.50 aa = 28 = 27.25 a9 = 27 = 27.00 a7 = 27 = 26.50 a6 = 27 = 26.25 a4 = 26 = 25.75
So formula seems to be quite good.
And while looking at the formula, I was thinking about the conversion between Celsius and Fahrenheit : T(°C) = (T(°F) - 32) × 5/9
If we consider T(°F) = byte7 / 2, it is nearly the formula. Unfortunately, when computing values, it is more different that current formula.
But I think it may have a link with F and C.
By the way, the wired remote can't display temperature higher than 35°C even if temperature is higher.
Byte7 could also be the direct value of the temperature sensor maybe like a resistor.
Some temperature samples with remote in Fahrenheit
c0 = 92°F b9 = 89°F b7 = 88°F b6 = 88°F b4 = 87°F b3 = 86°F b1 = 86°F b0 = 85°F ae = 84°F ad = 84°F ab = 83°F aa = 82°F a9 = 82°F a7 = 81°F a6 = 81°F a4 = 80°F a3 = 79°F a1 = 78°F a0 = 78°F 9f = 77°F 9d = 77°F 9c = 76°F
One thing I would like to point out is that you need to let the temperature rest before taking measurements. I was capturing continuous communication with Saleae for long time periods and I have noticed that quite often indoor temp was fluctuating by 0.25 degrees multiple times within one second. What I am trying to say is that it is possible RC-E5 does not update indoor temp value immediately.
The best way to find out how exactly does RC-E5 convert byte 7 to temp would be to connect Arduino directly to it (its interface module) and make it a SPI master. That way you could feed predetermined data and see how it decodes it.
By the way, are you sure your RC-E5 displays air temperature, not its own temperature? More info.
For now, I already decode SPI myself with ESP32 and temperature change on the remote occurs really just after a change in the SPI data and remains stable for a while. I was just thinking about sending my own data to be able to create a full mapping table between data and temperature :) And yes, my remote is correctly setup to be a thermostat :)
But I have very few time to work on it unfortunately.
Well, it looks like it is a dead end. I was hoping to find out more about this protocol than it is already known. Unfortunately, without having the latest wired remote control it is next to impossible to draw any conclusions about what is really happening apart from stating the obvious, like byte #12 is always 0xFF and byte #18 is always 0x00. I do not know how to figure out what is the meaning of those bytes and if they can hold different values.
I was thinking about ordering both RC-EX3 and compatible interface module, so that I could test them out and return within 14 days (I do not really need them). But that would be a huge hassle given that they are not sold locally.
If you find any spare time to build a prototype that allows you to send data directly to your RC-E5 please let us know. Not only it would interesting to see how exactly does room temperature map to byte # 7, but it would also be interesting to try out different values for bytes #12, #18 etc. Long data captures made with Saleae would also be helpful.
Through the wired remote, we can configure many things, like for example : use the temperature sensor of the remote by adding 3° to it. There are many parameters. When manipulating these parameters, there is a "downloading" step to get current settings from MHI unit. And during this step, bytes 12...16 which are usually FF are modified.
I have only observed bytes #13-16 being other than 0xFF, byte #12 is always the same in my setup.
If you have some spare time, please run Saleae for a few minutes or so and capture what is being sent and received when each option is being changed.
I have just restarted from scratch with a clean breadboard. MHI provides 12V power with 5V CLK/MOSI/MISO lines and ESP32 uses 3.3V input/output. So I use voltage regulators from 12V to 5V and 3.3V to power bidirectional convertors between 5V and 3.3V input/output Unfortunately, I can spend only few time per day on this project, but I'll do it !! :) Here is the breadboard, not totally finished yet :)
