sjenkins

This beta completes the communications with Ratgdo in and out as well as the docs. The Bonjour resolution for the Ratgdo is working consistently but can take a really long time on start-up the odd time. Feel free to use it or put in the IP number for your ratgdo config label. Finally, a small fix on the switch node from 3 months ago returns On/Off messaging. I also did this as a hot fix for the production version. For old installations it meant some switches will be True/False and some On/Off. Unfortunately to fix, the node (NOT the whole plugin) needs to be deleted and regenerated. The complete procedure is in this thread: I will let this run for a number of days and move to production. FEEDBACK IS WELCOME! VERSION = '3.1.9' """ 3.1.9 DONE Garage device read status directly from Ratgdo through ESPHome RESTapi DONE update docs for garage Ratgdo integration FIX switch st uom from 2 True/False to 25 On/Off TODO Bonjour discovery is sometimes slow 3.1.8 DONE Garage device sends commands directly to Ratgdo through ESPHome RESTapi DONE Bonjour discovery of Ratgdo garage device 3.1.7 DONE Small refactors DONE redo environment 3.1.6 FIX better solution to markdown2 issue 3.1.5 FIX repair docs due to markdown2 issue 3.1.4 DONE docs updated for garage 3.1.3 DONE: new device 'garage' door (update to/from variables option) 3.1.2 DONE: ISY name changes based on updates to config / YAML / JSON 3.1.1 DONE: YAML file option for configuration DONE: JSON option for web based configuration DONE: Discover button to update based on config updates 3.1.0 DONE: move version history out of README to own file DONE: update docs 3.0.1 DONE fix get value from variable 3.0.0 DONE add control ability to contact device DONE refactored to modern template previous updates: see versionHistory.md """

@hart2hart, sorry to say its a 3 month old fat-finger of mine when I first refactored the code. The profile info was done right but in the switch.py code I made the uom 2 instead of 25. Means only new nodes are affected. The old ones are fine. You win the prize for finding it now. I checked the other nodes and they are consistent. It's now been fixed in the production and the beta code. Unfortunately, it's kind of sticky once you make a node with this mistake. The node needs to be deleted either individually or the whole plugin. I suggest the former. 0. close the IoX launcher / Administrative Console 1. goto the store (either production 3.1.6 or beta 3.1.9, depending on your preference) and install the virtual plugin on top of the current one (do NOT delete it first). I did not do a new version for either, just a hot fix. 2. goto the virtual plugin & configuration & make sure the "Allow ISY access by plugin" is ticked and saved 3. goto the node button & delete ONLY the nodes which are showing True/False [three in your case @hart2hart]. **The only issue will be if these nodes are part of scenes, they will have to be reinserted in those scenes at the end. Programs will be fine when the node is regenerated. 4. restart the plugin, the nodes will be regenerated. Start the admin console. Happiness (reinsert in scenes if necessary). Apologise for this one and the steps required. I know of no other way when the drivers are defined in the code wrong but the profile nodedefs are right. Let me know how it goes. I have tested it on both the production and beta versions, locally and installed from the UDI servers.

Hi @hart2hart, just for clarity, I think you are using the current production version. Is that correct?

This version adds the control set, and Bonjour for direct Ratgdo integration. This beta is ALL focused on the garage device & integration to the Ratgdo, something I've been stepping towards with the last two versions. To remove confusion, there is another Ratgdo garage integration by @Goose66 (called Ratgdo) which is more focused and likely more fully baked ; those not interested in my additional feature set should go there. As he knows I've been on this path for a bit and have a slightly different take on the feature set due to my use case. Plus I'm really stubborn and wanted to write it myself. 1. Bonjour discovery for the Ratgdo garage device is added. Unfortunately, this it can take a bit after start-up & the odd time it seems to take much longer. Bonjour has been around for a year in the udi_interface, I just recently cracked the code, with some help from @bmercier. I hope to continue to optimise this. 2. Second, commands can now go directly to the Radgdo and not through variables and/or Home Assistant. I will NOT be removing the ability to use variables for the garage device as it is meant to be a generic solution for garage users. ( I use them for my Boat house which does not have a Ratgdo ). 3. TODOs, direct Ratgdo status. Optimise Ratgdo. Update the docs! AS ALWAYS FEEDBACK IS WELCOME! VERSION = '3.1.8' """ 3.1.8 DONE: Garage device sends commands directly to Ratgdo through ESPHome RESTapi Bonjour discovery of Ratgdo garage device TODO: Garage device read status directly from Ratgdo through ESPHome RESTapi Speed up Bonjour discovery optimisation. Speed & reliability. 3.1.7 Small refactors redo environment 3.1.6 FIX better solution to markdown2 issue 3.1.5 FIX repair docs due to markdown2 issue 3.1.4 DONE docs updated for garage 3.1.3 DONE: new device 'garage' door (update to/from variables option) 3.1.2 DONE: ISY name changes based on updates to config / YAML / JSON 3.1.1 DONE: YAML file option for configuration DONE: JSON option for web based configuration DONE: Discover button to update based on config updates 3.1.0 DONE: move version history out of README to own file DONE: update docs 3.0.1 DONE fix get value from variable 3.0.0 DONE add control ability to contact device DONE refactored to modern template previous updates: see versionHistory.md """

Question: The ability to do BONJOUR automatically is now possible (has been for a year in the interface, I just figured out how to use it). This would allow you to put powerview-g3.local in your config instead of all the gateway IP addresses. The program would still figure out which one is the master. I will warn that it can take up to a minute on startup and I have seen instances of where it took longer. Does this interest anyone? I may still do it with the above caveats in the instructions. Really just flushing out beta testers for the journey As usual, feedback is welcome!

**Moved to production NOTE: These changes will only matter to the G3 crowd. Both are minor improvements to stability & accuracy. I will move to production after a few days assuming no other input from the crowd. 1. Had missed a shade-offline event before now. I think because I added nine shades (14 total now, two gateways, all G3) and one of my gateways was moved halfway between rooms it started showing up the odd time. Only noticed as my events array was not removing them. Not passed on to the ISY, as I don't currently have a status indicator. It is logged.error for now. 2. I use the PowerView scenes in my programs. So I define them in PowerView and activate them in my ISY. The odd time it looks like the plugin does not match the PowerView for scene activation. I added to the longPoll an all check of the scenes activated ; this correction is kind of belt & suspenders to the event engine. Additional bonus; this allows my ISY programs a chance to check that all happened the way they should too. AS ALWAYS FEEDBACK IS WELCOME! VERSION = '1.12.2' """ 1.12.2 DONE add shade-offline event handling to error log; currently not passed to ISY DONE add updating of scene activation status on longPoll as backup to event 1.12.1 DONE environment updates DONE small refactors 1.12.0 DONE change versioning to align with workflow DONE update docs: README, versionHistory, logging for previous version see versionHistory.md

well, look at that I poked around a bit, but not enough

Went to do a backup and my settings menu on has Systems in it?

@RMichael thank you & good to hear all is well. You are the only user I know of using both Gen 2 / 3 . I am curious if you find any anomalies. I think that scenes are completely separate as they are run from the gateway (local which is really nice) but wasn't sure if the Hunter mobile app does any glue-together between Gen 2 /3 . You can now do these with ISY. Also, let me know if there are any other interesting observations. Enjoy!

Hi Rod, first, you are doing nothing wrong. So as I developed this plugin I started with a scope of just gen3 (what I have), then along came a user who has gen2. So right now it’s written as “either or”. So two solutions. I can do a bit of a rewrite; might take me a bit. The other solution is to install the plugin twice in different slots. Setup one as gen2 & the other as gen3. try that first and let me know here if there are any negatives to that. we can take it from there.

@rg65, yes it was solved; mostly an issue of learning the configuration & fighting with the ratgdo to be stable. If you upgraded all the packages on your eisy then you my friend will likely need to put in a ticket to udi. That is well beyond us to help here.

I had that same thing but just on my developer local plugins. All the betas and production ran. @bmercier I ended up having to pip install the idi_interface, even though it’s in my requirements . Found that out by ssh in and trying to run locally. I blamed me, and still do, but it was the same log message. Hope that helps a bit.

@hart2hart, yes this is why I was interested in taking on this plugin. The esphome version of ratdgo is way more stable than the mqtt version. Although the HA ui is a nightmare imo once the automations are written they are quick and stable. I am happy to share my automations, my eisy progs, and variables to make this work. since putting this into service I am now using remote lock, motion, and other stuff from my opener where I didn’t before. let me know how I can help; it’s worked out very well for me. I put in a pi ha instance but you can put a flask one on your eisy instead. That was just new tech for me which I may go to later.

@hart2hart discover is now on both the controller node and the pg3 interface. (didn't click the button on the developer push)

@hart2hart , Hopefully the json & yaml docs were helpful (I pasted them at the bottom of this for others). Let me know if they were not clear. Thanks for the above two questions on Discovery: 1. What I mean is that in Discovery node names in the ISY will be renamed if the config name changes in JSON or YAML files. The basic config has no name given but when initially being made a 'compound' name of the type and id number are given. This name will NOT be pushed to the ISY so as to not wipe out any changes the user has made to that name. If you have a more concise way to say that let me know. 1b. If like in your situation a node exists from a basic config & you now goto JSON or YAML config, the name in the config will be pushed to the ISY 2. The discovery button exists in the PG3 screen as well as as a command in the control node for the plugin in the Administration console. If it's not showing up in PG3 then I think I did not 'tick the box' in the developer list. This is the first time I have pushed that feature to production (as opposed to beta or local). I likely missed it. I will check when I get home ; oops , sorry.

hi @hart2hart, glad the upgrade worked. The json & yaml configs have turned out real nice. For just a few devices the json is good, if you end up with more than three I would suggest the yaml as if you put the file in the right place it can survive a deletion of the plugin. Hey obviously I can answer your question here, but if you don't mind, I am going to give you an assignment & ask you to look at the docs when you hit the configuration button in the plugin. Then please give me critical feedback on it. I still have more to do but am trying to bring the level of the docs up so they get people through the normal flow.

I do not know that plugin but can tell you it is completely case by case. the writer of the node needs to set it up to allow control. If done that way then yes it can be a control in a scene. basically just try it out to do it. If it works, great, if not you could start a conversation with the plugin writer.

**Update** v3.1.6 better fix for the markdown2 library issue. Sorry to all for the churn, not self induced **Update** v3.1.5 is a hot fix as it seems a markdown2 library change messed up the docs (required a minor program change) NO NEED TO INSTALL, JUST FOR DOCS **Update** v3.1.4 moved to production : didn't hear any complaints about v3.1.4 so moved it to production **Update** added docs for garage So I added the garage device I wanted and integrated it to my Ratgdo device using his ESPhome version. One day I hope to crack the code on the communications protocol. For now I have a Home Assistant instance as a man-in-the-middle. Boy is HA an awful UI environment ; UD feels like a dream after that. I added the ability to pull / push from variables but didn't put it in the Admin, rather the config, json, or yaml. Seemed cleaner, I really think the temp devices look messy, I may add some duplicate versions done my way & people can choose. My TODOS are: 1. to add docs for the garage device, if anyone else wants to use it. 2. back-feed my garage plugin improvements to the other devices. Mostly try, excepts & logging. 3. above idea of duplicate temp devices with variable selection in the config, json, or yaml 4. open to suggestions Try this out for a few days & then I will put it into production, if no comments are forthcoming. VERSION = '3.1.6' """ 3.1.6 FIX better solution to markdown2 issue 3.1.5 FIX repair docs due to markdown2 issue 3.1.4 DONE docs updated for garage 3.1.3 DONE: new device 'garage' door (update to/from variables option) 3.1.2 DONE: ISY name changes based on updates to config / YAML / JSON 3.1.1 DONE: YAML file option for configuration DONE: JSON option for web based configuration DONE: Discover button to update based on config updates 3.1.0 DONE: move version history out of README to own file DONE: update docs 3.0.1 DONE fix get value from variable 3.0.0 DONE add control ability to contact device DONE refactored to modern template previous updates: see versionHistory.md """

Yes version is right, moved to this to better follow the workflow. I do a branch for every major version with the last digit for hot-fixes. I use main for local which is pushed to beta for when a new feature is ready. Current beta moves to production. This will allow those who want more stability to stay on production. Also, moved versionHistory to its own file as its getting large. Invisible to you but have been getting the logging stable and consistent to help with future debugging. Finally have been doing some doc improvements. The readme lets you look below the hood and for those who are interested may give you some ideas for future features. Thanks, and feedback is welcome. (seems that new versions take up to a few hours to make it to everyone's store) VERSION LOG 1.12.0 DONE change versioning to align with workflow DONE update docs: README, versionHistory, logging 0.1.11 DEBUG event rewrite to handle edge cases for previous version see versionHistory.md

@bmercier thanks for the hints, I see this enough I will see if I can track it down myself. Not a big deal as you can force the grouping. I usually see it when a number of nodes are added quickly.

That happens the odd time with many plugins besides this in my experience. Nothing to do with the config method. hit right mouse and “group nodes” to fix. Perhaps @bmercier knows why that happens and if I can do something to fix.

So calibration is automatic in G3 but is an available command in G2 as it is manual. So the api says. Obviously, not used much by your response. That’s all I need. Much appreciated.

As you can tell we are mostly stable with this plugin. I do not plan on any new features at this time until either I or one of you dream up something useful ; happy to add then. (QUESTION for the G2 crowd: Does the Calibrate command have any use to you?) I use this plugin daily in my system. Please let me know of any bugs, and we will be right on it. Notes on 0.1.11: Specific to G3, found some events with long text were not being processed properly by the sse. Rewrote the event engine. I discovered it as we got nine new shades which in some cases move in unison ; this created large groups and thus long event messages. If you are wondering about the Beta (non-production) store program, it mostly just follows the GitHub master. I use it to test after testing local. Should NOT be used for anything you depend on. VERSION = '0.1.11' """ 0.1.11 DEBUG event rewrite to handle edge cases 0.1.10 DEBUG multi-room scenes sending Discover into exception past versions: 0.1.9 DONE Fix G3 Events stop working after some period of time 0.1.8 DEBUG branch 0.1.7 DONE rename nodes if changed in PowerView app 0.1.6 DONE parameters based on shade capabilities 0.1.5 DONE format for program setShadePosition DONE set Shade Position change using False to define which parameters to change DONE more debug on G2 so it acts as expected 0.1.4 DONE add node_queue & as result need pause updates while in discovery DONE FIRST TRY G2 tilt feature 0.1.3 DONE node discover rewrite to allow add/remove DONE add event 'homedoc-updated' currently no actions DONE limit room label size to 15 as room - shade/scene < 30 for ISY DONE clean up LOGGING.debug messages DONE G2 bug fixes 0.1.2 DONE change icons to nicer ones DONE docs with screenshots & description for udi spotlight DONE add troubleshooting document DONE add some support for G2 gateways (no gateway push, only polling) 0.1.1 DONE tap into gateway events, which allows longPoll update to move from 30s to 60s DONE active scene indications from events DONE shade motion indicator from events DONE shade position update from start, stop, online events DONE remove parameters based on shade capability (primary, secondary, tilt) DONE update readme & config instructions to highlight G3 scope 0.1.0 DONE handle multiple gateways automatically, picking primary & switching if required DONE updated configuration instructions as well as link to the forums 0.0.9 DONE fix uom for positions(100) & ids(107) DONE more notices clean-up DONE shade naming to include room as scenes DONE remove status based on shade capability (primary, secondary, tilt) 0.0.8: DONE handling of notices individually DONE polling 5s short-poll 30s long-poll DONE status for programs (positions etc) 0.0.7: DONE faster status updates when command is given DONE bug fix DONE re-order of parameters displayed 0.0.6: DONE move shade by specific amounts DONE bug fix scenes not activating 0.0.5: DONE change shortpoll to 30s DONE update shades on shortpoll DONE clear start notice at shortpoll DONE clean up error proofing in get DONE fix updating variables with shortpoll DONE limit device ping to 5s 0.0.4: DONE discover when new gatewayip is entered DONE poll status regularly using shortpoll DONE update required after nodes added to get status DONE notice when gateway get error """

@maxnorth to answer your question of when, I was waiting for stability & for @TriLifeto return from vacation. We currently have two betas as we both have been developing features and testing them independently. And so with the way polyglot is structured it does not lend well to multiple developers or more accurately more than one releaser of versions. I honestly don’t know if the name change will do it due to the fact that the id used is pushed from one persons developer list who first pushed the app. The id is specific to that app but can be pushed to more than one store. What I normally do when I have caused this issue inside of my login (by creating the listings independently) is go into my developer list, delete one, and push the beta or production from the listing for the other one. This aligns the ids. @bmercier do you know of any way for two developers to push a shared app which then the stores will allow users to install on top of a current install? Is the matching name enough? Or is the id the critical item. You can modify/mimic a name but not mimic an id. Or is the system set for on person to be the pusher of store listings. bottom line our new versioning structure will make this easier. If @TriLife pushes a major version to each store, say 0.45.0 using branch 0.45.x to beta and 0.44.6 using branch 0.45x to the production store. Through the GitHub I can make changes to the branch and they will push. Not perfect as the minor version is currently represented in the push. Again the system is not set up for multiple pushers of development versions.

I had one of those hubs (they were cheep and I was curious). Don’t use it anymore as it added no value to my setup. But while a pita , it’s not as nuclear as resetting all your devices. More of an elephant , one byte at a time. (sic) It’s just a controller like any other. Start adding your devices to it. I think it can just find them if I remember. Scenes were not so easy then, but it may find those now. I was able to use it in parallel to my PLM and 994 at the time. When I dumped the hub I just deleted everything off it (the opposite of what you will do) I didn’t add any automation to it as it could only do schedules then. You could add some simple ones to “sell” your house. Just wipe your PLM and 994 before you leave.