gviliunas

re. Cannot backup Z-Wave configuration. I installed 5.0.13D then did a Sync All. No failed nodes were found but I did see many instances in the log indicating a device was not sync'ed. After this, I tried a backup 2x. Notice that the backup operation fails at a different point. Logs attached. Logs attached ISY-Events-Log.v5.0.13D__Fri 2018.08.24 04.26.24.txt

Thanks for the suggestion. This worked 1 time only. I performed the Sync All. There was a red-slash note at the top of my tree "ZW-000" I deleted that node and was able to backup successfully just 1 time. BUT then I tried the backup operation again and again several more times....and these all failed. I even tried a re-sync again but no bad nodes were found this time ...... But still the backup Failed ( I disabled all of my programs for this last test). Here are screen shots and logs from the last attempt. ISY-Events-Log.v5.0.13C__Wed 2018.08.22 19.13.48.txt

Hi Michel, Re. Inability to backup Z-Wave configuration on new dongle. Thanks for your suggestion. 1. Yes, I believe that all of my Z-wave devices are working. 2. I tried to Sync All nodes as you suggested. This seemed to complete successfully but the backup still failed. Here is additional data... 3. I disabled all programs (to minimize the log entries) and then opened the event viewer in Level 3 and tried again. Attached is the result. ISY-Events-Log.v5.0.13C__Tue 2018.08.21 20.19.06.txt

Error when backing up new Z-Wave Dongle. ISY version 5.0.13C I installed the new dongle several weeks ago and everything appears to be working. I did test the ability to backup the dongle upon installation and it worked correctly. I also tried this a few days ago and it also worked without error. Today I excluded and re-added two Zooz smart plugs as secure devices, successfully healed the network and then played with my "The Buttons" parameters to try and make these devices more reliable. Everything appears to still be working. As a last step, I wanted to backup the new dongle. When I did, the operation failed and I received 2 pop-up errors: Top Pop-up: Could not open file: [/DEF/F6/I1/NLS/EN_US.txt] Below Pop-up: The Z-Wave Dongle has not been backed-up. An error occurred while reading data from the Z-Wave dongle. I first tried rebooting and then tried power-cycling the ISY but received the same pop-up errors above when attempting to backup ISY. ISY Error Log.v5.0.13C__Sat 2018.08.18 07.52.14.txt

@blueman2 No, no Door Locks. Only the items that I listed.

I upgraded to 5.0.13A several days ago and then installed the new Z-Wave board and restored settings yesterday - No problems encountered - Initially I did not heal the network - Everything works without re-heal. I did a backup of the new Z-wave board and it finished successfully within 1 minute. Backup of the original module took ~40 minutes. Added two additional Aeon Multisensor 6 and a Fibaro The Button - No problems encountered. Since I added and re-located the new modules, performed a network heal - No problems encountered. My system includes ~25 Insteon modules + (3) Stelpro Thermostats, (1) GoControl Thermostat, (7) Aeon Multisensor 6, (1) EcoLink Door/Window sensor, (2) Fibaro The Button, (1) Zooz ZEN06 The new Z-Wave module seems to be working perfectly for me. Thank You for another great product. ------------------------------------------------ Possibly unrelated cosmetic issue - I was editing some programs after the upgrade and the Admin console was very slow and sluggish. Click to save a program and wait several seconds for response. Click on another program and wait sever seconds for the focus to change to that program. etc. No errors and the action I was requesting eventually completed successfully. I had been using the ISY Launcher through the 5.12-5.13A period. Tried restarting ISY from the Admin Console - No change, still slow Cleared Java cache and reinstalled the ISY launcher and everything seems normal. I'll do further digging if this problem returns.

Hi Mark, It seems a little early for you to be experiencing the dreaded 2-year PLM failure but if ISY doesn't know about status changes, your PLM might have lost some links OR something has been introduced into your home environment that is causing communication problems. If this happened to me, I would wait for a quiet time when the devices aren't changing state and then select to restore modem. If you use RF devices and have a 994 pro then you may want to deselect writing to battery powered devices first. All you want to do is restore the PLM links and this is done in the first 30-ish seconds of the restore modem operation. If this fixes your problem, good but be on the lookout for future failures. If these occur, you may have capacitors that are failing. Search for PLM reliability and you'll find how this can easily be fixed. With the outstanding help of Lee and other members of this board and Michel from UDI, I have been able to fix all of the problems that have occurred in my system. I am confident that your problem will not be a mystery for long. Good Luck Greg

After ~2 months, I just experienced yet another ALL ON event. This time was slightly different than previous events. 1. Earlier today I received a Battery Low signal from a v2.20 2420M Motion Sensor. I changed the battery about 2hr before the event and did verify proper operation before placing it back up on the wall. Okay, so it wasn't the MS low battery signal that I ignored for too long.... 2. In previous occurrences, I was comforted by the fact that All ON events never happened when we weren't home. I could always blame someone for switching on the light or tripping the motion sensor at the "wrong" time. Today, we were all at the dinner table. Nobody changed any switches for, at least 15-minutes prior to the event and it was impossible for anyone to trigger a motion sensor. All of a sudden, Poof!, all the lights were ON, all the fans were ON, the fireplace was ON, and my garage compressor was running. I was very worried to see the fireplace and compressor on. This could have cause a serious problem had we'd been out of town.... Given that now I understand that these events can occur without a human trigger, I am worried about leaving some loads in Insteon's now "less than capable" hands when we are out of the house. Hopefully Smarthome is continuing to investigate and we can expect a fix or, at least, some type of defensive action.....soon. I am wondering if I should add a "All ON Indicating" switchlink to my system and have ISY test status every few minutes. I need to test status since ISY doesn't usually know that these events occur since log events showing a cause are absent. If the status of this SL is ever found "ON" then ISY can assume the worst and execute a series of programs to put everything right. Defensive actions such as this suddenly seem prudent in light of random failure and Insteon being used in vacation homes and other buildings not continually occupied. Greg FYI: PLM is a v9B that was installed ~December, 2013. I don't believe that the PLM version is the issue as I have had ALL ON occurrences for several years using various PLMs ISY Error Log.v4.2.2__Mon 2014.05.26 20.43.11.txt

Add Button A to a new scene as a responder then turn the scene off as part of your program.

I'm not sure that the problem can be attributed to PLM version 9B more than attributing it to a generic PLM or Insteon architecture issue. I have experienced this problem for more than 4-years across 5 different PLMs, both 2413 and 2412. My occurrences are very rare 1 per 1-2months. Timely motion sensor battery changes and Michel's suggestion to add time delays when programs affect KPL scenes have done the most to reduce the frequency of occurance. I replaced my PLM with a new v9B about 5-6 months ago and I haven't seen a problem (yet) with this PLM. I think I'm very happy with the v9B in my specific case (cross fingers here and pray). I'm not ready to "pin" this on any one version of PLM but am not happy with the overall reliability of that weak (PLM) link. Greg

I have experienced the random-ON events for3-4 years now. I have very little faith that this will be solved in the near future. For me, these occur once every 3-4 months. Fortunately, the problem, for me, always occurs when somebody is home and can usually be traced to a point where someone in the home activates an Insteon device (switch or motion sensor). I have not been able to attribute my events to any 1 (or small number) device. The problem began when I installed my first (early revision) KPL. With that KPL, I could cause the ALL-ON regularly (every few days) by pressing button "A." After replacement of that KPL, the frequency of occurrence dropped to the once per 1-2 month level. Through better programming (adding wait delays when motion sensors trigger KPL buttons) and regularly checking my motion sensor batteries, the frequency has fallen to once every 3-4 months. Viewing the ISY log, it appears that ISY is surprised by the ALL ON as many device status are wrong immediately after the event. I need to turn everything off and run a Query All to get the system operational again. I don't have much proof but feel that this is a Insteon issue (rather than an ISY issue); possibly PLM or some code common to 2412 PLMs, 2413PLMs, V1/V2 Motion sensors, or KPLs. Given the variety of implicated devices, yes, I guess the problem could be caused by external noise but I haven't found a common trigger in my home yet. All-ON can be a serious and dangerous occurrence especially if doors, fireplaces, irrigation systems, heating plants, or other critical equipment is being controlled via Insteon. With a growing number of users experiencing this potentially critical issue, I believe that users should review their installations to determine if the results of ALL-ON events warrant continued control of this critical equipment via Insteon. At the same time, can I ask if it doesn't make sense for Smartlabs to investigate blocking Group 255 commands (All ON) in future product revisions. Can this even be done??? Although the frequency of All-ON occurrence at my home is tolerable, I am concerned by the increase in users enjoying the random "Insteon SURPRISE." I was further discouraged reading this thread and hearing of a potential PLM fix and then hearing that Smartlabs denied that such a fix was in the works. As I said, I don't have faith that this will be solved so be sure to consider the risk of controlling critical equipment via Insteon. For me, other than this one issue, I am thoroughly pleased with my Insteon system and ESPECIALLY, my ISY!

Before variables, there was an issue with ISY on nights where the time automatically changed forward or backward. I don't know if this is still an issue but it only affected people who used programs as flags. In my case, I used these as "Master Enable" flags to allow my motion sensor programs to run. Every time we experienced a time change, all of my flag programs would be reset to FALSE by ISY. This effectively disabled my motion sensor programs. Last year, I changed all of my programs to use variables instead of flag programs and haven't experienced any failures since. I don't know if this problem was ever fixed by UDI. If the OP is using programs as flags, this may be why your programs suddenly stopped working Sunday. If these are unexpectedly false you can set them to true (run Then) and everything should work again. Good Luck Greg

YES! apostolakisl, you are correct! I installed my system before the web control was popular. Yes, this would be a far cheaper way to implement a dry contact interface. Greg

Hi John, I have been using 3 EZIO8SAs and 2 EZIO2x4 units for the past 2+ years without any problem. The 8SA inputs are connected to pir sensors to trigger lights on stairways and exterior lights. I use some of the relay outputs to control my HVAC fan high speed and hrv high speed. One 2x4 monitors garage doors and he other is used to control kids TV and Network access time. I have not attempted to use the "F" node input, (1-wire connector) of the 8SA as I haven't needed these...yet. I think this will require a simple RJ11 cable and configuration using the SHN utility program. If you plan to use the analog inputs, be sure to check SHN's web page for the correct termination resistors. Good Luck Greg

Thanks for your suggestions Michel! I don't think I have anything causing loops but I added a 3-second delay in each program that causes a KPL secondary button to change state. I use these programs to monitor all devices in different areas of the house and light KPL secondary buttons when any device in an area is on. I had been suspecting that motion detectors were sending group 255 commands (without a shred of proof) but yes, my KPL status programs also could be the cause. Thanks for your help. Given the very low frequency of occurrence (~4mo), I don't expect to know for several months if this solved my problem. Greg

I have experienced the random all-ON problem for several years. Given the rare occurrence (about ~4 months) I haven't been able to exactly pinpoint the cause. I have learned a few things though: 1. The problem occurs with either ISY99 or ISY994 as controller in my system. 2. The problem has occurred with many different revisions of ISY firmware installed 3. The problem has only been observed when people are home. i.e. I have never arrived home and found all lights on. 4. The problem "seems" related to KPLs and wireless motion detectors. At one point, I had a KPL secondary button that triggered an ISY All-Off program. Sometimes, when I clicked that button, all lights would come on. I eventually replaced that KPL, the replacement KPL triggering the same program does not cause lights-on. 5. When this problem occurs, ISY seems overwhelmed with the massive status changed going on in the house. After the event occurs, most light status have not been updated by ISY until I manually run the global query program. Also, there is no meaningful log information captured by ISY. 4a. For me, the problem now seems most related to motion detectors with older batteries. Two nights ago, the problem occurred just as a motion detector was triggered. There is an older battery installed. I haven't replaced the battery but the problem has not re-occurred over the past 2 days so the low battery idea is just a guess at this point. I don't query my motion detectors but this one is directly linked to a Switchlinc relay and set to send only On commands. ISY listens for this and triggers a countdown timer to turn off the light if no further motion is detected. The status of the Switchlinc being ON triggers an ISY 1st floor light status program to light a KPL button. Lighting this KPL button through a scene is not controlled directly by the motion detector status though. Troubleshooting tool / method needed: Is there a way to program ISY to trap occurrences of group 255 (All ON) being sent by Insteon devices within the network? If ISY could do this, the ALL ON problem could be easy to troubleshoot. Greg

Another point to consider is that the 8SA has both normally-open and normally closed contacts. You could just let your scene turn on the relay but use the NC contact.

Actually, I believe that the "circular device" connected to the PCB with red/black wires is the beeper. greg

There is a lot of property crime where I live so it is important to be to be notified if I leave a garage door opened. Some of this may be overkill for your application but for me, this solution works perfectly and is nearly 100% reliable: I am using two remote doorbell chimes and an IOLinc to notify me when a garage door has been open longer than 15-minutes. There are less expensive remote chimes out there but I know that this one works: http://www.smarthome.com/50810/I-O-Linc ... Kit/p.aspx - I use two receivers triggered by the same transmitter. One chime is in the garage and the other in the house. The chime in the garage is to let me know that I am bothering family members by having the door open and to bypass the system (see below). - The 15-minute timer in an ISY program is triggered by the DSC alarm zone being violated. ISY is notified of this through DSCLink. - If I double-click on a garage light switch (send fast-on to ISY), a program will disable the 15-minute timer and the chime. This also sends a signal to an EZIO2x4 relay in the garage to light a LED and let me know that the chime is disabled. - The chime warning system will automatically re-arm itself either when the garage light is switched off or after 2-hours. - If the door has been left open and once the 15-minutes has elapsed, the chime rings every 10-seconds and I get one text message sent to my cell phone to notify me of the problem. I hope some of this may be useful to you. Greg

Hi bsobel, I have seen this type of lock-up with my i99 IR Pro. I had also noticed that I seem to get the lock-up if I try to access the admin console within a short time after ISY shuts down after loading new firmware. I setup a program to notify me that ISY has been rebooted. I don't know if accessing ISY too soon after restart can cause the lockup but I don't seem to get the lock-up anymore now that I wait until I receive my "ISY was Rebooted" text message before attempting to access the admin console. Greg

Gatchel, I agree 100% with your comments about UDI's role in the success of Insteon. I've been using ISY 99 since 2008. I've installed systems in three other homes and have upgraded my own system many times including upgrades to the new 994pro IR. In each case, the ISY makes the system easily possible. Yes, I have had my share of strange occurances but have always found good answers from members of this forum. Yes, Smartlabs should be paying a royalty to UDI for making Insteon a viable home system. I've tried some of the other controllers in the early years but only use ISY today. I hope that Michel has been invited to sit-in on Smartlabs product strategy meetings. I just don't think that you can find a better performance / $$ home automation system than Insteon with UDI ISY 994iproIR controlling. I wish that Smartlabs would license the PLM to UDI and let UDI manage the link database within ISY. My $0.02 Greg

Upgraded from 3.3.6 without issue.

Hi Lee, Thank you for the suggestion. I thought of that also and checked that the proper version (3.3.5) was listed in both firmware and UI callouts on the About window. It was. Since these were correct after I cycled power to ISY and accessed the Admin Page, my thought was that the firmware upgrade had proceeded normally but that the programmed reboot at the end of the upgrade process possibly didn't happen. My GUESS (without any facts to back this up) was that ISY programs triggered and running at the time of upgrade may stop the reboot phase of a firmware upgrade and hang ISY. For me, this is not a problem as my ISY is 10ft from my desk. A user trying to upgrade remotely may not be as happy if they would need to travel to their site to power-cycle ISY. I do have many programs running at all times and I don't know if I'm the only person experiencing this behavior occasionally. I might just have a flash card beginning to fail?? If it matters, my pro/IR is about 4-years old with no slot in the metal case to remove the flash card (easily). I have the Weather and Networking modules installed. I am awaiting delivery of a 994 pro/IR upgrade unit to maintain upgradeability and not because of any problem with my 99i pro/IR. I couldn't be happier with ISY, UDI , and especially the support received from you and other members of this forum. Greg

I upgraded from 3.3.4. The upgrade seemed to progress normally however, after a few minutes (20) I noticed that my programs were still not running. I could not access the admin console. I checked ISY and noticed PWR, TX, and RX LEDs on solidly. Since I use a 2413 PLM, I have a separate power supply for ISY. I cycled power to ISY and everything is working properly. I have had this problem occur in the past when I upgraded firmware. When this occurs and after cycling power to force a reboot, can I assume that the upgrade completed successfully or should I re-flash the firmware? I verified that scene test now works as expected. Thank you!! Greg

re. Scene Test diagnostic I noticed the same thing with 3.3.4. (But I haven't used the scene test in a long time so don't know if this began with 3.3.4) Every Scene Test I tried failed 100% yet everything in the house is working well. I think the scene test may have a problem? Greg