sjenkins

So the proposal: Dimmer/generic by-the-node: default = Insteon = Static - set the onLevel(OL) manually or programatically 5-100 - not changed by DON/DOF/DFON/DFOF/BRT/DIM - modelling behaviour of Insteon optional = Dynamic - onLevel CAN be set manually or pragmatically 5-100 - changed to current level with BRT/DIM, will not go below 5 or above 100 - changed to last level with DOF, DFOF - basically a "last on" persistence for status Will need to add GV0 to be flag for the static(default)/dynamic choice. defaults, range: ST = 0, 0-100 OL = 100, 5-100 GV0 = Static, Static/Dynamic This work?

sorry, didn't mean to lock the topic ; the point is discussion!

For everyone's info, currently 10 is already being used as the floor for onLevel and 2 is the increment/decrement for brighten/dim. if we want this I would likely do this per node as dimmer/generic is the only Virtual node using these parameters. @hart2hart , I tend to agree with you on the Insteon definition, I did this method after added the persistence and before realising I should look at how my other many switches work. @Diesel, what do you think, static onlevel or dynamic(last on) onlevel? .....others?

up and going again, thanks!

I had everything working perfectly ; felt wrong, so I did the update on the first day

@Panda88 great minds.... just did an install in a clean slot, no joy, sorry. Get what you need done -- we will be fine, I just wanted you to know or me to know it was my system.

@Panda88 just did the update to ISY 6.0 ; most started up ok but Yolink local will not show connected , nor update any of the devices. I sparked up the regular remote Yolink I keep in another PG3 slot, it started up just fine, showed connected, and started populating devices. I looked at the plugin logs and got nothing. the main logs looked like they sparked just fine, no errors. I did a re-install (which the upgrade does as well). No joy. Any others having issues after upgrade?

Couple extras that I would rather add to the beta before we mess with production: For those who use generic / dimmer which persistence was aded in the previous beta I added visibility to the onLevel(OL) in the AC or eisy-ui. The question is would you rather OL is "dynamic" where it changes to last set or "static" where it starts default at 100 but when is set to something less it stays there until re-set. Very much a preference thing. If we want to mirror Insteon we use the former, but many devices use the latter. Does not affect device or scene commands. FEEDBACK please. Added a Notice when someone forgets to tick the little box for authorisation to write to ISY. Matters for temperature & garage nodes if they are configured to write to ISY variables. I have seen this on a regular basis for those new to the node. The rest are in the logs but should be invisible to the user. Other than debug, or the above choice in dimmer/generic, I am thinking that the development cycle can slow down now. 3.1.21 DONE generic/dimmer to model dimmer ST & OL DONE name & address check using poly interface DONE consistent use of poly versus polyglot DONE fix nagging error check in main() DONE controller discover refactor DONE add notice for ISY authorized error (was only in logs) 3.1.20 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 DONE backfeed garage improvements to switch(done), generic(done), temperature()

How about just support UD & buy an eisy. I upgraded to Polisy from my 994 when it came out. Then lots of things happened in the world and UD needed to come out with the Eisy. I think they have been extremely gracious in their support. This is not a huge company, the upgrade path is not complicated. @Michael& his team @bmercier & volunteers like @Javi are pretty phenomenal. If you spend anything near what I spend on devices, go pick up an Eisy. just my opinion & ymmv.

This should bring to an end this writing cycle, for those of you tiring of the updates. Should move to a period of stability with just debug unless someone comes up with a brainwave of a new feature. I am much happier with the stability and maintainability of the plugin now. This minor update focused on the start-up which was very repetitive and hard on the gateways with too many polls for data. I also really did not understand much of the polyglot ecosystem when I started this plugin ; feeling better about that now, especially how persistence and parameters work. 1.13.1 DONE refactor controller discovery, put, get, goodip functions DONE refactor controller startup, config, params, naming, logging DONE refactor cmdSetPos

Same. Try ISY reboot. Only had this once ever. May be related to the new eisy-ui updates as that does change which piece of the stack owns talking to the portal AFAIK. also yesterday:

Ok, the re-write and validation of G2 & G3 is complete. Unfortunately, our sample size in testing is one of each system ; but here we go! The feature set is short but the code clean-up and resiliency should make up for it. polling 60 shortPoll, 600 longPoll (should roll out as default) 60 shortPoll is how often G2 will poll the gateway (same as before but was longPoll) to update (you can try shorter but you may flood the G2 gateway, YMMV) shortPoll also flips the ST cmd for heartbeat, re-starts the G3 client if it fails 600 longPoll is how often G3 will poll the gateway. Has been moved out to 10min as this is really just belt/suspenders for G3. Almost not needed as I have found the sse client is more than able to keep G3 updates accurate. longPoll does nothing for G2 controller ST cmd still tracks heartbeat, easy to monitor in a program ST status is tracking connected/disconnected, basically if the plugin is running number of nodes has been added and can be used as a check for how many shades + scenes you have discovered. G3 , complete re-write of the sse event client which is much much more resilient and less resources shades complete rewrite, should just work scenes G3 activation is now calculated. MUCH quicker and more accurate. Works even when the mobile app is blank. also a complete re-write Take a look at the code if you are interested on GITHUB . I welcome feedback & obviously value bug reports. NOTE!!! - there are a number of profile changes, if you are writing overtop of a current node, you will likely need to hit the load profile button and re-load eisy-ui or the AC. VERSION = '1.13.0' """ 1.13.0 DONE polling rewrite, controller: shortPoll=G2 poll, heartbeat for all, re-start G3 events, longPoll=G3 poll DONE polling rewrite, shade: shortPoll: re-start events if stopped, longPoll: not-used DONE polling rewrite, scene: shortPoll: re-start events if stopped, manually clear G2 scene activate, longPoll: not-used NOTE default & recommend setting shortPoll=60, longPoll=600 DONE major re-write of function and Event routines DONE add number of nodes managed by controller to controller node

@GTench, Great to hear ; again thank you for working with me, I needed to know that G2 was working. My G3 system is pretty extensive with three gateways and 14 blinds of 4 different types, so it gets a pretty good test. Well I am going to move the beta to production and hopefully not blow up anyone's system

Rewrite of the plugin is complete. If you are wondering "why mess with what is working?", I agree in that principle which is why since taking over the plugin I've kind of been a light touch. Except for the garage node which I started from scratch. I am sensitive to breaking someone's automation. Basically the code was pretty messy. Tough to read & maintain, as well there are some things which have moved forward in the udi_interface library. There was a lot of repetitive code, so I moved functions to a helper utility library, and consolidated all the TEMP nodes into one file. Finally, persistence was moved from *.db files to the provided api of the poly.Data structure. The majority of this should not be breaking or even force you to modify your code. Temperature users may have some changes due to the inconsistent use of precision in the original code. The code should be much easier to maintain, add features, or new nodes. Please take a look in the GITHUB & feel free to make comments. I held off on some other "improvements" which I knew would be breaking. The way changes are made in the UI for temperature are really ugly ; as well the precision setting is better set in the variables used. I could make a new node to clean this up, but I am not clear even on how many people use each node type. Some features which have been added (let me know if there are any more, or new nodes, you are interested in: controller: status follows if plugin is running number of nodes switch: cmd fixed so can be added to scenes TOGGLE generic / dimmer cmd fixed so can be added to scenes persistence was fixed & added to on-level could add TOGGLE if there is interest?? temp consistent behaviour due to one file persistence was inconsistent writing of variables only with changes precision handled more consistently (this may cause some program issues) garage this was a mess ; I started out writing a virtual node and ended up writing a Ratgdo interface. It does both, but likely should be two separate nodes. The clean-up makes that next step possible. This would be breaking to Ratgdo users (if there are any besides me ) sse client re-written, more solid persistence fixed I WILL LEAVE THIS IN BETA (NON-PRODUCTION) FOR ABOUT A WEEK BEFORE MOVING TO PRODUCTION ALSO, REMEMBER - tick the box in configuration to give the plugin ISY access, this lets it write to variables!!!! VERSION = '3.1.20' """ 3.1.20 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 DONE backfeed garage improvements to switch(done), generic(done), temperature()

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.