Avoiding loops on switch events and background scenes

I’m just getting started and I want to add a wall switch to my setup.

When the switch is turned on, I want to turn on the lights.

When the switch is turned off, I want to restore the background scene based on time of day. During the night that might mean having some lights on.

The problem is, one of the lights that gets left on will be the light attached to the wall switch.

This creates two problems:

  1. One of the lights will end up turning off, and back on, because the hardware switch will cut its power before the rule runs. I don’t think this is avoidable.

  2. I don’t know how to turn the hardware switch back on, without re-triggering the rule that will turn the room lights on.

How can I send a command to a hardware switch without triggering any rules associated with that switch?

I just thought of one idea. Maybe I bind two items to the switch, define the rules on one of them, but send commands to the other? The only problem is that my switch is bidirectional, so I am not sure if the switch would broadcast the change and OH would pick it back up on the other item and run the rules anyway.

Or, am I basically forced to not have lights on in the background attached to wall switches?

You can solve your problem 2 by creating a dummy switch e.g. “MonitorHardwareSwitch”. This is set to ON on startup.

Your rule that turns the room lights on is set to only run if MonitorHardwareSwitch is ON.

You then ensure that MonitorHardwareSwitch is turned OFF when your “restore background scene” starts running, and turns back ON say 5 seconds later.

Good idea. I can actually use this for a few other things. For example, I want to add presence monitoring, and one of the triggers for away/present might be flipping any switch in the house. But, when you go away you want to turn off all the light switches. So, again you end up in a situation where you have events triggering events.

(In that case the presence switch is completely virtual, so I just directly update its state which apparently doesn’t trigger the command event. I can’t do that with a hardware switch since I probably need to trigger the command to make the binding work.)

Drifting on topic, one general observation is that OH would probably benefit from more native functionality around scene definition and grouping of associated items. Right now I have a big list of rules and switches to apply scenes, because they’re hard to define in any other way. If they were just on/off maybe I could use clever groups for the dimmers (run through all the dimmers in a group turning them on), but sometimes I want a light at 60%. Also, with wifi bulbs I might want to update both the dimmer and the color temp on a bulb, but I don’t want to send color temp if the dimmer is 0, since that turns on the bulb, so I can’t just loop through the dimmer only. You almost need to treat a wifi bulb as an class/object that has its own methods/etc. The other problem with using rules to define scenes is that they’re slow. If you could define some kind of object that has a full set of settings for a scene (across numerous items) and in one command apply it very quickly that would help a lot.

Just food for thought. OH seems to be the best tool for the job, but it certainly has room to grow!

The Dead Man’s Switch Design Pattern might be applicable here.

The tl;dr is you set a flag which remains one value by default but temporarily gets set to another value while the rule is executing. You use this to tell the difference between a command sent by a rule verses one sent by physically switching the device.

That is basically what @dan12345 is proposing. The article above is a bit more complex and involved but has more explanation.

See the Group and Loop Design pattern, specifically the “TimeOfDay” changed rule, and see if something like that could be leveraged.

In short you would define a Group for each scene and Items to store the states for those scenes. If all your Items are named in such a way that they can be constructed in the rule you can pull out the custom setting Item for the light within the forEach loop using a filter[].

For example:

gNightScene.members.forEach[light |
    if(light.state as ColorType != new ColorType(0,0,0)) { // dimmer set to 0
        light.sendCommand(gNightSceneSettings.members.filter[s|s.name == light.name+"_Night_Setting"].state)

NOTE: I just typed in the above, I don’t know if that is how ColorType is initialized. But I do know when you have a Color Item, even though you can send it Dimmer or OnOff commands, internally it stores it as a ColorType so 0,0,0 == Dimmer 0 == OFF meaning to see if the light is OFF you need to check for 0,0,0.

The latency is a problem and one unfortunately difficult to address. Some users have seen huge speedups by using JSR233 and Jython for the rules that need to run really fast. There are other tricks one can use to get them really close together but none of them are really proven.