Lore

Just an opinion on the Watchdog, I'd argue that restarting the node and taking it out of commission for a minute, even once a day, is undesirable unless an actual error is confirmed. Is there a way this check could be replaced by sending a short ping or dummy command to confirm the connection if no other events have happened in the interval? I assume sending a command and not getting a response would trigger recovery, but in that case, it would be justified. Then, assuming no errors, the node would be more responsive with 100% uptime.

I get notified of a disconnect/reconnect every 61 minutes. The log gives this reason.. 2025-10-09 16:55:42.303 Thread-120 (poll) udi_interface ERROR hue:_check_streaming: No updates from streaming thread for >60 minutes, streaming hung up? Restarting the node server... 2025-10-09 16:55:42.303 Thread-120 (poll) udi_interface.interface INFO interface:restart: Asking Polyglot to restart me.

Yup. Hue rooms now start empty of scenes, just a button to import something from the gallery (that maps it to your bulbs where it becomes room specific) and a suggestion button. I had a lot of rooms created with older versions that pre-populated with Hue Scenes. Now it's cleaner, the first one you create (or import) is Scene 00.

Thanks, it's fully working now for my use case. Scenes work now, but I can't figure out the order. As I step through the scenes on the EISY and watch the Hue App, they jump between ones I created and preloaded scenes. Luckily, I can just select 00 and edit that scene to what I want, making it easy. The built-in and custom text in the scene drop down is dated since you can now delete, add, or edit all the scenes. Minor issues are, I see disconnect/reconnects on the HUE plug-in a few times throughout the day when nothing is going on. Also, when I blast out 5 bigger commands in an EISY program, like RGB color and brightness, I can see up to a 5 second delay before the last command gets to the bulb. I don't see this kind of delay with scenes or off commands, which I assume are smaller packets.

I'm using EISY & Hue Bridge Pro. No problem updating from the non-production store and seeing all my Hue lights. Plug-in is great and already way better than going through Matter. Everything seems to work except effects and scenes which have no effect and appear to do nothing. Scenes working is all I need to finish updating my programs.

Same problem, same question, but with some success. I enabled Matter in the config screen on EISY. Then went to the Hue App/Setting/Smart Home/+/Other Apps and got a MATTER Pairing Code. I went to the UDI app/Matter/Add Device and entered the pairing code. I now have my Hue Bulbs (unnamed) as "ZM 002.# On-Off Switch" which gives me basic on/off functionality. They come on in the last color I set. This doesn't really work for me as I need to be able to select hue scenes with effects and colors. I don't really need direct control over color. I'm wondering if scenes are exposed in matter and might be supported in the future. Having the names come through would also be nice, or a new Polyglot plug-in.

I've had no problem using this plug-in to turn on my hue lights with my Insteon switches and, closer to what you're doing, animating my yard lights to match audio explosions, etc.

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?

Most of my scenes have no controller and are fired off by programs. The control button is in an empty scene and a program checks status. If it's on, I set stuff how I want then I turn it off. In a few rare cases, I set the scene button to off if anything it controls is tampered with. This allows me to get quickly back to the scene without having to toggle it off and on again. I also try to make sure the switches are set to match the lights they control when I trip off a scene. I sort of had to do it this way once I started mixing in Hue lights and other non-Insteon devices into scenes.

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.

@GeddyYeah, the I/O Linc sensor status is always correct after a query, but act of doing a query seems to trip the relay when it's in reverse trigger mode. I have no idea why. Also, doing a query changes the status which trips my programs, so I'd have to also delay my programs until after I did the query. I finally gave up and stopped using Reverse Trigger. I use an I/O linc to monitor things like my alarm siren, which is normally open. Programs like MobiLinc assume the I/O link sensor is attached to something normally closed all their icons, include their siren icon, are set up normally closed. That's mostly why I wanted to reverse it. In any event, they work flawlessly if used without Reverse Trigger.