sjenkins

Thanks @bmercier, seeking to understand: so right now when I setDriver(GV0, value), I don't expressly set uom, like: setDriver(GV0, value, uom=#[name I used in EDITORS]) is that what you are thinking? or is it that value is possibly an int() rather than a float() This is part of the api which is rather quiet, as well when to use force=True or not. appreciate your time

Its for Virtual devices ; just called 'virtual' in the plugin store. I have been re-writing it as I took over curation of it a bit ago; the behaviour exhibits in both the old production and re-written non-production (you will likely find the re-write much easier to read). The issue shows itself in the temperature devices. If you install it & configure with one device: key value 10 temperature As far as 'configuring' this behaviour, you can see in the profile files there is very little ability to configure beyond a precision variable. Perhaps eisy-ui is ignoring that?

@GTench, Well I appreciate your patience ; sorry I was not much help in understanding the issue. Glad it seems to be working now. I have seen before where a battery status has shown 'no status' for some period then returned. That could just be comms between the shades and the gateway. Does the app show the status? Does everything else update and trigger as expected?

Lost an hour trying to debug this on the Virtual plugin ; until I asked myself if the AC did this.... @bmercier, the precision on display seems to be different between the entry number and the actual in Current versus Set Current: for some reason Set Current in the Eisy-ui is one tenth. Whats interesting, is the number you enter goes in properly but then shows as one tenth down below: correct in AC: Not in eisy-ui:

@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