I am just getting started with HA and mostly I have figured things out. I am having a particular problem with an automation for a Sonoff TH16. My aim is to turn on or off the switch side of the TH16 by determining first if the switch is on or off and secondly whether the current temperature is above or below a given temperature. The temperature state value comparison is where it falls apart. It seems that the temperature state value and the set value in the automation condition may not be the same data type. The sensor attribute value appears as expected in the Developer/States display and in the eWeLink app. I guess the question is if the state value is expressed as a number or text string and the same for the comparison value in the automation condition entry.
alias: Hot Water Recirc On
description: ''
trigger:
- platform: time_pattern
minutes: /2
condition:
- condition: and
conditions:
- condition: state
entity_id: switch.sonoff_######
state: 'off'
- condition: time
after: '05:00:00'
before: '23:59:59'
- condition: numeric_state
entity_id: sensor.sonoff_######_temperature
below: '95'
action:
- service: switch.turn_on
target:
entity_id: switch.sonoff_######
mode: single
The following automation triggers when any of the following occurs:
The switch is turned off.
OR
The time is 05:00.
OR
The temperature decreases from above to below 95.
When it triggers it confirms:
The switch is turned off.
AND
The time is after 05:00.
AND
The temperature is below 95.
If all three conditions are true then the switch is turned on.
In other words, if for any reason the switch is off after 05:00 and the temperature is below 95, the switch gets turned on.
alias: Hot Water Recirc On
description: ''
trigger:
- platform: state
entity_id: switch.sonoff_######
to: 'off'
- platform: time
at: '05:00:00'
- platform: numeric_state
entity_id: sensor.sonoff_######_temperature
below: '95'
condition:
- "{{ is_state('switch.sonoff_######', 'off') }}"
- "{{ now().hour >= 5 }}"
- "{{ states('sensor.sonoff_######_temperature') | float < 95 }}"
action:
- service: switch.turn_on
target:
entity_id: switch.sonoff_######
mode: single
All states are strings. Even if they look like a number.
Attributes can be any valid data type (sting, int, float, datetime, etc). But no matter what the declared data type is the entity will always return the datatype it “looks like” it is.
so if, for example, an attribute is a string of ‘95’ the interpreter will return that value as an int even tho the native type is a string.
that is all just as an FYI for later
BUT…
in your case none of that matters.
even tho states are always (always) strings the use of “numeric_state” treats it as a number. So the real data types don’t matter (even tho the state really is a string).
If your automation doesn’t work as written (but it looks fine to me) it has nothing to do with the data types in the numeric_state condition.
the only thing I see is that the time_pattern trigger may need to be written with quotes.
trigger:
- platform: time_pattern
minutes: '/2'
I always write them like the above and it’s that way in the docs but I’m not sure it’s absolutely required.
try it to see if it works.
Once you get that sorted out then at that point I would recommend using the automation posted by @123 above.
It’s better to use specific triggers instead of a time pattern if possible.
Not sure which part of what I explained you are referring to.
In an automation:
Multiple triggers are ORed by default.
Multiple conditions are ANDed by default.
The example I posted replaces the use of an inefficient Time Pattern Trigger with three separate triggers designed to trigger when one of the appropriate events occur. The automation’s condition ensures that the action is executed only when all three desired conditions are in effect.
The time being 5:00 AM is not a desired trigger. The idea of the Time Pattern trigger is to cause the automation to run periodically such that it is always testing the conditions set. There is a companion automation which turns the switch off when the switch state is currently on and the sensor state is above 104. The idea is that during the time frame of 5AM to midnight the switch will turn on with conditions met and turn off once sensor is above the set value and this continues during the day.
Perhaps you are unaware that what I posted is a common design pattern for the replacement of a Time Pattern Trigger. It doesn’t poll endlessly, it acts only when desired events occur. FWIW, I’ve helped many users convert their Time Pattern-based automations to this more efficient way.
With a Time Pattern Trigger it does this every 2 minutes:
Is the switch off and is the time after 05:00 and the temperature less than 95.
It does this regardless if none of the events it is looking for have occurred (especially when it’s checking every 2 minutes from midnight to 05:00).
The automation I suggested uses a different approach. When any one of the desired events occurs, it checks if all three are true. In other words, the question that the Time Pattern Trigger asks every 2 minutes is only asked when there’s a real need to ask it.
Run it through a few scenarios and you’ll see it only turns on the switch when the time is after 05:00, the temperature is less than 95 and the switch is currently off (i.e. precisely what the Time Pattern version does).
I will admit to not knowing how these automations run under HA. From what I understand from your explanation is that the trigger occurs whenever the time transitions through 5AM OR whenever the switch state is off. The following conditions further constrain action if the switch is off AND if it is >5AM AND if the sensor is <95. I agree that should work to turn the switch on if all conditions are met. My question is that as I understand it, if the time trigger is only going to be true when the time makes that transition through 5AM and the routine runs, satisfy all conditions, the switch will turn on thus both trigger conditions will be false. The automation will never run again unless the switch is turned off by some other means. That’s okay as I have another automation that turns the switch off, which also doesn’t work. The failure in both cases appears to be in sensor value comparison. If I eliminate that condition the automation runs as expected in both cases. Obviously this is not the desired action. I am going to keep working on your idea but at this point there is a ‘compile’ error concerning the action entry. I appreciate your help, by the way. From what you are implying or at least as I interpret that, is that the automation once enabled is going to continually monitor the switch state without having to trigger the automation with the time_pattern routine. That is the one thing I didn’t understand about how automations get started or triggered. I will have to modify your code to stop the automations running at night, i.e. not between midnight (11:59:59) and 5 AM.
Yes, triggers are constantly listening for “something” to happen. That “something” depends on the type if trigger.
State Trigger listens for the entity’s state value to change.
Time Trigger waits for the scheduled time to occur.
Numeric State Trigger waits for the entity’s state value to cross a specified threshold (literally, only when it crosses the threshold, it won’t keep triggering after it has crossed it).
Not quite sure why you say that because there is nothing that can happen during those 5 hours that will cause it to execute its action.
If either or both of the following things happen between midnight and 05:00, the action will not be executed because the condition will prevent it.
Temperature drops below 95.
Switch is turned off.
If both occur, nothing will happen until 05:00 when the Time Trigger occurs. At that moment, the time will be a tick past 5:00, the temperature will already be below 95 and the switch will already be off so all conditions are met and the action is executed.