Internal temperature always reports 22°C

svmaris commented 3 months ago

I have four units (3xMSZ-HR25VF and 1xMSZ-HR50VF) and I have been running the integrations from both geoffdavis and echavet on a Wemos D1 mini for a couple of weeks before switching to this one.

For the unit in my living room, I'm using an external thermostat (a sensor in Home Assistant) and that seems to be working fine. For the other units, I'm using the internal temperature and that doesn't seem to be working. On both the dev and june-improvements branches the "Current Temperature" is stuck at 22°C. Since the thermostat was working on the components from geoffdavis and echavet, either my config is wrong, or I'm running into a bug.

my config (the relevant part):

external_components:
  - source: github://muart-group/esphome@june-improvements
    components: [ mitsubishi_itp ]

logger:
  baud_rate: 0

uart:
  id: hp_uart
  baud_rate: 2400
  parity: EVEN
  tx_pin: 1
  rx_pin: 3

climate:
  platform: mitsubishi_itp
  uart_heatpump: hp_uart
  update_interval: 5s

Extended connect response:

[07:01:14][C][mitsubishi_uart:115]: Discovered Capabilities: Extended Connect Response: [FC.7B.01.30.10]C9.03.00.20.00.14.07.F1.84.25.A0.BE.94.BE.A0.BE 95
 HeatDisabled:No SupportsVane:Yes SupportsVaneSwing:Yes DryDisabled:No FanDisabled:No ExtTempRange:Yes AutoFanDisabled:No InstallerSettings:No TestMode:No DryTemp:Yes StatusDisplay:Yes
 CoolDrySetpoint:16.000000/31.000000 HeatSetpoint:10.000000/31.000000 AutoSetpoint:16.000000/31.0000

If there's anything else I can do to help diagnose this issue, please let me know.

Sammy1Am commented 3 months ago

Thanks for all the info!

Could you also take a look in the logs for the "Current Temp Response" packet? Should look something like: [07:37:20][V][mitsubishi_uart:201]: Processing Current Temp Response: [FC.62.01.30.10]03.00.00.0A.00.00.A9.00.00.00.00.00.00.00.00.00 A7 Temp:20.500000

Mitsubishi has two different ways to handle temperature and we've run into issues in the past where certain equipment does something different than we're expecting.

svmaris commented 3 months ago

For some reason this doesn't show up in my logs. Do I need to change verbosity?

[07:43:47][I][app:100]: ESPHome version 2024.5.5 compiled on Jun 17 2024, 06:14:14
[07:43:47][C][wifi:580]: WiFi:
[07:43:47][C][wifi:408]:   Local MAC: BC:DD:C2:78:89:8C
[07:43:47][C][wifi:413]:   SSID: [redacted]
[07:43:47][C][wifi:416]:   IP Address: 192.168.86.77
[07:43:47][C][wifi:419]:   BSSID: [redacted]
[07:43:47][C][wifi:421]:   Hostname: 'airco-roos'
[07:43:47][C][wifi:423]:   Signal strength: -57 dB ▂▄▆█
[07:43:47][C][wifi:427]:   Channel: 6
[07:43:47][C][wifi:428]:   Subnet: 255.255.255.0
[07:43:47][C][wifi:429]:   Gateway: 192.168.86.1
[07:43:47][C][wifi:430]:   DNS1: 192.168.86.20
[07:43:47][C][wifi:431]:   DNS2: 0.0.0.0
[07:43:47][C][logger:185]: Logger:
[07:43:47][C][logger:186]:   Level: DEBUG
[07:43:47][C][logger:188]:   Log Baud Rate: 0
[07:43:47][C][logger:189]:   Hardware UART: UART0
[07:43:47][C][uart.arduino_esp8266:118]: UART Bus:
[07:43:47][C][uart.arduino_esp8266:119]:   TX Pin: GPIO1
[07:43:47][C][uart.arduino_esp8266:120]:   RX Pin: GPIO3
[07:43:47][C][uart.arduino_esp8266:122]:   RX Buffer Size: 256
[07:43:47][C][uart.arduino_esp8266:124]:   Baud Rate: 2400 baud
[07:43:47][C][uart.arduino_esp8266:125]:   Data Bits: 8
[07:43:47][C][uart.arduino_esp8266:126]:   Parity: EVEN
[07:43:47][C][uart.arduino_esp8266:127]:   Stop bits: 1
[07:43:47][C][uart.arduino_esp8266:129]:   Using hardware serial interface.
[07:43:47][C][uptime.sensor:031]: Uptime Sensor 'Airco Roos Uptime'
[07:43:47][C][uptime.sensor:031]:   Device Class: 'duration'
[07:43:47][C][uptime.sensor:031]:   State Class: 'total_increasing'
[07:43:47][C][uptime.sensor:031]:   Unit of Measurement: 's'
[07:43:47][C][uptime.sensor:031]:   Accuracy Decimals: 0
[07:43:47][C][uptime.sensor:031]:   Icon: 'mdi:timer-outline'
[07:43:47][C][homeassistant.time:010]: Home Assistant Time:
[07:43:47][C][homeassistant.time:011]:   Timezone: 'UTC0'
[07:43:47][C][version.text_sensor:021]: Version Text Sensor 'Airco Roos ESPHome Version'
[07:43:47][C][version.text_sensor:021]:   Icon: 'mdi:new-box'
[07:43:47][C][restart.button:017]: Restart Button 'Restart Airco Roos'
[07:43:47][C][mitsubishi_uart:115]: Discovered Capabilities: Extended Connect Response: [FC.7B.01.30.10]C9.03.00.20.00.14.07.F1.84.25.A0.BE.94.BE.A0.BE 95
 HeatDisabled:No SupportsVane:Yes SupportsVaneSwing:Yes DryDisabled:No FanDisabled:No ExtTempRange:Yes AutoFanDisabled:No InstallerSettings:No TestMode:No DryTemp:Yes StatusDisplay:Yes
 CoolDrySetpoint:16.000000/31.000000 HeatSetpoint:10.000000/31.000000 AutoSetpoint:16.000000/31.0000
[07:43:47][C][captive_portal:088]: Captive Portal:
[07:43:47][C][web_server:173]: Web Server:
[07:43:47][C][web_server:174]:   Address: airco-roos.local:80
[07:43:47][C][mdns:115]: mDNS:
[07:43:47][C][mdns:116]:   Hostname: airco-roos
[07:43:47][C][ota:096]: Over-The-Air Updates:
[07:43:47][C][ota:097]:   Address: airco-roos.local:8266
[07:43:47][C][ota:100]:   Using Password.
[07:43:47][C][ota:103]:   OTA version: 2.
[07:43:47][C][api:139]: API Server:
[07:43:47][C][api:140]:   Address: airco-roos.local:6053
[07:43:47][C][api:142]:   Using noise encryption: YES
[07:43:47][C][wifi_info:011]: WifiInfo SSID 'Airco Roos SSID'
[07:43:47][C][wifi_info:012]: WifiInfo BSSID 'Airco Roos BSSID'
[07:43:47][C][wifi_info:009]: WifiInfo IPAddress 'Airco Roos IP'
[07:43:47][C][wifi_signal.sensor:009]: WiFi Signal 'Airco Roos WiFi Signal'
[07:43:47][C][wifi_signal.sensor:009]:   Device Class: 'signal_strength'
[07:43:47][C][wifi_signal.sensor:009]:   State Class: 'measurement'
[07:43:47][C][wifi_signal.sensor:009]:   Unit of Measurement: 'dBm'
[07:43:47][C][wifi_signal.sensor:009]:   Accuracy Decimals: 0
[07:43:48][D][api.connection:1321]: Home Assistant 2024.6.2 (192.168.86.20): Connected successfully
[07:43:48][D][time:050]: Synchronized time: 2024-06-17 07:43:48
[07:43:51][W][component:237]: Component mitsubishi_itp.climate took a long time for an operation (73 ms).
[07:43:51][W][component:238]: Components should block for at most 30 ms.

(... repeats of the last two lines with the occasional sensor update ...)

So it looks like the 22°C is just the last thing Home Assistant registered from when it was still working. I initially configured all units to sync to the same external HA temperature sensor, so that's probably why they all report the same value.

Sammy1Am commented 3 months ago

Ah, sorry, yes, logs should be VERBOSE for that line. Something like:

logger:
  level: VERBOSE
  logs:
    sensor: WARN

svmaris commented 3 months ago

It really does seem to think it's a constant 22°C 🤔

[09:43:12][V][muart_bridge:040]: Sending to heatpump [FC.42.01.30.01]03 89
[09:43:12][V][muart_bridge:016]: Parsing 62 heatpump packet
[09:43:12][V][mitsubishi_uart:201]: Processing Current Temp Response: [FC.62.01.30.10]03.00.00.0C.00.A2.AC.AC.00.42.00.01.FC.3D.00.00 D8
 Temp:22.000000

svmaris commented 3 months ago

I've monitored the Current Temp Responses over a longer period while turning the unit on and off (cooling/heating) to see how it affects the returned data.

[11:44:52][V][mitsubishi_uart:201]: Processing Current Temp Response: [FC.62.01.30.10]03.00.00.0C.00.A8.AC.AC.00.42.00.01.FC.4E.00.00 C1

It looks like it's currently picking PLINDEX_CURRENTTEMP (index 6), which is AC in all my log lines. If I read the code correctly, this corresponds to 22°C (as (0xAC - 128) / 2 = 22). The field that is changing however, is at index 5 (0xA2 in my previous comment and 0xA8 in the log line above).

I'm not sure how accurate these readings are, because they seem to fluctuate a bit, but they're closer to the actual temperature. The number seems to go up when I set it on "heat" and goes back down again when I set it to "cool".

I've checked the code of the SwiCago lib and echavet's component and they both seem to do the same thing: picking data[6] as the room temperature 🤷

svmaris commented 3 months ago

Update: I've switched back to echavet's component and it now also consistently reports 22°C. I'm now seriously doubting myself if it ever worked correctly after I switched from MELCloud to esphome, so let's forget about that. The room temperature is still wrong, but at least it's consistent with the other components, including SwiCago.

... or something really weird has happened that made the unit believe it's 22°C all the time. When I started with this component, I briefly had the same config on all four units, so they were all synced to the same external temperature sensor in HA. After that, I've removed it from the config for three of the units in order to switch back to the internal thermostat. I know it sounds far-fetched, but could that have anything to do with it?

svmaris commented 3 months ago

Another update: It's definitely related to the fact that I (temporarily) configured an external temperature source in the past.

I've just added an external source and then switched back again to the internal source and now it continuously reports 22.5°C as the current temperature.

I can't find the relevant code in this component, but looking at SwiCago, I see the following snippet:


              if(data[6] != 0x00) {
                int temp = data[6];
                temp -= 128;
                receivedStatus.roomTemperature = (float)temp / 2;
              } else {
                receivedStatus.roomTemperature = lookupByteMapValue(ROOM_TEMP_MAP, ROOM_TEMP, 32, data[3]);
              }

Could it be that my heatpump is supposed to get it's current temp using the lookupByteMapValue() function, but is returning data[6] because the value of the external sensor is persisted in there?

If that's the case, data[6] probably just has to be reset to 0x00. I've tried that by letting the lambda filter for the external sensor just return 0, but that doesn't seem to work.

Sammy1Am commented 3 months ago

Well that's puzzling for sure.

You're definitely on the right track. As you've found, because data[6] isn't 0, the code is assuming that is the correct temperature. I have something to try below that might reset that. However if data[6] is 0, the code is going to use data[3] as the legacy temperature (using lookupByteMapValue()), and 0x0C still corresponds to 22° (in the two logs you showed before).

data[5] is as far as we know the "Outdoor Unit Temperature". So I don't know exactly what's going on. When you say you "added an external source", what process are you following for that? You may already be doing this, but just in case here's what I would try:

In your ESPHome config, add a sensor:

sensor:
  - platform: template
    id: fake_temp
    name: "Fake Temperature"
    lambda: |-
      return 24.5;

and then add it to the Mitsubishi ITP section:

climate:
  - platform: mitsubishi_itp
    temperature_sources:
      - fake_temp
    ...

This should give you a "Temperature Source" select menu available in Home Assistant. Switch to Fake Temperature, and presumably the temperature will show 24.5°. Switching back to "Internal" will send a packet to the heat pump that should tell it to use its internal sensor. See if that fixes things.

This might already be what you're doing with the "external source", but just want to confirm so we're on the same page. I'm not sure I've seen data[5] have a value before, so this is definitely interesting.

svmaris commented 3 months ago

Yeah, that's exactly what I did to add the external source, but I'll do some more experimenting with it. Not sure if I updated the "Temperature Source" select option for example.

The reason I mentioned data[5] is because that's the only value that seemed to react to the cooling/heating (moving up and down), but that could easily be coincidental as the outside temperature was going up or down or something.

The other values that I saw changing looked like it was just going up every minute (like some sort of timer) and the last byte, which I assume is a checksum.

I'm not sure if my unit is supposed to use data[6] or data[3], but I'm determined to figure it out 😆

I'll go down this rabbit hole and report back if I find anything interesting.

svmaris commented 3 months ago

Yeah, switching it to the fake_temp source and back again to Internal fixed the issue. Thanks for the final piece of the puzzle!

So, this is kind of a weird edge-case, but it looks like the reported room temperature of the heatpump can get stuck at some fixed value when:

You add a temperature source to the config
Set the heatpump to use that sensor
Remove the sensor from the config and reflash

Now it is impossible to get the heatpump to report the correct temperature, unless:

You re-add a temperature sensor to the config (doesn't have to be the same one, a fake one works just fine)
Set the heatpump to use that sensor (it's on Internal by default)
Set the heatpump back to the Internal temperature
(optional) Remove the sensor/source from the config and reflash

If it's possible to send the "Use internal thermostat"-signal to the heatpump on boot when there's no other temperature source(s) defined might prevent other people from running into the same problem.

Thank you for your patience!

Sammy1Am commented 3 months ago

Hooray! But also weird. My experience with my MSZ-GL06NA has been that if no new remote temperature packet was sent, after 10 minutes the unit will automatically revert to using the internal temperature. (i.e. I see the behavior you do where the current temperature is stuck, but then after 10 minutes it just switches to internal and unsticks)

I think your suggestion of sending "Use Internal" on boot is probably good idea-- I can't immediately think of any reason why this would cause problems for anyone. I'll leave this issue open to track that fix.

As you continue in your testing though, if you could do us a favor: If you convert the values in data[5] to Celsius using the same formula as data[6], do they seem to be reasonable values for the outdoor temperature? The first two values you shared seem to be 17° and 20°, which seem like a bit of a big fluctuation, but it's possible the sensor is being heavily affected (maybe intentionally) by the coils on the compressor. Though if this were the case I would expect the temperature to get warmer when you're using "cool" mode and colder when using "heat".

If they seem like reasonable outdoor values, I'll probably go ahead and add that as a sensor (we just haven't had a unit that supports that to test on yet).

svmaris commented 3 months ago

Yeah, my MSZ-HR25VF doesn't seem to do that automatically. As you can see in the HA graph a few comments up the unit was blasting on 18°C all night because it kept thinking it was still 22°C in the room. And I definitely had no other Temperature Sources configured.

As for data[5]: According to my other thermostat (the one provided by my central heating), the outside temperature is 22°C right now (my lucky number). I've set the unit to cool at max capacity (16°C, fan on max) for a couple of minutes. Then, I switched it to heating (31°C, fan on max) for a couple of minutes. data[5] is pretty consistently reporting AA (21°C) with the occasional A8 (20°C), so I'd say it is pretty accurate and doesn't seem to be affected too much by what the unit is doing. I haven't seen anything else in between, so it looks like the outside thermostat has a precision of 1°C.

I can test this for a longer period and compare it to the readings of my other thermostat, but then I would need the sensor configured in the component. If you have a branch or patch I could run to help test this, please let me know.

Sammy1Am commented 3 months ago

Okay, so I just pushed https://github.com/muart-group/esphome/commit/14e75bbddf842f2c81f49f5faa6659733fe33064 to the june-improvements branch that adds an Outdoor Temperature sensor. I can only test what happens on systems that don't have a value there, so please let me know if it works okay for you (should help provide a graph in HA though to make sure it's matching outdoor temp).

I made a note in #44 to preemptively send an Internal Temperature packet when we only have the one source; there might be some other refactoring so I'll just keep it all together over there.

Closing this issue for now since your temperature is unstuck, but definitely please let me know if Outdoor Temperature is working successfully.

svmaris commented 3 months ago

Thanks @Sammy1Am, I've installed the latest version on all my units and started tracking the outside temperature in Grafana:

Some preliminary findings:

None of the units are reporting the same value.
None of the units are reporting the same value as my central heating thermostat (it's called "Outside" in the chart, the green line). No idea how accurate it is though.
There are big differences between the units. The weird thing is that the two units that show the biggest difference (17°C compared to 25°C) are right next to each other on the same side of the house.
airco_woonkamer (reporting 17°C) is currently on cooling mode, the rest of the units are turned off

I'll keep monitoring them for a couple of days, but either the sensor is really inaccurate or it's not really the outside temperature. Maybe it's some kind of internal gas/fluid temperature.

svmaris commented 3 months ago

Looks like the sensor for the outdoor temperature is not sent to HA correctly:

[13:17:57][V][mitsubishi_uart:201]: Processing Current Temp Response: [FC.62.01.30.10]03.00.00.0B.00.A4.AB.AB.00.42.00.01.FF.2D.00.00 E6
 Temp:21.500000 Outdoor:18.000000
[13:17:57][I][mitsubishi_uart:203]: Outdoor temp differs, do publish
[13:17:57][V][sensor:043]: 'Outdoor Temperature': Received new state nan
[13:17:57][D][sensor:093]: 'Outdoor Temperature': Sending state nan °C with 1 decimals of accuracy

Only the initial state of the sensor is published correctly, after that I only get NaN's.

I think this is because you directly update state instead of raw_state.

Sammy1Am commented 3 months ago

Yup, that would do it. Got confused looking at the binary sensors instead.

Should be fixed, thank you.

svmaris commented 3 months ago

I've installed the latest @dev branch on all my units and I can confirm the sensor now gets updated correctly. Thanks for the fix!

Now, as for the results... this is my reference graph, the outdoor temperature as measured by my central heating unit:

The indoor temperature as reported by esphome for all units:

And finally, the outdoor "temperature" (data[5]):

Some observations:

Only unit "Woonkamer" is turned on, as you can see on the second image (the squiggly line)
The real outdoor temperature has steadily increased from 16°C to 18°C over the last couple of hours
The indoor temperature for the units that are not active also steadily increases by a couple of degrees
The reported outdoor temperature for the inactive units don't change at all
The outdoor temperature for the active unit is all over the place, ranging from 16°C to 26°C

I'm starting to think that data[5] isn't a temperature value at all, because:

They don't seem to react on changes in the environment
Only change when the unit is active, but even then the reported values don't seem to be correlated to a temperature
It's a different precision (1°C) compared to the inhouse temp (0.5°C)

svmaris commented 3 months ago

I just noticed that the heat pump switched to "inactive":

This also stabilizes the outdoor sensor:

svmaris commented 3 months ago

🤔

KazWolfe commented 3 months ago

Out of curiosity, do all of your units report outdoor temperature sensor support in your 7B? (Byte 9, flag 0x20).

This flag came from the JP mobile app and was tested to be Mostly Correct:tm: on my NA units, but it's possible that there's some weird quirk for EU/AUS units.

Given these units tend to generate quite a noticeable temperature change in their immediate surroundings by virtue of their purpose, I wouldn't be surprised if the temperature readouts aren't particularly accurate. This almost seems correlated by the fact that they only move in 1 degree Celsius increments (something I've noticed on NA units as well), and the fact that this isn't really used anywhere either.

svmaris commented 3 months ago

@KazWolfe I assume you refer to the extended connect stuff, right? I've just checked all units and they all report the same value:

[FC.7B.01.30.10]C9.03.00.20.00.14.07.F1.84.25.A0.BE.94.BE.A0.BE 95

All my units are from the same series. The only difference is the capacity (2.5kW vs 5kW).

For some reason one of my units started reporting 0x01 for a couple of minutes (which translates to -63.5°C).

The reason I'm doubting we're looking at some temperature related to the outdoor unit is the fact that the value doesn't change at all when the unit is inactive (it doesn't even have to be turned off completely). One of them kept reporting a consistent 20°C all night, while the actual outdoor temperature was about 10°C.

Sammy1Am commented 3 months ago

-63.5°C weirdness aside, the purpose of the sensor is probably to help systems with defrost/auxiliary heat, so it might only be needed when the system is running. I.e. I don't know if this value was ever supposed to be shown to end users anyway.

KazWolfe commented 3 months ago

I suspect something similar - this is some semi-diagnostic sensor that we're exposing because we can.

Strangely though, I cannot reproduce this on my unit - even with it off, it tracks properly. I don't think I've ever seen it as 0x01, but I'll look more. It's very possible this field is overloaded, is different per-region, or is just something else we don't fully understand yet.

svmaris commented 3 months ago

Yeah, I think so too. Doesn't look like the sensor provides any useful information for the end user, although it would be nice to get a complete spec of the protocol eventually.

In any case, I'll keep monitoring it until you decide to remove it 😊

If there's anything else I can do to help, please let me know.

Thanks!

svmaris commented 3 months ago

For some reason the reported value seems to stabilize. This is the "real" outdoor temperature and the reported value from the unit for the last 48h:

And, for completeness, the indoor temperatures (target + current):

The indoor unit is turned off automatically by a HA automation at midnight and the turned on again at 5:30PM. It reports 0x01 during the night, but when it's active the reported temperature seems to be pretty accurate (going up during the day, going down at night, pretty consistently 1 or 2 degrees above what my central heating was reporting). No clue what happened the first day though, because the values were all over the place.

KazWolfe commented 3 months ago

For posterity, here's my own log with my heat pump/outdoor sensor:

It looks like yours also mostly follows this behavior, but interrupts at odd cases. I don't yet have a good explanation for why your unit is doing this, though I'll definitely try to experiment more with my units to see what's going on with them.

Regarding your temperature jump, is your system purely the ESP or do you have a thermostat or other control unit connected?

We've seen that certain units will "fall out" of auto mode in favor of a thermostat offering its own dual setpoint support.

As a general note for cleanliness, can you please create a new issue for each individual problem you have so that we can track them accordingly.

svmaris commented 3 months ago

After monitoring the outdoor temperature for a couple of days it definitely looks like it's pretty much consistent with reality. The only difference being that my unit is returning 0x01 when it's not active/turned off.

I'll leave it up to you to decide if the sensor is valuable enough to keep around :)

For the record: My system is purely the ESP indeed. I started with MELCloud and the "official" wifi module on the CN105, but switched to esphome when they messed up their API for the third time in a row (TLS issues, rate limiting issues, etc.).

Three of my units are using the internal thermostat, for the fourth one I'm using another sensor in HA as temperature source.

I do have an issue with that, though, because the unit keeps switching back to the internal thermostat by itself. Sometimes after 7 minutes (which I know is the default "time-out" for additional temp sources), sometimes after 10 or 20 minutes... and it does not switch back automatically. I'll do some investigation and will open a new issue once I get some more details.

Unless you want me to do some further digging, you can probably go ahead and close this issue.

paravoid commented 3 months ago

I do have an issue with that, though, because the unit keeps switching back to the internal thermostat by itself. Sometimes after 7 minutes (which I know is the default "time-out" for additional temp sources), sometimes after 10 or 20 minutes... and it does not switch back automatically. I'll do some investigation and will open a new issue once I get some more details.

You may already be aware of this and your issue may be entirely unrelated, but just in case you've missed it, the documentation has this warning: "_IMPORTANT: This component does not poll the sensors explicitly, but rather subscribes to update events on the sensors. If no updates have been received for 7 minutes, the equipment will be switched back to its internal temperature sensor. This means that even if the temperature hasn’t changed, the sensors need to publish updates. This may require the use of e.g. force_update: true to make sure updates are sent regularly._"

svmaris commented 3 months ago

@paravoid Thanks for this! I was not aware of the (updated) documentation, but I found it. The old docs on the muart-group website do mention the "7 minutes" part, but are missing the rest. This is probably exactly what I'm running into, as the current temperature obviously doesn't change every 7 minutes.

I find the docs about force_update: true a bit confusing. There's the force_update flag on the esphome sensor:

- platform: homeassistant
    id: woonkamer_temperature
    name: "Woonkamer Temperature Sensor"
    entity_id: sensor.inhouse_temperature
    force_update: true
    filters:
      - lambda: return x;

Which (obviously?) doesn't work, because this is not a sensor that publishes state changes from some internal component to Homeassistant, but a sensor that provides updates to esphome based on an sensor defined in HA. (Correct my if I'm wrong, I'm new to the whole esphome stuff).

So this probably means that my source sensor (sensor.inhouse_temperature) should have force_update: true on the HA-side, but that totally depends on the integration if such an option is available.

So, would it be fair to say that the preferred way of getting this to work semi-reliably is to set-up the service in esphome and let Home Assistant publish the current temperature with an Automation that fires every minute for example?

Sammy1Am commented 3 months ago

You are correct, the force_update would need to be on the sensor itself so that Home Assistant will correctly trigger actions/publish values often enough.

So, would it be fair to say that the preferred way of getting this to work semi-reliably is to set-up the service in esphome and let Home Assistant publish the current temperature with an Automation that fires every minute for example?

More or less, yes. I was able to set force_update on my sensors, so I have an automation that publishes the value to a service triggered by the forced updates.

The danger with just publishing every minute is that if the sensor breaks (runs out of battery, etc.) the ESP/heat pump will potentially keep thinking Heat or Cool is needed forever. You could probably add a check in the automation to make sure the value has changed at least in the last 30-60min or something just to make sure the sensor is still working (and stop publishing values if it's not so the unit can fall back on the internal sensor).

muart-group / esphome

Internal temperature always reports 22°C #45