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: 20Agreed. It’s not an ‘issue’ but that is besides the point. I am merely trying to see if I can have an automation that will get around the default state if under normal circumstances it would be on.
This is the automation I am currently using:
- action:
- data:
brightness_pct: 75
effect: white
entity_id: light.lounge
service: light.turn_on
alias: Turn Lounge Light On after Sunset (if HA restarts)
condition:
- condition: state
entity_id: sun.sun
state: "below_horizon"
trigger:
- platform: homeassistant
event: start
I am sure that will work if Hass restarts after sunset. But I would like it to trigger if it is 1:50 before sunset or less.
I think you are onto something with this. I’ll investigate. You can do some maths in Templates.
Thanks.
That was the point of the threads I linked for you. Those people are achieving exactly that, or at least trying to
Can you explain why? My understanding is that setting the initial state to on doesn’t set the lights to on but instead sets the automation as “active”
Without using initial state the automation wouldn’t function unless I opened up the HA dashboard and turned it on
Automations are active on start by default. The problem with setting an initial state for anything is that if your system is rebooted/restarted, then the last state of the objects will not be restored to the last known state, but will instead be set to your initial state. So if you had an action that turned off an automation, and you restarted HA, your automation would be re-enabled when it shouldn’t be.