Hi, I’m looking for ideas to solve the following issue:
My home is equipped with rollershutters that can be controlled via handheld remotes.
Now I want to detect if someone used these remotes to open/close these rollershutters, so that I can eg. disable some openhab rules that also control these rollershutters.
My initial idea was this:
SwitchItem manual {expire 5m, OFF}
SwitchItem auto {expire 10m, OFF}
RollerShutter shutter
rule "manual controlled"
when
Item shutter changed
then
if (auto.state == OFF) manual.sendCommand(ON)
end
rule "openhab controlled"
when
Item shutter received command
then
auto.sendCommand(ON)
end
However it seems that something is flawed in this approach, but I do not fully understand.
The manual actions are detected correctly, but it seems the auto.sendCommand does not propagate fast enough, so that the manual switch rule sees the state of the auto switch as OFF even when the openhab controlled rule already triggered to set the auto switch to ON (I used debuglog to check the order of rule handling)
Is the sendCommand handled asynchronously and therefor delayed? I have now added a timer to delay the manual check, but that feels not right.
Is there another pattern I can use?
Yes, it’s always asynchronous. Commands may result in no state change at all, if it does happen it would probably be courtesy of the autoupdate feature here.
Using postUpdate will speed things up - I imagine you’ve no need to actually send a command to your dummy Item.
However postUpdate is asynchronous too. A short delay in your rule is simplest, say 10mS
You might come at this from the other end. Why does your shutter Item’s state respond really quickly to an OH command event, even before your “auto” rule has done it’s thing?
An idealized openHAB cycle would be
command -> Item -> binding -> command -> device -> status -> binding -> Item.state
In real life, real devices may be very slow to respond, or may never report state at all. Your Item may e a dummy with no real device. The user experience there is crappy; click buttons and nothing seems to happen.
So they added autoupdate. Treat it as a psuedo binding - it listens for commands, guesses what the effect should be, and issues an predictive update. See the predictions in your events.log
If/when a real status update comes along, it just overwrites the Item.state again.
This is active by default.
Because this is all internal OH action, autoupdate is quick. I’ll bet this is why your shutter Item state changes.
If your mystery shutter provides prompt state updates of its own, you could choose to disable autoupdate for this Item. This would almost certainly give your rules plenty of time to get sorted, even if an update came back from the device within 100mS.
I’ve done it a similar way. I’m now not at a pc, so I can’t copy my rule.
But it comes down to the following: I’ve a proxy switch that set my roller shutter to auto mode -> rules check this, if true the rule is executed. But before the rule sends a command, it updates a proxy item telling the system it’s controlled by a rule (commandbyrule). On other rule listens if a command is received on the rollershutter. When it does, it the proxy item commandbyrule is true it does nothing, if it’s false, it disables the proxy item for auto mode.
With this, the manual mode will always over rule the rules, so you don’t get to fight with the system (eg you control manual UP, system controls DOWN)
Looks like my approach is the OH way to go (though I’ll switch to postUpdate iso sendCommand).
and I’ll keep the delayed handling in the manual rule. (@rossko57: I did indeed see the autoupdate logs coming by, thanks for the explanation!)
