Hello, can I trigger a Rule When a I receive a changed command? For example, I what to trigger a rule only when a value changes from ON to OFF, but only if from a Command, not a State Update. I can’t get the previousState working reliably. And I can’t find a way to on the Change rule to rule out the State Update or in The received command to rule out the same value as before.
Thank You all
Item received command [] Item received command [] https://docs.openhab.org/configuration/rules-dsl.html#event-based-triggers
Please post your code.
Hi, please check my previews post… I got it working for a while but then I started getting inconsistent results again.
What do you want to get, the previous value or the previous different value?
Post the relevant openhab.log lines please.
Let’s step back. Why do you want to do this? There may be another approach that works better that doesn’t require needing to trigger a Rule in this way.
For example, trigger on the command but only send commands or updates in the Rule if the new states are different.
I have a light, this light is on openhab. This light is controlled by a switch, this switch is triggered by mqtt,
Switch FF_LivingRoom_Switch1 "Interruptor 1" <wallswitch> (FF_gSwitch, gSwitch) {mqtt="<[mymqtt:mqtt/1/10/1/0/2:command:MAP(1on0off.map)]"}
The idea is that when switch changes value… it will change the ligh
rule "Switch"
when
Item FF_LivingRoom_Switch1 changed
then
if (FF_LivingRoom_Light.state == OFF){
FF_LivingRoom_Light.sendCommand(ON)
} else {
FF_LivingRoom_Light.sendCommand(OFF)
}
end
So far so good, all works well no problem here…
The problem starts when the switch sends a new message mqtt/1/10/1/0/24 that is used to report the actual state of the switch, so that openhab is allways in sync with the actuator… This message is sent every minute or so. I don’t what this message to turn on the light, ony update the switch state, so I cant use the changed trigger, because if the switch is off in openhab and recives a update that actually is on (because for example openhab was down at the moment of the switch chage) my light woud change is state.
So the mais ideia:
Actuator send both messages:
Thank You
The typical way this is handled is to make the incoming state (i.e. the state that comes in once per minute) be a state update, never a command. Then trigger your Rule on received command.
You probably don’t need a proxy Item for this either. For example, here is one of my MQTT switches:
Switch aKitchenBanaster "Kitchen Banaster"
<christmas> (ChristmasLights)
{ mqtt=">[mosquitto:cmnd/sonoff-3157/POWER:command:*:default],
<[mosquitto:stat/sonoff-3157/POWER:state:default]" }
Things to notice:
I don’t even need a Rule. But If I were to split the two and use a Rule to synchronize them, then the Rule would trigger on received command and thus the Rule would only trigger when the command is coming from OH itself. All the updates from the device come back as updates so the Rule doesn’t trigger.
This is the whole reason there is both a command and update in OH.
Hello @rlkoshak that was my first approatch, but it did not work because:
I don’t think that it’s possible without a rule…
Thank You
Correct.
But it IS possible if you use the right combination of updates verses commands.
So you care about changes from the Wall Switch to control the lamp.
But the wall switch works like a momentary button, not a toggle. Any change on the wall switch should result in a toggle of the lamp. Put another way, you do not keep the wall switch states in sync with the lamp. What you care is the wall switch received a command or changed states.
So just trigger the Rule on FF_LivingRoom_Switch1 changed (or the other wall switches as well). Or if you want to be very specific:
Item FF_LivingRoom_Switch1 changed from ON to OFF or
Item FF_LivingRoom_Switch1 changed from OFF to ON
If the Switch changes between these two states it means you need to toggle the lamp. When the switch sends the update messages, unless you have manually changes the state of the wall switch in some way or something else has changed the state of the wall switch, the update will not cause FF_LivingRoom_Switch1’s state to change and the Rule will not trigger.
You don’t need to care whether the change was caused by a command.
So assume this scenario, farfetch I know, but assuming the extreme:
The lamp is off and the switch is off state (the switch are toggle switches, not momentary switches), openhab, for some reason lost sync, for example MQTT is down, or openhab is down. Someone changed the switch state to on, openhab is down so no response… 1 hour latter the system is back online. This 2 scenarios can happen, and nither are ok:
If the state message arrives and I have the on change rule in placed, the switch would change is state, and the light would go on… not what I would whant.
If I change the state of the switch on the wall he will send a OFF state, the state of the switch in OpenHab is still off, so nothing will happen because the state did not changed. That is one of the main reasons of the update state message, change the state of the switch on openhab to the real state of the physical, to avoid black actuation.
At the moment I have the On Change trigger of the rule, this works well, but I have to ignore (don’t use) the update state message (the second one).
If it really is farfetched, you have to ask yourself if it is an edge case worth trying to address at all. Dealing with these sorts of edge cases can easily consume the bulk of your time and your code. So don’t tackle them unless it really is worth the effort. You would be hard pressed to convince me that it is worth the effort to deal with for a lamp.
That should only occur if you are using MQTT QOS 1 or 2 and/or retain. If you are using QOS 0 and not using retain the message will simply be lost. The typical default, particularly with devices like switches, are QOS 0 and not retain so you should be good. This is what you want. And even if you are using a higher QOS, there is a time to live for each message and if OH doesn’t come back online before that timeout then the message is dropped. I’m not sure where that setting is made. I think
So your first scenario should never occur unless you went out of your way to set MQTT up that way.
I don’t think this is quite right. If we assume your original preconditions (MQTT is down, OH is down) then when you send the OFF message then OH will not get the message. In effect, while OH or MQTT is down, messages are effectively lost/ignored.
Then OH comes back online. You have not mentioned whether you are running persistence with restoreOnStartup. Let’s assume you are not. In that case FF_LivingRoom_Switch1 will come up as NULL. Then one of the one minute update messages will arrive and FF_LivingRoom_Switch1 will change to whatever state the wall switch is in. But the Rule won’t run because we are using:
Item FF_LivingRoom_Switch1 changed from ON to OFF or
Item FF_LivingRoom_Switch1 changed from OFF to ON
meaning the rule will not trigger because the state changed from NULL to ON (or OFF).
IMHO, this is correct behavior. While OH or MQTT is down, commands should not have any impact on the lamp. When OH comes back up, the initial state of the Items should eventually (and quickly, in your case one minute) come to represent the current actual physical state of the devices. Only after this point will commands start to take effect (i.e. changing the state of a wall switch causes the lamp to turn on/off).
To achieve this:
With that, at most, you will only have problems while something is already offline and then for no more than a minute. There might be an edge case here or there but they will happen so rarely they wouldn’t be worth dealing with. The expire binding will set the Switch
But even if we take your second description at face value and somehow inexplicably the Item in OH is OFF while the physical wall switch is actually ON then at worst you will have a one minute window during which you will flip the switch to OFF, the lamp doesn’t turn on, you flip the switch to ON and the lamp turns ON. Or when the one-minute message comes in it is seen as a change and the lamp toggles.
So the real problem is how/whether the wall switch and its Item in OH can get out of sync. In all cases I can think of this is a failure case (i.e. something went offline). And you already have a fail-safe in place that would keep this out of sync state for no more than a minute.
The likelihood of the problem occurring is low. The mitigation is simple and intuitive (toggle the switch again). And the behavior is predictable. Is this really a problem worth solving?
But, despite the rareness of the error case occurring and the ease with mitigating it you still want to try to solve this problem then the switch MUST make a distinction between a command and a status update message. Then you need to use that distinction to trigger your rule.
For example, if the manual triggers are sent as a command then you need to use received command to trigger your Rule. Then the status updates come in as updates and don’t cause the Rule ot trigger. In this case you don’t care what the command is. If it is a command you know that someone manually commanded the switch to change (be it at the physical switch or from the sitemap or from a Rule) and you need to toggle the lamp.
I @rlkoshak thank you for the detailed information. When I say that the state message arrives, I’m talking about the message that is sent every minut to sync the actuator with openhab/controller. That message if incorporated into openhab it would trigger the change rule, and that is not intended! Probably I’ll ditch that message and live with it! Because all would be solved if I could have something like on command change or on state change!
Thank you