sjenkins

@bmercier Good enough for me. I will offer, if you have scraps of notes on hints or anything you want to puke out of your brain on the subject, to update the hints docs on the wiki and/or the github. Maybe a link from the developer docs. A while ago @Michel Kohanim asked me to do some docs based on my plugin docs. I failed him on that due to my non-use of vscode. Happy to help with this an let you do the more "high value add" stuff.

You mentioned having many Insteon temp and leak sensors. I had my house covered with them and have moved to YoLink for temp, leak, and water valve control. The LoRa protocol is the main reason and local aspects of leak detection (even with the non-local hub, because of the ability to link locally), are a real seller. In addition getting a read on the Insteon batter sensors was a bit hit and miss ; don't get me wrong loved them as an option, but have moved to YoLink for these kind of devices. Also, have moved to the local hub to satisfy my tinfoil hat. I keep Insteon for switches, tried one YoLink switch for a Florida house & would not use everywhere. Things you don't need instant data but want reliable are the sweet spot for these. YMMV but some thoughts with a > 10yr Insteon and few year YoLinker.

@bmercier , sorry to bug on this one, but as I am looking at my hints across my plugins. I have been using the github docs at: GitHubhints/hint.yaml at master · UniversalDevicesInc/hintsNode Server device node hints specification. Contribute to UniversalDevicesInc/hints development by creating an account on GitHub. but digging a bit I see in the wiki there is a less complete, but labelled 0.2 version: https://wiki.universal-devices.com/Node_Hints_Documentation They are a fair bit different in their specifications. Your 4,8,x,x suggestion would give me wildly different answers depending on which one I use. Is there a third place you are getting this from? I do not see anything in the developers docs which are linked from the main UDI site and eisy-ui.

Dydns works great, part of my plumbing for 15years.

Should be producing control events too. Test out with a scene or program, the button will trigger a program but not always a scene. Why you say? No idea. Feel free to post here any anomaly on a device. I am using them except temp and know they work in the field but maybe there is an edge case.

@bmercier thanks, I was using a different one; I’ll give this one a shot and we will test and report back here for documentation.

So one new device, onOnly, use case when you only want the DON signal, which is often used for motion sensors. Mostly valuable in scenes where you only want it to turn the scene on and never off. I am using it to turn on a light which is turned off by a timer, so it is triggered by a scene which control comes from a door sensor. This filters out the closing of the door. The rest of the updates are back office, part of the modernising of the code. Comments, tests, refactoring. Should make the code easier to maintain by me or someone else if I get hit by the Beer truck. So far my device adds are selfishly those I use. I have been careful not to break those which I don't use. These include the Temperature, Dimmer/Generic. Temperature seems pretty clunky in its present form, I'm open for improvements or for splitting the functionality. For example I know its being used to check upper / lower values. We could split that into a new device and add control limits which trigger DON / DOF, or do some kind of average over time. Or if you are real fancy, send to csv file which can be plucked by the ISY's web page. Just ideas, again, not in my current use case, just saying its not hard to make happen. This is one of the rare plugins which is not just an interface to external hardware, its more about language extension for the ISY. 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.25" """ 3.1.25 DONE add onOnly device DONE update generic project files DONE Controller comments, refactor checkParams DONE change hints for temperature devices DONE testing added

Plugin developer question. How do you tell ISY and thus Alexa what kind of device your node is. The hints do not seem to be respected but I may not be using the correct ones. Specifically I am trying to tell her that the node is a temperature / thermostat, based on a user request. Let me know if you have any breadcrumbs.

@tazman, Is the value a temperature or just a generic value? If we wrote a device from scratch, what else would it do (nor not)? ex. Would you have alarm limits? If it hit those limits would you have the node send a CMD? Like DON at hight limit, DOF at low. This would mean it could be used in a program or a scene. There are some interesting possibilities in this little platform.

Hi Guy, Not a dumb question at all. So the temp devices have a history before me but I did for a time make use of it ; I think some of the features are a bit depreciated. As you can see there is conversion of F to C or other way and as its called raw. The temp conversion is not as useful as the ISY has that built in now. The raw is really a divide by 10 which can be handled by precision. This is one of the devices I would like to know if there are people using it ; and if its meeting there needs or could be enhanced. So far in my rework of the code I have kept it static, even though there could be improvements. It can be useful if you want to move from or to variables, val or init, on a periodic basis and give a nice display of the temperature. I have had issues with Alexa and device types, not with this but with contactors versus switches versus lights. Can be very frustrating. I do know that if we want to change this I will need to reach out to the guys at UDI and ask how that is done. Not sure if the hints have something to do with this or its something they need to hardwire. I just checked the hints for the temperature devices & they were not set. I set it to a temperature device & pushed to the non-production Store the change, its V3.1.25 and has some other minor changes. You can try that out, I don't have high confidence but would be the easiest path. Let me know. edit: you can install the non-production on top of your production and all will be fine. Then go back later. Not all the plugins will do that pain free.

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