kaplansa

A Hue node server fork for PG3x/eISY, built on xKing's original, is up to 1.1.1. This version fixes missing status, stalled event streams and bridge requests that could hang forever. 💡 Also implemented: light power, brightness, fades, color/temperature where supported, group control, room/zone scene recall, motion/light-level/temperature/button nodes, and multiple bridges. These are source capabilities, not all newly tested features. Source: github.com/superflytnt/udi-hue-pg3 Latest release: v1.1.1 What this version fixes Query answers again: it re-reports cached driver values for the affected node types instead of doing nothing. A one-hour read timeout bounds silent or stalled event streams. If the stream thread dies, the next poll restarts it and refreshes device states to recover what was missed. Connection and read timeouts on bridge requests, so no request can wait indefinitely. Optional heartbeat monitoring: set the heartbeat_url custom parameter to any heartbeat/cron-monitor URL to catch missed plugin polls even while PG3 looks online (pings on poll callbacks, at most once per 60 seconds). Also included: diagnostic logging for private groups, entertainment configurations and older groups. Review logs before sharing, since they can contain bridge resource names. The intermittent eISY HTTP 404 remains open. Tested: stream timeout and restart observed, and on/off control through eISY on two lights with live bridge feedback. If your Hue status has been going stale, give it a spin and post your results here.

A patched Govee node server for PG3x/eISY is up to 3.1.1. This version fixes the API-heavy polling, wrong brightness values and misleading status of the original. It builds on Jean-Francois Tremblay's (AutomationGeek) node server and the govee-api-laggat library. 💡 Source: github.com/superflytnt/udi-govee-nodeserver Latest release: v3.1.1 What this version fixes One shared, long-lived Govee client and a single state sweep per poll, instead of every light fetching the device list plus each light's state. An 8-light setup drops from roughly 72 requests per cycle to 8. An API-budget check before each polling request leaves headroom for commands, and commands use the warm device cache, so you burn far less of Govee's per-minute limit. Correct 0-254 to percentage brightness conversion, including the first brightness command after startup. Offline devices show last-known status with an offline notice instead of stale data posing as a fresh reading. Failed commands report a notice instead of an optimistic success status. Optional heartbeat monitoring: set the heartbeat_url custom parameter to any heartbeat/cron-monitor URL for missed-poll alerts (pings on short polls, at most once per 60 seconds). Polling: the tested setup is a 900-second short poll and 1800-second long poll; the published defaults are 90/600 seconds. Match your heartbeat monitor's expected interval to your actual cadence. This fork still uses Govee's legacy developer API, so app groups, sync boxes and new-API-only devices are out of scope. Tested on six reachable lights. Give it a try and post your device models and results here.

💡 The WLED node server for PG3x/eISY is up to 1.5.8 - full control of your WLED controllers from ISY programs and scenes. Source: github.com/superflytnt/udi-wled-poly Latest release: v1.5.8 What you get Individual power, brightness and RGB color control, effects and palettes, preset loading, effect speed and intensity, transition timing, live override, playlist start/stop, nightlight status and sync-send Controller-wide On/Off, Brighten/Dim, brightness and effect commands - the Controller node is a scene responder, so one scene can run all your WLED devices Next/Previous Preset commands for cycling presets, including from scenes Local-network discovery, manual device configuration, effect-name rebuild at startup, and live status (online count, LED count, average brightness) Recent fixes 1.5.6: Set Color on device nodes now reads the R/G/B parameters where PG3 actually supplies them - no more falling back to white 1.5.7/1.5.8: optional heartbeat monitoring. Set the heartbeat_url custom parameter to any heartbeat/cron-monitor URL and the plugin pings it on each short poll (at most once per 60 seconds), even when controllers are off. Leave it empty to disable. Notes: preset labels are generic IDs (save presets, set nightlight timers and configure sync-receive in WLED itself), and discovery uses IP scanning rather than mDNS. The README covers configuration and the full version history. Give it a try and post your results here - your WLED firmware version and what worked or didn't helps everyone.

I take it 3.2.4 is the latest (as of this post)? Thanks for explaining it. The only thing that seems affected by the bug is the My Notifications section of the UD Mobile app. Suggest that while you're fixing the naming conflict, you might fix the UD Mobile app so that "cancel" returns to the main screen. It's minor. Thanks for explaining it to me. Best of luck. Cheers.

I recently performed a firmware update using UD Mobile to update my eISY (and PG3) to IoX 5.7.0 and PG3x 3.2.5. IoX successfully upgraded to 5.7.0, but according to the PG3 dashboard, it's still at 3.2.4. To make matters worse, when I click "My Notifications" (which is beta) in the UD Mobile app (on my iPhone 14 running iOS 16.6.1), I get an error message in UD Mobile (screen shot attached). The next screen asks you if you want to reboot. If you say "yes", it will reboot. If you say "Cancel", you'll go right back to the same "Upgrade Status" error screen. It's an infinite loop within the app from here. You have to swipe and close the app, never to return to the My Notifications screen or go through this again. So I've got two problems now - how to force PG3 to update to 3.2.5, and this infinite loop problem using My Notifications in the app. Thanks!

Hue node server works well, but every other day it needs to be restarted in order for ISY (on Polisy) to continue working with it. Any ideas? What other info can I provide to help? Thanks!

Thanks! And wouldntcha know it but Michel helped me in the end so it might not matter. Seems my problem may have been simply a matter of timing because I was working while UDI was going through sever upgrades on their end. Keep ya posted but for now everything looks better.... timing is everything I suppose...

Interestingly, my situation is nearly identical to that post. I also purchased my Polisy during the OG pre-order and let it sit and probably messed it up similarly although not exactly. Similar end result. The key to that solution though is having the img.bz image (that I don’t have). I’m comfortable with BalenaEtcher and I’ve already got all the necessary cables. At the risk of going trigger happy once more, any chance of getting that image file so I can take a stab at it at least? OG ISY and UDI SuperFan

Lol. You are correct. I meant IoP… But technically, isn’t IoP an IoT? Hah. Michel is obviously amazing and he’s called me “trigger happy” more than once from attempting my own hot fixes while waiting for his reply. Maybe that should be my new nickname. I do get the sense however that I screwed up the underlying operating system somehow and it’s nothing a good re-image wouldn’t solve but I should probably take your advice and wait… Yours in the IoT! — Trigger Happy OG ISY and UDI SuperFan

It's possible I may have FUBAR'd my Polisy, maybe by rebooting it before an update completed, not sure. I'm getting strange errors when IoT starts up, for instance, that suggest to me the OS is corrupt or possibly incomplete. I've even gone into SSH and deleted and re-installed ISY on Polisy just to be certain these errors aren't something that reinstalling ISY wouldn't fix. More examples of where my Polisy isn't working right, when I do a package update from the ISY Admin Console, I get 5 beeps, sometimes 6, but never 4. Similarly, if I click "restart IoT" from the IoT Admin Console, IoT never comes back online (can't see it in ISY Launcher), yet ISY Launcher suspiciously sees something because of the way it hangs like it's waiting for something (not normal behavior when everything works fine). In this scenario, only pulling the actual plug from the device will restart the device. In fact, the only way to restart IoT without having to pull the plug is by clicking the "Reboot" button in IoT. I have a ticket open with Michel who's been amazing to work with, but knowing that he has a million other responsibilities that don't include just me, what I'd like to do is re-flash my Polisy if such a method exists. For instance, on the ISY994i you could insert a fresh SD card. What method exists on Polisy to literally factory reset it with a proper OS that I promise not to accidentally screw up this time? Thanks!

Here's a screen shot of what I see in my ISY994i with WLED configured on my Polisy Server. I've got the WLED polyglot configured (there's only one configuration parameter - ipaddress_of_wled). I don't understand how Polisy works I guess. I've factory reset the Polisy a number of times too to clear it up, re-added my ISY and the this node server. I've removed and re-added the node server to ISY. I'm not sure what I'm doing anymore. Help? ISY SCREEN POLISY DASHBOARD WLED CONFIGURATION (INSIDE POLISY)

I can understand that. Nice call. Unfortunately, I'm not running any AV on these Macs (shhh, don't tell anyone). Although that gives me more to think about anyhow and makes sense. Anyone else had similar problems on Mac that you found out the culprit if not AV?

Strangely about 80% of the time when I fire up the ISY994i Admin Console, the two automatic writes buttons ("automatic writes to devices" and "automatic writes to battery powered devices) are missing. This is a problem because when those buttons are missing (and their corresponding File menu items are missing too, btw) the Admin Console doesn't work - it can't write any updates to devices, sometimes crashes (spinning beach ball), generally unpredictable and bad. When I fire up the Admin Console and see these buttons are missing, I close the Console and literally just fire it up again, and down, and up, and down, until it decides to start with those buttons displayed. Once they're displayed, things are generally okay. I've tried cycling power, rebooting, and I can't seem to find a pattern when or why this happens. Makes the entire system flaky and unpredictable. I've recently upgraded to 4.0.5 to see if this behavior changes and it doesn't. I'm also running on a Mac (latest OS) and this behavior is consistent across three different computers. Clearing Java cache doesn't seem to help either. Anyone else seen this behavior? Help.

Awesome code, Larry! In case anyone's wondering who's reading this, if you have two garage doors, the only changes that I see need to be made are: 1) Add both garage door sensors as responders to the same scene that your KPL is a responder also. 2) Create two (2) GARAGE DOOR CLOSE programs (I call mine "Garage Door Close - Left", "Garage Door Close - Right"). Each program looks identical to yours, except that each checks the status of only its sensor (program "right" checks the right garage door sensor, program "left" checks the left garage door sensor) 3) GARAGE DOOR BUTTON run both GARAGE DOOR CLOSE programs (left and right) in Then section 4) GARAGE DOOR QUERY program queries both the left and right garage door sensors and relays 5) GARAGE DOOR SET INDICATOR checks the status of both the left and right garage door sensors in the If section using an Or statement (i.e. "status 'Garage Door Sensor - Left' is On or status 'Garage Door Sensor - Right' is On") 6) If you're like me and used the green wires on the garage door opener kit, then your garage door at rest is "on" when closed. Since we're just using programs to set the KPL indicator, I see no problems reversing the sensor status logic in Larry's programs - e.g. "status 'garage door - left' is Off" works just fine. Only make sure that GARAGE DOOR SET INDICATOR program knows to set the garage door indicator scene to On when the garage door sensors are actually Off (either garage door is actually open). Otherwise, no problems that I'm aware after an hour of testing. Question though, Larry. You said, I don't understand the point here of this scene - it's not the same as the Indicator scene you suggested, which seems to work fine on its own. Why create this second scene with the KPLs as responders here too? Again, AWESOME work! You really made my day by making this so simple. Cheers Seth

Hello! I feel as though I have plenty of Access Points and Dual Band devices for my home to handle a mere 6 RF devices - 2-thermostat modules, 2-triggerlinc sensors, 2-motion sensors, yet my devices get spotty reception. I started with 2 Access Points and RF devices worked great until I started adding about 10 more Insteon devices (non dual-band - dimmer switches, that sort of thing). Then they stopped responding in my ISY-99i Pro. Trying to rule out RF interference I bought two 2-dual band lamplinc modules and places them literally within grabbing distance of my thermostats. Thermostats work now. But when I place either the lamplinc or an Access point directly underneath a motion sensor, the motion sensor acts as if the RF bridge isn't even there. So three questions: 1) Is there a way to tell if an Access Point is working in the ISY? What should I look for in the event viewer or otherwise to tell simply if an Access Point is sending/receiving any signal from the circuit or RF? 2) Is there a tool that you can use to check if any particular device (fridge, TV) is giving off or absorbing too much RF signal causing interference? I haven't added anything to my home along those lines since everything was working fine and I do most of my testing at night when nothing's on, no one's watching TV or doing laundry. 3) Could it be that I really need an Access Point or dual-band device at at outlet next to every RF Insteon device if I can't solve the RF interference (assumed) problem? Any other thoughts to getting my motion sensors back online in my ISY? Thanks for the advice folks!

Hey Lee. So this has been an exciting turn of events. On a whim I decided to pry a triggerlinc off my pantry door in the kitchen and bring it into my study where the dual band PLM and ISY are located, and guess what - everything relating to the triggerlinc works fine. I've since been walking around the house with the triggerlinc in-hand trying to figure out my RF signal pattern and the only place it consistently works is in the study right next to the PLM. So perhaps this has nothing to do with the firmware after all (I'm sure you guessed that a while ago), but I have two fairly new Access Points (just a couple of months old) and is it possible that both of them have stopped working? It seems the only good RF signal I get is in my study, and after about 15' it starts getting wonky. The triggerlinc starts blinking erratically when I get nearer to the kitchen, indicating that the device has lost its RF communication. That might explain the other RF devices too since they're not any closer to the PLM and nearer to Access Points that apparently no longer do anything. So... is there a way to check that the Access Point is repeating the RF signal of a device? Consider I have two (phase coupling on outlets of different sides of the fuse box) and neither seem to be repeating from my non-scientific observations. Appreciate any more advice - what to buy, what to return, maybe another dual-band device, at a loss. Cheers Seth

I've also done a PLM restore to see what happens. Nada. My PLM is connected, btw, since I know you're going to ask "13.23.E5 v92 / Connected" and there's an Access Point right nearby the TriggerLinc in case anyone's wondering. And BTW, when I said "all" my RF devices stopped working, I meant all of them - just realized that ISY doesn't see either of my thermostats any longer with this firmware either! There's a red exclamation point next to both of them. Not good Cheers. -- Seth

New battery was the first thing I tried Here's the log. All I'm doing is putting the triggerlinc into linking mode and trying to add it to the ISY using the manual Add Insteon Devices option... Sun 12/05/2010 11:15:58 PM : ---- Initializing the linked devices ---- Sun 12/05/2010 11:15:58 PM : ---- All Linked Devices are now initialized ---- Sun 12/05/2010 11:15:58 PM : ---- Add remaining devices ---- Sun 12/05/2010 11:15:58 PM : [ 13 E1 AC 1] Removing all links Sun 12/05/2010 11:15:58 PM : [13 E1 AC 1 ] Querying engine version Sun 12/05/2010 11:15:58 PM : [iNST-ACK ] 02 62 13.E1.AC 0F 0D 00 06 (00) Sun 12/05/2010 11:16:07 PM : [iNST-ACK ] 02 62 13.E1.AC 0F 0D 00 06 (00) Sun 12/05/2010 11:16:16 PM : [iNST-ACK ] 02 62 13.E1.AC 0F 0D 00 06 (00) Sun 12/05/2010 11:16:20 PM : [13 E1 AC 1 ] Failed getting engine version. Reverting to i1. Sun 12/05/2010 11:16:20 PM : [13 E1 AC 1 ] Using engine version i2 Sun 12/05/2010 11:16:20 PM : [iNST-ACK ] 02 62 13.E1.AC 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 00 06 (00) Sun 12/05/2010 11:16:29 PM : [iNST-ACK ] 02 62 13.E1.AC 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 00 06 (00) Sun 12/05/2010 11:16:38 PM : [iNST-ACK ] 02 62 13.E1.AC 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 00 06 (00) Sun 12/05/2010 11:16:42 PM : [ 13 E1 AC 1] ** Not added ** Remove Device Links failed Sun 12/05/2010 11:16:42 PM : ---- All Remaining Device Added ----

Yes, I always put it in linking mode first. I got a different error this time after this order of operations... Removing triggerlinc 1. Right-click "delete" for the triggerlinc in ISY 2. Put the triggerlinc into linking mode 3. Click "ok" on the ISY dialog. 4. ISY status bar does it's thing - triggerlinc gone. Adding triggerlinc back 5. In ISY "Link Management" --> Add Insteon Device 6. Choose Triggerlinc, fill out the the fields. 7. Put Triggerlinc into linking mode 8. Click "ok", "remove all links" 9. Dialog does its thing, displays the following error: Failed writing the highwater mark [-200000/-1] Node not added - failed removing links (13 E1 AC 1) [-200000/-9] If I try adding back the triggerlinc again, but in step 8 choose to keep existing links instead, I get the following error: Node not added - failed reading links (13 E1 AC 1) [-200000/-8] I should note that in every case, whenever the ISY attempts to write to the triggerlinc, during the writing process, there's an error underneath the status bar that says "failed getting engine version. Reverting to i1." I've since even tried factory resetting a triggerlinc and no differences. Do these errors provide any more useful information? Never had this much trouble before... Thanks guys!

@LeeG Any idea about the triggerlincs? What's [-200000/-15] mean? It's all a little disconcerting only because I've upgraded the ISY firmware a dozen times before and everything's worked fine (about 20 devices), but this particular upgrade made my RF devices stop controlling their scenes, as you pointed out with the motion sensor. Appreciate the help!! Cheers

All of my RF devices have stopped working (triggerlinc and motion sensor). Example - After the ISY update to this firmware, I tried removing a triggerlinc from a scene and got the error "Failed writing device link" with an error in red "[-200000/-51]". I tried removing the triggerlinc from the scene in the first place because I noticed it just all of a sudden stopped controlling the scene. Triggerlincs don't display current state in ISY either (blank). What does that error in brackets mean? My two motion sensors that control switchlinc dimmer scenes no longer control those scenes either. I've noticed that the red LED in the motion sensor, when tripped, flashes red several times as if telling me there's an error (which clearly there is, somewhere). In the ISY, motion sensors don't display current state, except for the low battery sensor, which is "off" for both my motion sensors. Thoughts? (for the record, alerts to my google account and controlling else seems fine.)

That's funny. Exact same thing for me too. All my notifications stopped a couple of days ago when I installed 2.8.6 and upon "testing" I got that same password error everyone else got. And this morning I opened my garage and I got a notification out of the blue. I'm scared to touch anything for fear that I'll stop getting them again, and like you, waiting for 2.8.7 which I hope will be out any day now. Michel and crew are probably just busy working the holidays, my guess

You think you're gonna have 2.8.7 out this week? Just asking because I use SMTP alerts for security and I'm obviously running blind with the SMTP problem in 2.8.6. I could downgrade if you think that's a better idea (to which version?) rather than holding out for 2.8.7 in the next couple of days. Thoughts? Cheers

Just bought two brand new 6 button KPL dimmers (v.36) and had to manually add them to the ISY (Link Management --> New Insteon Device). ISY couldn't find them automatically, which I thought strange. Nevertheless, they're added and seem to control scenes just fine. However, both KPLs (all KPL buttons) have those green 1011 arrows next to them. I've tried "write updates to device", I've even tried restoring, removing, re-adding, re-writing, you name it. Can't make those arrows go away. What am I doing wrong? Running ISY-99i v2.8.4.

Good idea. I tried. Unplugging and walking away to come back and plug in a couple of minutes later didn't change anything. Guess - when I flipped back to the green wire, IOLinc works fine again! So here are my observations: 1) IOLinc using green wire works fine for a couple of days. Sensor state is automatically sent to the ISY as they're supposed to. 2) Some trigger event possible throws the IOLinc into confusion mode. Sensor state is no longer automatically sent from the IOLinc. You have to manually query the IOLinc to get the correct sensor state. 3) Flipping from green to red wire sends the IOLinc back into "normal" working mode. Everything works fine. 4) Some trigger event possible throws the IOLinc into confusion mode again. Requires manual query to get state. 5) Perhaps because I'm using red at this point, state is reversed from what it should be when manually queried. 6) Flipped back to green wire. IOLinc works fine, but I need to uncheck "trigger reverse" in ISY to get the proper state reading. See how long this lasts until I need to flip back to the red wire to "reset" the ISY. Odd, isn't it? Thoughts?