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.

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.

ok @Guy Lavoie, @hart2hart, fixed the simple issue. Please keep trying to break this. I also, to @hart2hart, thought that it might be useful to be able to define in the json or yaml starting numbers. I have not pushed the commit, but will test a bit and roll that as a minor change to the beta. The docs are also being written as I go here. Please take a look and give some feedback with the hat of a new user.

Sorry, I’ll fix the simple version tonight. My bad. the colon is being stripped by the polyglot device name function. its newish & must not like colons, I hadn’t back factored to the earlier devices. I’ll check with udi and see what they think on this.

Thanks, I’ll add that tonight. as well need to add more to my testing routine 🫢🙈

Thanks , good to hear all is well, looks like the install.log is happy as well. I might have over engineered the solution and just needed to peg the version so it doesnt try to compile a new one.

@GTench, Putting this here, so that if others are interested they can check their install.log (if you don't know what I mean and don't have any issues, don't worry about it) I did notice something in your install.log where the aiohttp was failing to pip install. Seems it's a thing in freebsd in certain cases, but as its part of the "optional" bits of aiohttp, it seems to not affecting the running plugin. I do not know why it's good on mine and not on others. Anyway, based on my research, I made some changes to my requirements.txt and added a precompiled version in vendor-wheels directory. Would you mind installing from the non-production store into a separate plugin slot. You don't need to add any configuration. Let it go for about 5 minutes and pull the logs from the plugin log tab. The install.log will have what I want. Hoping this solves that issues & doesn't create any others. You can delete the plugin after that. Thanks!

Well I don’t disagree, sometimes a scene just seems to work. Also the nice thing in a scene you can often set it to try more than once right in the command setting.

@Guy Lavoie, I completely get it, it’s my wife that doesn’t ;). (Actually she is very gracious). I do similar things in my progs with the “bump” times. So take a look at my description of the onDelay, it can simplify the moving from one scene to another. Different paradigm but we can get to the result and simplify too. So in my example I go from a high level at my bar to the normal level after a period of time. Well if you wanted to “bump” the time you can either change the delay value and bump the timer or have a second timer. This would give you your initial and bump times. I guess my point is this is not just for non-programmers, I wrote it (like you did for timers) to clean up the non-value added countdown programs & leverage scenes. I am interested if there are features that would enable what you are doing more. good discussion, thanks.