CA Title 24 vacancy sensor blueprint? Need nested automation

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 :slight_smile:

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:

  - "{{ != none }}"
  - "{{ trigger.to_state.context.parent_id == none }}"
  - "{{ trigger.to_state.context.user_id == none }}"

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!)

Hope that helps!

1 Like

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.

Sorry I misunderstood. Replace all the X10 stuff and control it all with your phone! :slight_smile:

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.

1 Like

Hey, if your load to turn on is a light, I would recommend this sensor light blueprint.

Very easy to use, with many configurable optional features, used by quite a lot of people (so pretty tested).

Not sure if you can turn on a switch with this, but maybe a scene or simply changing the switch type might work.

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.

Thanks. I will take a look at it now.

Edit: I just did, and it has a ton of options, but unfortunately doesn’t look like it can do what I am trying to achieve.

My main use case is auto-off (step 2). The auto-on use case (step 3) is only because the motion sensor sometimes isn’t sensitive enough and fails to detect motion erroneously. Waving arms at the sensor when finding oneself accidentally in darkness can then solve the problem. This is how all California title 24 light switches operate (mandatory for bathrooms and kitchen in new construction) - they combine a motion sensor and a wall switch. I have about 97 of them around my house. All of them are dumb models. I’m trying to replicate the behavior, but with (semi-) smart switches.

You can use Shelly buttons to do what you want possibly. Also you can stay with the old switches and even make them smart by setting them to edge and putting a Shelly relay behind them in the switch boxes…

Thanks. Shelly is not really an option for those 4 X10 switches, also. They are deep and barely fit in the electrical boxes - probably no place to put a Shelly behind each one and especially not the extra wiring for them.

I don’t understand why any new hardware would be required in this case. The motion sensor detects motion/no motion. The switch can be turned on or off. It seems to me to be purely a software problem, not hardware. Are the automations in HA not powerful enough to do what I need ? It seems to me all that’s missing is recording the time of the automation’s last shut-off into a variable, and adding some if statement in the automation’s branch when motion is detected. I guess those things are not possible to implement in HA ?

Challenge accepted.

I don’t have a complete solution, but I’d look into examining the state object of the automation itself to look for a “last triggered time”. It’s exposed in the UI, so it’s probably in the state somewhere.

I’m working on setting up something similar for my bathroom, with the additional complication that I’ve got three different switches, two of which are dimmers. I want to first dim the lights as a “warning” before shutting them off, but allow restoring them to their original level if there’s motion during the timeout period.

Before I switched to HA I was a Hubitat user, and used the [RELEASE] Lights on Motion Plus (dim before off, remember individual bulb states, etc.) - Custom Apps - Hubitat app, which is where I got the “dim to warn” idea from.

I’m pretty sure this would require tracking custom state inside the automation itself, which AFAICT is not easy to do in HA.

Sure, use HA to talk to the motion sensors and switches directly then, no issue. What I was trying to say, was you wouldn’t even need to replace any switches - not even dumb ones - if you added in a relay. This all is easily done in HA, it is so flexible you can have numerous devices all from different manufacturers, interact with each other. No other system that I know of offers that much flexibility with so very many manufacturers either. So the answer is, yes HA can do everything you need

Thanks. Please let me know what you figure out for your bathroom. I looked for “last triggered time” on google and found this :

It doesn’t have a specific trigger associated with it in that example, just an automation, no trigger id. So, it may take 2 automations for one switch if I understand correctly. One for the simple OFF part like I had at the beginning of this thread, and another for the ON part that would track the last time the OFF automation was executed and have a motion ON trigger and condition (<30s) to turn the light back on.
This is less than ideal since the switch and motion sensor would both have to be specified twice, in two separate automations. Or perhaps the trigger ID can be used here too with “last_triggered” attribute ?

Yes, I understand how Shelly work - they work with any switches. They require space in the electrical boxes, though. And I pay someone to install switches, also, so this is not the most attractive option.

So my question was really, can I use HA with my existing Z-Wave motion sensor with X10 switches to create the equivalent of a CA Title 24 vacancy sensor, ie. without changing the hardware ? And that to me seems like a software question, which is why I’m positing here. Perhaps there is indeed a way to create that automation, I just haven’t figured out what it is.

Sorry I haven’t been any more help here. A little busy / distracted at the moment. If I get time I’ll work on the above automation for you, but the answer is yes, you can do it.

1 Like

No need to apologize. Take your time. I appreciate your help and others’ very much.

It’s been a couple months, and I’m still no closer to having this solved. Do the HA wizards have any idea to accomplish this ? I am adding a bunch of Z-wave switches (smart ones, that can report their status) but would really like to have the vacancy sensor behavior with them.