sjenkins

@vspete , so glad it’s working for you! Also going to complement you on your quick observations, I think you picked out all the G2/3 differences. G3 gave some real improvements through an sse or event server. Sending real time events. In G3 I update through events, polling, and of course send commands. G2 remove the events. 1. Default room is the name in the array from the controller. These are not a thing in G3 and none of my other G2 users used them (or mentions them. I could substitute something else for it? Did you try them? Reason I ask is in G2 multi-room scenes were activated with a separate command. Again you are the first on using them. Let me know. 2. G2 gives me no feedback when the scene is no longer active. G3 does. Let’s say you move the shade manually, eventually all scenes would be random. So in G2 you can command activation & I leave it on for a time for feedback ease of use. Previous G2 users actually did all their movement using ISY programs. 3. Motion is a G3 event feature. Sorry it’s a zombie in G2. Design decision to use the same node for both versions. I added G2 later when I got requests. Looking back the program would have been cleaner with separate nodes. 4. Again this is how G3 shows in the app. 0 to approx 65500 is the G2 way in the opposite direction. This seemed easier. You are absolutely right to shorten the poll rate; I think I even mention that in the config instructions for G2. 5. Yay! As you can see this node server is prejudiced to G3. I originally wrote it for me and shared even with text that it was NOT for G2 ; then I got a couple requests from people willing to work with me as I had no G2. Feel free to give feedback or feature requests; as long as you’re willing to debug with me. I’ve never written a program right the first time even after 45 years of programming. Either way I hope this plugin provides some good use to you!

@vspete, from the logs it looks like nodes were created and the shades were updating. The scenes were for sure erroring. Sometimes you need to restart the admin panel & in pg3 you may have to go back to the Dashboard and back into the node to see the nodes created. Either way I added some error proofing to the G2 code & if you are willing to stick with me and install again from the beta & do a restart & send me the logs. It would me much appreciated.

@vspete , Found an error in the scene node which only applies to G2 when it is looking for events, for background the arrays have a few different labels between G2/3. This line only fires when it needs to rename the node so I am only so confident that this bug is squashed. I also think you are my first user of multi-room scenes but that will not be a problem until you try to activate one of them (one bug at a time). If you would be so kind to go to the Non-production store and install from there. We can iterate on the beta before pushing to production. Would appreciate the logs as well. Thanks so much!

@vspete , if you could send me the verbatim from those links it would be great. I’m thinking the error is from my parsing of the json array in the plugin. Since I don’t have the G2 I’m wondering if they are just different enough in your case from my other G2 tester. Maybe because of your journey with the HomeKit. Just a text file with a few spaces between them is fine. Appreciate your patience.

@vspete , this should ping you this time. if you send me, PM me if you like, the results of these url's I may be able to find the issue, and make the plugin more resilient, for others as well. http://{g}/api/shades http://{g}/api/scenes with {G} being replaced with your gateway, 192.168.46.37 from above if still the same.

So, looks like you have one G2 gateway & it is good & it is finding a list of shades & scenes. Your lists don't look quite right. Do you really have 14 rooms in the app, with only 4 shades and 10 scenes? So you either really have 14 rooms and the plugin is not finding all the shades/scenes or the app has a bunch of empty rooms which may be messing up the sifting of the arrays I don't have a G2 so all my troubleshooting has been with a few users; I need to ask some questions. Can you look at what you have in the power view app and report back what's there. Even feel free to delete rooms or scenes you are not using. Let me know what are the numbers of rooms, which have what shades. And the scenes you have. Also if you are using the multi-room scene option (the scene spans rooms). thx

You might take a look at some of the Yolink robot valve offerings. They get into tighter spaces than the Titan but still are gear driven for the torque you need. Have been using it for a number of years with real life tests. The yolink leak sensors can be direct linked so even with no mains power / WiFi will respond to a leak event.

Good deal @EWhite , appreciate the update! you mentioned 'a few issues earlier', would you mind marking this as solved and add those issues to the stream for v3.1.11?

Thanks @EWhite for keeping us up to date on the journey. I am sure this was not on your agenda for tonight to work on. Sorry about that.

I have not seen that error before. Searched around on the forum here & found it on the notifications plugin. Looks like a reboot solved it.

When you say “it” shows, do you mean the logs on pg3?

Moved to production all the rewrites. Functionality improvements for switches and temps are really down to quicker updates. Back-office was significant rewrite/simplification of the code and docs updates. Minimal feedback from the betas on anything breaking ; thank you to those who tried the beta out. On this plugin I am slow to move from beta to production as it has been so stable for so long (maybe too stable). I don't want to break anyone's setup. The Garage device now will read/write from variables or Ratgdo read/write & write to vars if you want. It is event driven with polling on the longPoll. I am thinking of going all events with a poll for the Ratgdo to send current status to the events on the longPoll. Warning putting in an IP address makes boot much quicker as the Bonjour timing seems to be random on the EISY. If anyone starts using this please let me know. It is in full use for me for the last number of weeks but there are lots of set-ups out there. Do I give you the info you need from the Ratgdo? There are lots of fields I don't bring over. Let me know. Didn't get any feedback on my question of moving the variable setups for the Temp devices to configuration (JSON in config or YAML file), like the Garage device. I would add another device with this capability for users to try out. Advantage is it would mean config is immediate rather than forcing one to goto the Admin console to set up, as well it cleans up the Admin screen for the device. Let me know your opinions. Feedback, feedback, feedback. VERSION = '3.1.11' """ 3.1.11 DONE poll on longPoll, events sse DONE add motor, door position DONE update docs TODO Bonjour discovery is sometimes slow 3.1.10 DONE rewrite switch, dimmer, temp, tempc, garage DONE docs DONE move db files to subfolder 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 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 """

@Michel Kohanim it is a neat ecosystem. I haven’t looked at the discoverable aspect but in the virtual plugin, the garage node will talk to Ratdgo ESPHome control & using both its events sse server & polling. Working pretty solid. All you would need would be a controller per device & a node for every type of sensor on the device (cover, sensor, binary-sensor, etc). I have nothing else but the Ratgdo using ESPHome at the moment so it not on my todo. If someone is interested take a look at the virtual GitHub on the v3.1.1x branch, virtualgarage.py This is currently the beta branch.

So far the crowd has been quiet, this update may get some interest. I have so far not pushed to production to keep churn low. Other than garage, up until this version there was not really any features added. This one adds what I would call improvements of current features for the temperature crowd. Please give a try as I will likely push to production after a few days if no problems arise. ALL: I rewrote all the nodes to mostly clean the code up and make it more readable; aka updateable TEMP: need some feedback from the temperature folks as I like the changes but I use it for a couple of simple applications. The updates are now on the shortPoll, so much faster. The only irritant is when using the pull downs you need to be quick on the button or it will revert to actual. Let me know how irritating as I can likely do something there. I always thought how the range was done on startup or stats/database wipe was odd. No update until next change. it now updates with the first temp value. Let me know if this breaks someone's programs. the updates from the variables come in immediately as well; instead of waiting for the next change FEATURE QUESTION: any interest to use the JSON or YAML configurations to set the variables & conversions up when loaded? We could use this feature to clean up the screen on the IoX admin screen, just means the settings are static. Would likely do a parallel device like temperature_clean to keep it a non-breaking feature. Please let me know. SWITCHES, DIMMERS/GENERICS was significantly rewritten but functionally should be no change GARAGE, which I don't know if anyone but me is using currently was both rewritten and some fixes put in. Working on event rather than polling updates. more to come. DOCS updated. Called the temprc node "depreciated" as it is EXACTLY the same as tempc, same thing goes for the generic versus the dimmer. No code changes, nor am I deleting the other, just a curious relic & wanted to generate some discussion. SHOULD there be differences? Anyone know why they are there? PLEASE GIVE THE GIFT OF FEEDBACK! VERSION = '3.1.10' """ 3.1.10 DONE rewrite switch, dimmer, temp, tempc, garage DONE docs DONE move db files to subfolder INPROCESS garage switch from polling to events TODO Bonjour discovery is sometimes slow 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 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 """

Good deal! Please mark my answer as the solution if you don't mind. Might be helpful to some others. Actually, don't worry, looks like I have superpowers to do it myself!

@hart2hart, yes it may take a bit. Always shows immediately on my stores but on this and other plugins people often say it seems to take time to show. What that time is I have not been able to figure out. When I have asked UD they say it should be immediate. YMMV.

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!