sjenkins

@hart2hart is correct, was doing a lot of navel gazing for a bit to figure it out. Seems to be solved in eisy-ui v7.1

No worries @BHaus , everyone has been where you are. I am also sure we can get you where you want to go. You and @tlightne are correct, you don't use the AC. Since you installed the plug-in you must be able to get to the poly or eisy-ui menu, which the store was where you installed this plugin from. Go to the Dashboard, and then hit the Details button on the slot you installed the Virtual plugin. At the new menu you will hit the Configuration button. Here you can scroll down and read some documentation which will be real helpful to read. I would suggest starting with the Standard Configuration. Just make a switch. To do this go past all those instructions (really read those) you will find a section called Custom Configuration Parameters hit the button called Add Custom Parameter in key type in 10 in value type in switch now hit the button below called save changes now scroll all the way to the top and hit either Discover or Restart If you go back to the AC you should have a device called '10' which is a switch. READ THE INSTRUCTIONS FOR MORE, come on back here with more questions. have fun!

Same, installed the production on top of the renamed non-production v1.5.16 local ; no issues. Have now deleted my cloud Yo-Link, which was in another slot. Had written my programs to handle either local or cloud, now cleaned-up and running off the local. We are in the deep end. Thanks for all your work @Panda88 , Yo-Link devices are now my main Leak, water-valve, temp-humidity, power detection devices. Happy to have them locally based, keeping my tinfoil hat firmly on.

So three new devices, offDelay, onDelay, Toggle as well the ability with the JSON or YAML configuration to set initial default values 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! 3.1.24 DONE configuration based optional override initial default 3.1.23 DONE add onDelay, offDelay switch, update documentation DONE magic number scrub

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.

@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.

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, 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.

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.

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.

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.

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, I get that setting the variable by program is a PITA if you are not changing it from your initial setting. I'm putting up a new beta v1.3.24 "as we speak" which addresses it, you get the credit as your previous comment triggered me on this one. Basically, why wouldn't we optionally allow the user in the JSON or YAML configuration versions to override the initial defaults? appreciate the dialogue, it makes this thing better as we go.

Appreciate the thoughts @Guy Lavoie The Off button (documented in original post & README), you are right is of questionable usefulness. It will turn the status from On to Off if the toggle is not in one of the two TIMER statuses. The reason for not using a specialized Start button is scenes don't play well will that. DON, DOF, DFON, DFOF, and sometimes OL, are really your only command options. From what I have seen so far you are mainly a program guy, but @Diesel is mainly a scene guy. So in the design of these devices I have tried to bridge the gap, make it useful for both, as well as keep fairly standard to how the Insteon devices operate. I did think about another toggle to start off, but could not really think of a use case which I couldn't achieve with a wait statement or a thoughtful set of triggering. I would like to keep this clean & not add complexity if it doesn't fill a defined gap. Hope that helps.

@Guy Lavoie, You’ve got it. So my next question is, I documented that in the readme (above, first post), would you have gotten that from my text? I basically did it as a list of if’s when you switch it, or change status. As opposed to your story method.