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.

 

[hart2hart]

@sjenkins Thanks for taking the time but I do not have those options regardless of what I'm clicked on.  I'll research more and may post more images in future. 

I 100% understood scenes and their devices and scene level hierarchy when they were pure scenes and all my more complex scenes were created then so only had to replace a couple devices to keep it going. I haven't thought about scenes / groups definition detail in several years.  I guess with v5 FW is when the Group concept came in to being that gave many more capabilities with a single scene/group but was not as straight forward.  I've been looking for concise documentation this morning on groups/scenes and can't locate anything that doesn't have discrepancies with actual gui screens.  Therefore, I'm going to create another post describing how I understand it to get a point to better / accurate documentation that I likely missed.

 

If you have scene with 1 physical switch and one offDelay virtual switch:

• Turning on / off at the  physical switch does what is expected
• Turning on / off the screen from AC or UDM does what is expected
• Turning on / off the physical switch device inside the AC or UDM does not start the timer   - is this the expected behavior

[sjenkins]

1 hour ago, hart2hart said:

If you have scene with 1 physical switch and one offDelay virtual switch:

• Turning on / off at the  physical switch does what is expected
• Turning on / off the screen from AC or UDM does what is expected
• Turning on / off the physical switch device inside the AC or UDM does not start the timer   - is this the expected behavior

Certainly scenes are a bit of fun; sometimes not in a great way. 
With the scene you describe above both the switch and offDelay device need to be controllers. Then turning on the switch should start the timer. 

[hart2hart]

Certainly scenes are a bit of fun; sometimes not in a great way. 
With the scene you describe above both the switch and offDelay device need to be controllers. Then turning on the switch should start the timer. 

I created the scene and added both physical and virtual devices as controllers and both show ed up as red in the scene. However, after reading your reply, to be certain I looked at each device. The physical device showed it as controller and responder for the scene but the virtual device showed only as responder to the scene. I removed virtual device from the scene and added it back as a controller but again when I looked at the virtual device it showed only as being a responder to the scene. Next I deleted scene and started over. Same results.

Sorry if I didn’t say it very well but if I turn on the physical switch device using eISY AC, it did not start the timer and hence did not turn off the light after defined delay. Not sure if it’s what you would expect so wanted to point it out just in case and compound that with scene definition I found looking at what you said.

Yes, scenes / groups are great but to me they are described structurally instead of how to effect them through the AC UI. I wrote what I understood and asked for comments in a general eISY post.

[sjenkins]

@hart2hart,

something odd with the Controller adding as a Responder. Only thing I can think off is the profile didn’t take. You may want to reinstall the plugin. And / or reboot the eisy. 
I can add as responder or controller. 
 

[tazman]

3 hours ago, hart2hart said:

• Turning on / off the physical switch device inside the AC or UDM does not start the timer   - is this the expected behavior

I would say this is expected, scenes are not triggered when you operate a device from the AC. You can test this with any scene you have only the device you operate from the AC responds. I think because ISY does not receive a command from the switch when it is not manually operated.

@sjenkinsI like the new timer function thanks! I use the temperature nodes to record low and high temperature reached for the day. Is it possible to not have it use the "0" it sees on a reboot?

[hart2hart]

I would say this is expected, scenes are not triggered when you operate a device from the AC. You can test this with any scene you have only the device you operate from the AC responds. I think because ISY does not receive a command from the switch when it is not manually operated.

Thanks, makes sense based on flow of who sent the Insteon command.

[sjenkins]

4 hours ago, tazman said:

I would say this is expected, scenes are not triggered when you operate a device from the AC. You can test this with any scene you have only the device you operate from the AC responds. I think because ISY does not receive a command from the switch when it is not manually operated.

@sjenkinsI like the new timer function thanks! I use the temperature nodes to record low and high temperature reached for the day. Is it possible to not have it use the "0" it sees on a reboot?

You are right, about inside the AC & scene triggering. @hart2hart, you are right, I misunderstood the first time. 
 

@tazman, glad you like the timers. Sorry, about the new temp default, you are right of course. I will fix that.