Avoiding loops on switch events and background scenes

[rlkoshak (Rich Koshak)]

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

Automation/Orchestration Design Patterns

Posting this here so I can easily find it later. Two more design patterns came to mind. Separation of Behaviors Problem Statement: I have found in my rules and from helping others that often times certain sorts of checks, conditionals, etc. cross cut multiple functionality categories. For example, lighting and HVAC may both care about what time of day it is. Just about anything may want to send a notification. Lighting, blind/rollershutter controls/HVAC may all care whether it is cloudy. What…

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.

@rich0

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.

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

Automation/Orchestration Design Patterns

I’ve debated whether to continue this thread or to start a new one and decided to add to this thread. Ultimately this will probably be added to the wiki and/or included in the OH 2 user’s guide. So, it has been several months since I posted my design patterns above and as I’ve refactored things I’ve come up with some improvements which I will post here. Time of Day Design Pattern In the original above I use Switches to represent the current time of day state. This made sense at the time becaus…

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.