sjenkins

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.

Virtual Devices PG3 — v3.1.27 This beta release updates the Generic / Dimmer virtual device profile so it lines up with standard IoX dimmer behaviour. Thank you to shbatm for reporting the issues and the clear write-ups that made these fixes straightforward. That improves compatibility with third-party clients (including Home Assistant via hacs-udi-iox / pyisyox) and with the Eisy admin UI. ──────────────────────────────────────── Dimmer brightness via DON (standard convention) Previously, the dimmer exposed a 0–100% status but DON did not accept a brightness level. Clients that follow the usual Insteon-style pattern (multilevel status + DON with an optional level) would treat the node as a dimmer and send DON <level> — which failed with an error like “command 'DON' accepts 0 parameter(s); got 1”. On/off still worked; only the brightness slider/path was broken. v3.1.27: DON now accepts an optional brightness parameter (0–100), matching conventional dimmer nodedefs. Parameterless DON still turns the device on to the stored On Level, as before. Set Status (SETST) remains available as an alternate way to set level. ──────────────────────────────────────── On Level Type — enum display and direct set On Level Type (Static vs Dynamic) was defined with a boolean unit of measure, so many clients showed it as on/off instead of Static/Dynamic. The only way to change it was Toggle on Level Type (OLTT), which is awkward for UIs that need a dropdown or select. v3.1.27: • On Level Type is now an indexed enum (UOM 25), so labels Static/Dynamic display correctly. • New command: Set On Level Type (SETOLT) — set Static or Dynamic directly. • Toggle on Level Type (OLTT) is unchanged for convenience. ──────────────────────────────────────── Other fix Set On Level (SETOL) with value 0 now correctly stores the minimum dimmer on-level (5%) instead of overwriting it with 0. ──────────────────────────────────────── After updating Restart the Virtual node server on your controller so the updated profile loads. Existing nodes and scenes should keep working; parameterless DON and OLTT behave as they did before. If you use Home Assistant, you should see a working brightness control on virtual dimmers and a proper Static / Dynamic select for On Level Type without custom workarounds. As always, feedback welcome if anything doesn’t behave as expected on your setup, I'll leave it in beta for a few days based on feedback.

That looks cool. I have those nasty voles too; they ruin lots of things. Upvote for adding to the plugin!

Two plugin solutions for Eisy which give you complete control, both use the Ratdgo board. One is called Ratdgo the other is part of Virtual , one of the devices. I wrote the second one and use it everyday.

omg, I didn't even see that. Let me put that on the TODO list, in this day and age the app should be able to figure out case. (sorry for the late response, I've been on vac & the digging out process after)

@paulbates same experiences. Over the last number of years my wife & I went from using Alexa all the time to control stuff to now. I am toying with dumping them entirely, have one in almost every room . We use them the odd time, but mostly motion/automation, well placed Insteon switches or remotes do the job (and of course the excellent UDI app). I bet I do an Alexa turn on/off once a week now.

@aLf , I responded to your question in the HD forum but I see here you are also asking about Gen-1. I originally wrote the plugin for Gen-3 as that is what/when I bought mine. After some online harassment (you know who you are) I was able to add some functionality for Gen-2 as the interface is not too far away. Along the way I did read about Gen-1 and it is a really different beast, so it would be a different plugin, written by a different cowboy.

Hi @aLf , When they told you that you don't need a hub they are technically right, the blinds will communicate with the app on your phone by bluetooth. You will have to be in the room to make it work and cannot do any kind of automation unless you leave your phone in the room. The gateway does two things; it links the blinds to the cloud ; it also gives us a platform to talk to the blinds locally. If you want to use the plugin to connect your HD blinds to the EISY you need to have at least one gateway. If your blinds are in rooms/floors with some distance you may need more than one gateway. I have three. They talk to each other so the plugin only talks to one, which by some magic is decided to be the master. Take a look at the UD documentation on EISY and plugins for general knowledge. If you want to read up on my plugin before you have the hardware ; the github is here https://github.com/sejgit/udi-hunterdouglas-pg3 the README and POLYGOT_CONFIG.md will get you a long way. Come on back here with your questions.

Hi @tmorse305 , Not sure which version you were updating from but the user, password, & isy fields can be deleted. If you can pull those out, restart, and send me a log file, I will take a look.

Couple bits of news: First, as you know @TriLife has had the lead on this plugin for a few years, with me helping out, mostly with the non-Tasmota nodes. As his use case has been changing he has asked me to take the lead. Big thanks for all his time and efforts, both with building the plugin and tireless helping of users. I will still need to call-a-friend with the Tasmota nodes; he has more real world experience than almost anyone. Second, as I now have the "keys", I can put into the non-production store the 0.50.0 update named properly MQTT (as opposed to mqtt-poly). This beta version can be put into your production slot and then revert back to the production version as the NSID is consistent. There are a few out there who have been using the mqtt-poly version due to the new features and Droplet node. The plan is to let you play with it for a week then move it into the production slot. Please let me know if something is amiss or didn't work in the transition. Just to remind, below is the log of this non-production version: 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

A few minor updates, 1.13.2 is back office so I didn't announce it, while 1.13.3 fixes two bugs, one which caused a crash on every batteryLevel event. I will leave it in beta for a few days before moving to production. Let me know if anything seems amiss. sj """ 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

If there is value, it wouldn't be hard to make another virtual device which could hold an Integer or maybe a number with pick your number of decimal places (zero being integer). Would you move the number there in a program or like the temperature device. I don't have a need for this, is this something that is required for different use cases? This looks similar to what @tazman was looking for ; am I right?

I haven't yet ; started looking into it then a butterfly flew by. I've put it on the request list now.

sent you a DM with it.

Fixed with update

@Panda88 , Low on the priority list, but for feedback. I am growing my YoLink fleet & added a couple motion sensors to test. they are the YS7806-UC, seems the temperature is showing -67C on the AC no matter the temp showing on the app device screen. EDIT: seems to be well off for the Two button FOB YS3614-UC Again, I don't actually use these, just to add something to your todo list

@Panda88 , All my devices with legacy and non-legacy are the same except for the water valve manipulator. I have the YS5001-UC, see below, Manipulator (legacy) shows open the other shows closed. Legacy is correct.

This update takes production up through 3.1.26, with adding the onOnly device and fixing an old bug in garage which caused intermittent crashing. The rest of the changes are clean-up in nature, let me know of any unintended consequences. VERSION = '3.1.26' """ 3.1.26 DONE add timeout to ratgdo requests and sse client to prevent hanging DONE chg DFOF to DOF for Toggle & onDelay 3.1.25 DONE add onOnly device DONE update generic project files DONE Controller comments, refactor checkParams DONE change hints for temperature devices DONE testing added

@tazman , That mirror is beautiful, very nice job. I get the desire to get the data public for all to see. I need to get around to something like that. If you are good with the workaround, then I will put it on the list but not too high. If we get more interest in #3 I could move it up. Let me know if that changes.

I was having this new device issue ; 6.04_1 fixed it for me. So far it did NOT fix the socket error pop-ups though.