Lookup table for F to C conversion

[dlarrick]

The KumoCloud WebApp and app appear to use a lookup table for converting Fahrenheit to Celsius. If the indoor unit is set to a Celsius setpoint that's not in this table, the KumoCloud app fails to display (shows "--").

See dlarrick/hass-kumo#55 which contains a link to a doc I'm attaching the relevant portion of Javascript table.
f-to-c.txt

The task is to use only Celsius values that appear in this table when sending the setpoint to the indoor units. It may be sufficient to round to the closest half-degree C (I have not looked closely to see if there are any gaps).

[brgaulin]

Prefix: I know I've been a bit active lately, I hope my presence is welcome and not overwhelming, but please feel no pressure to quickly reply. I'm very excited by the work that has been done here and want to give back =)

I'm wondering if this lookup table was intentional, maybe to workaround a bug in the hardware. When working with set temp and room temp, it is always in 0.5C increments via the API. They do have the C -> F formulas, and use those in some places in the application, but they aren't being used here.

Interesting Note: When I use the IR remote to set the temp to 67F(19.44C), the API reports it as 19C, but the lookup table shows 19.5. Spot checking a few other temps via the remote, and they seem to all line up with the table.

On the idea of rounding to the closest half degree, that does get us very close, see this gist(apologies, js is my native language). I take 40-100 degrees F, and then:

• Use math to convert to C(Same formula as HA, and the rest of the world)
• Round to the nearest half degree C
• Compare to the table lookup.

Any line that ends in "ERR", the rounded number doesn't match the table lookup.

ex: 84F is actually 28.89C, which would be rounded up to 29C since it is more than 28.75. But the table lookup shows 28.5C. Overall, this rounding gets it right about 74% of the time.

One more note, via this gist we can see that sometimes, the table isn't used. I copied the convertFromTableIfWithinRange function and translated it for readability, and it appears that every 5C, we use the actual Fahrenheit math. This seems really odd, as the values in the lookup table match up with the real values, except for 30C, in the table it is 87F, but it would be displayed in the UI as 86F.

Proposal

Before I put fingers to keyboard, I wanted to run 3 ideas by you

1. For the set_heat_setpoint and set_cool_setpoint, introduce(and document) that the number will be rounded to the nearest 0.5C. This would technically be a breaking change, and I'm not sure if it is required by the Mitsubishi units but it would fix the Kumo Cloud app
2. Add(and consume in HA integration if HA config is in fahrenheit) new alternative functions set_heat_setpoint_fahrenheit and set_cool_setpoint_fahrenheit which use the lookup table
3. Same as 2 but for get_current_temperature. The Kumo app does appear to use the table for this value as well

[dlarrick]

The reason for this issue: if you use HA to change the setpoint, the KumoCloud phone app displays "---" for some setpoint temperatures. Changing the PyKumo code to round to the nearest 0.1 degree F didn't help; changing to round to nearest 0.5 degree F helped somewhat. Then some folks digging in the web app discovered this lookup table and it was thought that utilizing it would cause the app to be happy. Personally I don't care; not having to use the KumoCloud app is a blessing. But any added complexity in the pykumo code here needs to keep that original goal in mind, and I'd want testing done to assure that the KumoCloud app is happy at least over a reasonable range of temperatures..

[brgaulin]

I think the main question comes up: Do we want to emulate Kumo Cloud exactly, which uses this lookup table. Or do we think kumo cloud is being extra, and this lookup table isn't useful. If we do nothing, you will get the most accurate control of temperature I think, because Kumo is doing a lot of rounding / bad math.

1. in my proposal to always round to the nearest 0.5C in pykumo will fix the kumo cloud UI bug. However you may see a different value in the cloud when compared to setting via pykumo with F -> C math.

Proposal 2+3 are way more up in the air for me, Kumo cloud doesn't have a lookup table for going celsius -> celsius. If Mitsubishi is confident that the Celsius temps are accurate, then doing normal math to and from Fahrenheit should be fine. 2+3 would ensure that the temp in Kumo app and HA are identical, but I think it would introduce rounding errors / inconsistent temps and we would want to avoid it.

I think in writing this comment I've talked myself out of thinking this should be addressed, but it is good to note that switching to contol via PyKumo gives you much greater control/accuracy at the sacrifice of the Kumo App.

[zach-rosen]

Last night at 2am I woke up to my living room at 71 degrees and still heating. HA said thermostat was set to 66 and logs showed that it started heating when the temp had only dropped to 68! I noticed that Kumo App said "- -" for temperature and started digging in with pykumo to see if I could tell what was up. Living Room HVAC had spHeat=18.9… the only unit set to a non .0/.5 value.

Is it possible that this is more than a cosmetic/display issue and actually impacts the behavior of the HVAC? Could the Kumo adapter be storing/reporting the requested set-point as a float, but the head unit rejects the value is using a previous value?

[cjkrolak]

I've seen occasional null values on the Kumocloud app and pykumo, I know that changing the temp with the remote control is one way to cause this issue, I think that it can happen without even touching the remote control. I have one zone that seems to have more nulls than the other, I'm wondering if wifi adapter or wifi signal strength might play a role in this issue as well.

[brgaulin]

As documented a bit above, the "--" is because the kumo cloud for some reason does a translation from C->F using a lookup table which doesn't make much sense. The "--" is what it displays when it is unsure of what to show. The lookup table has every 0.5C, but has a few mistakes it seems. Where you would end up quite off when doing the translation.

Potentially related note, about multi head systems in general. When any unit is calling for heat, all units will produce heat. It shouldn't be too much heat, but in our case, our entire second floor achieves the same temperature no matter what, even if doors are closed and one room is set 10F colder than the rest. We've seemed to reach an equilibrium lol

[cjkrolak]

So if I set my temps via the remote and via python in whole number degrees C does the problem go away?

I've noticed a large temperature offset between the display temp in kumocloud and the actual intake air temp, I'm running a +6 (max) offset on one zone and a -5 offset on the other zone to mostly correct it, without the offsets I was having overheating problems on one zone like you are talking about, air intake temp at the head was in the 70's but kumocloud was reporting low 60's and the zone was heating 100% of the time.

[zach-rosen]

@brgaulin My concern was that the failed lookup might have been preventing Kumo from programming the HVAC (like some "if (lookup_err) return" before sending/setting the value). After switching the app to display Celsius it immediately resolves the '--' so it seems more likely this is just a cosmetic thing in the Kumo app.

[dBeau]

I condensed the table mentioned above and wrote a couple of functions to implement it. I'm playing with now and it seems to work.

This gist shows the code and test results for bi-directional conversions from 40F to 99F and back again.

For testing I've made some minor modification to hass_kumo's climate.py. In the couple of places where a temperature is sent to pykumo, temp_to_kumo() is applied to the value first. Likewise, in the couple of places where a temperature is taken from pykumo temp_from_kumo() is applied before storing.

It's my opinion that pykumo is the right place for this change. hass_kumo was just a bit easier to muck with in my environment.

[brgaulin]

I stopped using the kumo app and now do control directly through home assistant. My preference was to the more accurate temperatures, but if you are using the kumo automations it might be worth a go.

[dlarrick]

It's my opinion that pykumo is the right place for this change. hass_kumo was just a bit easier to muck with in my environment.

I agree, pykumo is the place for this, ideally as an option when constructing a PyKumo object. Then, in hass_kumo ideally it would be an option on the integration. Then those of us who never use the official Kumo app can have more precise temperatures, and those who do like to use it can have proper display. I will accept patches that implement things this way.

[rr326]

I'm not sure if this debugging info is helpful, but I'll add just in case.

HA 2023.10.3. Brand new Kumo Cloud App (iOS) and Kumo Cloud Installation.

This DOES seem to only be a cosmetic issue.

• House is temp 68 F
• Set HA Kumo to 70
• Kumo Cloud App shows "--"
• Wall thermostat (Mitsubishi) shows: 68 (or even 69) set point
• House actually warms to 70 F

So it is working but the displays are all wonky.