kzboray

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

@jhoulihan I strongly suggest you buy one and play with it before committing to the Zooz 5-button. One glaring issue you will have is it's inability to do scenes as you currently use them with Insteon. Also since you would then be mixing Insteon and z-wave you will have to create a multitude of programs to keep indicators and device states updated across technologies. There are other issues with z-wave in general. There are no standards, even from the same manufacturer different revisions of the same product can operate differently. I think z-wave has it's place but for lighting control Insteon is still the best solution IMHO. I'd just buy another 8-button from Insteon and call it a day.