Interesting Insteon behavior with scenes and polling

I’ve known about a bug in my programming for a while, I finally tracked it down tonight. Maybe someone later will have the same problem and come here to find the fix.

I have several rules that are triggered by Inseton switches as follows:

when
    Item Kitchen received update OFF
then
    Dining.sendCommand(OFF)
end

Seems simple, right? Well occasionally I would get into a situation where this rule would trigger unexpectedly. I would be in the room, Kitchen would be “OFF” and Dining would be “ON” - then the rule was triggered and Dining would turn OFF.

I finally tracked it down to Insteon modem scenes. If Switch1 is turned off in a scene - then Switch2 is turned on before Switch1 is polled again - the next poll of Switch1 will trigger the scene.

Important items:

Switch Group20         "20 Inside Off"   {insteonplm="44.85.d6:0x000045#broadcastonoff,group=20"}
Switch Kitchen         "Kitchen"         {insteonplm="43.f9.6c:F00.00.02#switch"}
Switch Dining          "Dining"          {insteonplm="45.1d.81:F00.00.02#switch"}

Group20 turns off both Kitchen and Dining. So if the log file goes something like:

10:00:00 Kitchen polled "ON"
10:00:30 Group20 turns off         // sends "OFF" command to Kitchen and Dining
10:01:00 Dining room turned "ON"
10:02:00 Kitchen polled "OFF"      // as turned off by Group20
10:02:01 Dining room turns "OFF"   // this would be unexpected

So to fix this I’ve basically made a rule like:

when
    Item Group20 received command OFF
then
    Kitchen.sendCommand(OFF)
end

So that the Insteon polling system expects it to be “OFF” instead of noting it as a status change and triggering an “item updated” rule. Note: “postUpdate” does NOT work for this rule. I only use this trigger on 2 switches so it’s pretty simple to work around.

If anyone out there has come across this issue and has a different fix please share! I’ve only seen it happen 2 or 3 times since I made that rule like 6 months ago but it was driving me nuts. I’ll sleep well tonight knowing it’s fixed.

2 Likes

I just realized the “related” tag on the binding might be a better way to manage this.

Does anyone know if the related flag works on group commands? I might try that out later this week.

I’d put the Kitchen Insteon ID as “related” on the Group20 item I believe.

EDIT:
Scratch that, this won’t work in the case when Group20 turns off the Kitchen light but not the Dining light because my rule would fire immediately and turn off Dining.

My FULL “Kitchen OFF” rule is:

when
    Item Kitchen received update OFF
then
    if(ExpireDummy.state != ON) Dining.sendCommand(OFF)
end

So the full Group20 rule to fix my issues is:

when
    Item Group20 received command OFF
then
    ExpireDummy.sendCommand(ON)
    Thread::sleep(200)
    Kitchen.sendCommand(OFF)
end

This keeps the Insteon scene from immediately triggering my Dining light “OFF” in the case where the scene keeps Dining light on but Kitchen light turns off.