Sparks

Yes, I have tried a factory reset but as I said, the failed LEDs don;t even light up when the unit does a brief flash after it powers back up after a reset which implies something is fried in there, either the LED chip itself or the driving semiconductor.

Saw this topic when I was searching for advice on an almost IDENTICAL problem that happened last week after a power failure and upgrade to 6.1.1. I actually had to read the original post twice to make sure somebody hadn't copied the support ticket I submitted. They were that similar, even down to the UPS giving up. The only difference was that my problem (total Insteon comms loss) did not happen immediately after the power was restored, but a few days later ..... so I was not sure initially if it was an Insteon problem, or an EISY upgrade problem. Michel gave a few good suggestions in replying to the support ticket that were very similar to those in this posting .... recycle power, change PLM outlet/circuit, restore devices, revert to an old backup (oops, this is when you realize you haven't saved one for over a year) but nothing would restore the comms. I could see events happening in the log when Insteon devices triggered, but EISY seemed unable to initiate any communication to anything on the network. Of course I suspected the PLM as well, even though it was a fairly new USB version I bought when I upgraded my 994 to the EISY. Swapping the PLM for my older (capacitor fixed) serial version with some bits of old cables and adapters did not yield any better results, even though the PLM would be an orphan in the network, but EISY was still not able to link anything to the new PLM either - no comms. So maybe the original PLM was OK after all and this was an old school Insteon gremlin, even though I had not changed anything in the house to suddenly cause interference, nor added any new devices to the network. But then in desperation, I ripped out the EISY and PLM from it's home in my server rack and set it up in another part of the house and it began communicarting ..... mostly. I thought I had identified the problem, if not the root cause. But then the gremlins really got to work. In 15+ years of using Insteon I never had switches that simply would not function on a local load. Lights would turn on, but then not turn off. Some switches would wait, respond and then start with the red blink. Some would work fine in the morning, but by the afternoon had given up. Activating one scene in one part of the house suddenly turned on a bathroom light and fan that were never part of that scene. It was literally like there was a ghost in the machine. I am still trying to fix the system. I have done power cycles (which initially allows you to turn off a light that would not respond) but these only work for a couple of cycles. I have done factory resets but then when you restore these from EISY they sometimes work, or go back to their misbehaving ways. The problem, as has already been mentioned, is that deleting devices from EISY and factory resetting menas a lot iof work to recreate links in all devices that are part of various scenes, and that those deleted devices also disappear from any programs that rrefer to them. So it is not only the time to reset and re-link them, but it's the effort to find where you have to restore them in scenes and in programs. It is much worse with Keypads which may have many scenes and program links. So I have been trying to factory reset the devices leaving them still in EISY and then do a restore to them, assuming what is in the EISY links table is uncorrupted. But the restore device sometimes works, sometimes nothing happens, and sometimes the process completes but leaves the little update required green symbol next to the device, which of course is wrong. I will continue to try and get the system back working again but it is proving to be a struggle and I am still no closer to figuring out what the root cause of all this disruption is. We have had power outages before as we are on a rural overhead circuit that has it's fair share of problems and the Insteon network has been pretty much stable for several years. I am even thinking there may be a rogue device somewhere that is failing and causing the problem, but finding it amonst 60+ devices is also a challenge when the communication/functinality problems are not always reproducable. Thought I would share my story anyways since somtimes there is comfort in shared misery!

So over the years with Insteon/SmartHome's quality control failures we have had Plasticcolorgate, Capacitorgate, Tactileswitchgate, now I appear to be suffering from LEDgate with some LED chip failures in some of my SwitchLincs after more than 5 years 24/7 operation ... probably the same defective batch It isn't a programming issue since they do not come on when you do a power cycle and you get the initial flash from all the LEDs. I can find multiple posts on the best capactitors, plus DigiKey suggested part nos for the tact switches, but nothing about suitable replacement LED chips that match the physical size and color profile of the Insteon parts. Has anybody had a similar problem and/or tried to fix it? Did you find a part # that works? Or are they just too much trouble to try and fix?

Yeah - sorry. I didn't read the question - my bad! I will try to capture some more data from PG3 and EISY this weekend and post back.

So I looked at the event log. Zone 3 is the door contact. 20 8B 6B is the light. Zone 3 logical state changes 2 seconds before the physical state GV0 and the DON and of course before the light turns on. The 2 seconds appears to be repeatable. I tried using the logical state and the control trigger in the program but it makes no difference. The delay between the door and the light seems longer than 2 seconds but the log won't lie. (Ignore Zone 8 - that's other activity in the house) Any ideas?

Yeah - I agree I need to look at logs. Just checking if this was a noted problem, or not. It is odd. We are all seeing new "issues" after changing to EISY as ISY was so solid. That's the Home Automation World for you!

Just replicated the program in Home Assistant (ELK addin + UDI Insteon) and the lights turns on before I even opened the door fully - this cannot be right. The light is an Insteon scene though EISY so my only conclusion is this is somthing wrong with Polyglot.

So I did a quick search of the forums and found this thread. I have a similar problem - ISY with the Elk integration and the response was within a second. Now with EISY and the ELK Poly, it is like 2-3 seconds to trun on a ligh with EXACTLY the same program as before. EISY is supposed to be faster. Polyglot is supposed to be better and more robust, has more features and all. But if the basic functionality means we have a 2-3 second delay ... then we seem to be going backwards. Is there any reason you can think of .. .anything I can check in the logs. I did try changing from Status->Violated (as it always was with ISY) to Control->On but it makes no difference whatsoever.

Thanks for the feedback folks. It hasn't reached egg frying temperature so I guess running warm is normal.

I appreciate the body of the EISY is a heatsink but what is considered the "normal" surface temperature of EISY. Mine is almost uncomfortable to pick up and a quick measure shows it at about 45C. It is only running the standard UDI packages of Insteon plus a few Poly's - nothing extra. Just concerned that running hot 24/7 will affect lifespan.

I looked in the logs and nothing obvious appears relating to the store. I did see some store dumps in the logs and it is clear that the trial option is not there for Bond. So I can't explain it, and I don't want to waste any more of your time, or my own. I'll decide if I want to use Bond, I'll just buy it and hope it works. Thanks for your help.

Something weird happened in the Node Server store - I selected the Bond trial but it actually purchased the MyQ trial. Now the Bond trial option has disappeared but an option to install the MyQ trial is active. There is no way back, it seems. Is there something wrong with the setup of the Poly's? Other people must have installed this Node Server already. This happened on a brand new fully updated EISY/PG3X system. I put in a ticket to UDI, but Michel pointed me to the developer for support.

OK so weird thing - I rebooted via the admin console - no luck, failed authorization every time. Rebooted via the power cord (yes, a bad idea, but desperate times and all that) and PG3 allows me to login again. Apparently I'm still on 3.1.26 despite trying the "update packages" via the IOX admin page but looking at the changelog then nothing seems to have addressed this particular issue. I'll see how it goes, but certainly something strange afoot. I'll also try the power button single push but as this should just call the same routine as doin it from the admin page, I'm not hoping for miracles. So for now, I can login, but if I get locked out again I'll put in a ticket (because a hard power rest isn't really a solution) and see if there is anthing more I can help the developers to troubleshoot.

Just when I thought I was out of the woods ... back to the PG3X login failures again. I have seen other people having similar issues with various fixes suggested such as : upgrade to latest PG3x, restart the EISY and wait ...and hope. To be honest, this has been a problem from the very first bootup of a new EISY, fresh out of the box this week, fully updated to the latest everything (5.6.0 and 3.1.26), original admin/admin username/password (not changed). I see there may be a new PG3X 3.1.27 available, but then I can't login to check. I am getting the red box at the bottom of the PG3 login screen: HTTP failure response for https://eisy.local:3000/auth:401 Unauthorized. I found the Poly log using SSH ... in /var/polyglot/pg3/logs and it says : 5/24/2023, 14:35:53 [pg3] info: call_udx: Making reqeust to socket for /rest/pg3.auth.ns 5/24/2023, 14:35:53 [pg3] debug: call_udx: sending {"username":"admin","password":"admin"} 5/24/2023, 14:35:53 [pg3] info: call_udx: /rest/pg3.auth.ns on socket happened. 5/24/2023, 14:35:53 [pg3] error: call_udx: Request failed :: Error: connect ECONNREFUSED /tmp/udx2client261892 5/24/2023, 14:35:53 [pg3] info: UDXauth: {"success": false} 5/24/2023, 14:35:53 [pg3] error: UDX says we failed to authenticate admin: false 5/24/2023, 14:35:53 [pg3] info: call_udx: /rest/pg3.auth.ns on close happened. 5/24/2023, 14:35:53 [pg3] debug: call_udx: Wrote body data to socket Tried rebooting. Tried power cycling. I did get in once from one computer and was able to play around installing some nodeservers, etc. But then I had to logout and now cannot get back in again. I cannot believe the solution is to keep power cycling the EISY - the last thing you want to do with an automation controller is keep cycling power. There is obviously some issue here - it shouldn't be so fickle. And did the usual geek things - multiple computers, multiple browsers, no change. Any other ideas before I annoy the UDI team with another ticket - I think I reached my quota already!

ELK function keys now work, but I had to edit the relevant program entries because they mysteriously changed after the upgrade.

Looks like installing the firmware and ELK module does monkey around with the X10-esque addressing between ISY and ELK. All my lights are working incorrectly with ELK rules now. I have had to "add" all devices in the "export" tab of the new Security system module to assign X10 addresses, then export to XML, import XML to ELK lighting module, and then edit all the ELK rules because most of the addressing changed. It's worth it to get the long-awaited ISY functionality, but seems like a bug as all previous firmware upgrades have always managed to preserve the ELK X10 addressing. I'll be moving all my ELK rules to ISY now anyways. Thank you Michel and the ISY team! It's been a most anticipated upgrade.

There is a little info in the Wiki on using the GC100 with the ISY, but it is limited to the raly outputs on the GC100. The ITach uses the same command format as the GC100, but allows you to learn IR commands out of the box which the GC100 did not. The procedure for using Global-Cache and ISY requires you to learn the IR codes first using the Global-Cache iLearn software (see documentation on their website), then copy and pasting this command string into the ISY network module (which you need to purchase, if you have not already). The command structure looks something like: sendir,1:1,45234,34500,4,3,34,48,24,12,24,960 I have a GC100 and it works like a charm with the ISY once you have it all set up. If you have not already gotten the hang of the Global-Cache software to give you a command string like the above, then tackle this first, then move onto the ISY network module.

The biggest challenge I had with my GC-100 was learning the IR codes because the original GC-100 did not have a built-in IR receiver/learner. I had to buy the Global Cache IR learner (plugs inot a serial port) in conjunction with it's software. Looks like the new models have addressed this omission, but you will need software to generate the string to send. Once you have the correct string to send to the unit to generate your IR code of choice, and there are utilities from Global Cache to test these, then the ISY network module is very easy to get working.