Oooh, that’s fancy! I likey!
I will have a little stab at that. I don’t have the uptime sensor in my config as yet but can happily add it. As you say, it keeps this template tidy(er).
I have some similar automations for charging the Tesla on pure sunshine. I might need to ask your advise if I can’t get them to play nicely with the same concept.
I’ll report back if I get stuck.
Thanks to both of you!
Something did change. A restart used to reset the Numeric State Trigger but it doesn’t do that anymore.
The new behavior is actually better. Consider this example:
- platform: numeric_state
entity_id: sun.sun
value_template: "{{ state_attr('sun.sun', 'elevation') }}"
below: -4.0
It triggers at the moment the sun’s elevation decreases below -4 degrees (i.e. just after sunset). Imagine it is used to turn on a light which is later turned off at 23:00.
If Home Assistant is restarted after 23:00, it resets the Numeric State Trigger and so it triggers again. This has the unfortunate side-effect of turning on the light that was already turned off.
It’s important to remember that the Numeric State Trigger is designed to trigger only when the threshold value is crossed and not afterwards. However, a restart would allow it to trigger not at the crossing point but afterwards. That is not how a Numeric State Trigger is supposed to operate and so this non-standard behavior was eliminated.
Your automation relied on the Numeric State Trigger’s anomalous behavior at startup but now it must be modified to explicitly handle the case of what should happen when Home Assistant is restarted.
3 Likes
Thank you. I think you are absolutely spot on there.
This looks like the root cause of my change in behaviour. Nice work!
I will try Troon’s new template and see how it goes. Feel free to chip in if you know a better way.
No, the numeric state trigger has always worked like this (except for restarts as Taras points out) in fact there are innumerable threads where people misunderstand how this is supposed to work. And workarounds like @sheminasalam are common in the solutions.
Moral of the story: - When something doesn’t work as you expect it - test your assumptions, read the documentation and then search for similar threads
2 Likes
@Mutt
Do you have any theory as to what changed, if it wasn’t the numeric state trigger changing behaviour?
I did search beforehand but didn’t find anyone with the same change in behaviour of their automations.
FWIW, I had suggested the same approach sheminasalam did to someone else here:
It’s self-documenting because you see this means it’s handling startup:
- platform: homeassistant
event: start
Troon’s suggestion ought to work as well.
As for this:
You don’t need the extra condition any more
The “extra” condition is actually still there, just incorporated in the Template Trigger, but it is true that it doesn’t appear as an “extra” line in the condition section. However, this approach relies on an “extra” sensor (uptime). 
2 Likes
Eh !
No, my point is that most people expect (say in your case) a radiator to be on if temp below a certain value irrespective of when the automation was started, reloaded, values changed etc. If this behaviour is important to you, you must test all relevant conditions in order to provide the functionality you desire.
I would add that I think that @sheminasalam 's solution is simpler (and much easier to read) than the
By @Troon
The simple rule when having 2, 3 or 4 triggers to ‘start’ a sequence is that you should have similar conditions (testing the same things) as the triggers.
So to have a light come on, only if you are home, at 18:00 and if the sun is below the horizon but before 23:00 (ie to turn it off again) you could (in the simplest (newbie friendly) manner) set 4 triggers with 4 conditions and you are done.(and a restart is an extra)
You could also create a binary sensor and just flip the light on that (super simple but the binary sensor is not for newbies)
The restart is covered by pretty much any of the above.
But apart from the binary_sensor option - what happens when you write the automation (with the sensor already past the threshold) and reload automations to add said automation ?
Perhpas the odd thing here is that I am not concerned with temperature to control the rads. That would be nice and easy, comparatively.
My setup is aimed at using only 100% solar energy to power the radiators. I can see how that would be a fairly different flavour of automation and it results in a lot more on/off cycles as the trigger condition is met and then breached (clouds passing by etc).
It has gone cloudy at the moment but once I see some sunshine, I will try reloading the automations and see if it fires or not.
Yes, try to concentrate on your end goal (rather than your first stab at trying to get there)
If you want to save money (for example) then having a sensor advise how much surplus energy is available and have tiered switching based on that.
Be careful here as some kit can not be switched on and off arbitrarily or need minimum on times (compressors etc.) and there’s the duty life of components to consider. Switching something on-off 500 times a day will not help it reach its first birthday.
Binary sensors can sometimes help here utilising their “delay on” and “delay off” options
Reloading won’t help in that case as the previous version is still loaded until the reload (so continuous) I’m imagining a completely new automation (don’t use your live kit for this - leave it to someone with a test instance)
OK, the sun came out.
I was generating 4kW (well over the 900W threshold). I restarted Automations but nothing fired.
I had to manually toggle all 3 radiators and now the automations can turn them off and back on.
Regarding the hardware etc, all of this hardware has been running for 3 years.
I live in the Swiss Alps and have paid nothing to heat a 7 bedroom house for 3 years. It’s all good.
I am definitely open to improving the setup though.
I have recently tried tuning it a bit so they only turn off or on if the last state change was over 60 seconds ago. That has stopped the high frequency toggling but it’s not a huge issue for me. These are all second hand oil radiators and they seem to be bulletproof.
It’s worth mentioning that I tend to allow an overhead of approx 100W so they do not toggle on or off the moment there is enough energy being produced to cover their consumption.
That can lead to some pretty complex conditions though, with a lot of repetitions unless you move all the logic out of the triggers and keep it only in the conditions (e.g. trigger on any change to sensor state but do the “above/below” test in the condition). I don’t know if that would drive any increased computational load, or if it’s equivalent.
Troon, all good points, but the ‘watches’ determined when you load an automation are the things you are trying to avoid, as this consumes ‘some’ processor overhead (some would argue a tiny insignificant part (which I’d tend to agree with)) but generally ALL these are followed by an ‘evaluation’, especially when it’s a template trigger (of which, I’m massively guilty of) (and yours is a fairly complex template trigger).
Regardless : -
If you put ALL the ‘requirements’ in the conditions then you’d need a fairly frequent trigger to evaluate often enough to not miss an event (but you could still miss it by 59 seconds even if you use sensor.time (or time: minutes: /1) (note: seconds: /1 would just spam everything) AND then you’d have to do ALL the evaluations every minute. Very inefficient.
Much better to use state triggers where you can and then only do an evaluation when a state changes.
Well, that depends, if just the one instance then suck it up, alternatively (and this can be massively more efficient *) create a binary_sensor.
* when I ran on a Pi4 I replaced ALL my switched time conditions into binary_sensor’s and my processor use went from 5% down to 1% Note an example use was a speaker (I have 4 of them), on between (say) 08:00 and 10:00 and again 16:00 to 19:00 but only if we were home AND the TV was not on (the music runs 24/7 but I just turn the speakers on and off). My time triggers are text comparisons where possible (evaluate on sensor.time change 1/min rather than time: which evaluates every second) etc. (So 4 times * 86400 down to 1440)
I’ve added about 30 automations since then and have moved to a NUC but I’m still at 1% but that’s mainly for the reboot/reload/config check times
1 Like
Agreed — it’s just a question if it’s better to:
- keep the
triggerblock simple (but as lengthy as it needs to be) with a list of entities to watch for state changes, then do the logic only in thecondition; or - do the logic in both blocks (with e.g.
numeric_state) to try to reduce the number of trigger events, at the cost of duplicating the logic; or possibly even - make the
triggerblock a potentially hideous template to cover all the required logic, obviating the need forconditions at all.
As you say, it’s likely a case-by-case judgement of how far to go and how many automations are needed to do a job.
Trying to handle things like HA restarts can make the required logic hard to work out and even worse to implement with and and or condition blocks.
Just seen your edit, and I do suggest a binary sensor a few screens up. I use that in my config for timespans and things like light level thresholds. I believe now() only triggers every minute, incidentally [ref].
1 Like
What do you do about snow cover ?
Yep ! - and that was an update ‘nagged’ for by Taras (@123) (thanks to bdraco) this is a workaround to allow backwards compatibility in some templates (it originally (well since 0.112 I think) was not meant to trigger any updates - but bdraco yielded this concession)
I avoid now() in all triggers and only use it in ‘some’ conditions (ie “was this automation fired less than 20 secs ago ?”) but it’s often useful just to get something to read as a timestamp
FWIW, the use of now() in a template is a handy replacement for states('sensor.time'). However, both cause the template to be evaluated (at least) every minute which, depending on the use-case, can be either efficient or inefficient.
An example of inefficiency is where you only need to evaluate the template infrequently, like every day (or like in this situation, only after startup). That’s where the recently introduced Trigger-based Template Sensor really shines. It allows me to create a Template Sensor that is evaluated only when its Trigger fires. That means I can use a Time Trigger, executing at midnight, to evaluate the template only once per day (at the start of the day). A Trigger Template Sensor can use any kind of trigger (State, Numeric State, Time, Time Pattern, Event, etc).
1 Like