They make perfect sense and work exactly like they should. What is confusing you?
I had already tried his solution and it didn’t work, I’ll give it another try and see why it didn’t.
They make perfect sense and work exactly like they should. What is confusing you?
I had already tried his solution and it didn’t work, I’ll give it another try and see why it didn’t.
Okay, lets go back and look at what you have (not all of this is your fault nor is it particularly problematic, I’m just pointing stuff out, you are clearly happy with it so just dont change a thing).
The below is your current solution : -
- alias: Turn US Lights on Between 11:00 and 19:00
hide_entity: true
trigger:
- platform: homeassistant
event: start
- platform: time
at: '11:00:00'
- platform: time
at: '19:01:00'
action:
- service_template: >
{% if now().hour > 18 or now().hour < 11 %}
switch.turn_off
{% else %}
switch.turn_on
{% endif %}
entity_id: switch.lights_us
From the above : -
Instead I’d use trigger template and sensor.time (look it up) it only changes 1/minute so results in 60 times LESS evaluations, also its easier to read/change and match (only 2,880 evaluations)
So my solution would be : -
- alias: Turn US Lights on Between 11:00 and 19:07
trigger:
- platform: homeassistant
event: start
- platform: template
value_template: "{{ states('sensor.time') == '11:00' }}"
- platform: template
value_template: "{{ states('sensor.time') == '19:07' }}"
action:
- service_template: >
{% if '11:00' <= states('sensor.time') < '19:07' %}
switch.turn_on
{% else %}
switch.turn_off
{% endif %}
entity_id: switch.lights_us
Uses the same values in both, easy to maintain, more efficient
Note: 1 adjusted the off time to 19:07 to make sure you saw it was not whole hour dependent.
But as I said, you are happy, don’t change a thing
Note 2: sensor.time is part of the sensor time_date integration, to use it you need (in your configuration) : -
sensor:
- platform: time_date
display_options:
- 'time'
- 'date'
- 'date_time'
- 'date_time_iso'
- 'time_date'
- 'time_utc'
- 'beat'
Well, you need the first 2, ditch the rest if you like
Edit: NOTE that you can only have ONE sensor: heading in your config (unless you use packages)
You ‘could’ change the on and off times using input_datetime’s (has date false) which would mean you don’t need to change code or reload
Edit Again : I’d only really use platform time trigger, if I need a switch/light to come on at (say) ‘17:23:48’ and who needs that kind of ‘to the second’ accuracy ?
I’m a complete noob (installed home assistant the first time one week ago). So I am still using the GUI for automations (yes, I know, like a cave man ). But would this not work? I am doing it for a switch, but the same would apply for a light:
Instead of posting a screenshot of your automation, it’s preferable to post it as YAML. For future reference, in the upper right hand corner of the Automation Editor is the overflow menu (three vertical dots). Click it and select Edit in YAML. Copy-paste the displayed YAML into your post to share it with others.
Your posted automation should work but there’s a potential problem with using a very long delay
(you’re using 8 hours). If you restart Home Assistant (or Reload Automations) while the delay
is underway (so at any time during its 8-hour countdown) the delay
is cancelled. That means your coffee pot will be left on indefinitely.
The preferred way is shown in previous posts. Both the start and end times are Time Triggers and the automation’s action
doesn’t employ a delay
.
Thanks! I’ll do that in future. Was my first post. And what you say makes 100% sense. I will do it like that.
Why not use action type Condition? Something like that?
alias: Christmas Tree Light
description: ''
trigger:
- platform: homeassistant
event: start
- platform: time
at: '16:00:00'
- platform: time
at: '22:00:00'
condition: []
action:
- condition: time
after: '15:59:00'
before: '23:00:00'
- type: turn_on
entity_id: light.wiz_smart_plug
domain: light
- condition: time
after: '21:00:00'
before: '23:00:00'
- type: turn_off
entity_id: light.wiz_smart_plug
domain: light
mode: single
Because the automation you posted uses inline conditions and doesn’t work the way you think it does.
If the first condition evaluates to false
the execution flow stops (it does not proceed to check the second condition).
For example, when the Time Trigger triggers are 22:00
the first inline condition will evaluate to false
and no additional actions will be executed.
I mistyped the first condition. I fixed the time from 21:00 to 23:00. Now when the trigger executes at 16:00, the first condition is true and the light is turning ON.
When the second trigger is executed, the first condition is still true and it will try to turn the light on, but it is already ON, so it goes to the next condition, which is true, and execute the second action, which is turning light off.
Imagine someone manually turned off the lights before 22:00
. At 22:00
, the lights will receive two commands in rapid succession, the first to turn on and the second to turn off. Depending on the lighting technology, one may see a brief flash.
It’s a poor way to do it and that’s why there are almost no examples, in this community forum, promoting this technique. There are simpler and more robust methods (already explained earlier in this thread).
Hy @Burningstone @Mutt @HellfireZA you are using that “hide_entity: true”.
Can you tell me what this does?
This option was deprecated a loooong time ago.
So i can just drop this?
Or is there any code that takes its place?
It does absolutely nothing, it has become obsolete with lovelace.
I am a cave man, and I can understand the screen shot better then yaml. I think that 98% chances your server wont be down so for me I am ok with the light or coffee staying on a couple times a year. If I notice it on, ill turn it off by hand