What triggers programs?

[lhranch]

This shouldn't be a hard one...

Say I write a simple program, the semantics of which are:

    If I can't get a status reply from device A, send me a piece of mail saying that the circuit breaker has popped again.

(The actual program would need a state variable to send the mail only once, etc., but just assume this simple example.)

Do I have to set up another program to schedule that program every half hour or whatever, or does the hub somehow (in the course of whatever it does all day) notice that it isn't hearing from that device, and run that program itself?

[oberkc]

There is a condition where an insteon device condition "responding is true/false" might be useful for such a program.  I have not used it before, so I can only theorize.  I am unsure how the ISY-994 would know whether a device is responding, but I assume that it would depend upon the frequency with which something has tried to communicate with a given device.  There is also a "query" option for insteon devices.  Perhaps a program running at some period of time (every hour, for example) you could query a device, hoping that frequent queries would quickly identify "non responding" devices.  Then you would create a program to send a message based upon a condition that a device is non-responding.

[larryllix]

1 hour ago, oberkc said:

There is a condition where an insteon device condition "responding is true/false" might be useful for such a program.  I have not used it before, so I can only theorize.  I am unsure how the ISY-994 would know whether a device is responding, but I assume that it would depend upon the frequency with which something has tried to communicate with a given device.  There is also a "query" option for insteon devices.  Perhaps a program running at some period of time (every hour, for example) you could query a device, hoping that frequent queries would quickly identify "non responding" devices.  Then you would create a program to send a message based upon a condition that a device is non-responding.

I believe that condition is only known from the last query ISY did on that device (3:00 AM?) , or from the last ACK response ISY got from sending a commend to the device.

A cyclic query may need to be set up, if the device or NS does not send a heartbeat.

[Whitehambone]

I just picked a device not doing anything, tried it, and it worked.  I unplugged the 'Christmas Tree" (On/Off Outdoor Module) then Queried the device.  You just need a program to query the device at some given interval.  I sent a message with the Push Node Server.  

Push Test - [ID 0024][Parent 0001]

If
        'Christmas Tree' Responding is False
 
Then
        Set 'Nodes / Push / Garage' Message Don't forget!
 
Else
   - No Actions - (To add one, press 'Action')
 


 

 

[MrBill]

19 hours ago, Whitehambone said:

I just picked a device not doing anything, tried it, and it worked.  I unplugged the 'Christmas Tree" (On/Off Outdoor Module) then Queried the device.  You just need a program to query the device at some given interval.  I sent a message with the Push Node Server.  

Push Test - [ID 0024][Parent 0001]

If
        'Christmas Tree' Responding is False
 
Then
        Set 'Nodes / Push / Garage' Message Don't forget!
 
Else
   - No Actions - (To add one, press 'Action')
 


 

 

This actually does work, and I'm going to use it to find out when a GFCI trips, it already has downstream permanent Insteon after the GFCI.   

I was however confused about the second query program and created it to run the If of the program in your example, that's not correct.  here's what worked for me:

AAA test no query loop - [ID 00EA][Parent 0001][Run At Startup]

If
   - No Conditions - (To add one, press 'Schedule' or 'Condition')
 
Then
        Repeat Every  15 minutes 
           Set 'Christmas-Front#' Query
 
Else
   - No Actions - (To add one, press 'Action')
 
-------------------------------------------------------------------------------

AAA test no query - [ID 00E9][Parent 0001]

If
        'Christmas-Front#' Responding is False
 
Then
        Resource 'zzz-push test'
 
Else
   - No Actions - (To add one, press 'Action')
 

  

Of course since the query generates Insteon traffic so you don't want to run it too often.  In reality for my application I only need it to run once in the late afternoon.  So as I go make this permanent I'll probably just set the query for one specific time per day.

 

[larryllix]

If the device is Insteon then querying it is unnecessary unless you have bad comms and events are missed.

 

On power up ISYwill query all devices to resynch again.

 

Sent using Tapatalk

 

 

 

 

[lhranch]

1 hour ago, larryllix said:

If the device is Insteon then querying it is unnecessary unless you have bad comms and events are missed.

The whole point of the program is to see if a circuit breaker has tripped, which would certainly be a source of bad comms and missed events.

[lilyoyo1]

40 minutes ago, lhranch said:

The whole point of the program is to see if a circuit breaker has tripped, which would certainly be a source of bad comms and missed events.

That's actually a poor method of finding out information. In order to know that type of information, you'd need to be constantly querying devices which would put unnecessary load on your system slowing the whole thing down tremendously (depending on frequency and number of devices). This will affect your actual use of the system much greater than an unresponsive device. If your circuit breakers are popping like that, you need to fix the problem not put a bandaid on it

[lhranch]

I check it programmatically a couple times a day. The breaker doesn't typically trip except during storm activity (it is a GFI that feeds a remote gazebo). I installed a remote light switch out there so I can walk to it safely at night if I need to. 

The actual issue I'm defending against is having a long, undetected power outage to an irrigation controller that is also on that circuit, which would result in damage to a bearing orchard. I lost one tree due to the irrigation being out, and I don't want to lose more.

It's not like I'm sending it ten signals a minute.

I was only interested in knowing whether I had to poll the device for the hub to realize that it wasn't responding, or whether stuff the hub did during the course of a day would notice that the device wasn't responding and trigger the mail program.

[larryllix]

12 hours ago, lhranch said:

The whole point of the program is to see if a circuit breaker has tripped, which would certainly be a source of bad comms and missed events.

Since you never disclosed what "device A" is/was it is hard to know how it could work.

[gviliunas]

So I thought this would be a simple exercise but this turned out not to be so. 

I can see the importance of being able to monitor this type of critical remote circuit. I had two ideas to solve this problem:

Option 1. Connect the coil of a relay (Or possibly just a wall-wart if I/O Link can handle this) to the 120V circuit to be monitored and then use an I/O Link (Plugged into another circuit)  to trigger the circuit-down notification. The down-side of this is the extra hardware required.

Option 2. Since ISY offers a Status of "Responding," this seems a more simple option. The idea is to plug a LampLinc into the monitored circuit and then just periodically check if the LampLinc responds. I used a spare LampLinc and wrote the two programs below to test:

Program 1 - Periodically test the circuit     // Start this program by right-clicking and selecting Run Then

     If:

     Then:

           Repeat Every 10 seconds                  // I set this to 10 seconds for testing. I expect that a reasonable test frequency might be every 8 hr.?

           Run Program 'Program 2 - Test LL Responding

     Else:

 

Program 2 - Test LL Responding

     If:

            'Test LampLinc " Responding is True

     Then:

            $i_Test_LL_Responding = 2

     Else:

           $i_Test_LL_Responding = 1

 

This method using the two programs above FAILED. Why????

I started Program 1 with the LampLinc plugged-in and saw the variable change to "2" as expected. When I unplugged the LampLinc, the variable never changed to "1" ☹️ No

I even added a "Test LampLinc Query" line to the Then section of Program 1. Still, with the LampLinc unplugged, Program 2 failed to detect the not responding condition.  It appears that with ISY, the Status of Responding = True seems to work quickly but ISY doesn't seem to be able to detect Responding = False.

Is there some minimum time that a device needs to be uncommunicative before the Status of Responding is set to False? 

 

 

[MrBill]

@gviliunas What happens if you reverse the logic?  'Test LampLinc " Responding is False.

I was only testing in one direction yesterday. I have a GFCI that trips occasionally due to lightning, in my final program pair I query only once per day at 4PM and the GFCI was purposely tripped.  After I reset the GFCI, I manually turned the queried switch on and back off, specifically to update the ISY's status. 

[apostolakisl]

Querying a device once every 15 minutes should not put any sort of problematic load on your ISY com.  I see no problem in the program posted by @MrBill above.  @lhranch doesn't even seem to need that level of precision.  So I suppose you could go with once every few hours if you want.  But even once a minute should be fine.  Many Insteon users have a house full of switches and motion sensors and stuff which altogether is going to have com running constantly.  What is one more device query in that mix?

[gviliunas]

@MrBill I tried that also. After the initial test, the Responding condition is always True. If I test for Responding = False, the Else section fires.

[MrBill]

1 minute ago, apostolakisl said:

Querying a device once every 15 minutes should not put any sort of problematic load on your ISY com.  I see no problem in the program posted by @MrBill above.  @lhranch doesn't even seem to need that level of precision.  So I suppose you could go with once every few hours if you want.  But even once a minute should be fine.  Many Insteon users have a house full of switches and motion sensors and stuff which altogether is going to have com running constantly.  What is one more device query in that mix?

heh, I actually had 15 seconds in that program when I was testing, I typed over it manually as I was posting the program.    Specifically tho, I would imagine on larger Insteon systems the problem would come at the 3am factory query all.   Query all already takes 10-12 minutes which I'm more painfully aware of during and ISY restart, I'd try to avoid a being too frequent with a loop that produces insteon traffic.

[MrBill]

6 minutes ago, gviliunas said:

@MrBill I tried that also. After the initial test, the Responding condition is always True. If I test for Responding = False, the Else section fires.

weird, when i used Responding = False the THEN block executes on failure.

 

Edit to add: perhaps it requires 2 programs ( Responding = False and  Responding = True) to monitor both states (3 total programs)

[apostolakisl]

@MrBill How many devices do you have?  I think I have about maybe 100 or so Insteon devices and my startup query only takes a few minutes.  

[gviliunas]

@MrBill I think that I was not giving enough time for my query to run (to timeout) before testing if the LampLinc is Responding. The following pair of program now works:

 

Program 1 - Periodically test the circuit     // Start this program by right-clicking and selecting Run Then

     If:

     Then:

           Repeat Every 15 seconds                  // I set this to 15 seconds for testing. I expect that a reasonable test frequency might be every 8 hr.?

           Set 'Test Lamplink' Query

           Wait 10 Seconds

            Run Program 'Program 2 - Test LL Responding  (If)

     Else:

 

Program 2 - Test LL Responding

     If:

            'Test LampLinc " Responding is False

     Then:

            $i_Test_LL_Responding = 1

     Else:

           $i_Test_LL_Responding = 2

 

When the LampLinc is plugged-in, the variable is set to 2. When unplugged, after the Query times-out, the value reverts to 1.  This is Correct.

[gviliunas]

As a test, with the LampLinc plugged in, I stopped Program 1 (above) and manually ran the 3AM Query All and unplugged the LampLinc. As expected, the 3AM Query All caught the non-responding LampLinc and Program 2 set the variable correctly. If only a 1 per day check is okay then you only need Program 2.

So, this method of detecting a circuit breaker trip can be used.

[MrBill]

1 hour ago, gviliunas said:

So, this method of detecting a circuit breaker trip can be used.

I do agree with others, if the issue is a tripping circuit breaker (from load, ARC Fault, or even random nuisance GFCI trips) the root cause should be determined and corrected instead. The single EXCEPTION (that I can think of while typing this) being a GFCI Tripping from lightning which both OP and I appear to have (his is a GFCI breaker, mine is a GFCI outlet).  Lightning is not generally a problem until the amount of wire after the GFCI is long, or the lightning is very close.  It's a problem with a root cause that can't be fixed. 

 

2 hours ago, apostolakisl said:

@MrBill How many devices do you have?  I think I have about maybe 100 or so Insteon devices and my startup query only takes a few minutes.  

That's something I've been wondering for awhile and you just nudged me to figure it out.     I knew that the ISY Inventory Node Server reports 286 Insteon Nodes.  That number is inflates the device count tho.  I have a lot of 6, and 8 button controllers, not to mention wireless devices with multiple nodes.   So to count devices i used Generate Topology and then cut and pasted the nodes table into Excel, then extracted the device number column and only truncated it to the left 8 characters, leaving a column of AA.BB.CC Insteon device addresses, then used the Excel remove duplicates function.  The result I have 114 unique Insteon addresses.   Next I'm going to workout how many of each type of device are present.

[apostolakisl]

@MrBill  Well you really tackled the question head-on.  I just sorted my devices from the admin console by Insteon address which put all the Insteon nodes together, then I counted 40 lines fit on my screen and scrolled down to see that they filled 3 screens.  I then subtracted for the 4kpl's to come up with roughly 100.

The one thing that will slow you down a lot is if you have non-connected devices.  It will dwell on those devices for a long time when they don't respond.  So be sure to disable non-connected devices (ie Christmas lights)

[MrBill]

53 minutes ago, apostolakisl said:

So be sure to disable non-connected devices (ie Christmas lights)

I literally leave the Christmas Insteon devices plugged in all year round, lol.   3 stay in place and the other, 2 I move to a plug strip under my desk.  My wife bought a new fountain, so one of the "Christmas" devices became a Summer fountain controller this year.  

Today, I've actually been wondering if open/close sensors and recessed open/close sensors are getting hammered in the Query all.  (they shouldn't be, but since V5 tries to write to them for scene changes it's made me wonder if ISY is trying to query them).  I'll try running a 'query all' soon with the event viewer open to level 3 to see if anything gets queried repeatedly and/or errors.

[MrBill]

@apostolakisl this has been an interesting exercise.   But it just proves once again that I don't understand what's happening in the error log.    I ran the THEN branch of the Factory query twice, it finishes quickly,  2.5 minutes with zero devices error-ing out.   I wish I could watch it during boot.   I'll have to start watching the error log again at the 3AM mark. 

[lhranch]

14 hours ago, larryllix said:

Since you never disclosed what "device A" is/was it is hard to know how it could work.

It is a remote light switch, as I mentioned in the post to which you responded. In particular, a Decora dimmer switch.

[lhranch]

12 hours ago, MrBill said:

Specifically tho, I would imagine on larger Insteon systems the problem would come at the 3am factory query all. 

Now see, here's a nugget of information I didn't have: the hub always queries all devices at least once every 24 hours. So it looks like I really don't need to run a timed loop to check my circuit breaker (once a day is plenty fine for me).