sjenkins

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.

@Guy Lavoie Instructions to generate the bearer token are in the polyglot config file which shows up when you hit config after installation. I will add something about Brecon compatibility tomorrow

@Guy Lavoie , very cool !! Glad the Beecon worked ! Took me two shots at the token too! hey if the instructions are different to get the token, pass them to me , and I'll put them in the config instructions. Not sure which version you ended up with as I have been pushing all day v0.0.22 is latest. Feel free to list off the gripes. On my eisy-ui and remote app the shades show as two arrows in opposite directions, but in the admin they are a light bulb, that's odd. btw: : the io are shades you can set the position and read the position, unlike the rts shades which are fire and forget.

Took a bit but got scenes working, unfortunately also found an issue that say Tahoma only lets control happen through the cloud and they have no plans to change that. sigh. So optionally you can add your Tahoma/Somfy login to the plugin and it will activate the scenes you make on the app. Leave blank if you don't want it. The shades are still local api and the scenes will populate through local only (but are useless and won't activate). Kind of a bummer and my tinfoil hat gets warm going through the cloud for almost anything except Universal Devices Its likely better just to make Eisy scenes and use them ; I just wanted to see if I could make it happen. So there you go, play with it as it is, up to v0.0.22 . Leaving it in beta / non-production for a while until it feels stable. Full disclosure I used my Hunter Douglas plugin as the base for this, which I wrote by hand, then used Cursor to help me mod it for this one. I read all the code over and am cool with it. There are some word choices in the docs I have been correcting as I go, but let me know if anyone finds something they think sounds weird. For sure any code you don't like.

Glad to hear there is some interest here. @Guy Lavoie let me know if the Beecon works, if it does I'll add it to the docs, if not I could do some research on the differences and see if possible. @jfai let me know if the Zibee motors works, and if not quite DM me some logs. BTW: : I was able to spend some time this afternoon and work on the scenes working as well. Not working yet but they show up. There may be an update since you installed.

This is a Somfy TaHoma NodeServer plugin for controlling shades and scenarios (RTS, io, Zigbee, and other TaHoma applications) on Polyglot for EISY/Polisy. This is the model Tahoma Box / Switch , I am on Firmware version 2026 2.3-5 Phantom Blinds (RTS) is the primary application this project was built for, because that was my need, but I quickly came to conclusion that this could be used for quite a bit more. Take a look at the readme if you would like to see more: https://github.com/sejgit/udi-tahoma-pg3x and the config https://github.com/sejgit/udi-tahoma-pg3x/blob/main/POLYGLOT_CONFIG.md I am using this now at home, seems to be handling my 8 RTS Phantom Blinds well. commands: Open / Close / Stop / MyPosition status: id / battery (if it has them) / last command (on the rts this is just success or failure if the Tahoma processed your command. io & zigbee can give you much more including position commands and status, these are in plugin but not tested. Next on the agenda is to add scenes which can be defined in the Tahoma box. Very interested in feedback, while it should bring in an io or zigbee device, they have not been tested... send me your logs!

Moving the v0.50.0 version to production ; moved the source repo which should be invisible to all. Lately I have just been in 'support stability' mode, but I am thinking of combing back through the code a bit if there are any features of interest to the crowd. VERSION = '0.50.0' """ 0.50.0 DONE refactor Controller/Nodes for Pythonic & commenting DONE add user defined default status_prefix & cmd_prefix DONE add numofnodes DONE add MQDroplet device 0.40.3 DONE: fixed typos in POLYGLOT_CONFIG.md STARTED: Organize device types according to Tasmota, Sensor etc. TODO: Reorganize sample devfile for clarity and comments

Sorry for delay, been a busy few weeks with kids grads and such. $210 sounds about right, if you have ethernet nearby the blinds I would spring for the 'pro' model with ethernet, not required just takes one variable out of it. As you know nothing HD is cheap.

Bringing production up to V1.13.4, pretty stable now, just docs and dependabot. Let me know if you are having any issues, otherwise my current plan is to just touch it every so often for stability. It's meeting my needs, so any feature requests will need to come from the crowd. 1.13.4 DONE package updates "dependabot" 1.13.3 DONE package updates "dependabot" DONE fix typo, crash on batteryLevel event DONE fix timeout, drop every 300s timeout 1.13.2 DONE requirements.txt changes DONE comments improvements DONE testing additions 1.13.1 DONE refactor controller discovery, put, get, goodip functions DONE refactor controller startup, config, params, naming, logging DONE refactor cmdSetPos 1.13.0 DONE polling rewrite, controller: shortPoll=G2 poll, heartbeat for all, re-start G3 events, longPoll=G3 poll DONE polling rewrite, shade: shortPoll: re-start events if stopped, longPoll: not-used DONE polling rewrite, scene: shortPoll: re-start events if stopped, manually clear G2 scene activate, longPoll: not-used NOTE default & recommend setting shortPoll=60, longPoll=600 DONE major re-write of function and Event routines DONE add number of nodes managed by controller to controller node

Been looking for inconsistencies in the code and found a few more minors: VERSION = "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 Let me know of any unintended consequences before I go production.

Just about every device with a plugin for Eisy has its own app, so as you mention it’s all about integration. For me, when I hit play on plex my lights dim and the blinds close. When my daughter hits a scene button or Alexa keyword, the lights dim slowly to black, her Vivaldi bedtime playlist plays on her Sonos & the blinds close. In the guest room the morning progression from dark to partial by way of sheers can be modified easily with one change rather than 6 scenes. Feedback through scene status can give lots of opportunities to trigger other things. Eisy is about integration of wildly different devices, otherwise we would just control using the devices own apps.