Remote temperature timeout when temperature isn't changing

[homegreen]

Hi,

This may be more of a HomeAssistant question, but I figured I'd ask here because it's highly related to this functionality.

I recently got some Shelly temperature sensors, and have them setup with my cn105 through HomeAssistant. This mostly works great, except for one problem:

HomeAssistant doesn't record a value when the temperature probe reports an identical value multiple times in a row (when the temperature isn't changing at all). So I have periods where the HomeAssistant data shows no updates for 30-60 minutes, and so the cn105 remote temperature times out.

I enabled debug logging in HomeAssistant for the shelly integration and I can see that the probe is sending updates every 10 minutes or so in these periods. But the cn105 consistently gets a remote temperature timeout because HomeAssistant isn't sending the same value again.

Has anyone run into this, or found a way to work around it?

[phidauex]

Hmm, in my experience it is a bit of a balance between what kind of failure mode you want to most protect against. You could extend the timeout time longer, but you run a greater risk over overheating or overcooling if the sensor fails. A shorter timeout is safer in that sense, but yes, a delayed update from the sensor, or very stable temperatures in the air, could mean that it reverts to the internal sensor unexpectedly (though it would go back to the external sensor on the next update, and if room temperature is that stable anyway, then it wouldn't be likely to actually cause a problem).

One thing to test might be to try calling the update_entity action from HA Developer Tools, and see if that forces an update on the ESP device. If so, then you could potentially just have an automation force that action every 20 minutes if the value hasn't changed. Some integrations may support the force_update option which does the same thing, but can clog up the database.

I'm a bit leery about it, because of of the failure modes I've had on some zigbee sensors is that they will continue reporting values, but always at a stuck temperature value. So in my case I want the timeout to revert to the internal sensor in that case, even if it means it does it more often than it needs to.

[homegreen]

though it would go back to the external sensor on the next update, and if room temperature is that stable anyway, then it wouldn't be likely to actually cause a problem

In my case, there's a 1-2 degree (fahrenheit) constant offset in the two temperatures, because the mini-split unit is mounted on an exterior wall, so it ends up being a little bit colder than the remote sensor most of the time

then you could potentially just have an automation force that action every 20 minutes if the value hasn't changed

I think that's functionally the same as removing the timeout entirely.

I've been doing a lot of reading on the topic, and apparently there's now a mechanism in HA to handle this (see https://developers.home-assistant.io/blog/2024/03/20/state_reported_timestamp/), but it doesn't appear that the HA esphome integration uses it (yet). And I don't think it's possible to write an automation that uses last_updated either.

One ugly hack I could consider is modifying the shelly HA integration so that everytime it ingests a new temperature reading, it adds a very small random value to it, like between 0.0001-0.0100, just to make the value different everytime so the update isn't filtered out.

[theflu]

I use last_updated in my automations for this.

alias: Dining Room revert Remote Temp
description: Revert back to internal temp if remote temp hasn't updated in 5 min
triggers:
  - minutes: /5
    seconds: "00"
    trigger: time_pattern
conditions:
  - condition: template
    value_template: >-
      {{
      (as_timestamp(now())-as_timestamp(states.sensor.atc_f1a8_temperature.last_updated))
      > 300 }}
actions:
  - metadata: {}
    data: {}
    action: esphome.mini_split_dining_room_use_internal_temperature
mode: single

[homegreen]

After investigating what all is happening, I realized there were two problems:

1. The sensor updates when there was no change were being filtered by HA (as is normal HA behavior)
2. The ESPHome integration, in the code that handles sending updates to ESPHome devices that register a homeassistant sensor, was also filtering when there was no change (https://github.com/home-assistant/core/blob/e4aaaf10c32e271aeddf5f4f2c68538a3b8ed10b/homeassistant/components/esphome/manager.py#L294-L299).

So I decided to try putting all the logic into an HA automation so I could make it do what I want, but unfortunately that involves polling. Here's what I came up with, which seems to be working ok:

alias: Kitchen heatpump remote temperature
description: ""
triggers:
  - trigger: time_pattern
    minutes: /5
  - trigger: state
    entity_id:
      - sensor.kitchen_temperature_temperature
conditions:
  - condition: template
    value_template: >-
      {{ (now () - states.sensor.kitchen_temperature_temperature.last_reported)
      < timedelta(minutes=20) }}
actions:
  - action: logbook.log
    metadata: {}
    data:
      name: Kitchen heatpump remote temperature
      message: >-
        Temperature last reported {{
        states('sensor.kitchen_temperature_temperature') }} {{
        states.sensor.kitchen_temperature_temperature.last_reported }}
      entity_id: sensor.kitchen_temperature_temperature
  - action: esphome.kitchen_hp_set_remote_temperature
    metadata: {}
    data:
      temperature: "{{ states('sensor.kitchen_temperature_temperature') }}"
    enabled: true
mode: single

[jontires]

Thank you for thisinfo, it helped me get this working with my heatpumps. I'm not worried about missing, stale, or incorrect values, so every 5 minutes my script just sets the remote temperature from the room temperature of the smart thermostat. Having a stable remote temperature source seems to help the heatpumps run more efficiently.

[tmchow]

I'm not sure if I'm experiencing the same issue exactly, but it seems similar. I am using a Ecowitt remote temperature sensor which is reliably connected to Home assistant. Looking at the logs this is reported temps:

I'm using it as remote temp sensor for my wall mounted mitsubishi unit but getting weird reports of the temps jumping way high. The high temperature I've found is when it uses the built in temperature sensor since it's so close to teh unit it always reads really hot. Ifyou look at the times, it's spiking to 80F+ when the actual remote sensor is giving readings to Home assistant.

My ESP config has remote temperature sensor timeout at 30 mins which is actually longer than I'd like given the ecowitt sensor is giving readings every 1 min.

I tried @homegreen's solution which was basically matching it identically except changing my sensor name. I'm getting an issue with F vs C I believe as when the automation runs, the climate temp is shown as 32F which is the telltale sign something is wrong, although I'm not sure where.

The relevant portions of my ESPHome config is this:

substitutions:
  name: ruby-room-climate
  friendly_name: Ruby Room Climate
  remote_temp_sensor: sensor.ruby_room_temperature

esphome:
  name: ruby-room-climate-controller
  friendly_name: Ruby Room Climate Controller

- platform: homeassistant
    name: "Remote Temperature Sensor"
    entity_id: ${remote_temp_sensor}
    internal: false
    disabled_by_default: true
    device_class: temperature
    state_class: measurement
    unit_of_measurement: "°C"
    filters:
    # Uncomment this line to convert F to C on incoming temperature
      - lambda: return (x - 32) * (5.0/9.0);
      - clamp: # Limits values to range accepted by Mitsubishi units
          min_value: 1
          max_value: 40
          ignore_out_of_range: true
      - throttle: 30s
    on_value:
      then:
        - logger.log:
            level: INFO
            format: "Remote temperature received from HA: %.1f C"
            args: [ 'x' ]
        - lambda: 'id(ruby_room_climate).set_remote_temperature(x);'

In HA, the sensor is configured like this:

To debug this, I ran the automation once and looked at the ESPHome device logs and saw these lines:

19:31:10 | [I] | [CN105:405] | Last heatpump data update successful!
-- | -- | -- | --
19:31:12 | [I] | [CYCLE:039] | 1: Cycle start
19:31:13 | [I] | [STATUS:134] | [received       ]-> [room C°: 0.0, operating: NO , compressor freq: 0.0 Hz]
19:31:13 | [I] | [STATUS:134] | [current        ]-> [room C°: 23.0, operating: NO , compressor freq: 0.0 Hz]

So for some reason it got 32F / 0C. Is there a bug in my automation?

alias: Ruby Room Remote Temperature Keep Alive
description: >-
  Ensure that remote temp sensor regular sends an update so there is not timeout
  due to steady temp.
triggers:
  - trigger: time_pattern
    minutes: "5"
  - trigger: state
    entity_id:
      - sensor.ruby_room_temperature
conditions:
  - condition: template
    value_template: >-
      {{ (now () - states.sensor.ruby_room_temperature.last_reported) <
      timedelta(minutes=20) }}
actions:
  - action: logbook.log
    data:
      name: Ruby room remote temperature
      message: >-
        Temperature last reported {{ states('sensor.ruby_room_temperature')}} at
        {{ states.sensor.ruby_room_temperature.last_reported }}
  - action: esphome.ruby_room_climate_controller_set_remote_temperature
    data:
      temperature: "{{ states('sensor.ruby_room_temperature') }}"
mode: single

Calling the sensor state from dev tools indicates it is indeed in F and correctly reporting:

I then tried setting the temperature by calling the action directly:

doing this resulted in the temp also going to 32F right away:

So this begs the question what is the right way to send temp to the action?

[jontires]

Looking at your ESPHome configuration, it looks close to the one I'm using that's working, but with some exceptions. In the esphome: section, if you were to replace:

esphome:
  name: ruby-room-climate-controller
  friendly_name: Ruby Room Climate Controller

with

esphome:
  name: ${name}
  friendly_name: ${friendly_name}

Then the values in the esphome: section will match those in the substitutions section.

Also, the start of my climate: section starts with:

climate:
  - platform: cn105
    id: hp
    name: "${friendly_name}"

In the api: section of my config file, I have the following which references the id from the climate section, which is hp.

api:
  services:
    - service: set_remote_temperature
      variables:
        temperature: float
      then:
# Select between the C version and the F version
# Uncomment just ONE of the below lines. The top receives the temperature value in C,
# the bottom receives the value in F, converting to C here.
#        - lambda: 'id(hp).set_remote_temperature(temperature);'
        - lambda: 'id(hp).set_remote_temperature((temperature - 32.0) * (5.0 / 9.0));'
    - service: use_internal_temperature
      then:
        - lambda: 'id(hp).set_remote_temperature(0);'

My section for defining the remote temperature sensor looks like this:

# Creates the sensor used to receive the remote temperature from Home Assistant
# Uses sensor selected in substitutions area at top of config
# Customize the filters to your application:
#   Uncomment the first line to convert F to C when remote temps are sent
#   If you have a fast or noisy sensor, consider some of the other filter
#   options such as throttle_average.
  - platform: homeassistant
    name: "Remote Temperature Sensor"
    entity_id: ${remote_temp_sensor}
    internal: false
    disabled_by_default: true
    device_class: temperature
    state_class: measurement
    unit_of_measurement: "°C"
    filters:
    # Uncomment this line to convert F to C on incoming temperature
      - lambda: return (x - 32) * (5.0/9.0);
      - clamp: # Limits values to range accepted by Mitsubishi units
          min_value: 1
          max_value: 40
          ignore_out_of_range: true
      - throttle: 30s
    on_value:
      then:
        - logger.log:
            level: INFO
            format: "Remote temperature received from HA: %.1f C"
            args: [ 'x' ]
        - lambda: 'id(hp).set_remote_temperature(x);'

Hope this helps.

[tmchow]

Thanks @jontires! I think the salient difference is in your api section, you are also doing the unit conversion between F to C which mine wasn't. I'll try this and report back.

[tmchow]

@jontires can confirm it worked! The right change was adding the F to C conversion. Thank you!