#Thermostat temperature change event does not work

1 messages · Page 1 of 1 (latest)

hushed lichen
#

This automation says:
when

  • thermostat temperature changes
  • configured temperature changes
    then
  • check if wall heater is off
  • check if temperature is below configured temperature
    if so:
  • enable wall heater

The second event works (when I change configured temperature, the cheks are done and the wall heater turns on or not)
But the first event is never thrown

image.png
#

Thermostat temperature change event does not work

#

The temperature continues to drop, Home Assistant correctly reads its values, but it does not throws any event

image.png
dusk elm
#

Can you post the yaml code? Use formatting please.

#

And you are sure there are no traces for the temperature changes?

hushed lichen
# 
triggers:
  - type: temperature
    device_id: 1409c66caeaf4e697b580037c549e2ea
    entity_id: 70a0a743b438e46e7b7f6b1dd552e045
    domain: sensor
    trigger: device
    above: -10
  - trigger: state
    entity_id:
      - input_number.consigne_temperature_cuisine
conditions:
  - condition: and
    conditions:
      - condition: device
        type: is_off
        device_id: 075ee5225c324dfe7d488da27c930104
        entity_id: 4a3b52e646a479c899d59edf8927f98c
        domain: light
      - condition: numeric_state
        entity_id: input_number.consigne_temperature_cuisine
        above: sensor.thermostat_cuisine_temperature
actions:
  - type: turn_on
    device_id: 075ee5225c324dfe7d488da27c930104
    entity_id: 4a3b52e646a479c899d59edf8927f98c
    domain: light
mode: single
hushed lichen
#

But it doesn't trigger the automation

dusk elm
#

ok let's start first by changing this automation completely, by removing the device_ids and replace them with entity_id only

#

https://community.home-assistant.io/t/why-and-how-to-avoid-device-ids-in-automations-and-scripts/605517 please read this.

Home Assistant Community
Why and how to avoid device_ids in automations and scripts

Background When you start writing automations, a device trigger seems the obvious choice. Everybody knows what a device is and it comes at the top of the UI dropdown list. It works… but it is certainly not a “great way to start” because it is storing up problems for the future. Far better to use an entity, with state or numeric_state....

#

also, in the conditions, you don't need to explicitly add the "and" because the conditions are by default sequential and all must pass, so it is "and" by default.

#

In the temperature trigger, you have the "above: -10", which means that trigger will happen once the value goes from under -10 to above -10 - it is a transition trigger. and since the temperature is currently 24degC, it will never trigger.

hushed lichen
hushed lichen
hushed lichen
#

I was like, if it changes anything above -10 it will work, but I was wrong

dusk elm
hushed lichen
# 
triggers:
  - trigger: state
    entity_id:
      - input_number.consigne_temperature_cuisine
  - trigger: state
    entity_id:
      - number.thermostat_cuisine_decalage_de_temperature
conditions:
  - condition: device
    type: is_off
    device_id: 075ee5225c324dfe7d488da27c930104
    entity_id: 4a3b52e646a479c899d59edf8927f98c
    domain: light
  - condition: numeric_state
    entity_id: input_number.consigne_temperature_cuisine
    above: sensor.thermostat_cuisine_temperature
actions:
  - type: turn_on
    device_id: 075ee5225c324dfe7d488da27c930104
    entity_id: 4a3b52e646a479c899d59edf8927f98c
    domain: light
mode: single```
dusk elm
#

Here I've done very quickly the demo for you:

triggers:
  # You can use one state trigger with multiple entities if you want
  - trigger: state
    entity_id:
      - sensor.home_average_indoor_temperature
      - input_number.heating_call_threshold
conditions:
  # Use entities for states, not device_id and entity_id like you did, because the device is not replaceable easily
  - condition: state
    entity_id: light.office_ceiling
    state: "off"
  - condition: numeric_state
    entity_id: sensor.hvac_heating_calls
    above: input_number.heating_call_threshold
actions:
  - action: light.turn_on
    target:
      entity_id: light.office_ceiling
hushed lichen
#

Oh, yeah, I kept "device" for wall heater^^ still, it works, but I'll change it

dusk elm
#

see my example, but you are improving now 🙂

#

but you have a heater on "light" domain?

hushed lichen
dusk elm
#

Normally a switch is a switch. If you have something like Shelly device that has a relay, it will be a switch domain, not light domain. You have an option in HA to "change the domain" from "switch to light" in case you have a light connected on a switch

#

but since you don't have a light connected, having the entity called light.xxx is a bit odd

hushed lichen
dusk elm
#

From "light to switch" I am not sure, but in the helpers there is a "switch to light".

#

you could use the tempate switch to go other way around, but this is "stupid" IMO in that case. I'd like to rather understand how did you end up having "light" for your heater...

hushed lichen
#

Maybe it was default set to light

#

But that's not a big thing: The most important was the event, now it works using entity instead of device

dusk elm
#

it works because you removed the "above", but the use of entities now gives you portability. If the switch hardware fails, you replace by new one, name it the same entity name and, as french would say, "et voilaa" 🙂

dusk elm
#

this is also a good reading for you 🙂

hushed lichen
dusk elm
#

Hmm, strange. All my Sonoffs are detected as switch.xxx

#

so I used the helper to convert switch as light because I have a light

hushed lichen
#

And they are detected as light by default