Best practice for rules involving randomization, rules involving hunman intervention

Can someone offer an opinion on the the best way to accomplish these 2 simple things:

  1. Add randomization to the timing of certain rules:

When not at home, I would like certain lights to go on/off with a bit of randomness so that it does not appear to be programmatic. i.e. NOW: lights x,y and z turn on at sunset, and turn off at 11:45 pm. GOAL: A random interval inserted before every on or off command so that each day the timing is slightly varied. Presently the only way I can think of to do this would be to create a parent rule, which triggers a list of children rules (x,y and z), each child having 2 events, some kind of sleep timer (a script?) and then send the command itself. Is there a cleaner way to do this? Should I skip the GUI and just write a script?

  1. I would like to opt-out of certain automation rules, if the related thing was recently manipulated by a person.

e.g. If a light was turned on by a rule, the light can/should also be turned off by a rule. BUT if the light was turned on by a person, i prefer that the person overtakes responsibility for the state of the thing, and certain automation rules should no longer apply.

This would mean that certain people wouldn’t get upset when she finds herself in the dark due to a bot/rule because; “obviously I want the lights on, I JUST turned the lights on”!

I can imagine any automation rule setting a state like “bot-activated” to be “true”, and then ONLY fire related automation rules if “bot-activated” is still true, however, unless I manipulate the “bot-activated” state whenever controls are manually manipulated (without a rule), it won’t actually accomplish the goal. What’s the concept I’m missing here?

I’m still pretty new to this. Your thoughts are much appreciated.

On question 1, read This Thread
On question 2
One way of doing it would be by using a (proxy-) item which tracks wether the switch was triggered by a rule ( On only if the switch was enabled by a rule).
The automation rule for switching ON would need to check if the switch is still OFF ( otherwise do nothing), switch on the switch and the (proxy-) item.
The rule to switch OFF would only work if the (proxy-) item is set to ON, and it would switch both the switch and the (proxy-) item to OFF.
Note that such a rule would switch to ON although the human migth have switched to OFF shortly prior!

1 Like

Often overlooked, but important feature.
It’s getting automation to work with us, not against us.

I don’t think you are missing anything.

The difficult part in most set-ups will be detecting manual actions.
Very often the logic will actually work more the other way round, as in -
“Something changed, but openHAB didn’t issue a command recently- so let’s call it a manual event.”

In my own setup I go at it this way - setting a “manual” condition upon detection, with a long timeout reverting to “auto”.
Motion sensing rules check and are blocked by “manual”.
Care needs to be taken about any already scheduled events when “manual” changes.

(Bonus effect - by detecting manual switching, you have effectively added another sensor to any “presence detection” scheme you may have.)

In my case it’s about motion-activated lighting, so “occupancy” and “want auto” may be true at the same time.
For your anti-burglar lights however, you’d want “not occupied” to be a condition of “want auto”? Simplifies things as you could concentrate on making reliable occupancy detection as your approach.