Hi all,
I’m searching for a smart approach to get a lock option implemented into my rules.
Goal is to set a lock by e.g. a rule so if another rule triggers the item, the command is not set. E.g. a blind that should not move down by timebased rule, if the window is open,
or a light that should not be switched on by a presence rule, if a specific scene is activated.
My first approach was to add a separate switch item for each light or rollershutter item with a suffix “_lock”. And to check the state of this item in each rule.
But from my point of view this rule has the disadvantage that you need to remember to do it in each rule.
I don’t have a simple solution for this, because I am currently searching for a better rule engine to achieve a similar thing.
It would be nice to have methods in rules so you could call the method switchLight which gets a parameter item of type group lockable and then check the locking… But this is just my wish to create rules.
For the default rules I can only think of 2 additional items per lockable item.
The hidden item is the old default light item. All Light_x items are in the “lockable” group. A rule that triggers if an item in the lockable group gets a change will check if the _lock switch is not active and updates the hidden item. Otherwise it will do nothing.
You need to set the lock switch item from external to lock / unlock the item and control the normal item through the lockable group.
Better or less complex solutions are highly welcomed
I’m a little confused by this. It sounds like you’re adding items purely to serve as conditional checks for other items? If that’s the case, you have:
A rule to turn the lock item ON or OFF when the window is OPEN or CLOSED
An if condition in your time-based blinds rule that checks if the lock item is ON
If so, why not just check the state of the window directly? That’s all you really need to know.
Scenes are a bit different, since they’re intended to be stateless, fire-and-forget sequences. In this case you would need that lock item to be toggled when the scene is active or inactive. However, it may be more complicated than that if you have two different scenes that share common items. And what happens if one of the items that was turned ON by the scene gets turned OFF manually? Is the scene no longer active? If I recall correctly, this is one of the reasons why scenes are fire-and-forget.
The closest thing I have to what you’re asking is my system_mode item. It’s a string, and it gets set based on the time of day and my activity: wakeup, home, leaving, away, bedtime, sleep. Many of my rules check the system_mode state before doing anything, as well as time_of_day.
So, I would say to use a lock item if you have multiple rules checking that specific item before acting. But if it’s just a condition for a single rule, I don’t think you need it in the middle.
I would like to somehow extract the lock logic from the rule that triggers the items, because there can be multiple ones. e.g. blinds can be moved down because of sun protection or in the evening, so I don’t need to implement the logic in both rules
Select script transform profile (e.g.js or ruby) and write the logic there to intercept the command from the item to handler.
Your code can check for a global setting (which can be stored in a virtual switchitem.as on or off state) and based on that, either propagate the command to the handler, or discard it (by returning null) thereby cancelling the command, regardless of who or which rule sent that command.
I understand wanting to not repeat logic…but you said that your original approach was to make a lock item for every light and rollershutter item. You would then need additional rules for all of those lock items. And then you would still need to do conditional checks on those lock items from your original rules. It feels like a lot of extra stuff to avoid duplicating some code.
So, let’s look at it this way.
You absolutely need to have a rule that does the conditional checks to determine if a light/shutter should be toggled. There’s no way around this.
You want your main rules to somehow access the logic in the light/shutter rule, without bothering to do repetitive conditional checks.
If you use UI rules, this is actually very easy: UI rules can trigger other UI rules. So rather than sending commands to an item, your main rule would just run the light/shutter rule. You can’t do this with Rules DSL, but I think it may be possible in some other languages. (@JimT?)
Otherwise, I’d suggest a slight adjustment to your original approach. Instead of lock items, use proxy items. It’s the same thing, but instead of “checking if the lock item is active”, you send commands to the proxy item. This triggers the respective light/shutter rule, which would then check conditions and command the light/shutter.
I do something kind of like this with my IR-controlled fan. Since it doesn’t report a state to openHAB, I use proxy items as stand-ins. So, I only ever send commands to the main proxy item. A rule then checks the other proxy items to determine the last-known state of the fan, and sends the required IR commands to the fan.
@JimT has proposed the most elegant and comprehensive solution. It will work in all the ways you can send a command to the Item and requires no additional Items or logic in the rules. Just a simple script transformation.
@Desmond206x’s solution is what I’ll call the “traditional” approach.
Another approach can be to only command the shutter Item from a single rule. You can apply the condition(s) to this rule. Then only ever control the shutter by calling this rule, making sure to pass true as the argument to apply the condition.
This third approach has some obvious limitations The biggest of which is the Item can still be commanded independently.
A fourth approach which works for languages that support libraries is to put the commamd and check into a library function. But again the Item can still be commanded independently and there’s really no way to command the Item from the UI in this approach.
