I have an issue where the defined trigger states are not recognized in my automations, most of the time. Sometimes (it seems random) a trigger is recognized and the action is taken.
I made a simple example for this topic.
When the temperature on my terrace is higher then the temperature in my basement I’d like to receive a notification on my phone.
The temperature on my terrace is always higher then the temperature in my basement, so it should always trigger.
Nothing happens though.
When I create an automation with a time interval as a trigger (1 minute) and as a condition the same information as the trigger from the first automation, the automation will work every minute and I will also receive a notification every minute.
What am I missing here?
I created these two automations in the GUI, not YAML.
Fires when the numeric value of an entity’s state (or attribute’s value if using the attribute property, or the calculated value if using the value_template property) crosses (and only when crossing) a given threshold. On state change of a specified entity, attempts to parse the state as a number and fires if the value is changing from above to below or from below to above the given threshold.
No, I did this just for testing.
Because of a moisture problem in the basement and the use of a dehumidification device I’d like to have an automation where if the humi and temp outside are lower then the basement the air ventilation should turn on.
Now I know that I need do this by checking with a time interval and this doesn’t need to be every minute.
I generally use call service => switch turn on => then entity.
This is a (in my opinion) better option since the device id is fixed to this particular device. If/when it breaks you can’t get a new device with the same device id, but you can name a new entity the same.
So if you want to plan for devices breaking on you, use entity id and call service.
If you want it easier now then use device.
If you only have one as trigger then it could be happening in the wrong order.
You had temp as trigger, so let’s say the temp crossed the threshold, at 10:00.
An hour later the humidity goes above it’s threshold, but the humidity is not a trigger so the automation doesn’t trigger.
If you have both as triggers and both as condition then the automation will trigger once but die because of condition, and the second time it triggers both conditions are also true and it fires.
Edit
You could also create a template trigger that will only trigger once when both temp and humidity true.
This really is something I wish the HA developers would change about the UI. It currently defaults to ‘device’ but in reality, we all learn over time that using entities/states are better. Most people end up going back and refactoring their code after they use HA for a while to get rid of non-needed device IDs… I digress.
Ok, I’m trying to understand this.
Triggers need crossing.
If one of the two triggers crosses above, the other one doesn’t also cross exactly on that moment.
So then there will never be a time where the automation triggers?
Or does it remember the first trigger and then when the second one triggers an hour later both are triggered and both conditions are also met, if the first one didn’t change?
No it does not remember anything.
That is the issue here. Because it does not remember the the temp has already crossed and triggered then the automation will not fire if you only use one trigger.
(Except the template version I will post later, just a bit busy now).
The other way to have only one trigger is wait for state in actions.
Its a very bad idea so don’t think about it, but you could get away with one trigger using that method.
The issue is that as soon as you reboot HA or save any automation then it will not wait any longer, the automation is reloaded and all memory is lost.
with that trigger, you won’t even need your conditions at all but it won’t hurt to leave them if you want to convert them to templates. Not really needed though.
Message malformed: expected float for dictionary value @ data[‘condition’][0][‘above’]
If I google it then find a post on here that says:
I see no evidence in the docs that you can use a template in the above: or below: parts of a numeric_state condition. You could, however, replicate that with a template condition. You should be able to use an input_number , but if that isn’t working, the answer isn’t to try to use a template.
If you want to ‘test’ it, you can go into the developer tools under /states/ : /change states/ and update the values of the two sensors to trigger the automation manually for testing purposes.
I did not know you couldn’t use templates in conditions.
I’m shocked to see this, a few years ago a lot of fields that was just values was made to values or templates. Strange that this was not fixed.
But yes the way Rob posted was what I was thinking.