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 Friday at 09:44 PM 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.

 

[hart2hart]

9 hours ago, sjenkins said:

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.

Thank you for taking the plugin to levels far beyond what I initially found.  I've never had need for a temperature virtual device, but I created one to see what you described.  Looks good and I'll file knowledge away in case I identify a use case.  Yes, I used a couple programs in my test to load delay seconds from a variable when it was changed, and it is straight forward.  I may expose that variable as a favorite in UD mobile to make it very quick and easy to locate and update it.

 

I have 2 ratgdo devices so I'll try them out with virtual devices soon.

 

9 hours ago, sjenkins said:

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.

I've looked and searched several times to locate how to do this and clearly, I'm missing something simple.  Can you point me to where I can set these retries?  All I can locate in documentation is the Advanced -- PLM Communications for retires which when I select says not available for this device.  My only guess is its one of my older devices and that was not supported at the time.

 

 

[sjenkins]

3 hours ago, hart2hart said:

I have 2 ratgdo devices so I'll try them out with virtual devices soon

I’ll respond to the retry question when I get home with some screenshots. 
on the ratgdo, I wrote it originally kind of like the temp devices, with variables, because I was running the HA plugin, which communicated to the ISY through variables. Later I added the direct ESP client to this device and I don’t use the variable read/write feature, even tho it’s still an option. Currently it’s very solid, I use it for my main garage door, it integrates well to my programs. Even using an off delay for the light. let me know what you think. 

[sjenkins]

5 hours ago, hart2hart said:

I've looked and searched several times to locate how to do this and clearly, I'm missing something simple.  Can you point me to where I can set these retries?  All I can locate in documentation is the Advanced -- PLM Communications for retires which when I select says not available for this device.  My only guess is its one of my older devices and that was not supported at the time.

This is what I meant by, in a scene, an Insteon controller can set retries.  This can be set to a specific number or if the arrow is clicked, to a variable/plugin-value.

[hart2hart]

Still missing something as I don't get retries (or ramp rate but its a relay)

 

[sjenkins]

@hart2hart,

So on the left in my pic, notice I am on the Insteon device controller for the scene, that is why I get the repeat field.

You are on the scene itself ; you would get the same if you are on, for example, my offDelay device, or a z-wave device.

Scenes are from the perspective of the Controller for the command they send.  So if you fire the scene from a program, look at what the scene name sees.  If you are firing from an Insteon switch it will send the commands to each of the receivers the way you set it up.  So in mine, on the right, this is showing what the Insteon switch is sending to another Insteon switch.  You can set the command to whatever you want, default means it just sends pass through whatever the Controller is sending.  Makes it possible to send a DOF to one device in a scene.

Appoligise if you knew most of all that, but I had treated scenes for a long time just as sending individual level commands, but they can do quite a bit more, if you want.  Certain devices have limitations as well.  Its why the VirtualSwitch devices wouldn't work in scenes so long, they were just status devices & didn't sent commands.

Hope this helps.