KPL status in Percentage causing problems

[johnnyt]

For a while now (can't remember when it started) status ON has been reflected as 100% in some case and it's been more of an annoyance than a problem. Tonight, however, I'm seeing a situation where status = 100% is causing a program triggering problem.

 

In the attached image you'll see program conditions touching 3 different KPL's, one of which reports and can only be set to a percentage or OFF (or responding) rather than ON or OFF (or responding). Unfortunately 100% is not read as ON and the program is inappropriately triggering. It is now Running Then when ALL of the KPL buttons in the program condition are ON and it shouldn't. This causes a new program I wrote tonight that looks for an opposite set of conditions to run to send a scene ON command to turn the first two KPL buttons ON again (including the one being reported in %), causing the attached program to run again (when it shouldn't), causing the other one to run... and on and on. Removing the offending KPL (where status is listed in %) stops the madness. (Fortunately I have a 3 second delay in the action so I wasn't encountering a crippling race condition.)

 

What am I doing wrong?

 

Am running 4.2.10.

Edited August 29, 2014 by johnnyt

[EricK]

Hi,

Check this thread on how to post programs to the forum. Copy to clipboard, hit the code button, past in the program.

http://forum.universal-devices.com/topic/5443-how-to-copy-a-program-to-the-forum/

Maybe not off or not on is what you need, but please post the entire program first.

E

[johnnyt]

not off doesn't work either but even if it did I'd like to understand why 100% <> ON.

 

here's the code (using not OFF) in text format:

 

If
        Status  '1-MISC (Non Lighting) / HVAC / Kitchen.E-Vent' is not Off
     Or Status  '1-MISC (Non Lighting) / Bedrooms / JeanKPL.G-Vent' is not Off
    And (
             Status  '1-MISC (Non Lighting) / HRV / Back KPL.G - HRV High (XLink)' is Off
          Or Status  '1-MISC (Non Lighting) / HRV / Back KPL.H - HRV High (XLink)' is Off
        )
 
Then
        Wait  3 seconds
        Set Scene '1-MISC (Non Lighting) / HRV / HRV Venting Buttons for Prgs' Off
 
Else
   - No Actions - (To add one, press 'Action')
 

 

and attached is the scene that's called OFF by the above and ON by another program that works and is what causes this one to trigger.

Edited August 29, 2014 by johnnyt

[apostolakisl]

I believe one of the recent firmware upgrades got rid of "on" for all dimmable devices.  There was a lot of confusion of what "on" meant (it meant 100%), but lots of people thought of it more as "not off".

 

I agree that a kpl button itself is either on or off, so probably having the percentage thing is bad.

 

Anyway, using 100% or "not off" should be working.  You may have a com issue.  Can you confirm that the com is good?

[johnnyt]

Can you confirm that the com is good?

Unless I'm missing something the problem is related to what ISY thinks the status is, not what the KPL button actually shows. The offending KPL button is not harmed (pressed) in this process, meaning whether or not the command got to the KPL doesn't matter?

[apostolakisl]

Unless I'm missing something the problem is related to what ISY thinks the status is, not what the KPL button actually shows. The offending KPL button is not harmed (pressed) in this process, meaning whether or not the command got to the KPL doesn't matter?

 

What ISY "thinks" the status of the KPL is the only thing that matters as far as programs are concerned and is all about the com.  If the ISY did not receive the insteon message of the most recent change, then ISY will have the status wrong and the program will not execute as you expect.  Programs do not query the device when they run, they only check their own register to see what it was last time it received a status update.

 

I am about 99% certain your problem is missed com's, not anything with the ISY program or internal logic.  Try using dual band kpl, adding more dual band devices in general, or finding signal sucking/noise problems in your home.  You can also try adding a test program to send you an email every time ISY sees the switch status change.  Your emails will then create a log of every status change.  Compare that to your actual usage.

[johnnyt]

hi apostolakisl,

 

what happens is that my pressing the HRV High button "ON" (which works fine, no comms problems) when either of the "vent"-labeled KPL buttons is "not OFF", it causes another program to run (as expected) that calls an "HRV Venting buttons" scene to turn the two KPLs that have "vent" in their name ON. Works fine every time, triggered by an "if control HRV button ON". ISY at this point thinks (or should think) that "JeanKPL G-Vent" is ON or, perhaps, 100%. Doesn't matter whether the button itself is lit up since a scene command is not acknowledged back to ISY, meaning a comms failure would not be known (or matter) in this case. Again, in case I'm missing something.

 

[apostolakisl]

If a scene command is written to turn the kpl on, and the kpl receives the scene command, the kpl turns on.  But if the PLM does not receive that same scene command, it will not know it turned on.  Conversely if the scene is turned on, and the PLM receives the message, but the KPL button does not, then the PLM will think it is on, but it is not.

Edited August 30, 2014 by apostolakisl

[johnnyt]

But ISY is the one sending out scene on and scene off commands that affect the offending kpl button AND causes the program to evaluate. If commands from ISY are not making it to the PLM I would be having issues elsewhere, and much bigger ones, in fact.

 

 

 

 

Sent from my iPad using Tapatalk

[johnnyt]

Here's what happens over the insteon network when the offending KPL is included in the program:

 

1. The push of one of the "HRV High" buttons:

 

1-MISC (Non Lighting) / HRV / Back KPL.G - HRV High (XLink)    Status    100%    Sat 2014/08/30 07:53:44 AM    System    Log
1-MISC (Non Lighting) / HRV / Back KPL.H - HRV High (XLink)    Status    100%    Sat 2014/08/30 07:53:44 AM    System    Log

 

2. ISY calls scene to turn the offending KPL on, which I visually see turn ON in the GUI:

 

Scene:1-MISC (Non Lighting) / HRV / HRV Venting Buttons for Prgs    On         Sat 2014/08/30 07:53:51 AM    Program    Log
1-MISC (Non Lighting) / HVAC / Kitchen.E-Vent    Status    100%    Sat 2014/08/30 07:53:51 AM    System    Log
1-MISC (Non Lighting) / Bedrooms / JeanKPL.G-Vent    Status    100%    Sat 2014/08/30 07:53:51 AM    System    Log

 

3. The program posted above runs despite ISY seeing all the KPLs in the condition as ON (meaning it shouldn't run):

 

Scene:1-MISC (Non Lighting) / HRV / HRV Venting Buttons for Prgs    Off    0    Sat 2014/08/30 07:53:58 AM    Program    Log

1-MISC (Non Lighting) / HVAC / Kitchen.E-Vent    Status    0%    Sat 2014/08/30 07:53:58 AM    System    Log
1-MISC (Non Lighting) / Bedrooms / JeanKPL.G-Vent    Status    0%    Sat 2014/08/30 07:53:58 AM    System    Log

 

Here's what happens when the offending KPL condition is removed from the program:

 

1. The push of one of the "HRV High" buttons:

 

1-MISC (Non Lighting) / HRV / Back KPL.G - HRV High (XLink)    Status    100%    Sat 2014/08/30 08:10:48 AM    System    Log
1-MISC (Non Lighting) / HRV / Back KPL.H - HRV High (XLink)    Status    100%    Sat 2014/08/30 08:10:48 AM    System    Log

 

2. ISY calls scene to turn offending KPL on, which I visually see turn ON in the GUI:

 

Scene:1-MISC (Non Lighting) / HRV / HRV Venting Buttons for Prgs    On         Sat 2014/08/30 08:10:54 AM    Program    Log
1-MISC (Non Lighting) / HVAC / Kitchen.E-Vent    Status    100%    Sat 2014/08/30 08:10:54 AM    System    Log
1-MISC (Non Lighting) / Bedrooms / JeanKPL.G-Vent    Status    100%    Sat 2014/08/30 08:10:54 AM    System    Log

3. Nothing. Button is ON and remains that way.
 

Edited August 30, 2014 by johnnyt

[apostolakisl]

But ISY is the one sending out scene on and scene off commands that affect the offending kpl button AND causes the program to evaluate. If commands from ISY are not making it to the PLM I would be having issues elsewhere, and much bigger ones, in fact.

 

 

 

 

Sent from my iPad using Tapatalk

 

I never said ISY and PLM are not communicating, that is via a highly reliable, short, cat5 wire.  It is between the devices and PLM where comm could break down, that comm is insteon signalling and pretty much no one has perfect insteon comm.  The PLM is ISY's ears and mouth, ISY hears the other devices through it and speaks its commands through it.

 

You are now adding to the mix that there is a second program that you didn't mention prior and have not posted.

 

Discovering now that you have a second program, this opens the possibility of circular logic which could easily be screwing things up, especially with all of the code looking for "status" of each device.  

 

ISY does understand 100% and "on" to be the same thing.  This is not your problem.  Trying writing some test programs for the buttons in question (and disable your other programs so as to avoid interference).  You will see that turning the kpl, either by scene response or control, will trigger the following program true when you turn it on, and false when you turn it off.

If
        Status  'Family Room / Family Rm-Over MantleLt L / Family Rm-Over MantleE' is 100%
 
Then
        Repeat Every  1 minute 
           $itest  = 0
 
Else
   - No Actions - (To add one, press 'Action')
 

[johnnyt]

I think the second program is a red herring. It is simply something that turns the scene ON, which then triggers the problematic program I'm posting about. It is just one of many ways to make the problematic program run. Yes, there was a circular element to it because the non-problematic program re-ran as it should to change the KPL back to OFF thereby re-triggering the problematic program that turned back to ON. I watched as the non problematic programs ran "then" for a few seconds (I had put in a 7 second delay to make sure I saw it running) followed by the problematic program running for a few seconds then the cycle repeating itself until I stopped one of them. I fixed the circular issue by looking for a button press (i.e. control) instead of status. Even though I still think the second program is a red herring after more testing, I've attached it here given that I am at a loss to understand why the problematic program is running when it shouldn't so anything you want I'll provide.

 

As suggested, I created a test program (below) and 1) manually pushed the KPL button in question ON then OFF several times (I also did it using "not OFF" as the condition), 2) ran the scene that turns the bottom ON using the GUI several times, and 3) caused the non problematic program that sends the scene ON command to run. Each time I received the appropriate notification by email.

If
        Status  '1-MISC (Non Lighting) / Bedrooms / JeanKPL.G-Vent' is 100%
 
Then
        Send Notification to 'me'
 
Else
        Send Notification to 'me'

I think this points to two things. One, there isn't a comms issue since the button press was seen by ISY. To that I would add that the only time I've had a comms issue with the keypad in question - which has been in place for several years - has been (sometimes) when I've query the device links table - a fairly lengthy process given the KPL has 80 some links in it. (I did a device links query again just before the above testing and it did not encounter any problems.)

 

The second thing it says to me is that the condition does work by itself.

 

The question remains why is this program (re-posted here for quick reference) running true when the first two conditions are false. Then the program does NOT run true under the same triggering circumstances when the second condition is removed.

If
        Status  '1-MISC (Non Lighting) / HVAC / Kitchen.E-Vent' is not Off
     Or Status  '1-MISC (Non Lighting) / Bedrooms / JeanKPL.G-Vent' is not Off
    And (
             Status  '1-MISC (Non Lighting) / HRV / Back KPL.G - HRV High (XLink)' is Off
          Or Status  '1-MISC (Non Lighting) / HRV / Back KPL.H - HRV High (XLink)' is Off
        )
 
Then
        Wait  7 seconds
        Set Scene '1-MISC (Non Lighting) / HRV / HRV Venting Buttons for Prgs' Off
 
Else
   - No Actions - (To add one, press 'Action')
 

VentButtonsONprogram.txt

[johnnyt]

figured it out!

 

I needed to bracket the first two "or" conditions.  D'oh!

 

The following works as intended.

If
        (
             Status  '1-MISC (Non Lighting) / HVAC / Kitchen.E-Vent' is not Off
          Or Status  '1-MISC (Non Lighting) / Bedrooms / JeanKPL.G-Vent' is not Off
        )
    And (
             Status  '1-MISC (Non Lighting) / HRV / Back KPL.G - HRV High (XLink)' is Off
          Or Status  '1-MISC (Non Lighting) / HRV / Back KPL.H - HRV High (XLink)' is Off
        )
 
Then
        Wait  7 seconds
        Set Scene '1-MISC (Non Lighting) / HRV / HRV Venting Buttons for Prgs' Off
 
Else
   - No Actions - (To add one, press 'Action')
 

[apostolakisl]

Perhaps you meant to have your first 2 conditions together in parenthesis and'ed to the second 2

 

EDIT:  looks like we figured it out at the same time.

Edited August 30, 2014 by apostolakisl

[oberkc]

The question remains why is this program (re-posted here for quick reference) running true when the first two conditions are false.

 

I would ask what you mean by "first two conditions".  Which is the first condition?  Which is the second?

[apostolakisl]

I would ask what you mean by "first two conditions".  Which is the first condition?  Which is the second?

 

Compare his first program to the one he posted last.

[oberkc]

Yes, i saw the changes, and the fact that it was now apparently working as expected.