[MSZ-GE35VA] Internal temperature sensor readback not decoded to correct temperature in °C

[Ricc68]

The temperature read by the internal temperature sensor is reported twice, but in both cases is not correct:

• in the sensor 'sensor.ac_name_current_temperature is reported to be -64 °C
• in the climate attribute 'climate.ac_name, current_temperature' is reported to be 14.5 °C

The correct temperature is around 23 °C.

I have just installed this component which is the only one that allowed me to use software serial (which btw is working very well at 2400) so I'm sorry I cannot help more in diagnosing the issue, but if you need some debug log of the serial chat I'm happy to help.

[Sammy1Am]

I think this has actually been fixed but not released yet. Would you mind trying main by adding ref: main to your configuration?

If it works I'll try to get a release out later today.

[Ricc68]

I am already running on 'main' sources because I noticed your fixes in the commits 😊 By the way to make sure I cleaned the project and recompiled and run: no change, -64 and 14.5 but still this is an improvement over the 'release' because in that one both readbacks were reported at -64.

[KazWolfe]

Should be fixed by Sammy1Am/mitsubishi-uart#33, though there are some interesting oddities here.

First off, I'm pretty sure your current_temperature sensor is just dead. It was removed as part of commit 1efe6c61355cb4410619a2afedb021c2791916c2, so I suspect that's just stale data on your HA that will fade away eventually.

Regarding your temperature information, your heat pump is reporting a current temperature of 0x0D (per your Issue Sammy1Am/temp-issues#2). This (to our knowledge) does accurately decode to 14.5 °C. Even if we were to use the legacy setpoint scale for this conversion, we'd only see 18 °C. This leads me to believe that your internal temperature sensor is way off (very possible if your unit is high off the ground), or that there's something else fishy going on.

[Ricc68]

It might be that the internal sensor temperature is off. Consider that the room temperature sensor is 50cm above the ground and in the middle of the room measuring 23.7 °C while the unit is high above the floor by 2.5m and in a recess on the far angle of the room. I placed a sensor near the unit and it is reading 23.0 °C so even considering a measurement error of -1 °C probably the internal sensor is really offset by as much as 5 °C. Maybe there's way to offset in the unit the internal sensor?

[KazWolfe]

I don't think it'd be an issue at all to add a calibration setting somewhere. I would like to ensure that everything works roughtly as intended first, though.

Do your setpoints tend to respect the actual (calibrated) temperature of the room?

[Ricc68]

Yes, that is something I was thinking, that maybe there's something else weird with this readback. In general the AC is working correctly: the room (calibrated, literally 😊) sensor tends to match the AC setpoint. I just did a quick test:

• the current readback from the unit is 15 °C and the room temperature on the calibrated sensor is 23 °C.
• I switched on the unit in cold mode with a setpoint of 21 °C from the IR remote
• The unit started and by looking at the front panel, the two green LEDs are lit which means the unit is not at setpoint (actively cooling trying to reach the setpoint)

How can the unit recognize that it is not at setpoint in cooling mode if its internal sensor reads 18 °C and I programmed a setpoint of 21 °C?

Tomorrow morning should be colder and I can note the two temperatures again to see how they move.

[KazWolfe]

It'd make sense for there to be a calibration, but I also don't see any calibration documentation in the manual....

The current room temperature (at present) is read from packet 0x62 type 0x03, and in your case specifically byte 3.

The only thing I can think of right now is that the decoding format we currently have for that packet (documented here) is somehow inaccurate, but that information came from Kumo's internals so I'm slightly confused here. It might be helpful if you can keep a log of what that packet says and what your expected value is so that we can try to piece this together.

[Ricc68]

I think I've got it! I was looking at SwiCago's library and it appears that the 0x62/0x03 is decoded by a "room temp map":

const byte ROOM_TEMP[32]       = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f};
const int ROOM_TEMP_MAP[32]    = {10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41};

and the conversion is simply 10+data which decodes 0x0D (13) to 10+13= 23 °C, my correct room temperature!

Instead, the get/set settings temperatures, for example 0x62/0x02 are encoded by a "temp map" which is different:

const byte TEMP[16]            = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f};
const int TEMP_MAP[16]         = {31, 30, 29, 28, 27, 26, 25, 24, 23, 22, 21, 20, 19, 18, 17, 16};

with a simple conversion of 31-setpoint, so if I set 21 °C (0x15) it encodes to 31 (0x1F) - 21 (0x15) = 0x0A and the other way around when decoding setpoint from unit: setpoint = 31-data and data=31-setpoint (this needs double check).

I'm fairly certain of what I saw but please, double check my findings as I may have overlooked something, plus the maps in this post are copy pasted so double check they are pasted correctly.

This also shows that the legacy temperatures mode supports only integer values.

Btw, I would not use the maps as they are overkill in an MCU, the calculation is fairly simple and fast compared to a lookup table which uselessly consume space in flash.

[KazWolfe]

Interesting, I wonder how the Kumo docs are wrong then:

room_temp: function (e) {
  return 63 >= e ? {
    or_lower: Boolean(0 == e),
    or_higher: Boolean(63 == e),
    celsius: 8 + 0.5 * e
  } : {
    _invalid: 'Room temp code out of range'
  }
},

I'll update the code accordingly to deal with this case, though it's definitely interesting/annoying that this is what we get to deal with.

Re the setpoints, that formula should be good already, but we're unsure if fractionals are properly supported. Will be something that needs further testing.

[Sammy1Am]

Hey there, the PR merge automatically closed this, but if you have a moment to confirm this actually resolves your problems, @Ricc68 , it would be appreciated.

[Ricc68]

@Sammy1Am My unit is not in kumo compatibility list, I only see the MSZ/Y-GE which is not my unit's code. I have also checked the temperature range on the IR remote which is 16-31 °C, no decimals, which is partially confirming the mapping above and by thinking at that byte in the protocol I don't see how the fractional numbers can be encoded in that single byte which, by the looks of it, uses only the rightmost 4 bits. Also, issue Sammy1Am/temp-issues#2 shows that trying to set a fractional temperature returns back 31 °C which I think supports the theory of the lookup table and integers-only setpoints.

Yes, tomorrow I will confirm the room temperature fix.

[Sammy1Am]

This makes me slightly concerned that there might be two different formulas out there for converting the legacy temperatures. But until someone else comes along with something that doesn't work, at least it's working for you :)

[Ricc68]

@Sammy1Am Perfect, now the room temperature is read as 25 °C which is fairly close to my thermometer which reads 24.5 °C:

This is definitely fixed.