Unfortunately, this doesn´t work (the automation still does not trigger when sensor value increases). It is such a simple usecase… makes me angry still not learning that language -.-
Don’t use a from or a to, so that the automation triggers whenever the number changes.
Add a condition to prevent the automation running if the state decreases:
Note your condition template would probably work too, if you changed it to =1 instead of >1 because it will only be over 1, if the number it has changed to is 2 or more than the previous state.
Interesting approach! But will it also trigger if the sensor value is not numeric (e. g. none or more likely unavailable e. g. during sensor initialization/HA restart etc.)? I don´t want those cases to fire my automation.
{{ (trigger.from_state.state|int(0) < trigger.to_state.state|int(0)) and (trigger.from_state.state != 'unavailable' and trigger.to_state.state != 'none') and (trigger.to_state.state != 'unavailable' and trigger.from_state.state != 'none') }}
Edit:
Yes but your template would still have worked, you were limiting the automation by having from:0 which will only ever fire once when the state changes from 0 and won’t fire again until the state has gone back to zero and then over it again.
your previous condition template worked Didn´t know it´s possible to not set a ‘from’ or ‘to’ in a state trigger. Probably mixed it with the mandatory ‘above’ or ‘below’ in numeric_state trigger.
Seems to get quite complicated when there are 3 states I try to avoid: unavailable’,‘unknown’,‘none’, maybe there´s a smarter solution? Hopefully piping to int or even int(0) catches those states, doesn´t it?
How can I use the difference (“new number of problematic entities”) in the action part (notification)? Can I use this to calculate?
Yes, The best way to catch all the errors is to set the default to a minus number that you would normall never see - something like this:
{% set t_new = trigger.to_state.state|int(-99) %}
{% set t_from = trigger.from_state.state|int(-99) %}
{{ t_from < t_new and (t_from > -99 and t_new > -99) }}
That ensures that if either the from or to states could not be converted to an int, then they become -99, which we can easily check, and stop the automation going any further.
As for your number 3, yes - that looks good to me.
P.S.: Only downside I could find so far is: the “last_triggered” for that automation of course now doesn´t mean there actually was a problem, because we gonna monitor ANY sensor value change now. Not nice, but still a quite small trade-in for the benefit of getting a notification for every increase of that sensor value.
Good day. I See this thread is from some time ago. It is exactly what I am trying to do. In my case water flow. I want to start an automation when water starts flowing for 5 seconds.
My issue is that I want to execute another automation of water stops flowing for 5 seconds.
Post a new thread, and you can provide a link to this thread if you think it is relevant. In your new thread, you’d want to post some information about the relevant sensors you have in HA: Do you already have a sensor that reports flow? Does it measure flow and report a value, or is it a binary sensor that turns on when flow is detected?
Have you tried to create an affirmation yet? Can you post the yaml code from something you have tried?