IndyMike

I will start by confessing that I didn't know what the -10 error meant. After reading your posts, I went back through a number of error logs that I had saved. FWIW, the -10 errors are rather common on my system. I have not noticed any performance issues over the time frame covered below. The 4.8 errors per week are lower than my most recent log, but higher than the previous. I am not sure what to make from this. I have never experienced a PLM failure. I've replaced several units over the years due to various improvements, but no failures. I seem to be blessed by "good" power (Hate letters to the normal Email please). I also have logs going back to the 2011 time frame that show the -10 error. They seem to come in clumps, with no particular day/time preference. If I weren't old and lazy I would try to run an analysis on the data to see of there was a correlation with other events going on in the system... I'd be interested to know if there appears to be a time/day preference for your errors. If you are having errors across several PLM's, MrBill's advice is sound. Submit a ticket to try to determine if the errors are due to hardware or environment. Firmware Start Date End Date Days Errors Errors/Day V5.3.4 7/15/2022 11/29/2022 134 125 0.9328358 V5.3.4 10/5/2020 7/13/2022 638 270 0.4231975 V5.3.4 12/8/2019 3/7/2020 89 239 2.6853933

I'm probably beating a dead horse here. I agree that the ISY should be a standalone system that requires very little maintenance. Barring updates or technology expansion, it should just run. Unfortunately, a number of the "modules" have gone away over the years leaving customers stranded. UD has tried to make new options available to replace the disappearing modules, but that isn't always possible within the confines of the given platform. Maybe I misread the OP's post. The words "running again with my ISY" signal to me that he had the NuHeat module running on the ISY994 and it died (presumably when PG's died). Geddy did an excellent job of laying out the events that led to the demise of PG2/PGC and options for getting things running again (PG2 on Rpi or PG3 on Eisy). Unfortunately, there doesn't appear to be a solution using the OP's existing ISY994. I can understand his frustration. It worked previously, but now he needs to buy a Polisy (can't get) or an Eisy (not available yet). Does that mean that he wasn't paying attention? He wasn't involved enough with the forum to understand that things were breaking and being deactivated? You and MrBill are extremely well versed on the technology and various platforms. I enjoy reading your explanations of the various problems and workarounds. In short, I've learned a lot from both of you. Unfortunately not all of us are as up to date on the ISY, PGC, PG2, PG3, Polisy, Eisy happenings. We do have jobs, families, and little distractions that take time away from keeping on top of the technology. Please treat us gently. We often do not have the time to invest in reading years worth of posts trying to find a solution.

Let me start by saying that I've been a UD customer since 2007. In my mind, UD helped to take Insteon from a well engineered but haphazardly deployed product to an Integrated system. I still use my ISY994 for Insteon and the Elk Module integration daily. So, what is my point in posting? I have to object to a number of the posts above that indicated that the OP "you haven't been paying attention" or that "it's on the consumer to keep up as things can change significantly". I would be shocked if UD were in agreement with this. In contrast, their website advertises the products as standalone devices that are stable and do not require babysitting (see below) This device should not require constant maintenance or vigilance. That's why we purchased a dedicated hardware device (not cloud services). If you do not make changes to your installed system, hardware/software changes and upgrades should not be required. By indicating otherwise, you are alienating UD customers that have come here for help. If I am wrong in assuming that this should be a low maintenance product, please correct me. I will immediately begin looking for hardware replacements that fit the description below: UD Webiste Ad Automation | Energy Management | IoT | AI We invented and commercialized the first low cost, embedded, and fully standalone home automation controller in 2007. A few inventions later, 10s of 1000s of rock solid installations later, our ISY994 Series line of products embody the perfect marriage of Automation, Energy Management, IoT, and AI Assistants. You can easily consider ISY as your sidekick@home. You can program your ISY with what needs to be done and it does it. Literally and forever unless you instruct it otherwise. You can count on it. Your ISY does not need to be babysat, it is not a glorified remote control app on your mobile phone. Neither is it some magical essence in the cloud that might take a break once the Internet is down. Your ISY can notify you of major and important events, you can talk to it, and it can talk to you. Yes, via natural voice using Alexa and Google Home. Your ISY can even help you save money, save energy, conserve water, and save the earth! Why should you trust us? Because we stand behind you and our products. Don’t take our word for it. Take a look at our Testimonials

Hello balli, I have had nothing but good experiences with the Zooz gen7 devices. I do not have any Zen76, but do have 4 Zen77 (dimming version) as well as a number of battery devices and a Zooz ZST10-700 controller. As Techman implied, I would submit that your problem is the 500 series controller in the ISY994. I struggled with this for years with my system. Kept adding repeaters to the system trying to fix intermittent problems. I finally moved to the zooz 700 system (controller, locks, switches) and have been extremely happy. Most of my battery devices now direct connect to the controller. To put that in perspective - my controller is in the basement, battery devices are in the garage (75', attic 35', 1st floor, 2nd floor). It may be painful, but I would suggest moving on from the 500 series controller. I moved to Home Assistant on a Raspberry PI for my Zwave devices. I am still using the ISY994 for Insteon. Home assistant interfaces nicely with the ISY994 (I can share scenes, and actions). To be clear - your Zwave communication problems are not the fault of the ISY. It is the 500 series Zwave controller that is constraining things. Unfortunately, the ISY994 does not support 700 series Zwave controllers. The following Zwave network map doesn't show that well. Items on the 2nd level down have direct communication to the 700 series controller in my basement (10 devices). 3rd level devices require 1 hop to make it to the controller (4 devices). Keep in mind that I only have 4 wired devices (repeaters). Everything else is battery. Hope this helps, IM

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.