sjenkins

, if it's a local only plugin, you need to reinstall it. @Michel Kohanim , Just to be clear, local only, with no beta or production with same id, or all local? Thx

should just be simple dependabot updates, no user facing changes. ## 0.50.7 - Bump pip dependencies in Pipfile.lock to resolve 12 Dependabot security alerts - urllib3 2.5.0 → 2.7.0, requests 2.32.5 → 2.33.0, pytest 7.4.4 → 9.0.3, and related transitive updates

@Guy Lavoie ,Should not be customer facing but I treat any change with suspicion, that’s why I roll from local to beta to production.

Dependabot updates: VERSION = "1.13.6" """ 1.13.6 DONE package updates "dependabot" — aiohttp 3.14.3 security fixes

Went much longer in beta than I intended but got busy. No response from the crowd and my system is working well, let me know if your mileage varies. VERSION = "1.13.5" """ DONE sync versionHistory.md with hunterdouglas-poly.py; older history in versionHistory.md only DONE fix ready_event poll checks (Controller, Shade, Scene) DONE fix updateAllFromServer throttling and in-progress guard DONE fix parameterHandler startup flag after checkParams DONE replace eval() with json/ast parsing for gatewayip list DONE accept gateway hostnames in addition to IP addresses DONE thread-safe stale gateway event cleanup DONE reset controller event_polling_in on thread exit DONE add HTTP GET timeout to match PUT DONE G3 shade discovery sets roomId and default batteryStatus DONE Shade updateData null guards for missing shade data DONE fix battery-alert event batteryLevel key handling DONE fix Scene Gen2 active check (generation not gateway IP) DONE safe scene-deactivated remove from sceneIdsActive DONE consolidate PowerView URL constants into utils/urls.py DONE consolidate gateway event lookup helpers in utils/gateway_events.py DONE shared start_event_poll_thread helper for node event polling DONE fix start_event_poll_thread when called from Controller DONE get_gateway_event wait timeout so pollers cannot block indefinitely DONE SSE Not Found handling restarts stream without stopping node pollers DONE G2 updateAllFromServerG2 fails if rooms/shades/scenes fetch fails

Hopefully boring Dependabot updates, as well am moving all my plugins to simpler branch structure: master/main->local development beta->non-production store production->production store Should remove some confusion for those looking at the repo. 3.1.29 DONE upgrade dependencies to address Dependabot security alerts (aiohttp, requests, urllib3, ujson, black, and others) DONE setuptools remains pinned <81 for pyisy/pkg_resources compatibility (udi_interface Node import) let me know if there are any issues, I will move to production after a few days of quiet.

ok without a version bump I added Somfy Beecon compatibility into the readme and the Store description. Gave it a weasel word of "some" as I'm not sure of perfect alignment.

@Guy Lavoie I did not. Later tonight I will put the timer on the todo; doesn’t sound too hard. Good idea. @Techman , if we can get you a controller we might expand this plugin’s usage by 50% , 🎉

Found a periodic crash and connection issue ; as well updated some dependabot complaints. What's in this release 1. Discovery fix — tolerant setup/devices parser for partial TaHoma records 2. Dependency updates — aiohttp>=3.13.4, requests>=2.33.0, pyasn1>=0.6.2, pyoverkiz>=1.13.0,<2.0.0 Let me know if you find anything or want anything. (especially @Guy Lavoie , I think its only you and I using this thing , which is fine as I use it daily.)

@EVictory , Glad your solution for #1 worked. I also use MQTT Explorer and would call it invaluable. On your #2 issue, on first blush it looks like you have an extra double quote and comma before the "Temperature" label. (In the future could you paste the raw MQTT output from an individual output in addition to the history. It has the raw JSON. The picture of the history list is useful but makes it much harder to get the actual text.)

v0.50.3 was in beta for quite a while. It has a lot of backend changes so I wanted to give the community a chance to check it out. Its been two months and there are not any comments, so here we go. v0.50.4 is just a docs change. Added to the README the formats which are expected by the plugin by device. Its a question which comes up every so often, not needed for regular config, just if you are going deeper. There is a link in the configuration to it. v0.50.5/6 are install minor fixes Let me know if you have any unintended consequences. ## 0.50.5/6 install.sh minor changes ## 0.50.4 - Add MQTT payload format examples to README for all sensor types - Link POLYGLOT_CONFIG sensor section to README payload reference ## 0.50.3 - Restructure POLYGLOT_CONFIG for devfile-first setup with upload and SSH paths - Add starter data/mqtt-devices.yaml template - Trim README to capability and installation overview only ## 0.50.2 - Extract device discovery and topic registration into discovery module - Unwrap Tasmota StatusSNS payloads once in Controller before routing to nodes - Skip duplicate status topic registration on re-discovery - Remove dead pass stubs from node modules - Fix disconnect handler exception path ## 0.50.1 - Fix startup handler gate when CUSTOMPARAMS arrives last - Fix poll heartbeat guard to respect controller ready state - Accept documented devlist JSON arrays alongside legacy dict upserts - Merge devfile and devlist configuration as documented - Resubscribe MQTT topics after DISCOVER when already connected - Add MQTT connect timeout instead of infinite wait - Fix sensor message routing to use two-argument updateInfo - Refactor config loading, device registry, and MQTT bridge modules - Add MQTasmotaSensor base class for shared Tasmota sensor behavior - Unsubscribe MQTT topics when nodes are removed - Add legacy config regression test suite

Hi @EVictory , Appreciate the in depth data on your questions: At first glance I do not see anything wrong, but there may be more in the logs. You may try deleting the nodes that are not working, so they can be remade. If you have been iteratively working on this, the node which was made in a previous attempt may be blocking the making of a new one. Two ways to do this, either stop the node then hit the 'x' on the right side in the node listing you attached above, or go nuclear and delete the whole node instance (make sure you have your yaml file safe). When you start the plugin again it will remake the nodes. If this does not work then I need the logs to go further. As you mentioned, not the first time this 'What is the format expected?' question. I am adding a section to the README.md and a link in the POLYGLOT_CONFIG.md so people can get to it but it does not pollute the config help. For your specific question: { "AM2301": { "Temperature": 72.5, "Humidity": 55.0, "DewPoint": 54.3 } } Hope this helps, let us know here how the project goes, your translation program is neat. When you get it working and know what you want for translation it could be added to this plugin as a feature request. Just need the raw data you are getting from the device and the desired conclusion on the node side.

Hi Dave, None of the publishers of Nodes are making money equal to the time they invest here. Some make a few bucks to defer the many hours. I have four plugins and don’t charge for them as three of four are for my own use & happen to be useful to a few others. One is “me and the other guy” who use it. Two I took over from the original writer so they kept going. You never know who will find something useful. My most recent, like you, I thought no one would care, but lo and behold, others use it. @Jimbo.Automates plugins gave me best practices to use even though I didn’t at the time use his plugins. Join the developer program because it defers some cost for UD (the UD team have spend significant time just with me), grows the community, and will come back to you in a positive way. But no, the developer program is not for people looking to make money.

First, thanks for all you put into this plugin & the community. On this topic, I understand the effort to give richer messaging but as I scan my plugin screen for issues it does break the visual management of “if a plugin has a message it’s either starting up or something is wrong”. On a few of my plugins I bring up these kind of messages during startup then clear them after some time period. Just a thought; ymmv.

The ud alexa interface allows you to pick a state variable and decide on/off open/close raise/lower

@dwengrovitz , I am assuming you have some kind of Alexa skill for a commercial garage door opener. Which one? Sounds like your code is a function of that skill. What I think you are trying to accomplish is to get away from that proprietary skill and get to a home automation friendly one, either through the eisy or home assistant . This integration is tailored to either the Ratgdo device or network interfaces you have manually added to your eisy. Ratgdo is a device to handle the MyQ family of openers (liftmaster for example) or it can contect to generic contactor style doors. I originally wrote it to connect to my network interfaces before I got the Ratgdo. Btw: there Is another plugin on the store which is specific to the Ratgdo. As far as voice control, it’s the same setup for any Eisy device, use the UD Alexa skill. Set up in the portal. I don’t use Home Assistant anymore, the Eisy is my core integrator. When I can’t find a plugin that meets my needs I write it. I found the overhead for HA to be onerous. Hope this helps

Thanks so much @Panda88 , works like a charm.

Some stability and fixes ; also giving capability to upload the .yaml file in a .zip format. Should make it easier than having to scp to the controller. Let me know feedback. ## 0.50.3 - Restructure POLYGLOT_CONFIG for devfile-first setup with upload and SSH paths - Add starter data/mqtt-devices.yaml template - Trim README to capability and installation overview only ## 0.50.2 - Extract device discovery and topic registration into discovery module - Unwrap Tasmota StatusSNS payloads once in Controller before routing to nodes - Skip duplicate status topic registration on re-discovery - Remove dead pass stubs from node modules - Fix disconnect handler exception path ## 0.50.1 - Fix startup handler gate when CUSTOMPARAMS arrives last - Fix poll heartbeat guard to respect controller ready state - Accept documented devlist JSON arrays alongside legacy dict upserts - Merge devfile and devlist configuration as documented - Resubscribe MQTT topics after DISCOVER when already connected - Add MQTT connect timeout instead of infinite wait - Fix sensor message routing to use two-argument updateInfo - Refactor config loading, device registry, and MQTT bridge modules - Add MQTasmotaSensor base class for shared Tasmota sensor behavior - Unsubscribe MQTT topics when nodes are removed - Add legacy config regression test suite

ok thanks for the feedbck, I will publish v0.50.3 as beta, and will give it a week or so for general comments. Let me know if you find anything.

You are right, and I had fixed it in v0.50.3 but hadn't pushed it yet. You are the first one to comment so I didn't think the issue was breaking, but obviously is in your situation. In the beta (non-production) store there is a v0.50.3 that you can install directly over top of your current version. Give it a go and let me know how it works for you.

Dm'd you logs

Looks like there were four rogue button pushes on the last button I manually pushed. So in this log the last four are button 1 short rogue and the previous 6 are on purpose manual on both buttons short/long. OMG, when I went to the beta with the same name I forgot to put logging back to debug. duh. I will get you logs later today but since last night there were four rogue button pushes from the last purpose pushed button. So same results.

The beta with the same name was able to load on top. I did get 4hrs on the one with different name in new slot with no rogue pushes (normal ones tested out). I am on the beta in normal slot & will let you know tomorrow morning.

Unfortunately its treating yolinkLocalSR as a different node, not letting me install on top. Its not treating it as beta to your production local. I'm going to need to run for 24hrs to know. If you issue a beta off your production it should work. Worst case I could run two for 24hrs, not sure if there are issues with that? for now I'm just stopping my main one and running this. up and going, I'll let you know either tonight or tomorrow morning if I get any rogue button pushes.

ok, sorry for delay, had to attend my daughter's swim meet. look around 21:25 for both buttons , long/short on speaker hub times two. then a reset then same x2 of both buttons short/long on local hub all done with debug logs. YolinkLocal_6-23-2026_93109_PM.zip