Room temperature formula
niclet opened this issue · comments
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.
I will try to switch the wired remote in Fahrenheit to check values.
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 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 :)
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?
Any updates?
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!
Unfortunately, no time at all to work on this project past few days. I'll update this thread as soon as I can.
I don't forget you. But no time at all for now.
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!
@damienmorrissey, do you have any wired remote controls (e. g. RC-EX3)?
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.
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.
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.
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.
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.
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)
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.
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.
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.
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
In my setup, MOSI frame always starts with 0x6d, 0x80, 0x04 and MISO - 0xa9, 0x00, 0x07.
Ok, so it may depend on the device connected to the unit. Is your WiFi interface directly connected to the unit ?
Yes.
By the way, your RC-EX3 should come with a CD that has software to control RC-EX3 over the PC. I would really like to get a copy of that software. Could you upload it somewhere once you receive your RC-EX3?
When I force MOSI db0[5] to 1, nothing changes on the remote display, but on return MISO forces it to 0.
By the way, you RC-EX3 should come with a CD that has software to control RC-EX3 over the PC. I would really like to get a copy of that software. Could you upload it somewhere once you receive your RC-EX3?
Sure.
Yes, on returned frame that bit is set to zero (e.g. MOSI - 0x31, MISO - 0x11). Maybe your current wired remote control does not understand it.
It is also interesting, that your remote control will understand 0xae value as 35°C, while in my case it will show 23°C. The last bit has some special meaning.
Actually, 0xae displays 29°C on my remote.
23°C is displayed for 0x96, 0x97, 0x98 and 0x99.
Sorry, my mistake. I was talking about setpoint temperature (db2[7]). For room temperature: (0xAE - 61) / 4 = 28°C. Not sure why it is off by 1 degree on your control.
I have just checked that the temperature setpoint is actually
T[°C]=db2[6:0] / 2 instead of T[°C]=db2[6:1]>>2
My remote displays half °C for setpoint, and it matches the least significant bit.
@absalom-muc, you can update it on your side.
So you cannot set your temp in half degree steps with a remote control, but you can do that with wired remote? Have you tried toggling the last bit of db2?
Setting db0[1] to 0 or 1 doesn't change anything on my remote.
So you cannot set your temp in half degree steps with a remote control, but you can do that with wired remote? Have you tried toggling the last bit of db2?
Yes, with IR remote, only full degrees, and with RC-E5, half degrees.
Setting db2[7] to 0 or 1 doesn't change anything on remote either.
Maybe a useless bit.
Did you ever seen it as 1 during tests ?
Did you ever seen it as 1 during tests ?
Yes. I have captured it being 0xAE.
You can try different values for db7 and db8. In my setup they are fixed to 0x02 and 0xff.
db7 is sometimes 0x00 or 0x02 on my side
and db8 is always 0xff too
I have just checked that the temperature setpoint is actually
T[°C]=db2[6:0] / 2 instead of T[°C]=db2[6:1]>>2
My remote displays half °C for setpoint, and it matches the least significant bit.@absalom-muc, you can update it on your side.
Thank you niclet, documentation is updated.
@riov, when you connect the Wifi interface to the connector, is there some kind of init dialog on SPI, or do you get directly stable infos ?
Actually, it takes ~3 seconds from the moment I stop receiving 0x6d, 0x80, 0x04 and then start receiving it again. During that period crazy stuff is happening. It supposed to be some sort of synchronization process, but I do not not have a clue of what is actually going on.
@niclet, what about my old request to do some data capturing with Saleae? Would you be able to do that? I would like to see communication between your AC unit and your wired remote control.
I'd rather not modify my installation. But I can provide you some logs like
6c/a9 80/00 04/07 a0/a0 9a/9a ae/ae 9c/ff 00/00 00/00 88/80 00/00 ff/00 ff/ff ff/ff ff/ff ff/ff 00/0f 00/00 08/08 f7/22
6c/a9 80/21 04/07 a0/a0 9a/9a ae/ae 9c/ff 00/00 00/00 88/80 00/00 ff/00 ff/f1 ff/f7 ff/ff ff/ff 00/0f 00/00 08/08 f7/2d
6c/a9 80/00 04/07 a0/a0 9a/9a ae/ae 9c/ff 00/00 00/00 88/80 00/00 ff/00 ff/ff ff/ff ff/ff ff/ff 00/0f 00/04 08/08 f7/26
6c/a9 80/00 04/07 a0/a0 9a/9a ae/ae 9c/ff 00/00 00/00 88/80 00/00 ff/00 ff/ff ff/ff ff/ff ff/ff 00/0f 00/00 08/08 f7/22
I have not seen your latest installation, but if you still use a breadboard, that is as easy as connecting 4 extra wires to Saleae. 4 frames are not enough to draw any conclusions or make any observations. Anyway, I will take a look at it, thanks.
Here are my observations based on the data you have provided:
- db0[5] bit is set, it does not happen in my setup.
- db0[7] bit is set, it does not happen in my setup.
- db1[3] bit is set, it does not happen in my setup.
- db1[7] bit is set, it does not happen in my setup.
- db2[7] bit is set.
- I have not seen MISO signature of 0x09, 0x21, 0x07.
Ok, I'll take some time to log more data tomorrow.
The RC-EX3 has been dispatched today, hope to get it by the end of the week.
Log_from_no_remote_to_stable_remote.txt
Here you can find full log with following states :
- no remote connected to unit
- remote connected and in "wait" status (synchronisation ?)
- usual mosi/miso communication
Thanks. I will need to investigate further. But right away I can say your "synchronization" sequence is very different from mine. What is happening with constantly changing MISO signature is a big question, it is most of the time being incremented. Are you in any way altering it?
For now, I never change the MISO line.
And for this log, nothing changed at all.
Maybe the RC-E5 was made for SC-BIKN-E, and not for the SC-BIKN2-E I have.
I don't understand why there would be so much MISO modifications.
There is no need to secure the wire connection.
At the beginning db13 has a value of 7 - never happens in my case, I have only observed it being 0, 1, 3, 5. So, the first three bits have some meaning. Some of you inner frames are unique, I have not seen them. That's all I see different compared to my setup.
What does it all tell us? I guess not much.
Still waiting for my new remote, it has arrived in France today, so I should get it in next few days.
By the way, since I have several internal units connected to external unit, I have tested an invalid mode. E.G. one unit is in heat mode, and I power on my spied unit in cool mode, the second one enters "invalid mode"
Here is the data of MOSI/MISO lines during this step
(50 = HEAT OFF)
6c/a9 80/00 04/07 50/50 22/12 28/28 9b/ff 00/00 00/00 88/80 00/00 ff/00 ff/ff ff/ff ff/ff ff/ff 00/0f 00/00 07/06 a8/c4
6c/a9 80/00 04/07 50/50 22/12 28/28 9b/ff 00/00 00/00 88/80 00/00 ff/00 ff/ff ff/ff ff/ff ff/ff 00/0f 00/00 07/06 a8/c4
6c/a9 80/00 04/07 50/50 22/12 28/28 9b/ff 00/00 00/00 88/80 00/00 ff/00 ff/ff ff/ff ff/ff ff/ff 00/0f 00/00 07/06 a8/c4
(49 = COOL ON)
6c/a9 80/00 04/07 49/50 22/12 28/28 9b/ff 00/00 00/00 88/80 00/00 ff/00 ff/ff ff/ff ff/ff ff/ff 01/0f 00/00 07/06 a2/c4
6c/a9 80/00 04/07 49/50 22/12 28/28 9b/ff 00/00 00/00 88/80 00/00 ff/00 ff/ff ff/ff ff/ff ff/ff 01/0f 00/00 07/06 a2/c4
6c/a9 80/00 04/07 49/50 22/12 28/28 9b/ff 00/00 00/00 88/80 00/00 ff/00 ff/ff ff/ff ff/ff ff/ff 01/0f 00/00 07/06 a2/c4
The only difference is on db16[0] which is 0 on correct mode, and 1 in invalid mode
Nota : I prefer giving bytes number from 0 to 19 instead of ignoring signature bytes.
I doubt if that bit means it is in invalid mode. I see that bit often set in my config. Either there are some important uncaptured frames in between HEAT OFF and COOL ON, or, more likely, remote control is clever enough to figure out that you are trying to set Cool mode while AC unit is reporting that it is currently in Heat mode. As an extra step of confirmation, you could try entering and leaving invalid mode several times and see if each time that bit is changing.
I think the way to proceed further is to do some collaboration. If you can find some spare time and if you are willing, we could meet in a chat (current form of communication is not effective) and do real time data recording and analysis.
Nota : I prefer giving bytes number from 0 to 19 instead of ignoring signature bytes.
I am also not a fan of db[*] notation, I prefer 1..20, do you like 0..19 more?
There was no missing frame.
I'll take some time to enable/disable this bit inside the MOSI line to check if the remote reacts accordingly.
By the way, my external unit has just been in defrost mode.
Here is the log during this step. I have not analysed it yet at all.
I believe defrost will be byte9, bit2 (your notation).
I believe defrost will be byte9, bit2 (your notation).
Actually my log was done during defrost mode, not while going into defrost mode.
So i'm not sure this is byte 9, bit 2.
I don't see specific difference, so there may be a step which tells the defrost begin and another which will tell the defrost end.
Well, you need to try toggling unknown bits in MOSI and see how remote reacts to that. That's not complicated given that you have already managed to modify MOSI stream before. That will safe us a lot
of time.
I have just received the RC-EX3.
No software provided for USB connection. The manual says it is available on web site, but don't know which.
I'll try to take some time for some quick test tonight :)
Great news. Please try if you can set automatic fan speed, L/R louvers' position, hi-power mode.
That's very odd that you have not received a CD with software. I have looked all over the web, software is not available for download. More importantly, there is no place where you can fill out a request to provide you a download link.
A quick test for fan speed, it deals with byte 4, as already discovered.
28 (1000) = fan speed 1
29 (1001) = fan speed 2
22 (0010) = fan speed 3
2e (1110) = fan speed 4
2f (1111) = fan speed auto
Regarding HiPower,
6c/a9 80/00 04/07 53/53 2f/2e 2a/bc 9c/ff 00/00 00/00 80/80 02/04 ff/00 ff/ff ff/ff ff/ff ff/ff 07/0f 00/04 07/07 bc/7f
6c/a9 80/00 04/07 53/53 2e/2e bc/bc 9c/ff 00/00 00/00 80/80 02/04 ff/00 ff/ff ff/ff ff/ff ff/ff 07/0f 00/04 08/07 4d/7f
So, the remote requests fan speed 4 (2e) and switches temperature from (2a=21°C) to (bc=30°C)
According to doc, HiPower remains active for 15mn. So this is probably something which is controlled by the remote itself and turned off after 15mn.
More tests later :)
@loki-amorf, thanks for the help. Is it compatible with the latest wired remote control (RC-EX3) and does it support all its new features? The title of that software says it is for RC-EX1.
A quick test for fan speed, it deals with byte 4, as already discovered.
28 (1000) = fan speed 1
29 (1001) = fan speed 2
22 (0010) = fan speed 3
2e (1110) = fan speed 4
2f (1111) = fan speed auto
What is discovered up until now is this. It is the first two bits of 4th byte and the 6th bit of 9th byte. Can you please clarify? By the way, if I set fan speed to Auto with my remote control, I see no changes in CNS protocol.
What about controlling position of L/R louvers?
Quick update for tonight.
During my test yesterday, only byte 4 (bit 0-3) did change when changing fan speed. 6th bit of 9th byte didn't change. I'll test it again asap.
Regarding L/R or U/L, I don't understand. It is not proposed on the remote, and according to the manual, it means the unit doesn't support it. But the "3D Auto" setting is available on the IR remote and turn on/off a LED on the unit when activated/deactivated. I don't have the "3D Auto" on the RC-EX3 because it is part of the same settings as L/R U/L.
There might have been an issue during RC-EX3 first initialisation, when the remote detects unit capabilities.
I'll try to do some test after some kind of reset if available.
I have just looked into your indoor unit's user manual (SRK35ZMX-S). It does suggest you can control L/R airflow. See the images attached.
Actually I can change L/R and U/D with IR remote, the unit reacts accordingly, but nothing changes on the MOSI line. This is probably why the RC-EX3 doesn't show this setting.
Yes, I know that MOSI line does not change when L/R direction is set with a remote control. The same happens if you set Fan speed to Auto. However, RC-EX3 allows you to set this mode. So, I was hopping it will allow you to control L/R louvers as well (its user manual says it has such capability).
Is there anything extra you can do with RC-EX3 that you was not able with RC-E5? For example, can you select between five (not four) U/D directions. Can you enable/disable Silent mode? Is there anything else you can do?
For now, I confirm that fan speed is set on bits 0,1,2 of byte 4, nothing changes on byte 9 in my case.
bits 000 = fan speed 1
bits 001 = fan speed 2
bits 010 = fan speed 3
bits 110 = fan speed 4
bits 111 = fan speed auto
In my case, the RC-EX3 doesn't allow me to change L/R or U/D, the manual says that the availability of the setting depends on the unit. This is strange, since my unit supports it with IR remote.
Regarding HiPower and Eco, I feel that RC-EX3 only changes temperature and fan speed. Actually, it doesn't seem to really activate these modes on the unit (HiPower LED is not turned on and Run LED doesn't turn from GREEN to BLUE in ECO mode, contrary to activation of these modes with IR remote)
For now, only the IR remote gives access to all settings. And I have not found any way to turn off BEEP when using it. It might be possible with some modification inside the unit itself.