Fahrenheit passthrough thermometer mode?

[aschmitz]

Hi, I'm just opening an issue to feel out your interest in a mode for an upstream-connected thermostat (via the uart_thermostat setting) that works with the connected thermostat set to Fahrenheit.

For a variety of reasons, I'm unlikely to switch the thermostat to Celsius, and Mitsubishi seems to have some well-known quirks with its Fahrenheit conversion (#65 among others). Would you be open to a mode that talks to the thermostat and converts existing/internal temperatures from Celsius to "Celsius values that the thermostat will display as the correct Fahrenheit values"? (And then presumably the reverse for set point changes from the thermostat - although I believe thermistor readings should be correct as-is.)

I understand you may not be interested in developing such a feature yourself, but if it seems like something you'd consider merging in (as a configurable, non-default option), I may try my hand at doing so.

[samphonic]

I think a good starting point for this discussion would be an example table from 65° to 71° F and what the associated °C values would be with this system.

I can do one next time I'm at a desktop, but I suspect the challenge will be:

• The C -> F conversion done by Mitsubishi is weird, but since the thermostat is limited to whole degrees F there is necessarily some overlap where two half-degree-C temps will round to the same F value.
• Converting F on the thermostat to C has some undefined use-cases. E.g. if I set the F thermostat to 67 or 68, which C values should be sent to the heat pump for those since there are two that are mapped?

[aschmitz]

I think there are two possibilities:

The Celsius-native option

1. Verify the table in https://muart-group.github.io/user/configuration/useful-snippets#use-mitsubishi-temperature-conversion against what my thermostat attempts to set for various Fahrenheit set points.
2. When reporting a temperature (set point or current temperature) to the thermostat, convert the value from Celsius to Fahrenheit (using the correct 9/5ths+32 formula), round to the nearest integer degree Fahrenheit, and look up the corresponding "fake Celsius" temperature in the table and report that to the thermostat (so it shows the correct Fahrenheit value).
3. When receiving a new set point from the thermostat (in "fake Celsius"), look up the corresponding Fahrenheit value, then convert that faithfully to Celsius and round to the nearest half-degree.
4. Pass through Thermostat-reported thermistor temperatures. (Probably? I'm assuming they're correctly reported in Celsius, rather than going through some sort of conversion, but I suppose if there were a good way to verify that, it would be ideal.)

I suspect your assumption that there are half-real-Celsius values that may not be selectable with that configuration is correct, but I'm not sure that there's a best way to handle that. (Besides changing the thermostat to Celsius, of course, but we ought to be able to provide a better Fahrenheit experience.)

One possibility would be to keep the existing "allow setting half-degree Fahrenheit values in Home Assistant" feature, and allow users to override it there (and presumably not override it with the thermostat's value if the existing value is within bounds). Beyond that, though, I'm not sure there's a better option: the existing thermostats already have to skip over some possible values as well, so we shouldn't be any worse off than the out of the box experience. (And of course, half-degree Fahrenheit is more specific than half-degree Celsius, so the Home Assistant interface is also not quite in sync with the heat pump.)

This discrepancy leads me reluctantly to:

The "rescale everything" option

1. Verify the table as above, so we can read thermostat set points as Fahrenheit. Do that conversion when reading set points from the thermostat.
2. When in Fahrenheit mode, convert Fahrenheit values (from Home Assistant or the thermostat set point) into "fake Celsius" values by doing the following:
   1. Round to the nearest integer degree Fahrenheit.
   2. Subtract the set point (in Fahrenheit).
   3. Divide by two.
   4. Add the (correct) Celsius equivalent of the set point.

This effectively rescales the "Celsius" values in the protocol to exactly map onto integer Fahrenheit values, keeping it centered around the correct Celsius value in case the ESPHome device dies or control otherwise reverts to the air handler's thermistor. This means that there are no Fahrenheit values that are inaccessible or duplicated in what can be represented, allowing a smoother user experience. Additionally, because there are 0.9°F per 0.5°C, for temperatures near the set point, the total error will be minimal. (And presumably either the temperature is near the set point, or the heat pump will be working at full - or no - power regardless, so the discrepancy is unlikely to matter.) Additionally, if the ESPHome device is removed, control reverts to the air handler with the nearest possible Celsius value anyway, so the correct behavior is preserved.

This feels bad, in that it's reporting the "wrong" values to the heat pump, at least according to the reverse-engineered protocol, but I suspect the user experience may be better. Fahrenheit thermostats (including my Mitsubishi one in Fahrenheit mode) typically allow only integer selections, and each integer would be meaningfully represented in the rescaled option, with no large jumps in reported values. Additionally, there will generally not be other systems involved between the ESPHome and heat pump, or otherwise talking to the heat pump that could be confused by the rescaled approach, so the side effects should be minimal. The heat pumps have some features that are affected by the absolute temperature delta (for example, the balance point), but that discrepancy should be minimal (approximately 0.4° Fahrenheit over the full range of balance point failure, which cannot be accurately represented via half-degrees Celsius anyway).

Working through the end effects of the two options leads me to lean towards the rescaled approach as providing a better experience, though it may be a somewhat more intense change than I was initially expecting when I thought the Celsius-native option was better.

(This does mean the Fahrenheit mode would be 0.1°F less granular in temperatures reported to the heat pump from a Home Assistant sensor, meaning a very slightly wider temperature swing, but I would personally take that tradeoff.)

[samphonic]

Some sample tables. First column is what the unit is actually set to, second is what the thermostat would display when this is the current temperature, third is what you'd have to set on the thermostat to get that value on the unit, fourth is the actual temperature in F (that other temperature sensors would be showing).

Mitsubishi Table

Heat Pump	Therm Display	Therm Set	Actual F
17.5	64	64	63.5
18	65	65	64.4
18.5	66	66	65.3
19	67		66.2
19.5	67	67	67.1
20	68	68	68
20.5	68		68.9
21	69	69	69.8
21.5	70	70	70.7
22	71	71	71.6

"Celcius-native"

Heat Pump	Therm Display	Therm Set	Actual F
17.5	64		63.5
18	64	65	64.4
18.5	65	66	65.3
19	66		66.2
19.5	67	67	67.1
20	68	68	68
20.5	69		68.9
21	70	69	69.8
21.5	71	70	70.7
22	72	71	71.6

I tried to follow your formula for "rescale everything" but it always resulted in any setpoint being converted to the current temperature; so either I misunderstood or there's an issue. E.g.
Current temp is 68F
Setpoint is 71F
i. 71 rounded to nearest integer is 71
ii. 68-71 is -3
iii. -3 / 2 = -1.5
iv. 21.666 + -1.5 = 20C

I kinda see what you're going for there though in terms of a distorted scale centered around the current (? or setpoint?) temperature. So potentially something like this:

"Rescale everything" current temp 20C/68F

Heat Pump	Therm Display	Therm Set	Actual F
17.5	63	63	63.5
18	64	64	64.4
18.5	65	65	65.3
19	66	66	66.2
19.5	67	67	67.1
20	68	68	68
20.5	69	69	68.9
21	70	70	69.8
21.5	71	71	70.7
22	72	72	71.6
22.5	73	73	72.5
23	74	74	73.4
23.5	75	75	74.3

Current temp 75.2F

Heat Pump	Therm Display	Therm Set	Actual F
23.5	74	74	74.3
24	75	75	75.2
24.5	76	76	76.1
25	77	77	77

There still ends up being some discrepancy between the thermostat F and actual F even at the setpoint, but it does avoid skipped/duplicate values.

---

There's still some issues, like if it was currently 68 and you set the thermostat to 75, it would set the heatpump to 23.5. As that temperature approached though, your setpoint would actually change to 74. If you actually wanted it to be 75, you'd either have to set it to 76 initially knowing that it will change, or after the heatpump shutoff at 74, go back and tell it "no, really, I wanted 75".

This is only an issue if you start looking at changes of greater than a few degrees, but that's probably a fairly common usecase for switching from unoccupied to occupied, or e.g. returning from vacation or something.

[aschmitz]

I suspect the confusion may be coming from confusion on whether the "rescale everything" idea is centered around the current temperature or the set point: I was centering it on the set point.

Let's assume a pair of functions, realFtoMitsuC and mitsuCtoRealF that convert from an actual Fahrenheit value to a Mitsubishi Celsius value that the thermostat shows as the same Fahrenheit value (for example, realFtoMitsuC(70) = 21.5), from a Mitsubishi thermostat's Celsius value to a real Fahrenheit value (mitsuCtoRealF(21) = 69). Then also define realCtorealF to convert from a Celsius to a Fahrenheit value using the standard (x * 9 / 5) + 32 formula.

We also have setC and setF to track the set point in the two scales, and currentC and currentF to track the current temperature in the two scales.

That would look something like this, (for a 70°F set point, set in the thermostat in Fahrenheit mode):

• We read 21.5 C from the thermostat for the set point, and convert that and save it as setF = mitsuCtoRealF(21.5) = 70. (Alternatively, we get input to set the climate entity to 70 F from Home Assistant or some other ESPHome component and set setF to that value, in which case we don't need the mitsuCtoRealF conversion.)
• We convert 70 F back to Celsius as 21.1 C, so we store setC = 21 (the nearest half-degree Celsius).
• We tell the heat pump that the set point is setC (21).
• If we receive a thermometer reading...
  • From the thermostat, report the thermostat's sensor value as mitsuCtoRealF(reading). If the temperature source is the thermostat, we also set currentC to the reading in Celsius, and currentF = mitsuCtoRealF(currentC). (I think this is the right move? The idea is that the thermostat probably uses Celsius internally, and reports it correctly over the wire but shows the "wrong" Fahrenheit value. This means we report the correct Celsius temperature, and show a Fahrenheit temperature that matches the thermometer in HA.)
  • From the heat pump internal thermometer, set currentC to the thermometer value, and currentF = realCtoRealF(currentC).
  • From another configured sensor (via ESPHome), set currentF = realCtoRealF(reading) (if it's already in Celsius, or I suppose just take a Fahrenheit temperature), and currentC = (setF - currentF) / 2 + setC. (This is the actual rescaled value with setF as the center: the other temperature sources are just being selective about which conversion to use where.)
• When reporting the current temperature to the heat pump, send currentC.
• When reporting the set point to the heat pump, send setC.
• When reporting the current temperature to the thermostat, send realFtoMitsuC(currentF).
• When reporting the set point to the thermostat, send realFtoMitsuC(setF).

So with a 70 F set point, with temperatures reported by the heat pump, we'd have:

Heat Pump Internal	Real F	realFtoMitsuC(currentF)	Thermostat Display
17.5	63.5	17.5	64
18	64.4	17.5	64
18.5	65.3	18	65
19	66.2	18.5	66
19.5	67.1	19.5	67
20	68	20	68
20.5	68.9	21	69
21	69.8	21.5	70
21.5	70.7	22	71
22	71.6	?	72
22.5	72.5	?	73
23	73.4	?	73
23.5	74.3	?	74

With temperatures reported by another sensor, we'd have:

Therm Display & Sensor	Therm Report	currentF	Report to Heat Pump
63	?	63	17.5
64	17.5	64	18
65	18	65	18.5
66	18.5	66	19
67	19.5	67	19.5
68	20	68	20
69	21	69	20.5
70	21.5	70	21
71	22	71	21.5
72	?	72	22
73	?	73	22.5
74	?	74	23

(In particular, we'd report 70 F, the set point, to the heat pump as 21 C because it's the closest half-degree to the set point, and then every degree F up or down as 0.5 degrees C up or down.)

[samphonic]

Okay, that would make things more consistent at least; so in short:

• The F setpoint (from HA or via lookuptable from thermostat) is converted as directly as possible to an internal C setpoint (hidden from users of HA or the thermostat).
• Any current temperature report would be taken at face value, but sent via lookuptable to the thermostat to force it to show the nearest accurate F temperature (because potentially otherwise the F setpoint would be rendered as a different value, like set=70 would show temperature reached at 69 on the thermostat).

A couple thoughts:

• If the thermostat is being used as a temperature source, I don't know if we can feed it current temperatures or if it'll just directly report its own temperature. This wouldn't affect setpoints or the unit, but means that the thermostat might read currently 69 when everything else thinks its 70.
• Certainly a lot of users are unhappy about the Fahrenheit weirdness so I don't want to dissuade anyone from implementing this, but: it might be worth circling back at least once to doublecheck what issue is being solved to see if there isn't something less complicated that might suffice. Is the issue that the thermostats don't allow fine enough control over the temperature? A mismatch between sensors?

[aschmitz]

Yep, that matches what I was thinking.

Double-checking the thermostat behavior is a good idea, although perhaps tricky. I think it will be fine, because the thermostat seems to display whatever it's told the temperature is via the protocol, rather than its internal temperature. Or at least that's the case on my PAC-SDW01RC-1, I'm not sure what the MHK2 does. (Given that the temperature source can be defined as an average of the thermostat and air handler temperatures via a function code, and the air handler temperature is never reported directly, I imagine the MHK2 does the same thing, but it would be good to verify with someone who has one.)

Thinking about a simpler solution is probably worthwhile too, although none has come to mind. My main issues are (in descending order of annoyance):

1. There are some temperature values that are hard to set given the thermostat's bad conversions. In particular, setting the thermostat to 69 F sets a value of effectively 70 F, while setting it to 68 F sets it to 68 F. It is not possible to set the temperature to 20.5 C, or effectively 69 F. This is true even setting the temperature via Home Assistant, as it appears as though the thermostat(?) rounds and re-sets the number, although of course I would like to be able to set it via the thermostat too.
2. The temperature reported via the thermostat and Home Assistant is often different, which requires me to remember which value I should be expecting in each location.
3. Setting the temperature in Home Assistant is relatively nonlinear: the step above 70 F is 70.5 F, then 71.5 F, and keeping track of which values are acceptable requires either memorizing the "real" steps or doing the conversions back to Celsius.
4. Probably least important but still annoying is that if I'm tracking the temperature and wondering what value will make the heat pump turn on, I need to convert to Celsius, round to the correct half-degree, and then convert back to Fahrenheit, rather than knowing that "the set point minus half a degree" will do it.

I suspect the "Celsius-native" option would resolve items 1 and 2, though not 3 or 4. Rescaling, on the other hand, seems like it should resolve all of them.