sjenkins

Can you restart and send me logs please.

@hart2hart, thanks, this is a frustrating one as the plugin is telling the poly to update the profile when the version does not match. Worse its a bit of a random walk why it sometimes works & updates and other times requires a rerun of the plugin or worse an ISY reboot. I find myself hitting the update-profile button every time change it and I stop or start the plugin in the hopes it will take. I'd love to solve this one. Please play with all the new bits of this plugin ; try to break it ; let me know if you find something you don't like.

@hart2hart, Thanks for the feedback. Obviously not normal, That’s been solid for a number of versions. In order can you restart the node, try it. If no joy restart ISY & try. Send me logs if still zero ; means it failed in discovery; like to see where. Possible, but usually blank, if you have updated to 6.0 I have seen it take time on the remote versus local login until the profile updates. thanks.

Sorry I wasn't clear. I don't think I am running 1.6.0 I think the timing was such: 1. I had 1.5.15 and the update came down for 1.6.0 2. crashed, did not work 3. later it came asking to update 1.5.16, did the install and all is good, initally said it was 1.5.16 but then the pg3 display says its 1.6.0 (I don't think it is) 4. it is now claiming to want to install 1.5.16 again I did nose around in the files but I don't know where you specify version. install.log

In the no news is good news category, I am moving v1.13.1 to production: Per the beta topic: 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

Ya it wants me to update again to 1.5.16 but showing 1.6.0 ; working fine now so ignoring.

Quite a few updates which for those of those following the betas will know. Below is the log which lays it out step by step; many of the rewrites are for future maintainability and stability. The logging should be cleaner and easier to follow as well. Some user facing features though: Controller: ST status follows the running of the node. Connected means running properly ; Disconnected for stopped or failed. ST control still is a heartbeat which can be checked in a program. Number of nodes is just a sanity check if all the nodes you put in your configuration add up. Switch: Added toggle Generic / dimmer Added onlevel & onleveltype, which mean we can mimic physical switches better On level is the return to level after the switch is off. Fast on will always go to 100 On level type is Static or Dynamic. The first mimics Insteon, set it and it will not change, the second will change with the on level. Temp user facing should be working better with variable writes Garage lots of reliability improvements 3.1.22 DONE generic/dimmer static/dynamic behaviour 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() 3.1.15 DONE generic, dimmer, change ST to OL, memory of level for DON, DFON/DFOF, command

With reboot, both plugins said v1.5.16 was ready (1.6.0 had installed for both). Updated and started, all was well. Version on both plugins now say 1.6.0 again ; store is 1.5.16 Thanks

Just did the install of 1.6.0 & its crashing log files attached. In addition once you start the node, both local and regular, it seems you cannot hit the stop button and get it to stop. Tells you its not running. Is this a result of the initializing status. Means I had to delete the node to get it to stop. update: not just the local hub plugin ; the regular plugin is crashing and restarting as well. TSTYolinkLocal_10-1-2025_92945_PM.zip

Keeping with adding as much to the beta before pushing to production. Want to balance those who are looking for stability versus feature growth. This beta came from some requests to build the generic/dimmer device a bit. What we've added recently to generic/dimmer Scene triggering Dynamic persistence of onlevel (returns to last onlevel) Visability of onlevel NEW: Ability to switch between static or dynamic onlevel. Static is consistent to Insteon switches, basically Don will always return to the set onlevel. DFON goes to 100%, again like Insteon below are the rest of the changes from current production, mostly modernization or back-office changes 3.1.22 DONE generic/dimmer static/dynamic behaviour 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() 3.1.15 DONE generic, dimmer, change ST to OL, memory of level for DON, DFON/DFOF, command

They will fill in eventually. Don’t spend too much time on it as it’s something they are working on and has been there since the Alpha. As you say the AC and UDM will show the data immediately. they will figure it out.

So I said: 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. What I mean by that is that dynamic is OL changes based on the last on condition. Insteon or Static, means you set an OL so every time you turn the light on it returns to that level, except fast-on which goes to 100%. This is how the Insteon dimmers work. give it a try, I just put it up in beta / non-production as v3.1.22 make sure you reset the AC and/or logout/in for eisy-ui as there are a number of profile updates in this one.

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