kzboray

Here is my experience with Polisy. Disclaimer: The first of three units was bricked by the attempted upgrade and required extensive intervention to recover. Upon clicking Upgrade from AC the first Polisy beeped once as if doing a normal reboot and the front panel lights started flashing, again as expected. But they only flashed for less than a minute, then the unit rebooted. It was not visible in AC, so I waited 30 minutes before contacting Michel to ask if I should power cycle the unit. Michel suggested a few things to try, but the unit was bricked. At this point, I pulled the SSD and used Rufus to install a new image supplied by Michel. My Polisy came back up, but it was running 5.5.4. Back into AC and Upgrade again. No matter how many times I tried @xlurkr, it wouldn't perform an upgrade. The UUID had also changed to all zeros. This was expected, and Michel had supplied me with a fix that unfortunately didn't work at this stage of the recovery. I then performed another imaging using Rufus and tried again, with the same results. I finally used the one button press upgrade option and that worked. The Polisy upgraded to 14.1 and AC 5.9.1 and the UUID corrected itself. This actually has to do with mosquitto being loaded. If it's not, then the UUID will show as 00:00:00:00:00:01 Thanks to good backups, I was then able to recover fully, with the exception of losing my LifX config file which I had to create from scratch because I didn't have a backup. My bad. The second and third Polisy I upgraded went a lot faster. Both units started OS 13.2 AC 5.8.4. This time I run AC => upgrade and waited until the Polisy was visible in AC again. Unlike the first unit, they both after about 10 minutes showed up in AC again. They still showed AC 5.8.4 and OS 13.2 so then I pushed the front panel button ONE time and with both units all the front lights started flashing as they should during an upgrade, this lasted for about 10 minutes and then the units rebooted and were running OS 14.1 and AC 5.9.1. THIS IS NOT THE APPROVED METHOD OF UPGRADE. It's just my experience. Your results may vary, but this has been my experience so far. And a reminder. I bricked the first unit I tried this on but had the proper HW to allow for manual reprogramming of the SSD directly (outside of the Polisy). If you aren't prepared and things go sideways, you could be left with a unit that has to be sent into UD for recovery, so be prepared for the worst. BACKUPS!!!!

All on events are the devil. They are probably caused by collisons at the PLM/controller interface. When the controller issues a broadcast group command to the PLM it takes the form (fast on): 02 62 00 00 XX CF 14 00 (Where XX is the group number to activate) The PLM transmits the following onto the power line per the Insteon Message Summary YY YY YY 00 00 XX CF 14 00 ZZ (Where YY YY YY is the PLM address and ZZ is a CRC). For a random collision on the powerline to produce YY XX and ZZ would be extremely unlikely. If we assume a collision at the PLM powerline (assume the PLM address YY YY YY is intact) we still need a valid XX and a correct ZZ (crc). Still rather unlikely. It seems far more probable that the collision (at the PLM/controller interface) affects the XX group number. Assuming it was a valid group number for the PLM, it would simply append the PLM address (YY) calculate the CRC (ZZ) and put it on the powerline. What all this means is the ALL ON events can be created by any device on the Insteon network. From personal experience the 2450 Garage door controller, 2443-2222 micro module, and 2475F fan controller have caused the most ALL ON events for the installations I manage. The real fix for all of this is to update the PLM to eliminate the Group 0 broadcast group without completely breaking the entire protocol stack. I can't say much but I can share that Insteon is aware of this issue and as already shared in other posts there is a new PLM making it's way through FCC certification. So fingers crossed this will soon become a non-issue.

@TomNow2 Over the years I've tried many different technologies for lighting control and none do a better job than Insteon. They natively support scenes which is a big deal when compared to Z-wave. Also UD fully supports Insteon natively as well. Since you're looking to buy something new anyway I'd encourage you to try Insteon. Like most products today Insteon works better with sufficient density and is more sensitive to line noise than I like, but otherwise it's a good lighting solution. I do not work with nor am I affiliated with Insteon. This is my opinion only.

@bhogan I would suggest you open a support ticket and let Michel sort this out for you. UD Support

@ThisIsTheWay Make sure you have enabled XMPP and assigned a static IP to the HUB. If both of those have been done then I would delete the NS and simply reinstall it. As part of the initial discovery the HUB should be located. You can also manually enter the HUB's IP in the Harmony NS if auto discovery fails.

1.) Is there a random number generator function in eISY that can be used in programming? 2.) Is there a way to define a variable within a range? Example sudo code If time of day = evening Then iRand = Generate a random Number between 15000 & 20000

You could create a rule in automations that triggers an unused output for 5sec when the motion sensor state changes to not secure and then setup a variable in the eISY to capture changes to that output. If it increments you have communications between the eISY and the Elk M1 so the problem is most likely not with the HW. But if it fails to increment then the problem could be with the PRI or how it's wired, or possibly how it's configured in the Elk. I use hard wired PRI's and they are always configured as 05 - Burglar Interior Follow

My bad. @glarsen @tmorse305 eISY 5.8.4 PGX 3.2.27 This started failing after one of the latest updates when I believe the python library was updated. As i recall it was one of the 5.8.3 updates. That change to the python library broke multiple node servers. This is one on the node servers I'm just now getting around to trouble shooting and looking for answers.

I believe the recent changes to the python library being used has impacted this NS. Here's a snippet from my logs. 2024-06-28 00:00:15.949 Thread-2269 (poll) udi_interface ERROR udi_interface:write: Exception in thread 2024-06-28 00:00:18.815 Thread-2269 (poll) udi_interface ERROR udi_interface:write: Thread-2269 (poll) 2024-06-28 00:00:18.815 Thread-2269 (poll) udi_interface ERROR udi_interface:write: : 2024-06-28 00:00:18.815 Thread-2269 (poll) udi_interface ERROR udi_interface:write: Traceback (most recent call last): 2024-06-28 00:00:18.815 Thread-2269 (poll) udi_interface ERROR udi_interface:write: File "/usr/local/lib/python3.11/site-packages/urllib3/connection.py", line 174, in _new_conn 2024-06-28 00:00:18.815 Thread-2269 (poll) udi_interface ERROR udi_interface:write: conn = connection.create_connection( These errors repeat every few seconds. I've disabled the NS for now. Is anyone else having this issue?

Sounds like it's no longer operating correctly. https://shop.insteon.com/products/dimmer-module

@landolfi I believe you have to first remove power form the 2457. Here are the factory reset instructions for Insteon devices. https://www.insteon.com/support-knowledgebase/2016/2/24/factory-resetting-insteon-hub

@Nestor You might want to check out the Notification NS. https://github.com/UniversalDevicesInc-PG3/udi-poly-notification/blob/master/README.md

Communications between the ISY/Polisy/eISY is uni-directional when it comes to control. HA can control all ISY/Polisy/eISY devices, but the ISY/Polisy/eISY can not control any of the HA devices. From what I've read, the Rachio NS on your ISY device is not correctly reporting zone status. Since you need the Rachio status to trigger on an Insteon device. I would move the Rachio to HA. Per Rachio... The Rachio platform on HA allows you to control your Rachio irrigation system. There is currently support for the following device types within Home Assistant: Binary sensor - Allows you to view the status of your Rachio irrigation system. Switch They will be automatically added if the Rachio integration is loaded. Now that you can correctly see the zone status you can create an automation in HA that triggers based upon the ISY device status and the status of the Rachio zone you are monitoring. Alternatively you can leave a note on the github page for Brian the original dev of the Rachio NS, but he hasn't done any work on this NS for 3 years.

@Arnaud42 The fact that your bulbs lose connection when the WiFi 5GHz N/AC bands are down doesn't make sense. LifX only uses the 2.4 GHz B/G/N bands at 20 MHz. I'm wondering if there is a H/W problem with the new router. LifX Wi-Fi Settings Supported WiFi channels supported 1 through 11. WiFi channels 12, 13, and 14 are not supported. UDP and TCP port 56700 should not be blocked. You may need to contact your ISP about allowing access to this port. WPA/WPA2 or OPEN only. No support for WEP or WPS. 2.4Ghz channel should be set to 20Mhz bandwidth 2.4Ghz band b/g/n, 5Ghz not supported.

@Jimbo.Automates This might be a ready made solution. 120-277v Insteon Load Controller