Ok in the YAML I have 2 “After” conditions but only 1 “Before” would this break the time condition regarding spanning the midnight threshold if both “after and before” are used, would adding another before as shown below make this work
thanks
alias: DOWNSTAIRS HALL NIGHT MOTION
description: ""
trigger:
- type: motion
platform: device
device_id:removed
entity_id: removed
domain: binary_sensor
for:
hours: 0
minutes: 0
seconds: 0
- type: no_motion
platform: device
device_id: removed
entity_id:removed
domain: binary_sensor
for:
hours: 0
minutes: 2
seconds: 0
condition:
- condition: sun
after: sunset
enabled: true
- condition: time
before: sensor.sun_next_rising
weekday:
- mon
- wed
- tue
- thu
- fri
- sat
- sun
enabled: true
after: "21:00:00"
before: "09:00:00" <<<<<< do i need to add this
action:
- if:
- type: is_motion
condition: device
device_id:removed
entity_id:removed
domain: binary_sensor
then:
- type: turn_on
device_id:removed
entity_id: removed
domain: light
brightness_pct: 10
else:
- type: turn_off
device_id: removed
entity_id: removed
domain: light
mode: single
Perhaps there’s a bug in how the Time Condition computes the time range when sensor.sun_next_rising is used to define the range’s boundary.EDIT Not a bug. Behavior is due to the operation of the first Time Condition. See dbrunt’s explanation below.
Multiple conditions default to ‘and’ unless you specifically use ‘or’ so in your first post, the first condition is after: sunset which defaults to before: midnight which results in ‘false’ after midnight so any other condition doesn’t matter. All conditions have to be 'true` to proceed.
Your two conditions do not make any sense to me, especially the second one with every day of the week specified!
I would just use an overall condition after: sunset & before: sunrise to prevent daytime processing and then in your actions use ‘if’ to determine what you want to do based on whether the time is before or after 9:00 pm.
Copy-paste the following template into the Template Editor and report the results:
{{ states('sensor.sun_next_rising') }}
{{ states('sensor.sun_next_rising') | as_datetime | as_local }}
Result type: string
2023-12-30T08:48:41+00:00
2023-12-30 08:48:41+00:00
This template listens for the following state changed events:
Entity: sensor.sun_next_rising
Good point. There are two Time Conditions and the first one effectively reduces the overall time range. Therefore there’s no bug in the second condition and it’s the combination of the two Time Conditions that explains its ultimate behavior.
Thanks but, as explained by dbrunt, your first example uses two Time Conditions. The second one spans midnight but the first one doesn’t. The two conditions are logically ANDed so that’s why the overall time range is limited by the first Time Condition.
I suggest you remove the first Time Condition and simply use the second one.
If you’re not going to turn on the light at a different brightness after sunset & before 21:00 then there’s no need for the condition after sunset & before sunrise. Just use the condition after 21:00 & before sensor.sun_next_rising as your single primary condition.
It all depends on your overall desired behaviour.
i have 2 profiles depending on time to adjust brightness
indicates you different brightnesses that but there’s nothing in this automation dealing with that, but it certainly could.
Consider this automation which will
turn on the lights at different brightnesses between sunset & surise when motion is detected
turn on the lights at sunset if motion is already detected
at 9:00 pm will change to reduced brightness if motion is already detected
turn them off when motion is clear or at sunrise
alias: Living room automatic lighting
description: ""
mode: single
trigger:
- platform: state
entity_id:
- binary_sensor.living_room_occupancy
to: "on"
id: Motion
- platform: state
entity_id:
- binary_sensor.living_room_occupancy
to: "off"
id: No Motion
- platform: sun
event: sunrise
offset: 0
id: Sunrise
- platform: sun
event: sunset
offset: 0
id: Sunset
- platform: time
at: "21:00:00"
id: 9:00 PM
condition: []
action:
- choose:
- conditions:
- condition: trigger
id:
- Motion
- Sunset
- 9:00 PM
- condition: state
entity_id: binary_sensor.living_room_occupancy
state: "on"
sequence:
- choose:
- conditions:
- condition: sun
after: sunset
- condition: time
before: "21:00:00"
sequence:
- service: light.turn_on
target:
entity_id: light.living_room_lights
data:
brightness_pct: 80
- conditions:
- condition: time
after: "21:00:00"
before: sensor.sun_next_rising
sequence:
- service: light.turn_on
target:
entity_id: light.living_room_lights
data:
brightness_pct: 20
- conditions:
- condition: trigger
id:
- No Motion
- Sunrise
sequence:
- service: light.turn_off
target:
entity_id: light.living_room_lights
data: {}
It’s easier to maintain your automations if you avoid using type: turn_on as device_id: will undoubtedly change at some point like when a sensor fails and you have to replace it, which will require you to edit all automations that used the old one.
Using service: light.turn_on means you only have to ensure the new device ends up with same entity_id the old one was.
These posts couldn’t have came at a better time, I managed to get local-tuya installed and was worried all my automations would break when I attempt to change over from cloud tuya, I’ve done what you said regarding entities.
Before you had done this I managed to get 2 automations into 1 (basically the same automations with different time/brightness profiles as above) however, doing this with 2x IF/THEN statements wouldn’t work, one would switch on the lights and the other after 2 seconds would switch it off as shown below
so after that I used “choose between 2 actions” with 2 IF-THEN statements,
I did however keep sunset and sunrise rather than state below horizon because it is too dark for a while, while the sun sets
and then I went back and changed all the devices to entity ID’s
I’m not sure if your automation has benefits over the way i have done it? I did copy your automation into a new automation YAML and have a look at the visual editor but its well above my understanding for what’s going on
it currently works but i have not tested it past 9pm or 12am yet
thanks again
alias: new test downstairs hall PIR CHOOSE - IF /THEN SERVICES
description: ""
trigger:
- platform: state
entity_id:
- binary_sensor.downstairs_hall_motion_sensor_motion
from: "off"
to: "on"
- platform: state
entity_id:
- binary_sensor.downstairs_hall_motion_sensor_motion
from: "on"
to: "off"
for:
hours: 0
minutes: 2
seconds: 0
condition:
- condition: sun
before: sunrise
after: sunset
action:
- choose:
- conditions:
- condition: time
after: "21:00:00"
before: "09:00:00"
sequence:
- if:
- condition: state
entity_id: binary_sensor.downstairs_hall_motion_sensor_motion
state: "on"
then:
- service: light.turn_on
target:
entity_id: light.hall_lights_light
data:
brightness_pct: 10
else:
- service: light.turn_off
data: {}
target:
entity_id: light.hall_lights_light
- conditions:
- condition: time
before: "21:00:00"
after: "13:00:00"
sequence:
- if:
- condition: state
entity_id: binary_sensor.downstairs_hall_motion_sensor_motion
state: "on"
for:
hours: 0
minutes: 0
seconds: 0
then:
- service: light.turn_on
data:
brightness_pct: 100
target:
entity_id: light.hall_lights_light
else:
- service: light.turn_off
target:
entity_id: light.hall_lights_light
data: {}
mode: single
This automation looks okay to me but I prefer my style which I find easier to debug.
Your automation more or less done my way would be:
alias: new test downstairs hall PIR CHOOSE - IF /THEN SERVICES
description: ""
trigger:
- platform: state
entity_id:
- binary_sensor.downstairs_hall_motion_sensor_motion
from: "off"
to: "on"
id: Motion
- platform: state
entity_id:
- binary_sensor.downstairs_hall_motion_sensor_motion
from: "on"
to: "off"
for:
hours: 0
minutes: 2
seconds: 0
id: No Motion
condition:
- condition: sun
before: sunrise
after: sunset
action:
- choose:
- conditions:
- condition: trigger
id:
- Motion
sequence:
- if:
- condition: time
before: "21:00:00"
after: "12:00:00"
then:
- service: light.turn_on
target:
entity_id:
- light.hall_lights_light
data:
brightness_pct: 100
else:
- service: light.turn_on
target:
entity_id: light.hall_lights_light
data:
brightness_pct: 10
- conditions:
- condition: trigger
id:
- No Motion
- condition: state
entity_id: light.hall_lights_light
state: "on"
sequence:
- service: light.turn_off
target:
entity_id: light.hall_lights_light
data: {}
mode: single
which I find easier to dig through & understand. It also has the benefit of being able to easily add to or change the motion triggers in one place if you need to, plus it’s 8 lines shorter than yours!
Please consider marking my post above with the Solution tag. Only one post in the entire topic can have this tag. It leads other users directly to it by automatically placing a link in your first post and adding a checkmark to the topic’s title. All of this helps users find answers to similar questions.
For more information about the Solution tag, please refer to FAQ Guideline 21.
