No it’s not that unreliable.
But what would happen if it restarted (like the other night it was 1 hour before sunset), the lights were on as they should be via my usual automation, home assistant restarts and they are off. It’s not a huge problem but I’d like them to just come on if they are 1:50 or less before sunset.
I find that my HassIO Pi runs happily until I go in and mess up some yaml… I wouldn’t bother mucking around trying to code for something that shouldn’t happen!
Oh ok. When I restart mine nothing changes- lights that are on stay on and if they’re off they stay off
likewise. The is issue is to do with triggers. ie: if a trigger such as ‘sunset’ passes while Hass is offline, the trigger wont occur so the action associated with it will not happen. Its something that really wouldn’t happen often at all. How likely is it that Hass is offline at that moment, given that it should be online all the time
If I took that attitude, I wouldn’t even have started with automation - I can just manually go and turn a light on after all!
My lights always flash on then off. Hassio has no way of knowing their state at startup so it puts everything in a known state. (LimitlessLED). Maybe your lights have native support? My Wemo switch for example always stays on or off. It’s just the lights that are the issue.
It’s no biggie and this is as much about learning how to make stuff work than trying to overcome a minor inconvenience.
Oh ok I have lights linked thru a wink hub and MQTT so I guess they all just let HA know their status. Didn’t realize yours didn’t!
my Yeelights just keep doing their thing until told otherwise. Hass can restart as many times as it wants and they wont change unless told to. They wait for a command, they don’t need a constant command.
bit of an exaggeration! 
Nothing wrong with automations, but do we really need to code for something so unlikely? Ideally your Hass server should be rock solid…
It is but the power isn’t
UPS? or battery pack. I was reading a thread the other day about using a USB battery pack capable of output while remaining on charge. Seemed like a really nice (and cheap) way to create a UPS for your Pi.
Cracking a walnut with a sledgehammer.
You can get small ones you know!
OR…
http://www.allspectrum.com/mopower/
http://www.allspectrum.com/mopower/supercap/MoPower-UPS-supercap-raspberry-pi-info.html
again, there are options other than messing around with code that may not do what you need anyway.
Fix the cause rather than the effect.
Well thanks awfully for the suggestion.
Can anyone else advise if what I have asked is possible or not?
I wasn’t trying to be nasty but in my line of work and experience, we always try to prevent an issue rather than fix the resultant drama caused by it. Sorry if I offended you.
Unfortunately my yaml coding ability is pretty low so couldn’t help with that side of it.
No offence. You are just making all kinds of assumptions and aren’t considering why I asked (to learn what I can and cannot do etc). I do appreciate you offering alternatives but I was trying to see what I can do in HA. It is rare of course but the other night I saw the 0.59.2 update was out so I updated on my iPad while watching TV and was plunged into darkness - a minor problem of course but if it was able to trigger the state for the lights that would be great. Not a UPS issue or anything else. That’s where I am coming from.
It’s odd that your lights would turn off due to a Hass reboot though. Is it not that an automation has caused them to turn off rather than not turn on? My lights (some z-wave, some Xiaomi Yeelight) do not behave that way. If on before the reboot, they stay on.
No it’s expected behaviour according to the docs. As I said my Wemo doesn’t do it but the LimitlessLED lights do and it’s documented.
i just read the docs for the limitlessLED’s. So my understanding is that this is not really an automation issue but more to do with the limitlessLED being “set to known default values” upon a Hass restart. The reason I say ‘not an automation’ issue is that these would rest even if they had been set to ON manually by the sounds of it. Is that what happens? ie: they will turn OFF no matter why they were ON before the restart? (either from being ON due to an automation, or manually switched ON). In this case I think you will also need to look for a way to restore the state from prior to the reboot, irrelevant of any automations. There was this thread and this one as well that talked about keeping non-volitile states stored. Perhaps you could use one method to save a non-volitile record of the limitlessLED state so it can be restored upon Hass reboot.
I think to make this work you’ll need an additional condition that contains a template that says something to the effect of “if the time now is between sunset and (subtract 110mins from time of next sunset))” …unfortunately i don’t know enough about templates yet to write that for you. The sunrise/sunset offset only fires on a specific minute, so that’s why the offset alone can’t be used
edit to add- it might be way easier to just use the sun’s elevation… take out the below_horizon condition and use the one below. That condition would be true from ~2ish hours before sunset to ~2ish hours after sunrise (depending on your location)
trigger:
platform: numeric_state
entity_id: sun.sun
value_template: '{{ state.attributes.elevation }}'
below: 20