sjenkins

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.

v3.1.2 renaming of nodes based on configuration ISY nodes to be renamed based on config / YAML / JSON changes - rename will happen upon restart or Discover - rename will not happen to default named nodes, where no name was given in the config, so as not to wipe out user renamed nodes in ISY Feedback is welcome, let me know if you have new ideas or devices you would like on the list. I next plan on adding the Garage device, which was my original reason for asking permission to take on this plugin.

See the config instructions for details, Bottom line I added two additional ways to do configuration YAML & JSON, which should make it easier to keep longer lists of devices and back them up. Additionally, this allows more specific naming of your nodes in the configuration. Added the Discover button which in most cases will add/remove nodes based on the configuration. Beware this will delete nodes if they are not in your configuration which was possible to do in the past. I have seen cases where the node is not deleted as it does not show up in the poly node list, just the database. Those you have to delete in the node list. If this is a big deal I can return to it. Finally, some more documentation rework. Let me know if anything is unclear or you find mistakes. Feedback is always welcome! VERSION = '3.1.1' """ 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 TODO: updates to YAML / JSON based on ISY name changes TODO: new device garage door (update to/from variables option) 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

thanks @hart2hart , the electrons must be running slow tonight

Thanks @tazman, Interesting, perhaps the updates are going out slowly?

Thanks guys, I’ll put a ticket in.

odd, like I say I verified on two different devices & downloaded from them I have had issues in the past with updating to the store but that was before they fixed the name change issue. Could someone else out there verify the versions on the production and beta stores for Virtual ?

Thanks for the feedback @hart2hart Beta store should have version 3.1.0 Production store should have version 3.0.1 Are you referring to the blue message that there is an update available or that the store did not update? I did not get the blue update message but the new versions were available in the stores and I was able to upgrade into the existing slots on my EISY and POLSY. I am going to assume the lack of blue update messages is one time as this is my first upload to production. The UID did reset. Can you verify you were able to load them into your current slots?

No functional changes, just refactoring and fixing of the variable write features. see beta Topic for 3.1.x discussion ISY ACCESS IS REQUIRED , tick box is in configuration for those new to this variable write cannot work without this since PG3x changes, see code if you are nervous about this 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 udi-Virtual-pg3.py

@tazman thanks so much for the verification. also, I didn’t mention the need to turn on ISY access for the write to variable to function. I will need to add that to the config instructions And yes you are right on the one digit precision, wasn’t sure if there was any need for more flexibility based on use cases.

I love my OpenSprinkler!! Had the same unit for over 10years now, its plastic is severely yellowing but it’s rock solid. Thanks to @Javi for writing the plugin for the ISY, if I remember right he had to mod it for me because my device is so old & an early version. I am likely the only one still running 2.1 hardware.

per @Goose66 , my multi-device set-up with the homeESP version & HA has been solid for a month now. One day I am going to come back to it and simplify with a plugin, but for now I am pretty happy.

ok I pushed an update to the beta 3.0.1 This fixes the temp and tempc devices as far as the pull and push. So you know, it doesn't pull/push immediately, but on the short poll timeframe. This was a bit of a quick one, so give me feedback; also, I have not been much of a user of these devices until now. opportunities: The average calculation is a bit rudimentary, just high-low / 2 cleaning up the code ; it has some relics hanging around Adding the ability to handle variables with precision other than zero would be good too. Busy week for me so the improvements will not be fast but I should be able to do bug fix. If anyone feels so motivated to update the docs & put up in a thread for peer review, that will speed up the process a bit.

Shouldn’t need to delete to remove those things. Just click the x beside the variable in the configuration tab. save configuration. Restart the plugin.

I would be curious what it looks like after an ac reboot.

I will likely move to a json string holding those variables. btw: : ip, login, and password are holdovers from pg2. They should not be required & looking at the program are not used.

@paulbates , I think the instructions have opportunities, as you have found out. think of the variable name just as a key field. Just needs to be a unique number, has nothing to do with your variables in your ISY. No mapping there. unfortunately the name is just the device type. I would like to add better naming from the plugin. You can rename it to anything you want in the ISY. I keep the number id in the name so I can keep the link. hope this helps.

@tazman , I must apologise, I was testing things out with a number of different starting settings in my local version. It must have been late when I pushed the Beta. Cleaned that up now. As the only changes that I was 'attempting' to make was refactoring, the only testing requested is that it works the same as the old version. Next step will be to start making modifications. Appreciate the feedback & if anyone has any old bugs or new feature requests.

I would say the best is to play around a bit with it. Put a virtual in a scene too. agree you can do it all with programs; this does simplify & make more readable. And we can add more devices if their behaviours are stable.