- alias: 'Bathroom lights off when no motion'
id: 'Bathroom lights off when no motion'
initial_state: 'on'
trigger:
- platform: state
entity_id: sensor.bathroom_motion_sensor
to: on
- platform: state
entity_id: sensor.bathroom_motion_sensor
to: off
condition:
condition: time
after: '07:00:00'
before: '00:00:00'
action:
- service: script.turn_off
entity_id: script.switch_off_lights_delay
- condition: template
value_template: >
{{ is_state('sensor.bathroom_motion_sensor', 'off') }}
- service: script.switch_off_lights_delay
and see if the adjusted trigger would prevent a loop by preventing unwanted triggering in attributes changes.
Current situation is that the automation is working and the script is working. Have not tested the if humidity > 50 part yet.
So the light turns on when motion is detected and it will turn off after time has passed if there is no motion. If motion is seen during the timer, it will reset it. So now that part works as intetended!
I will keep testing and report back to you!
But again, thank you! This would have been impossible for me to tackle alone!
so you’ve got all variables in place, and things are much tidier than with the first attempts at a trigger template. Let alone the possibility of restart, and, important, extensibility.
The code seems to work for me too based on one night testing.
One thing I started to think about is that if I would like to make the logic better the automation would react to humidity on lower levels. This because now there is a chance that the humidity is still too low and the longer timer does not trigger. And also after the shower there is no need for the timer to be so long so the timer should be shorter but the humidity is still too high eventhoug it drops pretty fast (unless really long shower).
I think that would be the next step to make the code even better but need think closely on the facts that triggers the timers
But for now, the code works so that it makes life easier
Great.
And yes, that’s the way to go on and develop. Now it’s working and the logic and structure are as it should be, you can add conditions, or change current ones to your needs. Remember to decide where you add or change, in automation or scripts. If a script stops (because of a condition not being met, the main automation will still go on. While if you put all in the automation the automation would then stop …
I have been using the automation for a while now and it seems to work pretty well. Only thing that I’m trying to change is that there would be 1 minute delay before the humidity is checked. This is because when someone goes to showe, motion sensor goes really fast to ‘off’ and this means that the automation triggers and humidity is still really low. If that would be delayed like a 1 minute, the humidity would have risen enough.
I tried to add delay to automation but that did not actually work. First it seemed like OK but later I noticed that the timer does not reset always when there are motion so it was not usable. The code looked like this (I tried multiple positions for the delay part so not sure if that was the best place for it):
- alias: 'Bathroom lights off when no motion'
id: 'Bathroom lights off when no motion'
initial_state: 'on'
trigger:
- platform: state
entity_id: sensor.bathroom_motion_sensor
to: 'on'
- platform: state
entity_id: sensor.bathroom_motion_sensor
to: 'off'
condition:
condition: time
after: '07:00:00'
before: '00:00:00'
action:
- service: script.turn_off
entity_id: script.switch_off_lights_delay
- delay: '00:01:00'
- condition: template
value_template: >
{{ is_state('sensor.bathroom_motion_sensor', 'off') }}
- service: script.switch_off_lights_delay
Scripts:
switch_off_lights_delay:
alias: Switch off lights with delay
sequence:
- delay:
minutes: >
{{ '2' if states('sensor.zha_01ddaf89_1_1029' ) | int >= 25 else '1' }}
- service: light.turn_off
entity_id: light.bathroom
well, here you are,… this seems to be the exact issue I had when I wanted to have a delay built-in on the trigger, and created my intermediary binary_sensor template we discussed in the beginning of this thread.I use it as a wait_template, but maybe (behavior of these sensors is not always as you’d expect, so you have to try) you can already set in in the trigger section:
If suggest replacing the second trigger with a new sensor, it has a delay for the state Off of a minute, and if motion is detected won’t turn Off, so the automation won’t trigger on Off yet):
reason I suggest shit is it woud always reset the full automation if motion would occur during the wait.
I have an automation using this which is only triggered on to: on, so works a bit differently. I post it here for your information, and maybe second option to try if above wouldn’t go as you want it to:
Thank you again, I shall try to get this working Just to clarify that I still call the script like currently, just add the wait_template to the automation?
Hmmm… OK, so the humidity check goes to the automation part then? Since I need there to be 1 minute delay before the humidity check that then decides if the lights are turned of after 2 minutes (total in three) or in 14 minutes (total in 15).
It is a bit hard to test the automations because when I reboot the HA my turn on automation is not triggered anymore at all :S I have to rewrite it multiple times until it suddently starts working. And no info on logs.
all automations or only this one?
there are many issues with automations not triggering after updating to I think 0.84.xx not sure which it was. Had the issue myself today after a reboot, and restore state didn’t work at all. If that happens you can either chose to us the initial_state: on on all automations, (which I don’t want because I want my automations to be set through the interface, and be able to dynamically change them) or trigger them once manually to have that state stored in the .storage/core.restore_state.
not really sure what that means…
but, if you have changed the automation to the above, you should be able to trigger it manually in the all_autmations group, or on the dev-service page.
Automations that turn the light on (night and day modes) are the one that I have seen affected, do not know if others have problems since those are more rarely used.
Rewriting means that I delete the automations related to the turn on function and reload the yaml and then add it again in reload again.
I had a quick try on the automations you gave me. It did not work for some reason. The automation had always state “on”, do not know if this is related. It stayed “on” even when reverting the code and rebooting so might be a bug in the HA.
But have to try again later since the automations have been acting up. I have version 0.85.1 so do not know if there is something in that version this is causing this?
you’ll have to search the community for that I am sorry, I didn’t upgrade because of that reason and a few others to be solved first…
this is good isn’t it? It simply means the automation is set to run, waiting for triggers to happen. It doesn’t mean the automation is being run at the moment.
I havent read anywhere you have to rewrite your automations at all, so I don’t know why you are doing that. only thing people are doing is add the initial_state: on to their automations. But, as said, I don’t want that, I want recorder, or now the .storage to take care of restore state.