Room temperature formula

[niclet]

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.

[coyote1]

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

[niclet]

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 :)

[mukowman]

If you want someone to test I have some NodeMCUs and an MHI AC, willing to test if you want to share your code.

[niclet]

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.

[niclet]

I have received wired remote and interface. I can now monitor CLK, MOSI and MISO correctly. Next step : analyse MISO temperature from wired remote.

[riov]

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?

[niclet]

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 :)

[riov]

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.

[niclet]

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 :)

[riov]

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.

[niclet]

Oh, OK. Do you have a link for the official WiFi module ? Seems I started in wrong direction with the wired remote.

[niclet]

This item ? https://www.aircosuper.nl/Wifi-module-MHI-airco-bediening

[niclet]

Or http://www.mitsubishi-electric.co.nz/heatpump/i/69744/wi-fi-interface But my MHI seems not to be supported (SRK35ZMX-S)

[riov]

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.

[niclet]

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

[riov]

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.

[niclet]

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.

[niclet]

I think I will have to use a hair dryer to create a matching table and try to extract a formula.

[riov]

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.

[riov]

niclet, do you have any updates? Have you managed to figure out what is wrong with your temp?

[niclet]

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.

[niclet]

I will try to switch the wired remote in Fahrenheit to check values.

[niclet]

Byte7 could also be the direct value of the temperature sensor maybe like a resistor.

[niclet]

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

[riov]

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.

[niclet]

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.

[riov]

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.

[niclet]

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.

[riov]

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.

[niclet]

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 :)

[riov]

I were you, I would use an external power supply to power those voltage regulators just to be safe. What about data capture with Saleae, do you intend to do it?

[riov]

Any updates?

[loki-amorf]

Thank you for brilliant work! Now I am doing renovation in my flat, and I am planing to install 2 pcs. SRK20ZS-S with one SCM40ZS-S. When renovation will be done, I going to connect to MHI CNS port and try to control it. I am realy waiting for this moment!

[niclet]

Unfortunately, no time at all to work on this project past few days. I'll update this thread as soon as I can.

[riov]

Almost one month has passed since the last update. @niclet, do you have any news?

[niclet]

I don't forget you. But no time at all for now.

[damienmorrissey]

Hi all. I too am very interested in assisting wherever I can with this project. I tried to get the original code working- which is an awesome start by the way, but it seemed buggy at times.

If there's anything that I can help with I'm happy to try when I have the time available. I've got three different types, possibly four actually, MHI units.

Thank you all for the hard work!

[riov]

@damienmorrissey, do you have any wired remote controls (e. g. RC-EX3)?

[damienmorrissey]

Unfortunately no. Only the wireless remote.

On Fri, 25 Oct 2019, 15:37 riov, notifications@github.com wrote:

@damienmorrissey https://github.com/damienmorrissey, do you have any wired remote controls (e. g. RC-EX3)?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rjdekker/MHI2MQTT/issues/8?email_source=notifications&email_token=ANALEHJNGTRJHRT7TRN7AU3QQJZXJA5CNFSM4G3KLM4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECHE6GQ#issuecomment-546197274, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANALEHN54K2SBIQDYHMQWVTQQJZXJANCNFSM4G3KLM4A .

[riov]

Unfortunately no. Only the wireless remote.

Unless someone gets access to the latest wired remote control, there is nothing I can do to investigate communication protocol any further.

[damienmorrissey]

Ok. Thanks for letting me know.

On Sat, 26 Oct 2019, 02:45 riov, notifications@github.com wrote:

Unfortunately no. Only the wireless remote. Unless someone gets access to the latest wired remote control, there is nothing I can do to investigate communication protocol any further.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rjdekker/MHI2MQTT/issues/8?email_source=notifications&email_token=ANALEHJ2UWPP6SX5CLOJUN3QQMIBHA5CNFSM4G3KLM4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECIYCAY#issuecomment-546406659, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANALEHJRKSOXDHVMEUA6EQTQQMIBHANCNFSM4G3KLM4A .

[absalom-muc]

Since I'm working on a similar project based on rjdekker efforts, I created some documentation for the decoding of a SPI frame here. I can confirm that the formula for the room temperature seems to be correct.

[niclet]

Hi all,

I have worked a little bit on my installation. Regarding @absalom-muc work, on my SRK35ZMX-S, the signature for MOSI is 6c.80.04 so it depends on model. And regarding SPI protocol, I get more stable data when looking at CLK falling edge.

I was trying to dynamically modify the MOSI data to check all possible temperature values displayed on my remote, but unfortunately when doing this, the remote displays an error message and the unit shutdowns itself. I think it will be very difficult to go on this project unfortunately :(

At the early beginning, I wanted to simulate IR remote which is more easy. But there is always this annoying BIP when IR are received on the unit. That's why I wanted to use internal connector.

@riov, does your wifi adaptor works locally, or does it always require an internet connection through an external account (seems to be the case according to the doc I have seen from your link)

I don't think that the RC-EX3 will help us more if the unit shutdowns itself as soon as something suspicious occurs.

[absalom-muc]

Hi niclet,

Regarding @absalom-muc work, on my SRK35ZMX-S, the signature for MOSI is 6c.80.04 so it depends on model. And regarding SPI protocol, I get more stable data when looking at CLK falling edge.

There was a mistake in my documentation, my signature is also 0x6c, 0x80, 0x04 I'm surprised that you get more stable data when looking at CLK falling edge, so far, I'm happy with the stability when looking at CLK rising edge. Anyway I'll try it.

[riov]

I was trying to dynamically modify the MOSI data

How exactly you was doing that?

I think it will be very difficult to go on this project unfortunately :(

I am pretty sure you did something wrong. There is no way wired remote control can distinguish whether data is being received from the AC unit or some other device.

does your wifi adaptor works locally

I had to create an account, download an app for my phone and then log-in in order to be able to control my AC unit.

I don't think that the RC-EX3 will help us more

I do not agree. You will immediately be able to find out if you can set automatic fan speed, control L/R louvers, set hi-power mode etc.

@absalom-muc, good start. However, there is still plenty of unidentified bits. For example, what does db0[5] mean (it can be both 1 and 0), db2[7] (same) and so on.

[niclet]

OK, I got it, and I can now test nearly any combination of MOSI frame. I have restarted my analysis from scratch. I was previously using interrupt on CLK line to read/write MOSI/MISO, and it was not really stable. I now permanently read CLK line and guess falling/rising edge myself, and I get a lot more stable results (no errors detected after few hours testing) @absalom-muc, you are right, MOSI/MISO must be read when CLK rises from 0 to 1.

I have started to test various temperature values to check what is displayed on the remote control. For example, when temperature byte is set to 0x40, it displays 1°C. So the formula seems to be quite good. But "-61" seems to be quite complicated in electronic. I have also tested 0x30, and it displays 0°C, I think it can't display negative temperatures (the RC-EX3 manual says that it must be used between 0°C and 40°C) I will give some time to test all possible temperature values.

@riov, I have finally ordered a RC-EX3 on eBay and should get it in some days The displayed temperature is maybe more precise on the EX3 (half degree maybe)

I will then be able to guess missing bytes (hopefully)

[niclet]

Ok, so I have tested all possible temperature values.

0°C for all values <= 0x3d 1°C for 0x3e to 0x41 (4 values) 2°C for 0x42 to 0x45 (4 values) .... 34°C for 0xc2 to 0xc5 (4 values) 35°C for all values >= 0xc6

Maybe there will be decimal display of temperature on the RC-EX3.

[niclet]

According to https://www.mhi-mth.co.jp/en/products/pdf/pjz012a130_english.pdf it seems the RC-EX3 can display outdoor temperature (so it is part of the MOSI frame, and it must be a byte which doesn't fluctuate too much) But displayed temperatures seem to be integers.

[riov]

OK, I got it, and I can now test nearly any combination of MOSI frame.

Can you try toggling unknown bits and see what happens? E.g. db0[5] and db2[7]?

I have finally ordered a RC-EX3 on eBay and should get it in some days

That's fantastic news. I am not sure if your current interface module (SC-BIKN-E) will be fully compatible with RC-EX3 as manufacturer specifies to use a newer version SC-BIKN2-E.

it seems the RC-EX3 can display outdoor temperature

Yes, you can. It is a part of what I call inner frame, db11.

[niclet]

manufacturer specifies to use a newer version SC-BIKN2-E

Yes, I checked that before ordering it, and my interface is a SC-BIKN2-E despite I had ordered a SC-BIKN-E

Can you try toggling unknown bits and see what happens? E.g. db0[5] and db2[7]?

I'll try to check for db0[5] today.

By the way, I have a doubt on MOSI signature. I might be only the first byte. On return, only the first byte of the MISO line stays fixed. Here is an example of two MOSI/MISO frames

6c/a9 80/02 04/77 51/51 22/12 2a/2a a2/ff 00/00 00/00 80/80 00/00 ff/00 ff/f1 ff/f7 ff/ff ff/ff 03/0f 00/00 07/07 ad/23 6c/a9 80/00 04/07 51/51 22/12 2a/2a a2/ff 00/00 00/00 80/80 00/00 ff/00 ff/ff ff/ff ff/ff ff/ff 03/0f 00/04 07/06 ad/cb