Lore

Not sure why I got the results I did, but more testing shows the AI inconsistent and will change what it does based on prior commands. In my ISY "study" vs Hue "study bulb" case, if I said "turn on study" it would use the ISY scene. If I said "set study to purple", it would use the Hue "study bulb". If I then said "Turn off study" after asking for a color, it would also use the Hue "study bulb", where normally it would use the ISY "study" scene. I was wrong and there doesn't appear to be a way to set skill priority, however, routines take priority over skills, so I was able to create Alexa routines to mimic the ISY skill behavior. Routine voice "turn study off" sets study to off and always works.

I'll test any new version that gets posted. The latest Beta is pretty good, but still restarts every hour for me. I've tried scripting hourly non-destructive commands like query and set rate, but they apparently don't generate events. Not quite ready to flash a bulb hourly, I'd rather buy a hue motion sensor. update: everything seems good now. No hourly resets. Seems faster too.

Alexa+ puts UDI at the bottom of its internal list making it unlikely to match. It will trigger any other sound alike (or close) device before the UDI Alexa keywords. Just say "Alexa, UDI device take priority over all other devices" and everything will magically work.

I just pulled the latest after having that issue. I still get what looks like the same issue. 2025-10-11 00:00:14.423 MainThread udi_interface ERROR udi_interface:write: Traceback (most recent call last): 2025-10-11 00:00:14.423 MainThread udi_interface ERROR udi_interface:write: File "/var/polyglot/pg3/ns/0021b9026dfb_3/roomba-poly.py", line 19, in <module> 2025-10-11 00:00:14.424 MainThread udi_interface ERROR udi_interface:write: from roomba import Roomba 2025-10-11 00:00:14.424 MainThread udi_interface ERROR udi_interface:write: File "/var/polyglot/pg3/ns/0021b9026dfb_3/roomba.py", line 42, in <module> 2025-10-11 00:00:14.424 MainThread udi_interface ERROR udi_interface:write: from collections import Mapping 2025-10-11 00:00:14.424 MainThread udi_interface ERROR udi_interface:write: ImportError Edit: sorry old log. New version does not save logs, or produces any logs at all, or finds roombas.

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.