sjenkins

@GTench, So sorry, I had not done a clean install in a bit & there was an error in the profile name for the "number of nodes" name. I need to do a clean install EVERY time I touch the profile files. They don't always effect you if you are installing on top of a node, but will on clean installs. I really would not run two of these plugins at the same time. Manually stop one before running the other. Not because of the EISY, but the gateway can get very grumpy in the G3 ; I imagine the G2 would only be more so being older technology. Its for sure ok to have many installed, ( I have four slots with different versions) just not running.

@GTench, The logs look clean right now. I would suggest stopping all your plugins (not just the HD ones) and starting the AC. See if it starts well. If it doesn't then it is not a plugin issue, start looking at your plugins. Try an ISY reset. If it starts up fine then start turning the plugins on one by one until you have an issue. In each case see if you can turn the issue on/off. Get logs in both cases.

@GTench, interesting, I have it loading 60 & 600 on installation. I’ll have to look. the 60 is the update cycle for G2. please try that as it’s less likely to overload your gateway.

@GTench, Thank you for the logs, I looked at them & in general they look good with no obvious errors. Can you verify you are using a shortPoll of 60 and longPoll of 600? Any chance of a race in your programs? Have you changed any recently?

Thanks for all the work ; putting my plug in for the last one on the list (I know you know)

the connected / disconnected is a feature of udi by adding: self.poly.addNode(self, conn_status='ST') Allows easy tracking. Not sure when that was added by the UDI boys ; I just added it to this. NOTE: So this means you can use the STATUS of ST to check for connected status. But in addition, this plugin (and many others) use the CONTROL of ST to check for heartbeat. Basically a program which checks in the IF section of a program for ON or OFF of the CONTROL, using the THEN to wait for a period of time, say an hour until setting an error ( I push a message using network to my phone). As the heartbeat goes back and forth the wait is reset and the error message is only set when it stops oscillating. I talk about this in the instructions but the status part is new. The creating widgets for scenes does not make sense to me. So if both are stopped does it work ok? I have not experienced that & not sure how it could effect that. Can you please send me the debug files of both the plugin and the main log of PG3. Might be best to DM them to me. If too big I can give you my email there. thanks.

you assume correct remember to tick the box by "Allow ISY access by plugin" and save.

@macjeff, the keys, "isy" , "user", "password" has been depreciated for quite a while. With this re-write I added error checking which defaults to flagging keys which are not recognised. In the configuration screen under the shortPoll , longPoll entries is a little tick box "Allow ISY access by plugin", make sure to tick that box. when you use that kind of configuration you need to enclose the dictionary in {}, {"type": "garage", "name": "VirtualGarage1", "ratgdo": "False"} will work fine for you, no limits on the number (within reason) hope that helps, & thanks for testing.

@GTench, I was using a new name checking function (which I "stole") from another plugin. Their reasonable choice (which I agreed with) was to cut from the left as that data is not as likely "unique", its the name of the room. You are less likely to end of up with a number of shade/scene names the same. As you do in the production version. I changed it back for now, but I am leaning to keep truncating from the left. Let me know how you think about it. Personally, I have just shortened my names a bit. As far as having more than one plugin running at the same time. The issue may be they are polling from the same gateway. On G3 I normally don't run them at the same time but what I find is the gateway crashes not the ISY. I just checked HTOP with three running and found it was ok ; but that is G3. Can you stop each of the plugins, and run one at a time? Let me know if you see a performance difference with production only, beta only, both. If you only see the performance drop on the beta, please send me debug logs. thx

@GTench, Good to go, as I was concerned about, during my refactoring I replaced 'id' with '_id' for G2 scenes. That's all it takes. Someday I will generate tests with my programs ; never really took hold for me. Would help in places like this, where I don't have the hardware to test. Please install in a fresh slot and give it a go. thanks again. PS: also, made a change to fix the noisy start-up before you put in your config gateway

@GTench, Made a change which should protect G2 from starting the sse client. Please reinstall.

@GTench , looks it didn’t detect g2 properly; It got there & is saying the sse server is not right. Yours doesn’t have one. can you do a restart of the plugin and give me the logs from the beginning until that message starts. I don't need it all just that. I added something to drop out of the sse client if it sees that too. I will look at the detection routine again. thanks for testing. This is the g2 stuff I couldn’t test myself.

@GTench, No I just now did a clean non-production install & all was well I have to ask, you updated the config with your gateway IP, right? assuming so, send me your debug logs please

@GTench, Sorry for the delay, fixed. The bug was in the discover routine which you have to do a clean install to find & have certain shades. I made a change before my last clean install test. My bad. Should be good to delete, re-install and check out. btw: : to all testers, please tell me if you are G3 or G2 when you give feedback. Thanks again to all!!

@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. sse and event polling re-written, poly persistence, logging much less noisy ST is being used to monitor a heartbeat, no status only control. Just like the controller, can be monitored with program. 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) DONE refactor function naming DONE refactor garage, fix persistence, sse client, added heartbeat to ST TODO backfeed garage improvements to other devices 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)