I have an Insteon light switch that is defined as
Switch Outdoor_Lights “Outdoor Lights” (G_OutsideFront, Lights, G_MyOpenhab) {insteonplm=“3B.9C.AA:F00.00.02#switch”}
In my rules I have the following:
rule OutdoorLightsOff
when
Item Outdoor_Lights received update OFF
then
logInfo("LIGHTS", "OutdoorLightsOff: fired")
outdoorLights?.cancel()
end
I expect this rule to run either if I modify the state to off via the web page or I physically flick the switch. In both cases this works.
However, when I modify the state via the web page this rule is also called for the command too. I was not expecting this. The net result is the rule runs twice. here is my log:
2016-01-05 21:07:02.664 [INFO ] [runtime.busevents ] - Outdoor_Lights received command OFF
2016-01-05 21:07:02.680 [INFO ] [rg.openhab.model.script.LIGHTS] - OutdoorLightsOff: fired
2016-01-05 21:07:02.984 [INFO ] [.o.b.i.i.device.MessageHandler] - SwitchRequestReplyHandler: set device 3B.9C.AA to OFF
2016-01-05 21:07:02.985 [INFO ] [runtime.busevents ] - Outdoor_Lights state updated to OFF
2016-01-05 21:07:02.989 [INFO ] [rg.openhab.model.script.LIGHTS] - OutdoorLightsOff: fired
Is this the expected behavior? If so is it possible to detect if the rule has been called in response to a command or an update from within the then block?
I’m running OpenHab version 1.7.1 under Windows, java 1.8.0_66
If you want to trigger the rule when the state is changed to OFF, you would use
Item Outdoor_Lights changed to OFF
If you instead wanted to trigger when a user sent an OFF command, you would use
Item Outdoor_Lights received command OFF
When you trigger on
Item Outdoor_Lights received update OFF
your rule could run any number of times, as it’s perfectly reasonable to send multiple update events to an item with the same state.
Another thing to consider is that, when a user issues a command to an item, by default the item’s state is set to the command state. You can suppress this behavior by adding , autoupdate="false" to the binding section for the item, like
Doing this means that the switch item should not change state on receiving a command, but instead not until the insteonplm binding later reports that it has indeed changed state.
So, if I understand you correctly, this is working as designed. Because the command is implicitly updating the state then my received update OFF rule is fired and then, when the Insteon plugin reports the light is off, it then fires the same rule again. That makes sense though it was not quite what I had expected.
I’ll try using the changed to OFF instead. I think that will resolve my problem.
I guess it did not help right?.
Because I try to have separate rules as well:
1st rule fires if command was received only
2nd rule will only fire if the item was changed (but not by command but e.g. by update).
Actually using autoupdate=false did resolve my issue mostly. I only see the rule fired once. The downside is that sometimes Insteon devices can be horribly slow reporting their status so this results in occasional rule execution delay. For example, I open my garage door and the garage lights come on ten seconds later.
Since this post I rewrote all of my rules in JavaScript so I don’t exactly remember what I did to circumvent the issue I had at that time.
If you can be more specific about your problem, assuming you haven’t already resolved it, it may jog my memory.
Actually I solved my issue - it was more like a missunderstanding like in your first post.
About your last mentione issue (garage door and light).
How about triggering the light together with the garage door to open?
So you don’t need to wait the door to open completely (neither to wait for the state to update)
rule "Garage light"
when
Item Garage_Door received command ON
then
Thread::sleep(3000) // this is optional in case you would like the light to wait a little (here 3 seconds)
Garage_Lights.sendCommand(ON)
end
I trigger it when the state changes to open. That’s because my garage door is often opened by mechanisms other than sending a command to OpenHab such as car mounted remotes or the number pad on the outside. It works well enough 98% of the time.
