Lore

Here's how I fix mysterious problems, and I have a 100+ Insteon network previously plagued with almost every known issue. Make the network more robust against noise by replacing pre-2012 modules. They don't validate messages and can fix up and repeat noise to the entire network, even newer modules. Reduce noise by moving modules away from power supplies, computers, and RF sources. Add Insteon power line filters to equipment with motors or switching power supplies. Restore devices with problems, and devices that might be repeating the signal. If something is turning on often enough, try disabling things that might be causing it to see if that stops it. The A/C, the fridge, the EISY, you can even try disabling just the RF or just the powerline communications in a module to determine which band the problem is on. My whole system acted funny with just one failing module not near where the issues were. It can be hard to figure out. Another crazy issue I had, were modules programed to respond to X10. A restore won't remove that, only a hard reset, followed by a restore. I tested for X10 by writing a program on the EISY to send "ALL LIGHTS ON" on every X10 channel, followed by "ALL OFF" after a delay so I could turn on my non-light devices and see if any went off. False X10 signals are even more likely to be created by noise, but also unlikely to be programmed unless you did it yourself or bought used modules that weren't reset.

Portal appears to have been down for me since about 9:10 PST.

I miss the portal already. No Alexa commands, no UD Mobile notifications, nothing. I almost had to get up to turn on a light when I remembered Mobilinc talks straight to the EISY. Still, what if my arms were full and I needed the lights on?!?!

I just moved from a hardware failed Polisy to an EISY and both my VUE node and Roomba node are getting those same errors. I already had to install the dev. packages for the HUE node which is working fine. I've reinstalled, deleted and reinstalled, rebooted, etc. No luck. I restored from a Polisy backup, but it was current, PG3X, IOX 5.8.4.

The Insteon leak detectors I have latch the wet state. I have to clear the water and quickly tap the little button to send the all clear update.

Any plans on a work around? I'm a C++/Assembly programmer, so my sympathies with Python. My Roombas need light to navigate and it was sort of nice to script it all.

Hue alone drops for 1 minute at midnight with the above debug log and two notifications showing disconnect and connect. Hue Hub V2 is hardwired to the same switch as the Polisy and nothing else drops.

I updated to PG3x and am still getting the Hue drop out at midnight. Polisy running 25 Hue Bulbs, 126 Insteon devices, 3 Roombas, 1 Rachio, 2 Venstar, 1 Vue, Weather, and Notifications. PG3x Version 3.2.13 Frontend Version: 3.2.13 IoX Version: 5.7.0

That worked. All connected. Just waiting for SCE to replace my meter for free because it turns out it wasn't HAN ready.

I installed and entered my login. It's showing disconnected. Rebooted, same thing. The log shows the same errors repeated.. 2023-10-04 20:11:23,106 MainThread udi_interface ERROR udi_interface:write: Traceback (most recent call last): 2023-10-04 20:11:23,107 MainThread udi_interface ERROR udi_interface:write: File "/var/polyglot/pg3/ns/000db953c7c4_6/vue.py", line 10, in <module> 2023-10-04 20:11:23,108 MainThread udi_interface ERROR udi_interface:write: import pyemvue 2023-10-04 20:11:23,109 MainThread udi_interface ERROR udi_interface:write: File "/var/polyglot/pg3/ns/000db953c7c4_6/pyemvue/__init__.py", line 2, in <module> 2023-10-04 20:11:23,110 MainThread udi_interface ERROR udi_interface:write: from pyemvue.pyemvue import PyEmVue 2023-10-04 20:11:23,110 MainThread udi_interface ERROR udi_interface:write: File "/var/polyglot/pg3/ns/000db953c7c4_6/pyemvue/pyemvue.py", line 8, in <module> 2023-10-04 20:11:23,112 MainThread udi_interface ERROR udi_interface:write: import boto3 2023-10-04 20:11:23,112 MainThread udi_interface ERROR udi_interface:write: ModuleNotFoundError 2023-10-04 20:11:23,113 MainThread udi_interface ERROR udi_interface:write: : 2023-10-04 20:11:23,114 MainThread udi_interface ERROR udi_interface:write: No module named 'boto3'

Same here. Got the email, tried to upgrade, 5 beeps, no change to the version. I assume the entire Polisy update is disabled, IOX 13.2 and ISY 5.7.0, and I'll just have to wait.

I have a Polisy. PG3 Version 3.1.23 Status: Connected Frontend Version: 3.1.23 IoX Version: 5.6.3 Connected No PG3x. I only have what comes down from updating on the ISY screen. Everything has IP reservations and I configured the node with the Hue Hub static IP. The recovery is quick and complete. I have 25 bulbs on my Hue Hub V2, so maybe a longer list causes a brief delay and the time out detection is too short? The Hue Hub really needs a refresh.

Nope. Plus the other nodes stay up, like my thermostat, which will report a drop if I reboot. I suppose the router could do a quick drop at midnight for some reason and it's too quick to be caught by the other nodes. It's not a big deal, it's just that an update to UD Mobile now tells me about such drops.

2023-07-26 00:00:04,272 MQTT udi_interface.interface DEBUG interface:_message: QUEUING incoming message longPoll 2023-07-26 00:01:04,761 Command udi_interface.interface DEBUG interface:_parseInput: DEQUEING longPoll 2023-07-26 00:01:04,762 MQTT udi_interface.interface DEBUG interface:_message: QUEUING incoming message shortPoll 2023-07-26 00:01:04,765 Command udi_interface.interface DEBUG interface:_parseInput: DEQUEING shortPoll 2023-07-26 00:01:04,766 MQTT udi_interface.interface INFO interface:_disconnect: MQTT Unexpected disconnection. Trying to reconnect in 10 seconds. rc: 7 This is the log. Seems to show some sort of polling, then a disconnect. It's the same every night.

The node goes offline and comes back at 12am exactly every day. Is this an intentional kludge or some clock timer bug?

To clarify, I'm currently using a kludgy set of programs to respond to half a dozen dim ranges from the insteon switch and then setting the hue light to a brightness that matches the switch. This lets guests use the hue lights as if they were normal lights on a dimmer switch. However, other programs, including Hue Sync, can set the lights to various colors and animations as required, making them rather covert party lights while also letting me keep the consistent look of Insteon switches everywhere. I'm looking for a less kludgy way to have a hue bulb follow the brightness on an Insteon dimmer switch.

I would like my insteon dimmer switch to control my hue lights. I'm using a Polisy with the latest firmware and the latest PG3 Hue software. Right now my code is a stack of programs for each dim level as shown below, which works albeit with less granularity than ideal. I'd like to just copy the Insteon Dimmer level directly into the Hue brightness and possibly compute the color temperature to mimick a Philips Warm Glow bulb when the bulb is controlled by the switch. Bar Switch Dim66 - [ID 003F][Parent 0001] If 'Bar Down Lights' Status >= 35% And 'Bar Down Lights' Status < 70% Then Set 'Hue / Bar' Color Temperature 2500° K Brightness 128 in 400 ms

That was useful. I guess I should have dug up the original email. I forgot it came with instructions. I even had the antennas wrong. I guess it's just waiting for matter stuff to arrive and the software to update.

I tossed my zmatter board into the middle slot, not sure if that's right. I don't have any zwave devices. I also checked zwave support on the ISY config page.

I have IP reservations for everything, the HUE hub and the Polisy. They're replacing the electrical wires and transformers in my area so I've been suffering a lot of scheduled power outages. I was hoping, after moving to ISY on Polisy HUE would magically work after an outage, but alas, it did not. After a power outage the HUE node is empty so I have to restart it, then I have to scan for nodes on the ISY and my HUE scripts works again. I also have a few Insteon low voltage moduals that are reversed states that must be cycled to get into the right state, making it more work than it should be to fully recover from an outage. For now, I threw on a huge UPS and haven't had time to more completely debug what happens after the power is restored.

I'm having what seems to be the same issue. I was using the original hardware ISY and the Hue V2 node, then I recently upgraded to Polisy ISY and the Hue V3 node. Same before and after the upgrades. The Hue lights can't be controlled by the ISY after a power failure. I can mess with it and get it working again, usually by restarting the V3 Hue node and pulling down the nodes on the ISY.

Oddly, I pull the scene names and numbers from the Hue Rest API. The phone app also pulls the names from the hub, but orders them differently so without the API, I have no idea what I'll get when I set a scene on the Polisy node. I'm working around the lack of support for the "smart" stuff I got at Costco by capturing network traffic to the devices and playing back the command when I get a UDP message from the ISY network resource. I just pre-ordered the Matter board and remounted the Polisy in a high and central location, so I'm hoping things will get a lot easier in the near future. Smart stuff is sort of a mess of proprietary protocals with decent SDKs few and far between, requiring far too much hacking.

No problem, it's great and fast! I have a huge Insteon setup with Insteon switches controlling HUE bulbs and a lot of Network commands going out to custom audio software for announcements and scene sound effects. My biggest issue, after getting around the update bug, was not realizing I needed to install the trial portal to get the portal code to install on the polisy ISY. After that it was just restoring everything and hitting buttons to refresh stuff until things worked. I was using a mix of Network commands to the HUE hub and HUE node commands. While that worked when I was using two boxes with two IPs, that failed on the single Polisy box. I switched to using just the HUE node, which is somewhat lacking, it really needs to show the scene names. I'm up and running and everying is vastly more responsive. My only question now is when will more PG3 nodes show up for all the other smart stuff I have? Things like the Atomi string lights from Costco or the Amazon Air Quality monitor? It seems like I should just be happy everything is working so well and just wait to see if Matter takes over or Insteon recovers.

I'm a bit worried ISY on Polisy will be some work and won't solve my entire problem, especially if my loss of Hue lights was caused by the Polyglot Hue Node starting up before the Hue Hub was fully booted. What I think I really want is a power up delay for the Polyglot Nodes, so what they talk to has a chance to boot. Maybe just put a long sleep in the startup script or something.

Does that work? I mean both the ISY on Polisy and the ISY starting before the Polyglot?