Factory Query All Program changes KPL state -- Program Question

[stillwater]

I can see from the ISY Event Log that when the Query All program ran 4 buttons  (E,F,G,H) on a particular KPL changed their Status to ON in ISY.  (However the lights in those buttons never turned on).   Two of these buttons have zero role in my ISY programs or scenes.  One (G) is a responder to a scene and also is tested in a program to open a window when the button is ON.   I have seen other forum entries suggesting that a failing KPL or PLM or communication issues may be to blame.  My insteon network is usually very reliable --  many nearby dual band devices, a phase bridge,  noise generators/signal suckers isolated behind filters, etc.   We did have recent power failures during which my UPS that powers the ISY ran out of battery, as well as  lightning storms though my house is protected by various devices.  I can turn off the program that opens the window during the time the Query All is active and reset the button to OFF in ISY based on the corresponding scene before reactivating the program, so I have already acted to avoid having the window open in the future.   I have factory reset the KPL and restored from ISY.   Will watch to see what happens in future nights. (Will set Event Log to level 3) 

My immediate question is:   If I had tested in the program on the CONTROL is Switched ON rather than Status is ON would the change in Status in ISY based on Query ALL have triggered the program?

I am running an ISY994i Pro with 5.0.16C RC1 though I doubt the software version is material here.   Insteon devices through PLM and a home-brewed raspberry PI node server and various network resources and rest interconnections but no ZWAVE.   I checked that nothing in the network interconnections was changing the state of the KPL or scenes. 

Thanks for any illumination on this.  

 

 

 

 

[larryllix]

I ran into this a few years back. IIRC The KPL LEDs indicate a toggled on/off status whether the buttons are in Toggle mode of not. It isn't related to the actual LED status, only to the button press count divided by two. ISY likely keeps it's own status but query overrides it with Insteon's version.

Insteon has never fixed this and China probably won't  talk to them any more.    The warranty on the design  expired years ago, and Insteon likely doesn't know how they work.
One more reason UDI started supporting Zwave.

Edited June 9, 2020 by larryllix

[stillwater]

Thanks , @larryllix  .I don't think anything happened that should have changed the status of just 3 nodes in the kpl without changing the state of the lights, unless perhaps cosmic rays or something...   whatever happened either changed the state in the KPL without actually turning on the light or caused ISY to believe the state was ON when it wasn't.   I should have queried the KPL manually but at 4 AM I probably wasn't think clearly.  When I pressed the buttons on the KPL (even before factory reset) the lights and state in ISY changed appropriately. 

  Last night's query went smoothly with no repetition of strange state changes.    I've installed a fail safe program to prevent the state changes during the query from causing action, and correcting changes in button status that are incompatible with scenes during the period when programs are disabled, so at this point its mostly a curiosity.   I did also change the program to be triggered by control rather than state,  but I have no idea whether that would make a difference.

 

 

[jmwhite5]

@stillwaterI just ran into a similar problem, but with an IOLink sensor.  I have a program that announces that my gate is opening.  Not a great feature when this announcement is barked for no reason in the middle of the night.  (In the IOLink settings, I have the trigger reversed and I now suspect it may be causing this side-effect).

I just added a time range where my program would not run (around the time the factory query all runs).  I was curious if that is what you did?  or did you use some additional logic using variables to know when the Query All has finished running?

[stillwater]

I just triggered on time  and reset the KPL brefore reenabling the program.  It wouldn't surprise me if there are more elegant ways. 

[gzahar]

@jmwhite5Are you basing your announcement on the status of the sensor input or the relay?  If you are using the relay and it is using the momentary mode, the ISY will see the relay close (ON) but not open.  If this is the situation, you can create a program that query's the relay a few seconds after detecting a relay change to get it back in sync on the ISY.

Gate Relay Reset - [ID 00D9][Parent 0108]

If
        'Backyard / Gate-Sensor / Gate-Relay' Status is On
 
Then
        Wait  3 seconds
        Set 'Backyard / Gate-Sensor / Gate-Relay' Query
 
Else
   - No Actions - (To add one, press 'Action')
 

[larryllix]

On 10/26/2020 at 7:35 AM, jmwhite5 said:

@stillwaterI just ran into a similar problem, but with an IOLink sensor.  I have a program that announces that my gate is opening.  Not a great feature when this announcement is barked for no reason in the middle of the night.  (In the IOLink settings, I have the trigger reversed and I now suspect it may be causing this side-effect).

I just added a time range where my program would not run (around the time the factory query all runs).  I was curious if that is what you did?  or did you use some additional logic using variables to know when the Query All has finished running?

This is a problem with using the io/linc status reversal with GDOs also. You need to program around it without using the reversal of the status or it should happen every query of the io/linc.

If the status indicates Gate_closed, then remove the reversal option and call the status Gate_open.

Edited October 27, 2020 by larryllix

[jmwhite5]

14 hours ago, gzahar said:

@jmwhite5Are you basing your announcement on the status of the sensor input or the relay?  If you are using the relay and it is using the momentary mode, the ISY will see the relay close (ON) but not open.  If this is the situation, you can create a program that query's the relay a few seconds after detecting a relay change to get it back in sync on the ISY.

Gate Relay Reset - [ID 00D9][Parent 0108]

If
        'Backyard / Gate-Sensor / Gate-Relay' Status is On
 
Then
        Wait  3 seconds
        Set 'Backyard / Gate-Sensor / Gate-Relay' Query
 
Else
   - No Actions - (To add one, press 'Action')
 

It is based on the sensor status (not the relay).   I still haven't made this work (see next suggestions from @larrylixx).  

[jmwhite5]

6 hours ago, larryllix said:

This is a problem with using the io/linc status reversal with GDOs also. You need to program around it without using the reversal of the status or it should happen every query of the io/linc.

If the status indicates Gate_closed, then remove the reversal option and call the status Gate_open.

I tried removing the Trigger Reverse option.  But that messes up my Keypad button (I want it ON when the gate is opened, and OFF when the gate is closed).  

Also, I just noticed that every time I manually Query the IOLink sensor, it triggers my program, even when the status is already ON (my program triggers on ON).  So that's odd.  But the factory Query All doesn't trigger my program.

So maybe I'll try something along the lines of what @gzaharmentioned about refreshing the status right away after the gate has closed.

[larryllix]

1 hour ago, jmwhite5 said:

I tried removing the Trigger Reverse option.  But that messes up my Keypad button (I want it ON when the gate is opened, and OFF when the gate is closed).  

Also, I just noticed that every time I manually Query the IOLink sensor, it triggers my program, even when the status is already ON (my program triggers on ON).  So that's odd.  But the factory Query All doesn't trigger my program.

So maybe I'll try something along the lines of what @gzaharmentioned about refreshing the status right away after the gate has closed.

If your device query triggers a program to run then ISY thinks the status changed. This happens when you have a bad comm nd ISY hasn't been updated to the latest status of the IO/Linc.

GDO are notorious for disturbing Insteon comms. I solved mine with two Insteon FilterLincs. They are easy and have two receptacles. One for the GDO (filtered) and one for the I/OLinc (raw). My Chamberlain MyQ GDO (with battery backup) crippled my Insteon system and made it easy to find. Then I realised my older Chamberlain GDO (straight AC motor) may be causing problems also. Unplugged it after five years and found 99.9% of the rest of any Insteon comm problems.
Note: GDOs do not have to be running the mechanism to make Insteon problems. They contain bad power supply filtering.

Edited October 27, 2020 by larryllix

[jmwhite5]

I installed a FilterLinc (I had a spare one in my closet).  It did not solve the problem.  I still observe the behavior.  I do agree that there seems to be a disagreement with the status.  I think you're previous comment is right that I need to get rid of the Trigger Reverse and program around it.  But I think I would have to compromise on my keypad button lights and I don't want to.  So I think I'll just simply give up on the announcement feature.

[mwester]

Replace and rewire the sensor -- if the one you're currently using is a normally-closed, replace it with a normally-open, and vice-versa.  Or, use a simple add-on relay circuit to "invert" the sensor before it reaches the IOLinc.  I've done this using both approaches on my two garage doors in the past, to work around this very problem.  Solve the problem at the source, anything else is a hack (at least with the way the IOLinc works).

[gzahar]

Just wrote a program to test the query issue for the IOLinc sensor.  I get the same results.  So doubtful a communications issue (at least a manual query triggering a program).

If I press the query button at the bottom of the device page, nothing; but if I right click the node and select query it triggers a program every time.  Curious.

Sounds more like a bug, unless there was some reason they did it that way that I can't see.   Regardless, that doesn't seem to be causing your problem.  I'll leave the program in tact overnight to see if I get any hits from the 'query all' just to verify.  I would imagine the issue to be more prevalent if it did.

So at this point you have an isolated? instance of the overnight query causing the program to trigger.  It is definitely possible that one time a message got lost and the status was incorrect when queried and properly caused a program trigger (could also occur after an ISY reboot if the query is disabled).  So you're either back to filtering or beefing up your Insteon communications (which will never be 100%) or program around it so that it doesn't go off in the middle of the night.  If you have a goodnight routine, you could include a query there.  Also a query every hour? would decrease the likelihood of a 3:00 announcement.  Or as you said, remove the announcement altogether. 

FYI, I set it up both with and without trigger reverse selected and got the same results.  Don't think that is your issue either.

Edited October 28, 2020 by gzahar

[larryllix]

Perhaps ISY has a bug in it's software that causes a program to trigger upon an IO/Linc status update  without change in status. It wouldn't be the first time this has happened. This happened in a previous version update with state variables from Rest i/f updates and UDI fixed it.

I suspect the query every hour, is to compensate for a bad comm already. It should never be necessary.

Edited October 28, 2020 by larryllix

[jmwhite5]

On 10/27/2020 at 4:34 PM, mwester said:

Replace and rewire the sensor -- if the one you're currently using is a normally-closed, replace it with a normally-open, and vice-versa.  Or, use a simple add-on relay circuit to "invert" the sensor before it reaches the IOLinc.  I've done this using both approaches on my two garage doors in the past, to work around this very problem.  Solve the problem at the source, anything else is a hack (at least with the way the IOLinc works).

I finally got around to trying out your suggestion and IT SOLVED THE PROBLEM!!!  Thank you for sharing.

For the record, here's my setup:

1) I'm using a normally open reed switch (normal state is a closed gate)

2) I use 1 scene configured like this (a bit different from how it's described in the manual where they use 2 scenes). 

 

The 2 controllers (the IOLinc sensor and the Keypad button - configured to Toggle) for my scene are configured like this:

Here is how the relay is configured:

My keypad button now correctly lights up when the gate is open.  The keypad also correctly reflects the gate state when I use my car remote, or my Chamberlain gate controllers, and even when I use Siri (through Homebridge) or Alexa to control the gate.

Further, the Querying the Sensor now works as expected (no magic flipping of state like before).  So I may restore my voice announcement if this behavior holds up.

 

 

Edited January 9, 2021 by jmwhite5