rleidy

I never experienced an ALL ON for all devices, but I did find my garage door opening unexpectedly. I did switch to the GoControl Z-wave controller and have not had any problem since.

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.

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?)

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.

Bingo! Thanks!

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.

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?

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?

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?

You won't be able to wire it without a rewire to bring neutral into the box.

You can set time range programs to "run at startup" so that if power returns during the range the devices will be set to the desired state.

It might also be an intermittent communication issue. I don't have a very rigorous mesh myself, and I've seen sometimes commands never make it to the destination device.

I relocated the PLM back to its original location in the electrical room and connected it to the ISY through Cat6 wiring and patch cords, and everything seems to be working. I won't know for a few days if that will solve the intermittency that I was seeing, but it doesn't seem to be any worse.

It sounds like there's room to hope it will work. I'll give it a shot. Thanks, all.

A little history: I had my ISY and PLM co-located in my electrical room, with the PLM plugged-in to an outlet right off the main panel and a short Cat6 cable between the ISY and PLM. Due to real-or-perceived issues with the IOlinc controlling the garage door opener, I decided to switch to a Z-Wave controller for the GDO. I had to move the ISY/PLM to the center of the house to get the closer to the garage, and with a couple Z-Wave outlets in between, the ISY is able to control the GDO about 80% of the time (not great, but getting there). However, I'm now having issues with Insteon devices with the PLM at its new location. There's an even greater lag than normal in program execution triggered by motion sensors, and sometimes KBL LED's are getting out-of-sync. So, my thought is that I move the PLM back to the electrical room and use the Cat6 though the structured wiring panel to connect it to the ISY. Is this likely to work at all or cause me any new issues? I'm guessing there's probably 50ft of Cat6 cable between the two, and it would have taken me less time to hook it up than to write this post, but I wanted to make sure I wouldn't harm anything before I tried it. Thanks!