sjenkins

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

Seems we have enough stability to take the beta to production. Let me know if there is anything you see or would like to see.

ok at between 16:00 & 16:33 I went through short/long of 1/2 on the speaker hub. Then I switched to local hub, reset the plugin, and went through the button sequence twice. YolinkLocal_6-23-2026_43913_PM.zip

So last night, on speaker hub it sent 3 button 1 long presses (DOF), which seems to confirm your heartbeat thesis. When I get back home from work tonight I will put it back on local hub and get you a log of a few different button pushes.

Sure can, so I'm clear, just remove it from the local network on the yolink app. That would make the speaker hub pick it up. But I can still run the yolink local version of your plug-in. I keep the program running picking up the presses.

On the #2 problem, long versus short , I set up short as on(DON) and long as off(DOF) for both buttons and in manual tests that works. On the #1 problem, button #1 is up to 20 program pushes over four days, none of them were physical pushes.

Thanks for the #2 help; I get it now. The log I gave you, I got the 14 button one key presses ; the whole time the fob was on a shelf, no real pushes. Nothing from button two.

Thanks again for all you do, this little plugin is pretty integral to my system with dozens of YoLink devices. So began using a mini remote two button YS3614-UC, getting it to trigger my Phantom blinds from outside, and ran into two issues: I am getting phantom(haha) button-1 pushes, after days of blinds moving on their own I shut that down and put a program to just increment every time I got a control button push. After two days I had 14 button-1 pushes and zero button-2 pushes. odd odd odd. I sent @Panda88 a DM with the logs and a section.log with the individual bits. For the long pushes, what is your intent on how you handle the programming. Seems status is the way, not control, as control only has the button pushes while status has a bunch more but you would still need two statuses with and and to know when a long push happens. I have tried many things but am not getting the vibe here.

Likely left this in beta too long but all seems well and no comments from the crowd. VERSION = "3.1.28" """ 3.1.28 DONE fix Controller/Temp ready_event poll gating (.is_set) DONE temp reset_stats clears prevVal; CtoF/FtoC mutual exclusion on GV13 DONE VirtualTempC commands match nodedef (no setCtoF) DONE QUERY in nodedef for switch/delay/toggle/generic/temp nodes DONE onDelay reports TIMER; generic SETST send/report naming DONE NLS typo CMD-ctl-QUERY-NAME; onOnly docstring 3.1.27 DONE virtualgeneric: DON optional level param (IoX dimmer convention, fixes #11) DONE virtualgeneric: ONLEVELTYPE UOM 25 + SETOLT command (fixes #12) DONE virtualgeneric: SETOL zero onlevel uses DIMLOWERLIMIT (else fix)

Took a run at the code with stability in mind and my good friend Cursor helped me find a bunch of small items which are small but truly errors in my code. Going to run for a week or so then will push to production barring issues. 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

Ya interesting, Keep monitoring please. Put logging into debug mode for a few days and see if we can find something; lots more go in there.

@Guy Lavoie , Agree, I think let's let this one stabilise with rts, zigbee, io somfy blinds. If in the future there is a bit of demand and some free time we can move in that direction. In the mean time I am moving my dhcp from my router to an independent server, my whole house has been grumpy for two days. sigh.

@Guy Lavoie When making the node there was a generic zigbee device which I ended up filtering. The device you got with all the parameters is the fallback shade device with every parameter. This plugin got its origin from my Hunter Douglas plugin, it only knows shades as that was really my scope here. If we want to go further not sure what deep end we are getting into. If this has value you can dm me a copy of your logs (don’t put in open forum can’t remember if I have scrubbed them yet for personal info, on my todo list) I can try to do something with them. Not sure if there is a table somewhere or I will need to do it device by device. If you send it to me include the model number of the zigbee device so I can reference.