I have never written blueprints before. I would like to implement a CA title 24 vacancy sensor. They normally work like this :
initially turn on the load by manually pressing a physical switch, or using HA, or using a physical remote. The method of turning on the switch is not really relevant to this automation.
after a (configurable) set amount of time elapses and there is no motion detected from the motion sensor, turn off the load/switch
if there is motion shortly after step 2 (typically within 0-30s or 0-60s), turn the load/switch on. This step is only ever applied if step 2 has turned off the load, never in any other case.
I can easily implement step 2 with a basic automation if I have a smart switch and motion sensor device. However, I donât see how to implement step 3. This requires a nested automation. I donât think itâs possible with the GUI, but is it possible with a blueprint, and if so, how ?
Thatâs easy. (even in the UI) Just add another trigger based on motion and a condition that the automation only runs if the switch (load) was turned off recently (within your preset timeframe) You can exclude the manual turning on from the automation and do that outside of this.
Can you please clarify how to do this with the GUI ? I thought all the triggers in the GUI were logical OR . Is that not the case ?
Or did you mean that I should write a separate automation for step 3 ? But if so, how would I pass the time around between the two ? I guess I have only written some fairly basic automations despite having used HA for the last year.
Here is an example of automation I have for step 2 .
alias: >-
Turn office light off when ZWave motion sensor detects no motion for 10
minutes
description: ""
trigger:
- type: no_motion
platform: device
device_id: 6b90264c3367435453d6c7deb88ab3ed
entity_id: binary_sensor.office_motion_sensor_motion_detection
domain: binary_sensor
for:
hours: 0
minutes: 10
seconds: 0
condition: []
action:
- service: switch.turn_off
data: {}
target:
entity_id: switch.office_ceiling_light
mode: single
If you use trigger_idâs then you can have a nice tidy automation with everything in the one place.
Have a trigger for step 2 as you have above (although I would steer away from using device, just use entity_id) and give this a trigger_id of âoffâ.
Create a second trigger with trigger_id âonâ, being the motion sensor state to âonâ, but with no for: section.
In your action, use the choose: function based on the particular trigger_id. If the trigger_id is âoffâ, turn off the load.
If the trigger_id is âonâ then have a subsequent condition that the loadâs state change must be within the timeframe you wanted (within the last 30 seconds, or whatever you want)
Thanks again ! The trigger id is very nifty.
I still have 2 questions :
what type of trigger do I use for entity instead of device ?
There is no âentityâ drop-down in the GUI for the types of triggers. I have been using Device triggers for most of my automations. Is there something wrong with it ?
unfortunately, I just couldnât figure out the part about checking the time since step 2, even with the link you provided . Is this part doable in the GUI as well ?
2:
I havenât actually done this myself, only look at that example. Iâll have to have a play with the template dev tool to figure it out, but yes, it can be done in the UI as you can add YAML in there. See âedit in yamlâ:
Edit: this seems to work, though very short duration for the first trigger (seconds) donât seem to work - or at least not quickly. Thatâs likely an issue with my motion sensor not reporting the state change fast enough. Itâs a ZSE18.
Edit2: now I need to turn it into a blueprint, since I have 4 switches that need this automation and I donât want to just duplicate the automation. Thatâll be for another day, though.
Thank you !
I think there is one remaining problem in the automation, though - if the switch is manually turned off, I donât want it to turn back on, even if there is motion in the next 30 seconds. This is to mimic the behavior of a real California Title 24 vacancy switch.
How are you manually turning it on/off? Via a physical device button or the HA GUI? Depending on this we should be able to create an additional condition.
Sometimes I do it from the HA GUI, but rarely, maybe 5% of the time. Most frequently, I do it using an X10 remote, either RF remote + RF to PLC transceiver or IR remote + IR to PLC transceiver. Those remotes end up transmitting signals on the power line that HA captures.
The 4 switches in question are X10 XPS3 and all control recessed lighting . If I press the switches themselves (either to turn on or turn off) there is no feedback over the powerline unfortunately, so HA cannot know the real status of the switch in that case.
This is a deficiency in the X10 hardware unfortunately, nothing that can be solved in software. I have not found anything equivalent to the X10 IR543 (IR to PLC transceiver) in the Z-Wave world, or by any other vendor than X10, really.
I never operate the first XPS3 switch directly, as itâs located behind my office door. For the 3 other XPS3 switches in my home theater, I sometimes turn them on/off directly at the switch. Itâs important for the lights not to turn themselves on accidentally in the home theater as itâs a windowless room with a projector and screen, and any amount of light significantly impacts the picture. Typically I turn off the lights with my ARRX18G learning IR remote from the couch, though, but again, not always
I think the automation shouldnât necessarily need to know the state of the switch to work (especially since the XPS3 switch state is partially unknowable). It just needs to know the last time the automationâs âoffâ condition was triggered, record it into some variable, and then, if the âonâ condition is triggered, have a condition that checks the difference between current time and the last automation-off (and not any other OFF source), before turning the switch back on.
When editing in YAML, you can determine when a light is turned off, if it was done manually (physically on the switch itself) using this as a condition:
Then use this in a simple automation to populate an input_datetime named âlast_manual_offâ with the current exact date and time.
Then, in any automations where the light would go on (from say motion detected), add as a condition in each of those automations to continue that automation to turn the light on only if this is true:
current datettime > (last_manual_off + (5 minutes or whatever))
Works like a charm for me - I was running into a situation where someone would turn a light off to then leave the room, but as soon as they walk towards the door the light would go back on again! So in my case I am essentially ignoring any motion sensed to turn the light on for 5 minutes after it was manually turned off. FYI, for my calculations above, it would only work intermittently, but I discovered I had to convert the datetimes to longs to then add the 300 seconds (5 minutes) to then compare the two longs (seems to be the most reliable accurate way to do it - it always worked after I did that). FYI from the get go - the above piece of logic always worked perfectly in determining if it was manually done.
FYI, I have found no other way to historically determine when the last time a light was turned off, if it was turned off manually or not. I think those trigger context details are never stored anywhere in the historical DB (would be great if they were, then I wouldnât have to jump through these hoops!).
My code may be whacky, but the above works an saves properly, but when you go to edit the automation, in the visual editor it is not shown, you switch to âedit in yamlâ and they suddenly reappear (they are there but hidden - weird!)
KruseLuds,
Thanks. I will try to use it when automating non-X10 switches. I donât think itâs possible to determine the state switch for X10 switches. Reason being they are write-only devices. You canât query their state programmatically. For example, if HA restarts, it cannot know their state. When you press these switches directly there is no signal of any kind being sent anywhere. And itâs not possible for to do a state query on the switch. You could call them ânot-so-smartâ switches. Yet they work with direct IR and indirect RF control, making them ideal for my home theater use, so I still have them. The motion sensor integration part remains to be fixed, though.
I wouldnât know what to replace X10 with. I like the X10 remotes very much. They can function without HA.
I especially like the IR543 which allows any IR remote to be used. No equivalent exists, AFAIK. I wish the switches could be queried, if course.
In the home theater which is a dark room, combined with my macular degeneration, I donât find the phone to be a compelling UI. Certainly itâs much slower than tactile buttons on an IR remote, RF bu
Anyway, it should be possible to create an automation even for switches you canât interrogate. The main relevant input are the motion sensor and time. The output is the switch state.
Let us know if you need more help implementing the condition to prevent the load being switched back on after being manually turned off. The idea from KruseLuds should work for you.
Dave,
Thanks for the offer. I do need more help. I donât see how KruseLudsâ idea helps. Honestly, the automation never needs to determine the state of the switch. This should be obvious by reading my OP. I donât need to know if the switch in the ON or OFF state for either step 2 or step 3.
For step 2, if there is no motion within the set time, the automation just needs to set the switch to OFF state. If itâs already ON (regardless of how it was turned on, physically, with a remote, or in HA), it turns it to OFF. If itâs already OFF (regardless of how it was turned off), itâs a no-op. Either way, it should behave as intended, without needing to know the switch state at any point.
For step 3, same thing. If there is motion between the time of step 2 was executed and, say, 30 seconds later, it sets the switch to ON. It has no need to know what the current switch state is.
