Here an example where I tried to add the device tracker:
- alias: Woonkamerlamp aan als zon onder gaat
trigger:
- platform: numeric_state
entity_id: sun.sun
value_template: '{{ state.attributes.elevation }}'
below: 3.5
- platform: time
at: '19:01:00'
condition:
condition: and
conditions:
- condition: time
after: '19:00:00'
- condition: numeric_state
entity_id: sun.sun
value_template: '{{ state.attributes.elevation }}'
below: 3.5
- condition: state
entity_id: group.noreenpaul
state: 'home'
action:
- service: light.turn_on
data:
entity_id: light.woonkamer_lamp
brightness_pct: 30
kelvin: 2200
- service: light.turn_on
data:
entity_id: light.ensuite_deur
brightness_pct: 1
kelvin: 2200
This automation only triggers when the sun is very low and after 7PM. And I have added the group tracker. Or should I add the group to the triggers instead of the condition section?
I do have something similar see if this fits the bill.
(I only do this for speakers not lights, lights generally give the appearance of the house being occupied though I’m yet to create my random (but utterly believable) light switch on / switch off system to keep the nasty men from my door)
I have speakers that have two time slots morning and afternoon (though that’s not hard and fast) they are set by input datetime’s in the interface, I can also switch them on with a timer to go off in (say) 60mins (again configurable) or I can switch them on manually.
I have binary sensors to determine if the speaker has been instructed to turn on.
This stays on all the ‘period set’ but this is not the control for the speaker unless the house is occupied. As if I leave the speaker will turn off. The speaker slot may expire whilst I’m out but if not, when I come back the speaker is switched back on
There are several ways to accomplish this but here’s how I would do it.
You need one automation that turns group.all_lights off when no one is home (this is an automatically created group that should already exist). Or include this command in your existing “Elvis Has Left The Building” automation.
light:
- platform: group
name: Arrive Home Lights
entities:
- light.entrance_light
- light.kitchen_light
Then create an automation that turns the group you created above on when someone comes home. In this automation you can put a condition for the sun being down or something similar so they don’t turn on when it’s light outside. You shouldn’t have to change any of you other lighting automations. This one can work independently. I also wouldn’t put this in your “Elvis Has Arrived” automation because you don’t want the daylight condition to stop the rest of the actions from happening.
For your daylight condition can use a simple sun condition or you can get fancier using sun elevations. Fancier yet would be the illuminance custom component.
I like Mutt’s idea. Create a binary sensor for each lamp and set binary sensor to true instead of switching on the lamp. And have another automation that triggers based on the binary sensor state and the device tracker to actually switch the light. Probably some vacation mode can be added to it that will override the device tracker in case you want to pretend that someone is at home.
The only thing missing is a way to set brightness. Color temperature will be set by Flux. But brightness might need another variable to store the value in. Are template variables global?
Jason’s solution is a LOT easier to accomplish and may be sufficient (why would you want to store the binary sum of 20 odd lights?
I have light level and colour pattern settings (which all lights adopt when they switch on or light that are on transition to when the segment changes) so I have no need to store these values.
But I just use input_number ‘s to store the patterns and input datetime’ s to store the transition times
And no. Template variables only live during that template evaluation
If you want to get all fancy and whatnot storing brightness and colors and all that I’d consider an arrive home scene instead of a light group. The you can also use it for anything else you want to change when someone comes home. @phsdv didn’t really say anything about any of that so I didn’t take it into consideration.
Needless to say there are several ways to skin this cat!
I’d avoid scenes if at all possible, they are being deprecated as we speak (seemingly anyway, less and less capable with each new release) easier to just to do it in scripts
Curious what makes you say this? At one point I would have agreed with you, scenes were terribly clunky. I didn’t use them at all. But things have improved!
They actually just created new capabilities such as the scene.create service so you can create scenes on the fly. I’m using it in a few places now and it works great! They also just introduced a scene editor for the UI but I haven’t tried that yet. That being said I don’t use them for anything but lighting so far, but they seem to work OK for that.
I’ll look for the other thread about moving them to scripts to future proof them, I think it was about no longer being able to use transitions in scenes.
Let me look
They can’t all be scrapped, cos as you point out, they’ve just done an editor
As far as I understand they removed the transition and the ability to call a script from scenes and they should be more seen as a desired state for multiple entities now.
Edit: just saw the other reply from @Burningstone about transitions, scripts…
Huh. I never would have even thought to use scenes within scenes. Clever. Guess I never really used them extensively enough to even consider it. Any idea if that is the only limitation now or have they changed anything else? Honestly, I don’t see myself using them for much other than lighting anytime soon. Even then it’s limited to when I need to store current lighting to restore after some event that affects the lighting.
I used to use Phil’s light store python script (and still do in some places) to accomplish this but I noticed the new scene.create service so I thought I’d try it out. It works so I left it. Here’s one example I have for the automation when my garage door opens. arrive_home_lights is actually a light group that includes the lights in my garage, my side entrance, porch light etc.
I’m generally a fan of Phil but actually I don’t use any of his components (I’m a liar, I use life360 and virtually every occupancy tip he’s ever posted because I don’t use ‘person’) but not come across that. Hmmm interesting, I’ll look at that later.
Of the above I don’t recognise the bit you I (it’s getting late) quoted (feel free to explain)
All the rest of it though could easily be done in a script so… What am I missing ? (its usually big and grey with a trunk)
Absolutely nothing! Different strokes for different folks! I just like exploring all the different options.
It’s a parameter for a script that prevents automation from changing entities if the occupant has recently used it. So say if I turn on a light in the living room no automatons will change that light’s state (until the associated timer runs out) unless ignore_user_state was set to true (for example the smoke alarm - the lights turn on no matter what the user state is). If you’re interested I can put into a gist for you.
I think this is a perfect example of a use case for the “new” scenes. I would use it the same way if I would use scenes
I think all of it can be done with scripts, it’s just “easier” with scenes.
Here is a good explanation I found on Github on how scenes work and why you can’t call scripts/scenes from them:
Scenes are based on the state of an entity. All entities that provide a meaningful state can be used in a scene.
Scripts and scenes and some other entities do not have a meaningful state, so they cannot be used in scenes. Scenes do not notice whether they are active or not, they are always scening . Scripts are on or off indeed, but this is only a momentary state and you don’t want the script to be on , you want it to have been executed in the past.
Long story short, neither scripts nor scenes will be usable in scenes in the near future.
@jazzyisj Jason (reply is to burning but you first) but I understood that scenes were one shots, so the point is moot.
I always want things how I set them so if I want them that way I set them that way.
I just don’t see the point in scenes.
Burning, thanks for that, the best explanation I’ve ever ‘seen’ (ha ha) So I’ll stick with scripts (never used a scene in my life - though maybe if I was doing theatre ??? (but then I’d have access to much better hardware)
Not sure if I’m high jacking this but I’m also planning to implement something similar to this, one difference would be i have a zigbee wall switch controlling a WiZ light. I haven’t wire them up, in process of renovations.
I’m thinking the tracker would trigger and check the conditions if to turn on the zigbee switch, though then (where I’m stuck) need to wait for the WiZ light to come online and connect, then switch the the appropriate scene. Or am i wrong to assume HA will only fire off to set a scene once regardless if device is online, and ends the automation. So if my WiZ was slow in connecting, it basically wont change to appropriate scene?
