sjenkins

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!

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 """