v3.1.24 in Beta ; optional override device defaults

[sjenkins]

Based on some of the dialogue on the previous version, this version allows the user in the JSON & YAML configuration versions to optionally override device defaults.  This is not just for the new devices but applies to them all, but just certain parameters.  Check the docs.

FYI, this will only be applied when the plugin/EISY/POLISY is rebooted and/or discovery (just for the new node).

I have it AFTER persistence, so it will override that. That is a choice, we may want it the other way around, looking for feedback.

Take a look at the docs please, I want some feedback if its clear with the "hat" of a new user:

README  &  CONFIG

Enjoy; try to break it, and let me know what you think!

 

VERSION = '3.1.24'
"""
3.1.24
DONE configuration based optional override initial default

"""
3.1.23
DONE add onDelay, offDelay switch, update documentation
DONE magic number scrub

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()

[hart2hart]

@sjenkins This will work great for defaults and I've already done a simple test!  My original thought was to point to a variable on the virtual device screen on eISY so one could simply update a variable to change delay timing. Would that have been possible -- not asking to do it -- just wanted to know / understand.

Also, since the eISy sends a single scene command, is my other question about having 1 or 2 retries on scene send a valid question? I understand this is an eISY "executed" scene command as opposed to pure device scene.  Does that make a difference?

Edited 14 hours ago by hart2hart

[sjenkins]

7 hours ago, hart2hart said:

@sjenkins This will work great for defaults and I've already done a simple test!  My original thought was to point to a variable on the virtual device screen on eISY so one could simply update a variable to change delay timing. Would that have been possible -- not asking to do it -- just wanted to know / understand.

Also, since the eISy sends a single scene command, is my other question about having 1 or 2 retries on scene send a valid question? I understand this is an eISY "executed" scene command as opposed to pure device scene.  Does that make a difference?

So if you look at the temperature device, that is exactly what it does (one of my nagging questions is "does anyone use those devices that I just rewrote?).  Takes/Puts the temperature to a specific variable.  Yes it is possible.  You also can just about as easily move a variable value in/out the delay (for example) parameter in a program.

On the second question, yes you could have the plugin send the DON or DOF more than once based on a variable.  If you look at the Insteon commands in a scene, they can be set this way (even from a variable).  Unfortunately, normal commands do not have this option.  No to the scene it would not know the difference that it came from a plugin.