hart2hart

@[mention= rel=]sjenkins[/mention] has done excellent work with the virtual plugin. The only thing I’d add is if you are on eISY V6.0.0 it’s got an issue and may show the new device 3 times. You can fix it by simply rebooting the eISY. Edit: eISY has the issue not virtual

I reported to UD and response was it’s a known issue and will be fixed in the next release. If you reboot eISY, the extra devices go away.

[mention=16016]bmercier[/mention] I was researching another issue and located a couple year old post that suggested an eISY reboot. I rebooted and it fixed that issue, so I looked to see if this was resolved and it damn sure was!

@bmercier The shades with the plugin have been working great. I was doing a little adjustment after installing v6.0.0 and noticed something odd. When I added my Middle honeycomb shade to an eISY managed scene it shows up three times when opening it later. See attached images as it shows 3 times in tree but once in the scene device list . I deleted and added the scene and the device in the scene a few times with same results. Other identical scenes for Right and Left shades are fine. Also, I had added two Lutron scenes that grouped my 3 shades a few weeks ago. I hadn't needed them exposed immediately on eISY so I had not discovered them via plugin. When v6.0.0 was installed and I assume querying and appears doing a discovery (took 45-50 minutes for that stage to complete) the two Lutron scenes were added at top of device. One of them was as expected added once and the other was there three times (same as issue above). I decided to perform same function with eISY scenes, so I have since deleted them from Lutron app and they are gone from eISY Not that its important here, but I did have to fight Alexa to get fully rid of them -- not sure its complete yet.

@@Guy Lavoie thanks

Just completed the upgrade. I've got many REST commands with the username and password coded into them. First off, they still appear to work unchanged with old AC username and password. However, I want to understand if they should be updated to use the portal username and password for future.

Took the plunge this afternoon and upgraded. The AC was back in about 10 minutes. The query for all devices step took about 45-50 minutes. Looking good so far. Great process and update UDI team!

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

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.

Scenes used to be defined with each device included in the scene showed up on the screen page with their various Insteon setting like On-Level, Ramp Rate, etc. With one of the major releases (V5?), the concept of Groups was introduced that gave much greater capability including mixing device technology types. I have been using it and have been fine but realized while researching another problem that, I had survived as opposed to fully understanding how to manipulate eISY to define them to fullest potential with the on-screen hierarchy. Defining a scene or group means creating the scene and then adding devices as: Controllers Responders Selecting the Scene/Group in the AC left side of screen tree defines how the scene will be executed if a scene command is sent from AC, program, UDM, or REST command While the Scene/Group is still selected on left side of screen tree, you can select individual devices under the right side of screen Managed Scene definition. Whatever capabilities the selected device has will be shown at the bottom of the right side of screen. For example, in Insteon: Responders might have On Level and Ramp rate Controllers show info related to controlling via managed scene? Selecting a device included in a scene in the AC left side of screen tree defines either how the scene will be executed by a specific controller or what appears to be just the devices definition (same shown if you just selected the device in the left side of screen tree) if responder only. I am guessing this is where the term Group started showing up. Controllers selected on left side screen tree displays the devices in the group on right side of screen which you can then select Responders show the device settings at the bottom of right side of the screen that will be utilized on that device if the scene is executed by the controller device selected on left side of screen tree. This means that a screen can do multiple things based on where it is executed like the AC or one of several controllers. Prior to groups/scenes being defined this way, I think I would have defined multiple scenes with a controller being a controller in one scene and responders in other scenes. I am not sure or clear about this part If Insteon is selected at bottom right of screen is when you can define scene attributes that are specific to that controller such as On Level, Ramp Rate, and Retries If Default is selected for the responder device, it will use whatever was defined when selecting the scene on left side of screen tree for that device. In other words, it inherits the managed scene definition Is the above accurate and/or is there a better way to describe it? The types on bottom right of screen are typically values listed below. Documentation that I found did not define these very clearly so I feel like I am just surviving here. Insteon Command Default Ignore Native was defined in one of the documentation files but seemed to be geared toward ZWave. I have never seen it on my eISY and IO have a few mixed Zwave and Insteon scenes. Was it retired? Please help by refining my definitions / understanding and/or providing better sources of documentation. Most docs I found defined scenes/groups structurally and not how to effect it in the AC UI.

@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

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

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

Would it be reasonable to select a variable on the offDelay device screen as offDelay time instead of only doing that through a program?

I tend to agree. I understood what you had had written in readme after I used it in discovery mode.

I tried the simple form of the conf and got similar issue. Switched to using json form of config and it worked. @sjenkins , I declared it this way with colon and the colon was stripped in eISY created device but doesn't happen for standard dimmer and switch types. {"id": "98", "type": "ondelay", "name": "Office:Closet Timer On"}

Thanks. In this case, Advanced / PLM Communications is not shown for the OffDelay virtual device, and it says "This device does not support PLM communication settings for the physical device in the scene. Am I missing something deeper / simple? As I recall, you can only set scene retries by device in a scene and I can't seem to do it for either device in this scene.

@sjenkins I like the functionality a lot. When I do same with programs controlling something like an electrical motor fan, I typically put Turn off Wait 1-2 seconds Turn off Wait 1-2 seconds Turn off This ensures the switch and device being controlled will almost certainly be turned off even if electrical noise from fan motor occasionally gets through. Does that make any sense here?

I typed that and then went out fur a run. Got about 2 miles from home when answer came to me. Define it like all my other virtual devices and the delay will show up on the created device. Oh well a dense moment passed. Thanks , Paul

@sjenkins great addition! I’m not clear how to configure and use. I want to use an offDelay switch so I’d create the virtual switch and add it to a scene with water closet physical fan switch. When the physical fan switch in the bathroom is turned on that would start timer to turn it off. Is that right? If that’s right, how would I define the virtual offDelay switch with a 15 minute delay to turn it off using json notation?

Thank you @sjenkins Second reboot of ISY and it’s now showing 14. I’ll be running 5.9.1 for a bit longer.

Just installed update! I saw such a minor issue but wanted you to know in case it’s indicative of something more severe in that number of nodes is showing 0 and there are actually 14.

Thanks for making Virtual plugin so much better! I’ll hopefully remember to install and test out tonight.

I installed the NVME drive and ran UD script to switch processing over to it. However, I’m not recalling it if fully boots from the drive or if some or all of OS still resides on default drive. I’ve opened a tuck and asked that question.