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!