Program re-fired after power outage

[mcisar]

I had a bit of an oddity happen last night, trying to diagnose why.   Long story short I have a "bedtime" program executed by a keypadlinc key on one of two keypads, turn some lights off, turn some lights on, lock some doors, etc.  One of the first pieces of automation I did on my system and it works great.   Except last night... at 2am the power goes out, I get woken up by the beeping of the UPS' in the computer room but just grumble and roll back over and go back to sleep, 20 minutes later *wham* all the lights in the bedroom and hallway are on, i hear the door locks beep saying they're locked.  

Need a hand in diagnosing exactly why the program decided to re-fire when the power came back on, and how to correct so it doesn't happen again

The program is initiated by a keypress on one of 2 keypadlincs, the keys are in "non-toggle on" mode for trigger purposes because off isn't really applicable (it's not a toggle, its not a scene... its just a "im going to bed, do some stuff").    The 2 buttons  (BedLR1 and BedLR2) are grouped in a scene (BedLED, as responders) for the sake of turning on the indicators on both keypadlinks so I remember I'm going to bed and have 10 minutes to do so   The program considers itself complete after 10 minutes and turns off the scene and thus the button LEDs.  Any of the lights turned on by the program are manually turned off as we proceed through our human "get ready for bed" routines.

The program itself is below (the removed parts are just other lights and devices getting turned on and off)... 

Bedtime Prg - [ID 000D][Parent 0001]

If
        'BedLR1' is switched On
     Or 'BedLR2' is switched On
Then
        Set 'BedLED' On
        Run Program 'Lock Doors' (Then Path)
        Set 'Front Porch Light Dev' Off
        ... (removed)

        Wait  2 minutes 
        Set 'Front Hall Light Dev' Off
        ... (removed)

        Wait  10 minutes 
        Set 'BedLED' Off
Else
   - No Actions - (To add one, press 'Action')

 

So, what little dangling tidbit could have made the program re-fire it when the power came back on (and FWIW the power went out many hours after the 10 minute timeout)?   Thoughts?

Cheers,
Mike

 

 

[apostolakisl]

I can only ask if you have another program or something outside of ISY that sends a "run then" command to this program.  The "if" clause here is only true at the instant when someone clicks the KPL button.

[larryllix]

If your scenes contain button LED controls and your program duplicates what your Insteon Scenes do, you may have caused yourself an ALL ON phenomenon. All the devices inside the KPL are on the same address and this type of signal  bombardment,  is  suspected of causing enough signal collision to cause a bad Insteon code, that other Insteon devices can amplify as an ALL ON or a Scene control command.

Take the duplicate actions out of your program, or remove the scenes from the devices and just rely on scenes for the on. If you need the response speed, I would isolate the KPL LEDs into separate scenes, allow the lights scene to work directly, and with a 1-2 delay make the program operate the LEDs only. Actually with any human keypress a 1-2 second delay for feedback, or any lights is not that noticeable.

Bedtime Prg - [ID 000D][Parent 0001]

If
        'BedLR1' is switched On
     Or 'BedLR2' is switched On
Then
       Wait 2 seconds
        Set 'BedLED' On
        Run Program 'Lock Doors' (Then Path)
        Set 'Front Porch Light Dev' Off
        ... (removed)

        Wait  2 minutes 
        Set 'Front Hall Light Dev' Off
        ... (removed)

        Wait  10 minutes 
        Set 'BedLED' Off
Else
   - No Actions - (To add one, press 'Action')

 

Edited June 6, 2020 by larryllix

[lilyoyo1]

2 minutes ago, larryllix said:

If your scenes contain button LED controls and your program duplicates what your Insteon Scenes do, you may have caused yourself an ALL ON phenomenon. All the devices inside the KPL are on the same address and this type of bombardment has been suspected of causing enough signal collision to cause a bad Insteon code that other Insteon devices can amplify as an ALL ON or a Scene control command.

Take the duplicate actions out of your program, or remove the scenes from the devices and  just rely on scenes for the on. If you want the response speed I would isolate the KPL LEDs into separate scenes, allow the lights scene to work quickly, and with a 1-2 delay make the program operate the LEDs only. With any keypress a 1-2 second delay for feedback or any lights is not that noticeable.

 

I'd agree except he is using zwave and running that through a separate program. Insteon all on shouldn't include zwave

[larryllix]

3 minutes ago, lilyoyo1 said:

I'd agree except he is using zwave and running that through a separate program. Insteon all on shouldn't include zwave

Perhaps he has defective Zwave KeyPadLincs then.

[lilyoyo1]

2 minutes ago, larryllix said:

Perhaps he has defective Zwave KeyPadLincs then.

???. The isy itself triggers zwave so it couldn't even be links stored within the kpl.

Edited June 6, 2020 by lilyoyo1

[lilyoyo1]

In addition, the all on would trigger all lights not just a few which are part of specific scenes and programs. If I had to hazard a guess, I would assume this being an aberration or another program (potentially no longer used) that caused this. Since it occured under specific circumstances, you could always try to recreate what happened. 

Edited June 6, 2020 by lilyoyo1

[larryllix]

Just now, lilyoyo1 said:

In addition, the all on would trigger all lights not just a few which are part of specific scenes and programs. If I had to hazard a guess, I would hazard this being an aberration or another program (potentially no longer used) that caused this. Since it occured under specific circumstances, you could always try to recreate what happened. 

Yeah, The twenty minutes likely knocks this program out of the troubleshooting.

OP should use the search function in the admin console to find any other reference to these devices.

[mcisar]

Thanks for all of the quick responses.  Will try to pick off some key points...

A couple of the lights that are being turned *off* in the program are in other scenes, the lights that are being turned *on* are not in any scenes at all (my naming convention "dev" to connote the device itself).  All of the lights are insteon, locks are zwave.

The program and buttons all work perfectly and do what was intended day-to-day, its just the random trigger after the power outage that's concerning.   I'm just building my system and as I get more and more devices I don't want worry that if there's a power outage while I'm gone for 2 weeks that some oversight in my programming has caused half of the lights in the house to be turned on and left on.

It was not just random lights that came on, nor some random lights that happen to be in the program.  The state of the devices was as if the program had just run (including to the point of hearing all of the locks trigger), and the keypad lights being illuminated.  Obviously the lights normally turned off by the program were already off so there was no indication there, but the KPL buttons did turn off after the 10 minute timeout so that pretty much proves that the program was running.  

There's nothing else in the programming that calls this combination of devices, nothing that calls this program, and nothing at all that calls the scene which houses the buttons except the push of the buttons themselves.

I had originally thought maybe the scene somehow was showing as "on"... but I've just confirmed that manually turning the scene on or off from within ISY does not trigger the program, it only lights the KPL buttons (I'm guessing the program isn't triggered because by this mechanism the buttons become "on" and are not "switched on"... still wrapping my head around that).

If it's not something bad I've done in the programming as far as I can figure that means that either the ISY re-ran the body of the program "just because", or the program was triggered by somehow receiving a spurious "switched on" from one of those two KPL buttons.   

Not so sure I want to beat up all of my electronics by turning off the main breaker to recreate the situation, I suppose I could try to kill the power just to the circuit the KPLs are connected to and see if it replicates.

 

[apostolakisl]

"is switched on" terminology (at least as it applies to kpl's) means one specific thing only . . . that someone physically pushed the kpl button.  Upon power cycle, a KPL STATUS will return to its previous state, but that will submit a "status" message over the network, not a "control switched on/off" message.

ISY at boot up may be set to "run at startup" for programs of your choice.  If the program has a populated "if" clause, then ISY evaluates the contents and proceed to "then" or "else" as logic dictates.  In the case that "if" clause is blank, it runs the "then" clause.  If ISY is not set to run the program at startup, the program sits idle at boot.  Your program has "if" populated, so "run at startup" whether checked or not really doesn't matter.  It is going to be false and the "else" clause is blank, so the results are the same either way, nothing happens.  So that isn't it.

If you are 100% certain that no other program references this program with a "run then", then I have no idea what happened.  The program should not have run.  A KPL button should not have sent a "control switched on" message at power up.  Even if it had, ISY (assuming it also rebooted on the power outage) would not have received the command since ISY takes far longer to boot up than the switch.

I keep going back to there being some other program that executes this program's "then".

If your ISY is on a UPS, then perhaps some errant message was sent and received by ISY.  This would be an error on the part of the KPL.  But I can't say I have ever heard of anyone having a switch send a "control switched on" message at boot.  There is always the possibility that when your power returned, it was full of noise and somehow that messed with things, but again, ISY takes a little bit to boot up and I would have expected the power to have cleared by then.

 

[lilyoyo1]

I agree with the statement above. If you're certain there's nothing else calling for that program to run them I would say it's an aberration. The only thing you can do is try to recreate. Outside of that, I would assume a gremlin

Edited June 6, 2020 by lilyoyo1

[kclenden]

6 hours ago, apostolakisl said:

A KPL button should not have sent a "control switched on" message at power up.

I agree with this, but would add that if a KPL button did send a "control switched on" message at power-up, you should see that in the ISY log.  If the ISY acted on what it thought was a KPL button press, it should have logged it, so if you don't see it in the log, you can probably eliminate that as a likely culprit.