sjenkins

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.