Communication failure detection?

[rleidy]

I'm troubleshooting an outdoor circuit that is on a GFCI circuit breaker that trips on occasion.  I would like to know when the circuit trips.  If I have an Insteon device on the circuit, is there a good way to detect when the ISY can no longer communicate with it? 

[Techman]

You could query the Insteon device using a program.

 

 

If

Time is 2:00 pm
and status device is not responding

 

Then

  Send message

 

Else

[rleidy]

Oh, okay, that's easy, thanks.  I never noticed the "responding" status value.  So, I would create one program to periodically query the device and then call a 2nd program to check the results of the query?  Does the device Query operation complete before returning?

[Techman]

Oh, okay, that's easy, thanks.  I never noticed the "responding" status value.  So, I would create one program to periodically query the device and then call a 2nd program to check the results of the query?  Does the device Query operation complete before returning?

 

If one of the values changes in the IF statement then the program would restart othewise the program would run until it completes.

 

I don't see the need for a second program, but if you decide to use one then the second program, once triggered, would run until it completes regardless of the status of the first program

[rleidy]

I'm not sure how to do it without 2 programs.  One to periodically query the device, and the other to check the status for "not responding" and send a notification.  Am I missing something?  Or does the check for "not responding" perform an implicit query?

[Techman]

I'm not sure how to do it without 2 programs.  One to periodically query the device, and the other to check the status for "not responding" and send a notification.  Am I missing something?  Or does the check for "not responding" perform an implicit query?

 

If the IF statement in the program evaluates as true then the THEN statement will run thus sending you a notification, if it evaluates as false then the ELSE statement will run, which in this case is null.

 

You can test the program by tripping the GFI to verify that you'll get a notification.

[rleidy]

I understand the concept of if/then/else.  I better, since I've been a software developer for 30 years.  What I'm trying to understand is under what circumstance will a program will trigger with a condition of "status device is not responding".  It seems to me that a command must first be sent to the device (whether a query or ON or OFF, etc.) in order for the ISY to detect that the device is not responding and consequently update its cached status value for the device, and then trigger the program.  In my scenario, the device should be ON constantly.  I won't be turning it ON and OFF, so if the GFCI trips, my expectation is that the ISY won't know about it until the 3am query, and then the program would be triggered.  If I want to know about the tripped circuit sooner, wouldn't I need to periodically issue my own query?  

 

This is currently a mental exercise, because I won't get a chance to install the device until this evening.  I'm just trying to get a handle on what I'll need to do ahead of time.  I guess I'll figure it out once I have the device installed. 

[mwester]

Yes, you are exactly right -- you won't know about the absence of the device until the 3AM query unless you arrange to query on your own.  So you'll need to query and then test the responding status separately in order for this to work.

[Teken]

I would suggest you set it to query every hour then use the second program to confirm with the ISY Series Controller that its not responding.

 

For example if this circuit was monitoring a critical load like a fridge / freezer. Having the system query every hour is well in the safety margin of keeping the contents cold. You can certainly query the device sooner but this can impact the Insteon network and the controller itself if there are lots of other over lapping programs running at that same time.

 

Regardless, all of the above is simply a band aid and not a final solution to the problem. If the GFCI is tripping its either because there is a real fault condition present. Or the GFCI needs to replaced due to being old or impacted by Insteon signals which has been seen a few times over the years.

 

The easiest thing to do is replace the GFCI outlet and see what happens . . . If the new unit trips you narrowed it down to two possibilities which are:

 

There is a real world condition that needs your attention - or the Insteon signal is causing a nuisance trip.  

[Techman]

Yes, you are exactly right -- you won't know about the absence of the device until the 3AM query unless you arrange to query on your own.  So you'll need to query and then test the responding status separately in order for this to work.

 

I just ran some tests, it's not necessary to issue a query first in order for the program to detect a failure and send a notification.

 

When you run the IF clause the "not responding" statement sends a query.

[rleidy]

I just ran some tests, it's not necessary to issue a query first in order for the program to detect a failure and send a notification.

 

When you run the IF clause the "not responding" statement sends a query.

 

Bingo!  Thanks!

[rleidy]

I would suggest you set it to query every hour then use the second program to confirm with the ISY Series Controller that its not responding.

 

For example if this circuit was monitoring a critical load like a fridge / freezer. Having the system query every hour is well in the safety margin of keeping the contents cold. You can certainly query the device sooner but this can impact the Insteon network and the controller itself if there are lots of other over lapping programs running at that same time.

 

Regardless, all of the above is simply a band aid and not a final solution to the problem. If the GFCI is tripping its either because there is a real fault condition present. Or the GFCI needs to replaced due to being old or impacted by Insteon signals which has been seen a few times over the years.

 

The easiest thing to do is replace the GFCI outlet and see what happens . . . If the new unit trips you narrowed it down to two possibilities which are:

 

There is a real world condition that needs your attention - or the Insteon signal is causing a nuisance trip.  

 

The GFCI is at the breaker.  I'm actively looking for the source of the trip, but meanwhile I want to know if/when it trips.  The breaker feeds an outdoor circuit with UF cable that was installed "creatively" by the previous home owner.  I've already eliminated the section of cable that was at least part of the problem, but until I get a heavy rain, I won't have confidence that it was the source of the entire problem.  I've got a pond waterfall pump on the circuit and that's the main source of aeration for the pond and It should be running 24/7.  I want to know if/when it stops so I can switch over to a temporary extension cord for the pump while I continue my troubleshooting of the circuit fault.   

[rleidy]

I just ran some tests, it's not necessary to issue a query first in order for the program to detect a failure and send a notification.

 

When you run the IF clause the "not responding" statement sends a query.

 

Does anyone know if there are other conditionals that are active in this way?  (As opposed to the passive comparison against the cached status in the ISY?)

[Techman]

Does anyone know if there are other conditionals that are active in this way?  (As opposed to the passive comparison against the cached status in the ISY?)

 

Can you give an example of what it is you'd like to do.

 

The ISY allows for a lot of creative options.

[rleidy]

Can you give an example of what it is you'd like to do.

 

The ISY allows for a lot of creative options.

 

Nothing in particular, I was just curious about this exception case.  My understanding was that a conditional that checks the status of a device actually only compares against the status that's currently cached by the ISY - no device interaction.  Techman's test indicates that a status check for is/is not responding actually hits the device.  I just wondered if that was the only exception case.

[Teken]

The GFCI is at the breaker.  I'm actively looking for the source of the trip, but meanwhile I want to know if/when it trips.  The breaker feeds an outdoor circuit with UF cable that was installed "creatively" by the previous home owner.  I've already eliminated the section of cable that was at least part of the problem, but until I get a heavy rain, I won't have confidence that it was the source of the entire problem.  I've got a pond waterfall pump on the circuit and that's the main source of aeration for the pond and It should be running 24/7.  I want to know if/when it stops so I can switch over to a temporary extension cord for the pump while I continue my troubleshooting of the circuit fault.   

 

There are quite a few 3rd party devices that monitor dedicated outlets. Some offer just a LED and siren, whereas others will send an alert to the end user of the very same.

 

Given your reply above it sound like the *Creative Wiring* still poses an issue . . .

[Techman]

Nothing in particular, I was just curious about this exception case.  My understanding was that a conditional that checks the status of a device actually only compares against the status that's currently cached by the ISY - no device interaction.  Techman's test indicates that a status check for is/is not responding actually hits the device.  I just wondered if that was the only exception case.

 

 

Other program options are CONTROL and STATUS, which respond based on a device either being physically changed or the status of a device being changed by a program or condition.

 

Take a look at the UDI Wiki which has a lot of programming suggestions

 

If you have a particular task that you want to accomplish just post it in the forum and you'll always get a quick answer.

.

[Scott847]

I just ran some tests, it's not necessary to issue a query first in order for the program to detect a failure and send a notification.

 

When you run the IF clause the "not responding" statement sends a query.

 

Hmmm... my experience was different. Coincidentally I'm working on a program like this and found that a query was necessary to detect a failure or power outage affecting a switch.

 

Following are my programs using ISY firmware 4.5.1. When state variable $s_Warning_Code is greater than zero another program sends me an email.

 

*** PROGRAM: Check Hourly Daytime - [Run At Startup]

If

        From     9:00:00AM

        To      10:30:00PM (same day)

Then

        Repeat Every  1 hour 

           Set 'Devices / Basement / Ventilation Fan' Query

           Wait  20 seconds

           Set 'Devices / Basement / Dehumidifier ZW030' Query

 

*** PROGRAM: Monitor Dehumidifier

If

        Status  'Devices / Basement / Dehumidifier ZW030' is not Responding

Then

        Wait  1 minute 

        $s_Dehumidifier_Switch_Failed  = 1

        $s_Warning_Code  = 9

Else

        $s_Dehumidifier_Switch_Failed  = 0

 

*** PROGRAM: Monitor Ventilation Fan

If

        Status  'Devices / Basement / Ventilation Fan' is not Responding

     Or Status  'Devices / Basement / Ventilation Fan' is Off

Then

        Wait  1 minute 

        $s_Ventilation_Fan_Failed_or_Off  = 1

        $s_Warning_Code  = 8

Else

        $s_Ventilation_Fan_Failed_or_Off  = 0