had a play tonight and looked and examined your scripts and managed to get it working with a few alterations but with your help got the way I wanted.
What was confusing me is that in my head i thought “When” was always the device that needed to be set but in fact you can have anything even a timer like you suggested and not just a device and then have the device in the “Then Do” by given it a choice and then trigger
my script, I changed the id and removed them as i am not sure if that’s a good idea to post?
it’s totally safe to post your entity id names. they don’t compromise your security unless you start naming your entities with secrets like your tax id or credit card numbers
some feedback on your yaml.
you switched them back to numeric device_id and entity_id’s. i’d recommend you unswitch them and use the friendly entity_id’s like i had. here’s info on why:
is the - condition: time part a bad copy? it’s indented incorrectly and should throw and error. you have it correct in the “when timed action” section.
it’s unnecessary to specify the weekday: section if you’re doing every day. it’s primarily there for if you want to specify only a couple days. no harm in doing what you did, but you do lose code beauty point…
after all that back and forth about how you want to leave the light on if the light is manually turned on and the harmony hub is never turned on… you said:
but you took out the code that actually enforces that…so at this point, your code turns the light off at 22:30 unless the harmony is currently on.
which means you have implemented the identical to my second code (what @liquid_cooled and i recommend) but you did it in a much more complicated way… which is typically more fragile and harder to update.
take a look at this version again. i think it does everything your version does but simplier and more maintainable:
trigger:
- platform: time
at: "22:30:01"
- platform: state
entity_id:
- remote.harmony_hub
to: "off"
for:
minutes: 1
condition:
- condition: time
after: "22:30:00"
before: "01:00:00"
- condition: state
entity_id: remote.harmony_hub
state: "off"
for:
minutes: 1
action:
- service: light.turn_off
target:
entity_id: light.great_room_lights
If it is do i need to change all my automations to a state or Numeric State in “When” from now on, why have a Device option if it’s not a good idea???
you posted
but you took out the code that actually enforces that…so at this point, your code turns the light off at 22:30 unless the harmony is currently on.
thats exactly what i wanted, becasue if the harmony hub is on that means i am still watching tv so i don’t want the lights to turn off at 22:30 but if the harmony hub is off that means i am not watching tv and went to bed meaning the light will now turn off at 22:30.
but if i turn the harmony hub off after 22:30 and let’s say 11:30 becasue i stopped up late when i switch sky off by the harmony hub its now switched from state sky to state off and now runs another automation script that that then turns the lights off after 1 min.
meaning i never have to touch my lights and are now fully automated.
but i’m curious. why not this? what’s the purpose of checking those two states in the action when you can combine them in the condition block?
trigger:
- platform: state
entity_id:
- select.harmony_hub_activities
from: Watch Sky [TV] ### is it important what it goes "from"? if it was from another activity to power off, should it also work?
to: power_off
for:
hours: 0
minutes: 1
seconds: 0
id: Sky Trigger
- platform: time
at: "22:30:00"
id: Timed Trigger
condition:
- condition: time
after: "22:30:00"
before: "01:00:00"
- condition: state
entity_id: select.harmony_hub_activities
state: power_off
for:
minutes: 1
action:
- service: light.turn_off
metadata: {}
data: {}
target:
device_id: light.downstairs_lamps
mode: single
as you go forward, it is definitely better to use state and numeric state (and all the other more logical triggers and conditions) . in the perfect world, you go fix up the stuff you have… but can also do it over time.
“why” have device id? well… there are some boundary cases where you should use device id. but that’s rare. why do they exist? that’s kinda like why mac addresses exist on network cards. it’s the real unique id for that one physical piece of hardware. every network card has a mac address. every one of these devices have a specific device id. if you ever want to specify THIS ONE… (and not have it work if you were to swap it out with another identical device) then use the device id.
hopefully that makes sense.
regardless, i’m glad you’ve got it working. and i’m more glad you’re learning about ha!
I edited my post above yours to explain why i still need the switch option as it triggers at a different time
not sure what you mean by “why” have device id? well…
might be becasue i did not run the tracer and did not change the entries as copied and replaced the ID number with the entry name and i might of not noticed the device id changing if that make sense, when HA runs it again tomorrow it prob change if that make sense
i just refreshed it and edited the post above yours and the code should look right now, does look cleaner.
If you feel like @armedad provided a resolution, I would mark his post as the solution and click the like button(heart). It helps folks in the future who may experience a similar situation.
if you look carefully at my code, it does do exactly what you asked. it does trigger at different times…
the trick here is to look at my condition block. It says it must be past 10:30 AND the hub must be off for 1 minutes.
The trigger is set for both 10:30 and after the hub is off for 1 minutes. So it will TRY… to trigger both times, but the condition will not allow the actions to run at 10:30 unless the hub has been off for 1 minutes. And it will also not allow the actions to run if the hub turns off before 10:30…
this is a common trick to trigger at the later of two triggers…
so I understand why you thought you needed the conditions… but think carefully about what I wrote and you’ll see that my code does what you want. And this is a valuable method for you to use in the future.
Ah right, I wondered why you used the 1 min option after the timer because your using two variables that have to be met and if both are met it will turn the lights off
As if I had one variable check at 10:30 and the trigger has ran and passed the lights would not turn off if the hub was turned on but after the trigger event of 10:30 eg. I turn the hub off at 11 by me it would do nothing as the event has passed and the lights stay on. so by using the 1 min option as the 2nd condition to the 10:30 to 01:00 timer it would turn the lights off if the hubs been off for over 1 min within the time frame so would still turn the lights off if I turn the hub off at 11
So, if I am still watching tv and the hub is set to sky and the trigger runs at 10:30 and see the hub on and has not been off for 1min then would try again when the hub has been set to off and has been off for over a min and after 10:30 and before 01:00 to Trigger the lights off
So the 1min timer is making the condition run all the time until it’s met otherwise it would just run the once at the set time.
And this also means I can remove the switch state routines as this is no longer needed because of the 2nd condition in the timer routine.
Is that right ? Or have I messed that up lol.
The way I was reading a condition block is that it runs all of it regardless then jumps to action I never thought a condition block could have more than one condition as I thought you would have to create two condition blocks to do what you said
yup, you’re understanding how it works. you’ve got that right.
now let me push my luck and go for some bonus points.
you initially said that if it is 10:30 and the lights are on, then leave it the lights on if harmony was not turned on between 18:00 and 22:30. in this latest version you left that off. (which i agree with!)
but the first version i gave you included that capability by doing this:
what this says is that “if it’s 22:30 (and the harmony is off) the harmoney_hub state is required to have changed sometime after 18:00”. if you think about it, this ensures that the harmony was turned off sometime after 18:00… if it hasn’t changed since before 18:00 and the state is off, that means it’s been off the whole evening.
so if you want to have your very original request that the light is left on at 22:30 if either the harmony hub is on OR if the lights were turned on manually/not via harmony, then you want to go back to my first automation and include this… but again, i like the elegance and simplicity of what i posted earlier today (about 7hrs ago).
hopefully this all makes sense and is also interesting/fun for you
ah right thanks i thought but still best to ask, by the way i tried it and worked a treat your code.
thanks
I am altering another routine and it’s so strange trying to figure out how to replace the device type option as you suggest its best to use state or numeric state. its so easy to use the device option but trying not to do so.
so, if each device has its own id it’s fine to use it but let’s say a bulb and i unplug it and plug it back in it will never change its id in HA??? Only if the bulb stops working and i had to change it for a new one the bulb would have a different ID in HA Which would stop my automations that used that bulbs id and i would have to find that bulb in all my automations that use the broken id and change it to the new bulb id, is that correct
so its best to use the names as if you swap the broken one for a new one it will still use the same name and will just work in all the automations its tied to.
also, don’t you find the entity_id names just easier to read? and if you accidentally have a typo in the entity_id, it’s much easier to find than if you accidentally screw up a device id.
on top of that, once you get more advanced, you can do interesting tricks… like using switch.{{ variable_name }} and have the entity name be passed in. but that’s for when you get more fancy
finally, if you look at the example that you changed, you have to admit the second one has way higher code beauty points than the first…
Yep agree the code looks Much tighter, I am using the gui based system to add my routines and when you add a device the gui interface is totally different to when you use a numeric state and you have to figure that part out if you know what I mean.
in the device gui
Pick device hue hub
Pick hue hub illuminate
Pick lux 3
In Numeric state gui
Pick sate hub illumination
Less than 3
What I am trying to say is that if you pick device and want to change it to numeric state or start with a state it Looks different and can throw you as you expect it to be the same menu options as device but it’s not, eg in device it actually says lux but in numeric state it just says below
I have to admit looking at the yaml sequence
Of each entry by gui does help A lot as your seeing what it’s doing more clearly at times.
I do see why people use device as it seem to be more self explanatory than picking state or numeric state in the gui menus.
Seen many posts On here where they use device and you see their code with the long numbers. But I suppose until something brakes you will Never know why until it’s a pain to sort out.
Just great full you pointed that out straight away as many posts I seen people try to help with the automations but don’t point out the device id could cause problems on top later on.
Also i need to start thinking how some things work like your automation because i thought your automation would run once at 10:30 and that’s it but by putting see if hubs been off for 1 min actually stops the automation if false until all entries are met and passed that’s when the automation has ran its course and will not just run the once.