IndyMike

You need to think in terms of current imbalance rather that power usage. A few milli-amps imbalance (fraction of a watt @120V) is enough to trip a GFCI. A length of buried cable that is leaking to earth can produce enough imbalance with zero load. It sounds like you have a number of devices and cable runs that could contribute to the leakage. Unfortunately, the leakage is small and difficult to detect. I would suggest using the process of elimination to isolate which device(s) are leaking. I say devices because it could be multiple underground cable runs that are contributing to the leakage. The underground cable to my post light lasted 20 years before it had issues. 1) With everything installed on the circuit, force run your 3am query to verify that you can trip the breaker - this is your detector. You can also query "my lighting" from the admin console tree. 2) Remove al of your outlets and loads from the GFCI circuit and repeat the query. Hopefully the GFCI will NOT trip. 3) Begin adding loads back to the circuit, repeating the query process. If you find a load/device that trips the GFCI, try it by itself. Remember that the leakage may be "additive" across a couple or several loads. This could be easy, or really complicated. Let us know what you find.

Hello rssorensen, Just a few addition comments to the good items provided above. To start (and not to be insulting) GFCI devices trip if there is and imbalance between the hot/neutral current. They are very accurate and fast. Insteon communications (130 KHz vs 60Hz) can cause a higher leakage if the path is capacitive. I have had a HP printer that had "high" leakage to ground and would intermittently trip a basement GFCI. I cured this with a filterlinc (isolated the printer from the 130KhZ Insteon). 1) The "Query all" program includes everything in "My Lighting" (excludes battery devices). This includes Insteon, X10 , and Zwave. You can create your own "house query scene" to limit the devices. I created my own query scene years ago when my 2-way x10 devices were having issues. It does require maintenance - you have to add new devices - and it is a patch - it does not solve your root problem. 2) I have had problems in the past with a garage circuit tripping the CFCI when my outdoor post lamp was on (photo cell) and there was insteon communication. I narrowed this down to a bad underground wire that was leaking to ground (or earth) during communications. Insteon communication is higher frequency an will cause higher leakage to earth (or ground) during communication. As ELA idicated, If you have high leakage on a circuit, the additional Insteon communication could be enough to trip the CFCI. 3) Recently I had installed a 2 prong Zwave repeater on my garage circuit. Soon after the GFCI breaker tripped. Reset the breaker, and noted that It tripped whenever my Zwave garage lock operated. Moved the repeater to another circuit and the problem when away. I bring this up because I did not expect it. I would not expect a 2 connection device to trip a GFCI unless it significantly delayed the current draw. This is not necessarily due to the Insteon device. You mentioned that your GFCI was on an outdoor circuit. Have a look at any outdoor devices that may have degraded over time (transformers, underground cables, smokers, etc). They can all contribute to leakage to ground. IM

JTsao, Thank you for the post. I had bought the WiFi version of this lock for my daughter when she purchased her new condo last year. She loves the smartphone/alexa integration as well as the fingerprint access (2 room mates). I'm not a WiFi fan and was exited when I saw the Zwave Plus V2 lock become available earlier this year. I was just waiting for the correct post to push me into buying it. Your post got me moving. Like you, I have 2 Schlage (original) BE469 deadbolts. The high maintenance unit is located in the garage ~ 75 feet from the ISY in my basement. The garage is also lined with foil backed foam on the inside, and stucco on the outside (Faraday cage). My zwave access is through the door window between the house and garage. I was constantly moving repeaters around hunting for the sweet spots to made the garage deadbolt reliable. I installed the Ultraloq Pro Z-wave deadbolt yesterday. I have only the ISY994, so I chose to pair the lock with Home Assistant and the same Zooz ZST10 that you used. It took roughly 30 minutes to install, setup on the phone APP, and pair with Home Assistant. The real kicker was that I included the lock in the garage location with my Rpi4 home assistant 90 feet away in the basement. I was astonished. I could not believe that it could be that easy. All the years of fighting with the Schlage using multiple repeaters, including with extension cords/cat 5 extensions so that I could include "in place", and the Ultraloq included in place with 2 Zooz Z77 switches as repeaters. The cherry on top is that the Ultraloq comes with a door sensor (magnet) to detect when the door is actually closed. I programmed it to autolock 5 minutes after closing. I had been using my ELK-M1 door switches to tell the ISY994 when the doors were closed. My programs on the ISY would then lock the door after 5 minutes and indicate the status on various KPLs. The ELK integration was one of the things that was keeping me from moving to the Polisy. I was worried that I would not be able to accomplish the same integration/timing on the new platform. No longer a concern. At this point, the second Ultraloq is on order (front door - easy one). Just need to figure out how to "back communicate" lock status to the ISY994 so my KPL security monitors display properly. Thanks again for the push in the back, IM

Apologies if this has been previously reported... As shown in the graphics below, the "my lighting" folder contains the buttons "Query, All On, and All Off" in the folder window. These buttons are functional. The folder windows also contain the "Query, All On, and All Off" button. They are not functional in any of the folders. The folder All On/All Off would be useful in determining which modules have the Insteon fix to NOT Respond to a ALL On/All Off. Windows 10 Running 5.0.16C

Hello oberkc, You may be correct. My experience is from the original ISY back in 2006 (very dated). At that time it was possible to set up a race condition in the manner that I described without a wait. Many things have changed since that time. I do not think we can test this without seeing the "security - back timer program". There may be issues where communication failures/re-tries factor into the program timing. In general, it's never advisable to modify the trigger conditions within the program. We may need Chris to weight in on whether this specific implementation is a problem with Ver 4.7.3. Realistically, I'm thinking he busy working on our 100's of other requests. Sincerely, IM

In general, you should not modify the state of your "IF" conditions within the program. It will cause the program to re-trigger. If you put a delay (1 sec) after the "Set dining room" statement, this program would exit 100% of the time. Without the delay, you have a race condition. Hard to say if the re-trigger will take effect before you make it to calling your other program. You may be getting "lucky" on your other program. Regardless, the "responding" drop down in the lower pane has no bearing on your saved program. It is simply an option for modifying/adding to the program. Please let us know if the modification works. It's possible you have another race condition in your called program.

Hello proj964, The lower panel is an "Action" panel for changing or adding to your program/conditions. The fact that it shows "responding" indicates one of the options for adding to, or modifying your existing program. Your existing program (if saved) is shown in the upper pane. Bottom line - the lower pane is distracting you from the real problem. 1) Your IF statement checks the "dining room/outside light switch" status to make sure it is off. 2) Your program set the "dining room/outside light switch" to "ON". This causes the program to re-trigger, and the "IF" statement is now false. 3) The program MAY exit before executing the remaining statements. It's basically a race condition. You could move the "dining room/outside light switch" ON statement to your "Security back timer" program to prevent the re-trigger.

joefly, In a nutshell, your 2486D is not acknowledging the link write from the PLM. The ISY tried to write the link to the device EEProm 3 times. It did not get an ACK from the device for any of the attempts and timed out. The cause of the write problem could be due to noise, signal absorbtion, or a failing device. I'd try multiple restoring the device times (reset the dimmer and retry the restore) since it could have been an isolated event. If the restore does not work, you can try the normal "inspection" technique, looking for any new devices that could be absorbing signal or generating noise. Alternatively, you could remove the switch and attach it to an appliance cord and plug it in next to the PLM. If a restore does not work with the dimmer next to the PLM, you have a bad dimmer or a failing PLM.

The 4827 boosterlinc will designed to repeat (amplify) X10 signals. Unfortunately, when it gets confused and corrupts Insteon signals. If you do not have X10 in your system there is no reason for the 4827 - remove it to preserve your Insteon signalling. If you do have X10 in your system there are far better amplifiers that do not step on the Insteon communication - again, remove the 4827. Jeff Volp has a line of X10 repeaters that will not interfere with your insteon signals: Jeff Volp XTB X10 Repeaters

Hello pjjameso, I agree that this could be a case where the scene command from the ISY/PLM could collide with the scene clean-up commands from the Keypadlinc. I'm wondering if your KPL is flashing, indicating that it is not communicating properly with one of the scene responders? The 2 second delay that Larry suggested should have gone a long way toward eliminating this possibility. It should have allowed time for the KPL to complete the clean-up communications, unless there are communications issues which could require re-tries (extending the communication time). Paul is also correct that noise or absorption near the KPL could be causing the KPL to miss the scene command from the ISY. Why am I posting? I do not recommend your "fix" as you have posted it. If I understand your scene correctly, you are issuing a scene command to a KPL that has just issued a control action. That opens the door for possible "all-on" collisions. Have a look here: Wiki: All-on-events I would rather see you place the 2 second wait in front of the 1st scene command.

Scott, I do disassemble the PLM and physically remove the antenna. I did this years back after having a all-on event. Can't say this was a solution since I made many other changes at the same time. I have had 1 all on since then. It was KPL triggered. I am a bit confused by your second statement. I was trying to point out to the OP that performing a factory reset would wipe the PLM. He has a very low link count now because he only added the motion sensors back in. It sounds like you and I agree that the PLM will ignore traffic that it does not have a link record for. That was the point that I was trying to make in my post. Did you mean to address this to the OP?

Jack, You've noted several times that the device has issues at the Sunrise + 10 minute point, but functions normally otherwise. We are looking for a noise source / signal absorber that is RELIABLY active at that time. Assuming that you aren't actively turning on another device programmatically, the only other device I can think of would be a photocell. This could be outdoor or indoor, but normally the indoor night lights don't pull enough power to be a problem. I have had issues with photocells generating noise in the past (post lamp). They can generate noise due to poor design, or aging of the sensor itself. I finally removed the sensor from my post light and used an Insteon switch to activate programmatically. Other possible offenders could be timed kitchen devices (coffee pot), a setback thermostat warming the house around that time, etc.

Hello GTCJ, You are correct about disabling the programs. The following is what I have done to read the link tables: 1) All programs in a folder which I disable with a $Programs_disable variable. This takes care of scheduled programs and queries. 2) Place the PLM behind 2 - filterlincs to prevent powerline communication from reaching the PLM. This does not always work. The filters are not 100% effective in eliminating the powerline signals. 3) I have removed the antennas from my PLM in an attempt to eliminate RF communication. Again, not 100% effective. My reasoning for eliminating the antenna is a bit obscure. Suffice it to say that I do prefer the PLM to operate in powerline only communication mode. Please note that I am not advocating that anyone perform the above operations. I am posting this mainly to show how difficult it can be to get a reliable PLM link count. If you cannot get a consistent link count 3 times (with nothing showing in the event viewer), I would not trust the result. Not a very useful function for most users. Since you factor reset your PLM, the ISY knows of the existence of your devices but your PLM does not. If you go to a Switchlinc and turn it on/off, the PLM will likely not register it's activity. You will need to restore the PLM before it recognizes communication from these devices.

Hello GTCJ, While it is entirely possible that your PLM is having power supply issues, getting a good PLM link table read is actually quite difficult to do. Problems arise if there is ANY program or device activity while the reading is in process. LeeG posted a rather nice explanation of what happens when the read process is interrupted here : https://forum.universal-devices.com/topic/19022-cant-view-plm-links-table/?p=177734 The fact you were seeing wide variations in the link count is more likely due to the read process being interrupted. Your most recent post after resetting the PLM has me confused. Either the PLM is failing or you "FACTORY RESET" the PLM, and in doing so wiped out the Link table. If you did perform a factory reset, you will need to restore the PLM from backup to restore the Link Table. I do agree with Stu that, with over 300 devices, you are likely at or over the PLM table limit of 1000.

The fact that "fast on" functions makes it sound like you may have a problem with the device ramp rate. Check to make sure it isn't set to something very long - making the device seem like it is not responding to the "on" command.

Unless something has changed recently: The ISY will not request a group cleanup after turning a scene on/off. There are no retries associated with an ISY scene. The ISY reports what "it believes" the correct device status is based on the scene command it executed. While not as reliable, this is very fast and does not encounter issues when stringing multiple scene commands together. A device direct command from the ISY (clicking a device on/off from the device tree) will request a cleanup response and will retry failed communications. A button press (KPL button or switch button) will execute a scene command and request cleanup from each device in the scene.

Techman, I also have the 2009 developers guide. No help there. The best information that I've seen on the subject is Lee G's post that you referenced above. Just to be clear, it isn't just the "EA" record that will show as a record mismatch. Since the hop count can increment from 0 to 3, you have three values that can create a mismatch. Better to simply mask the bits out of the comparison 0 Hop: E2 1 Hop: EA 2 Hop: F2 3 Hop: FA By the way, thank you for bringing this up. I don't have many I2CS devices and had been restoring them (incorrectly) when I noticed these mismatches. I feel a lot better now that I understand that the devices are modifying themselves.

Hello Techman, It looks like you found the correct post from Lee G. As he documented I2CS controllers are capable of changing the cleanup hop count to "adapt" to their installed environment. The "EA" link record is the result of a I2CS device increasing the default cleanup hop count to 1 hop. Since the hardware device is modifying its cleanup count locally, the ISY should NOT consider this a record mismatch. I had missed this post originally an am learning along with you. To verify, I went through a series of tests with a "new" KPL. The KPL was setup to "turn off" my 1st floor scene (~ 30 devices) using a non-toggle button. As programmed by the ISY there were zero mismatches. By varying the location of the KPL (wired to a cord) I could observe how it modified the cleanup hop counts for various scene members. The KPL both increased and decreased the hop count depending on its location. 1) As programmed by the ISY - no mismatches 2) Location 1: 10 mismatches 3) Location 2: 11 mismatches 4) Location 3: 12 mismatches

Hello jgcharlotte, My information may be a bit dated - most of my devices are V1.1 2420M sensors (Old). The behavior you are looking for below is exactly what I get with the "sensing mode" unchecked. I've just verified this with my spare sensor. With the "sensing mode" unchecked: 1) sensor sends an "On" at first motion, then an off after 30 seconds if no additional motion is detected. 2) sensor sends an "On' at first motion, and recognizes additional motion but does not transmit. It re-starts the 30 sec motion timer at each event. After 30 sec with "no motion", it will send an off. If this is what you are looking for, I don't believe you need any program intervention.

Hello GMD99, As others have correctly posted, dimmer switches generate heat that is a percentage of the power delivered to the load. The higher the power, the more waste heat generated by the dimmer. All (95%) dimmer switches generate waste heat in this manner. This is not something that is unique to Insteon devices. Since the hot faceplate appears to be new after the rewire, I am guessing that you had traditional (non-dimming) switches installed previously. If so, these would not have generated waste heat. With dimmers installed, the temperature of your faceplate will depend on many factors that affect the amount of heat generated, and how the heat is conducted away from the switch: 1) # of active dimmers/load power 2) J box type (plastic/metal) 3) Wall type (inside/outside; insulated/uninsulated). 4) Wall sheathiing (sheetrock/plaster/wood) 5) faceplate type (plastic/metal) I made some measurements on the heat generated by a KPL dimmer VS load some years back. That information is located here: http://forum.smarthome.com/topic.asp?TOPIC_ID=6969&FORUM_ID=9 The temperature vs load information should give you an idea of whether there is something "wrong" with your installation. My guess is that there is not, but I certainly do not want to minimize any concern on your part. If you believe your temps are running higher than what I am showing in the link, you should absolutely call your electrician. If you are concerned with the heat being generated at the switchbox and/or reliability concerns with the heat in the switches, post back - there are many ways to address this.

nil13, If you have the network module, you can use a program to log whatever data your heart desires (and variables support). http://forum.universal-devices.com/topic/10122-402-network-module-create-web-pages-using-programs/ I've been using this technique to log weather data for a couple of years now. Very nice.

Christopher, I agree that if your program ran, you should have received both a "Program" log entry as well as "System" log entries for each device in the Scene. I have a "recirculation pump" program that runs twice daily. I've been logging entries for this program daily even though the applicancelinc that is Scene uses was removed months ago. I don't have a good explanation for why your program indicated "run" but you have no log entries. This is probably a Michel question. My only observation would be that 12:59:59 may be a rather busy time for the ISY. You could try moving the trigger time a few minutes in either direction. I've never seen the ISY "miss" a program operation. Nonetheless, I do think this needs to be investigated.

Brian, I believe the 4826 had issues handling "Dim" commands from the X10 CM15a (firestorm event). Being that the 4826 is labeled as a "true X10 repeater", it should have been able to distinguish between X10 and Insteon transmissions. The Boosterlinc was a real time booster. It attempted to discriminate between Insteon/X10 by the start of the waveform in relation to the 60Hz zero crossing. It would invariably get fooled into thinking a low level Insteon transmission was X10 and would transmit on top of the Insteon.

Hello JSP0511, To be blunt - these are not the type of devices that I would trust to automation. Not just Insteon, but ZWave, UPB, X10, RadioRa - you name it. All of the automation protocols are subject to programming and communication errors. Think in terms of what would happen if your compressor or shop vac were to inadvertently turn on while you were away. This is not something we can answer for you - it's your application. Personally, I would not install such a system without a manual override. The problem is remembering to activate the override. If I were to vote, I would vote in favor of the "purpose built" current sensing switches that larryllix posted. I'm not sure if these are appropriate for you air compressor application - I'm unsure how you are using the compressor with your woodworking tools. My 0.02, IM

Like LeeG, your comment on this being an old Commercial building caught my attention: 1) Possible that you have "true 3-phase" power. Voltage across the mains (legs) would be 208 rms rather than 240. 2) Possible that your RF communication is being blocked by fire-breaks, metal, and other construction materials not commonly found in residential construction. As LeeG indicated, check your coupling between RF devices - make sure your phases are STILL coupled.