sjenkins

@GTench, Found a late dumb error in Discovery. Did a quick fix for G3, but give me the night & I will fix it properly.

Yes you can, I actually have production, beta, & development local on mine. I don’t tend to run them at the same time as sometimes the gateway gets grumpy. But nothing will blow up. you also can install the beta on top of the production, and then go back to production without your programs getting messed up. I do this sometimes too in my testing cycle. The poly platform is very flexible this way.

Should be in the non-production store.

I guess two ways to countermeasure the confusion for users 1. Make the local plugin handle both, the regular plugin handle remote only. Will likely have your more advanced users in the local plugin. Could use this as your slow merge plan. Cons: managing two plugins & as you state the testing involved. 2. Lots of warnings in the instructions and the labels on the configuration items to steer the remote users from entering anything in the fields. Again assumption is your local hub users are your more advanced. May, or not, be a good assumption. Pick your poison.

Pretty quiet group out there ; I am specifically looking for at least ONE Gen2 user to tell me the commands and updates still work before I go into production.

The one installed is 0.0.7, the one I got a message on and is in the store is 0.0.6. Assumed there was no difference, just wanted to let you know as it has happened to me before ; just causes noise with the users. I am good either way on do the non-local devices sit on the local plugin. Con is it means another plugin, Pro as you say is keeping it clean ( keeps it very obvious which ones you added to the local hub). Saying that, my additional speaker hub is sitting on the local plugin right now & seems happy enough. Do'ing it this way would allow me to utilise it with one plugin. I don't know what the plumbing is, but doesn't it give you a path to "one plugin to rule them all" if the local eventually swallows the functionality of the non-local hub? or does the communications go the other way? Good to support either way. I have debated this question with my Hunter-Douglas plugin, there are Generation 2 & 3 with very different update paths. I kept them as one, but nearly split them in my last rewrite. There are almost no blended 2/3 environments. In this case you will have many with at least a speaker hub which has some use but won't be on the local. More rambling than help, but maybe some things to discuss.

@Panda88, fyi the version in beta store has reverted from 0.0.7 to 0.0.6

Decided to start the rewrite ; mostly this is modernising the coding of the plugin, but a few features come along for the ride. Controller: re-written to be more pythonic Status which is meant to indicate if connected was never working right, on at start, off with stop / delete. If you monitor, it can be useful. I use it on folders to switch between my beta, local, and production versions of programs. Monitor the control version of ST for heartbeat. added NumberofNodes which may be useful to some Garage In the continuing roll out of control, the garage device added it for motor, motion, obstruction. will get its rewrite next version, lots to do here Switch added TOGGLE, as a receive command, the send will be DON or DOF, let me know how useful re-written to be more pythonic, logging should be much less noisy persistence is now using the polyglot management instead of individual files for those watching, the first run will use the file data then store it with polyglot, then delete the file Generic / dimmer didn't add a TOGGLE but could; thoughts? same as switch for re-write, logging, persistence much improved behaviour from 3.1.15 for remembering on level, won't get messed up by double off or fast off/on Temp / TempC / TempRC (curious if anyone uses these still?) poly persistence re-write, logging consolidated into a single file, still configured as separate, for backward compatibility variable read / write & updates should work more logically variable write happens with shortPoll updates but only when there is a change so not to fire programs constantly TEST IT OUT & Give me some feedback people!!! VERSION = '3.1.16' """ 3.1.16 DONE fix controller ST "status" on at start, off at stop / delete, "control" still heartbeat DONE garage send CMDs, motor, motion, obstruction ; get naming consistent DONE standardize startup sequence DONE rewrite checkParams, Discovery DONE add NumberOfNodes DONE switch/generic/dimmer/temp(R/C): nodes use polyglot persistence, delete old db files DONE swtich cmd TOGGLE add DONE consolidate temp, tempC, tempRC into one module DONE temp variable writing now with shortPoll (only upon change, considers precision) TODO refactor function naming TODO refactor garage, fix persistence, sse client, bring temp variable improvements 3.1.15 DONE generic, dimmer, change ST to OL, memory of level for DON, DFON/DFOF, command 3.1.14 DONE commands for switches, generic, dimmer, garage

So I tried that as the way you describe makes sense, but it doesn't work. Seems shift-space is required to get the load to happen. I am on osx in safari. Also, I do agree with @mmb , the announcement is my trigger to update and test ; I just found this update bc I was updating for other reasons.

This set of changes on effects the generic / dimmer node, to address control in scenes, fast on/off, adding memory so normal on will return to the last on level. Need to test so we know its not breaking for anyone. Details: changed ST to OL (on level) send is now DON, DOF, DFON, DFOF, BRT, DIM, OL (send level) accepts is now the same with OL setting the OL added a "memory", DON uses the memory set at 100 initially persistent over reboot of ISY, plugin BRT, DIM, modify the memory, but if DIM to zero, sets to 10 so ON is never zero OL mods the memory but if zero sets to 10 DFON does not affect the memory just sets level to 100 DOF, DFOF sets level to zero, mods the memory if level not 100 all seem to work for the programs as control / status Have not tested scenes exhaustively, but should work for control for DON, DOF, DFON, DFOF need to test more on effects for scenes for BRT, DIM, OL

So..... I do plan on doing a rewrite of this plugin mostly to bring the python up to date ; not for features. I am doing this with my Hunter Douglas plug in and am really happy with the readability and maintenance. But, I just did a few of the changes above with the criterium it should not be breaking for anyone. We will need to validate this. The only issue is they did require profile changes which can be a pita when you do an update. I put it in the beta (non-production) store as 1.1.15 changed ST to OL (on level) send is now DON, DOF, DFON, DFOF, BRT, DIM, OL (send level) accepts is now the same with OL setting the OL added a "memory", DON uses the memory set at 100 initially persistent over reboot of ISY, plugin BRT, DIM, modify the memory, but if DIM to zero, sets to 10 so ON is never zero OL mods the memory but if zero sets to 10 DFON does not affect the memory just sets level to 100 DOF, DFOF sets level to zero, mods the memory if level not 100 all seem to work for the programs as control / status Have not tested scenes, but should work for control for DON, DOF, DFON, DFOF need to test on effects for scenes for BRT, DIM, OL Let me know if this scratches some of what itches. Then we can go from there. (I will make a post stating this, let's continue the discussion there to keep versions clean)

Hi @Diesel, First, appreciate the thought you have put into this ; you have pushed me to think through this thing. I will seek to understand by asking a few questions. First, a bit of how I see the virtual plugin. Virtual was originally written to plug a hole which would bridge scenes to programs. This is the switch, dimmer/generic. Then devices were added to bridge variables to programs & add a bit of conversion math which didn't originally exist in ISY. Finally, the garage device was added to bridge SSE server/client to programs. In each case it is meant as a bridge to signal and allow control or status for a program to act on it, but not to replace the programming tool in ISY. In fact I think most plugin's are really meant to bridge and in some cases augment but not replace the basic node, program, variable tool set. So as an engineer I am often cognisant of the addage "just because I can, does not mean I should". With the stated vision of this plugin & would like to sort / sift your chart of features in these added features. Scenes are handed by the ISY as a passthru of commands, not as part of the node. So in the nodedefs.xml is set up to "accepts" commands and to "sends" commands. So the command set for scenes is limited to ones which other devices can send or receive. Other commands are for use in programs. Physical ; functionName ; cmdName ; scene use case ; program ***currently handled: Tap on ; setON ; DON ; scene receiver ; any status;then Tap off ; setOF ; DOF ; scene receiver ; any status;then holdUP ; setLevelUp ; BRT ; scene receiver ; any status;then holdDN ; setLevelDown; DIM ; scene c/r cmd ; any status;then --- ;setDim ; --- ; scene cmd ; status;then ***left to system Fast On ; left to system, could be added to goto 100 Fast Off ; left to system, could be added to goto 0 ***not in system Basically the "storage" and coordination of all the functions of a multi-dimmer circuit. *** could be added Like the switch node, can (and will) add "sends" of DON, DOF, BRT, DIM, which are on the "accepts" list. After, lets access FDON, FDOF and decide how we want them to act. *** not sure you are going to get what you want coordination of a set of dimmers beyond DON, DOF, BRT, DIM, FDON, FDOF. This is best done through programs. The reason is that the plugin is not aware of the scene which the node is in. *IT COULD BE*, but a bucket of effort. I don't know of any plugins which do that, and not sure its in the list of "should". Lastly, appreciate the discussion, let me know if I misread anything you are proposing or if other ideas come up (or you just disagree). We have a fun sandbox here & the possibilities are endless. *OTHERS* , feel free to join the discussion, this is not my plugin, it's ours!

So I did an update and reboot of my ISY, which I do incredibly rarely. A real testament to the stability of the system. Anyway, while testing my plugin I saw a few more items in my easy-ui menu, so I checked out the version number. For those that don't know: pkg info easyui will give you a nice update of whats new all the way back in the versions. Currently 0.6.0 has <truncated to last version>: elease notes for 0.6.0 - Programs page - Variables pages - Keyboard navigation in lists - Nodes page default sort by name - Added Sign up link on login page - Several Bug fixes First, thanks @bmercier thanks so much for my keyboard navigation!!!! Cursor keys will move the list around with <shift> cursor moving the node "in-focus", the node which gives the data you want to see. The bug fixes seem to be making their way along; I'm not getting the app-crash screen so far. Programs & Variables pages are nicely done, giving the info you need. I have only explored reading so far. The only continuing issue I have is the list view of nodes seems to update the status well, but the detailed view will disagree over time & requires a browser refresh to update. Moving off then on the node does not fix it. Thanks so much for all the work team UD, looking forward to not needing to update my Java!

Payday so I was able to drop the $15 All installed and booted nicely ; we are back in business....locally !!! btw: : over labour day weekend one of my yo-link leak sensors went off and found a leak in my RO water system. The dealer had "never" seen that failure mode (the plastic weld on the filter failed). Yo-Link saves the day & my supply of ice for the boat on the long weekend!! Thanks again @Panda88 for taking this plugin to the next level.

Basically rewrote the whole thing as the Python was pretty ugly & while I'm no expert I have come a ways in my journey. Also, stole shamelessly off a few other more gifted plugin makers. Thanks to all who make their work public. @Jimbo.Automates I'm looking at you. The end result is much more pythonic and readable ; hopefully easier to maintain. It is MUCH more responsive and less likely to crash ; with the old version did on a regular basis for me. Saying all that the feature list is very short & really only for the G3 folks. Small thing, added a node count to the controller node, does not include the controller. Saw others with it and can be useful as a sanity check. Motion for shades & Active for scenes should be good for use in scenes as controllers and in programs. In addition the shade actions should work in programs for control in addition to status. The event engine works much more quickly and reliably now, to the point I now pre-populate POLLING with 60s short and 600s long cycle. The 60s is for G2 updates and does nothing for G3 except restart the event engine if it ever crashes (doesn't seem to anymore). While the 600s is only for G3 polling and does nothing for G2. G3 almost doesn't need the polling anymore. YMMV. G3 scene activation I found was not always being updated by the PowerView gateway. The app would read correctly but when you went for the active list, it was out of date. Now I use the active scene event, but I set the active scene by calculating where the shades are. I also trigger calculations when the shades start or stop movement. Seems to work MUCH better. Sorry G2, there is no way to get the underlying shade data for a scene. I tried. Cleaned up the logs ALOT. INFO level is more sane now. Please send me DEBUG level if you have issues. I have tested a fair bit but I have 15 shades and about the same number of scenes, ONLY G3. I am most fearful that I broke something for G2. So I am really really sorry G2 but I gave you little and may have broke something. I will leave it in BETA as long as it takes, but I will need some of you to test it. One last note. With the move to EISY-UI, there is some behaviour that I am seeing across plugins. Once you update this plugin, you may need to run an ISY update / reboot. You should NOT need to delete and re-install (that will cause you to have to resave all your programs, yuck!!). If you don't update/reboot and you log-in locally, all is well. But the portal login may give you a lot of blank bits. They will update as scenes are activated or shades change but a update / reboot makes everything better. Or at least that is what I found. You can load the beta in a slot you have production, and move back to production. Most likely (!!) without breaking anything. I have done this a few times. I actually have my programs which schedules triggering of scenes to three different plugin slots (where I keep my production, beta, and local versions). I only run one at a time but it allows me to test back and forth quickly. Please give feedback!!

enjoy, let me know if you find any issues. I have only added dimmers / generic for dim up and done being active in control for programs. Scenes will take more, and a choice, if we want them to maybe return to the last on positions and trigger the scene, or 100% / 0%. I am reaching the end of re-writing my Hunter-Douglas plugin to a less ugly Python. My plan would be to come here next. VERSION = '3.1.14' """ 3.1.14 DONE commands for switches, generic, dimmer, garage 3.1.13 DONE prevent direct poll from re-running DONE add notice if comms check fails DONE clean-up & debug

Thanks @hart2hart for the kind words. As people are using this for lots of different things than I am , I just wanted to make sure the beta had time to soak. Just make sure it still meets your use case with no unintended consequences. I usually leave beta for a week or two then consider no news as good news and move to production.

First of all; good for you! I got starting in this black hole called plugin writing the same way, adding a node to this plugin. on the units, udi is the keeper of the list. I would suggest a support ticket is the easiest for them and you. In the mean time you could either convert your number or ignore the unit for now. sorry I’ve been dark but I have a big home project going on as I’m rewriting my Hunter Douglas plugin, oh and I work. lol. please keep us up on your progress (and frustrations), there will be both. And enjoy the journey.

The concept is already proven to me -- I'm on board

@Panda88 looks like the TSTYolinkLocal is now dead in the water. The "subscription" is out of date & it has shut down. Won't restart or re-install or update. Not sure what is required to give it a jolt, but would appreciate more time on it until the production version makes is out of your shop

sorry I should have been clearer as I knew it would NOT work as a scene controller only in a program as controller (versus status) Scenes prefer DON and DOF. I can add them but there is a design choice here: Insteon uses DON/DOF as 100% / 0% not brighten / dimming. Currently the dimmer / generic device does not have those commands. option 1: add DON/DOF commands as 100% / 0%, this is most consistent with UD scenes which are aligned with insteon scenes. option2: use the current brighten / dim which move the percent by 3% I believe. I would just send the DON / DOF command along with the current command. This might be more useful considering the device but confusing for scene consistency. thoughts?

works ; nothing blew-up ; thanks! Update: the trial period message comes back saying "this node server will expire soon", assuming that 60 days is "soon"

Try it out, I added the commands for tapping up and down on the bright but not for the new value. Also it currently doesn't have DON or DOFF which are the normal on/off commands. Could be added though.

I do think just a new version, same content just bump the version in the development screen & push out the trial time period. Just my opinion, I agree trying to do this in one remote and local version sounds like a nightmare. I at least have never written a program right the first time. You have made this thing really stable ; hate to ruin that. Michel/UDI are really helpful in everything but consider this ; you are truly adding a feature which was not part of the program we originally purchased. I can only speak for myself but I am more than willing to pass you a few bucks for the effort & support involved. My vote is put out a new Yo-link local and call it a separate plugin with a fair one time price. Just one vote but you could put it out to the population.

@Panda88, Would be great if you could "refresh" the beta and kick out the time period until you are more ready to either merge or not-merge the two. I was so excited about local that I DID move my programs over to the beta. No worries I will move to whatever solution you come up with, but would be nice to hang out with the current set-up until then. Thanks again for the efforts, this plugin is now part of the plumbing of my home automation ; literally & figuratively.