oberkc

This is accurate, but the trigger mechanism is slightly different. "Switched off" is triggered only by an "off" event (not by "on") and is triggered regardless of existing status, and is only triggered by someone "controlling" the actual device. "Status off" is triggered by, and only by, any change in status (off to on, on to off, dim to bright, etc...) and no matter how that change is accomplished, whether by direct control of the device, or in response to other forces such as responses to scene commands.

Unless one has ADD

One of the things I understand about the IoX and Insteon is that direct commands to devices (as opposed to scene commands) involve the command followed by some type of acknowledgement from the responding device. The command is repeated a few times if no acknowledgement is received. These types of commands tend to be more reliable, in my experience. Scene commands, on the other hand, do not have the acknowledgement and IoX simply assumes the responder device reacted accordingly. I find large scenes can be less reliable in response. I have devices that respond to queries and direct commands near 100% but respond to scene commands less reliably. I have a couple of devices at my house that are particularly prone to this problem. Communication problem? Yes. I have also found that replacing the suspect device (some of mine are probably starting to push 15 years old) usually solves the problem which makes me think that Insteon communication performance can fade over time without completely failing. Of course, the devices of the electrical system in my house have evolved over that same time and I am sure that the electrical environment (noise, attenuation) has evolved along with it. The only reason I bring this up is that I it is not uncommon at my house to find status mismatches between IoX and various devices but without showing "unable to communicate".

I think you will find that a single scene, with both as controllers, will work fine. Controllers are, by definition, also responders. Remotelincs, if I recall, have certain limitations due to being battery devices. I do not believe that they are constantly listening for signals (to save battery life) and may not respond to scene commands.

Are you trying to solve a particular problem or add a new capability?

I am considering trying this. I have had a tablet in the past, prior to UD Mobile. In fact, I already have a couple of tablets lined up for this. I think it would work very well for the switches, but I was hoping for a clock and camera feeds (have never gotten my cameras to work on UD Mobile.). Sometimes, I just don't know what I like until I try things.

That is a good summary. I would say that it is an echo device configured for wall mount and touch interface, specialized for home automation. The visual user interface seems to be the big difference. I have always wanted a touch screen interface for my home automation and thought this might be it. I would like something like an eight button keypad but touch screen based, that I can configure the labels and colors and icons. The main screen on the hub can also include some cameras and other stuff, but the jury is still out whether this is something I will like. It is programmed mostly through the Alexa mobile app, but widgets can be added and configured directly through the hub screen, itself. I am thinking that a tablet with UD mobile, pinned, might also work. I have a few around and may try it as well.

I already have the ability to open and close garage doors by Alexa voice commands, keypad buttons, UD mobile. I am attempting, however, to use an echo HUB and create a favorite that I can TOUCH to activate the doors and to simultaneously show status (basically trying to create a keypad button on the Alexa favorite screen). It is a little different than voice commands. Unfortunately, I am running into limitations with Alexa that is making this an interesting problem to solve. Also, unfortunately, I am fearing that I am not getting consistent response from the virtual switch to Alexa and Alexa seems to be missing some changes-of-state with the virtual switch.

I must admit that I have never had much use for setting a variable (a numerical representation of the switch status) to trigger a program when I already have the switch status (on/off) directly available that could be used without need to translate to a number. It seems like a lot of unneeded complication. Besides, I have not even stated my application. But since you ask, my interest is in having an Alexa favorite show the status of my garage doors (open/close or on/off) and, when I press the same Alexa favorite, it would trigger the door. I have a pretty good idea how to accomplish this, but was hoping to avoid unnecessary programs.

Thank you. I was looking for a simple answer to a simple question. I was hoping that there was a trick I was missing that would allow a virtual switch to be controller in a scene.

May I take this as your position that the virtual button cannot be a scene controller?

The way to do this with Insteon does not require a program. I cannot say about whether RatGDO would work the same. (Does RatGDO plug in have relay and sensor nodes?). With Insteon, create two scenes. One with the keypad button as controller and relay as responder. The second scene would have the sensor as controller and same keypad button as responder (set up so that the sensor is ON when the door is open). Configure the keypad button as non-toggle (on) mode. Configure the IOLinc to accept ON commands to trigger a momentary closure of the contact. Hopefully, RatGDO will work the same.

I am currently (may change) not using any programs. I am simply trying to use the virtual switch in a scene, as controller. I have tried controlling the virtual switch directly from the admin panel, and in response to an Alexa echo device. The virtual switch changes status, but the scene in which it is added as a controller device remains untriggered. I hope that there is some step that I am missing, but suspect this is not possible.

I assume that you have the light powered by a single insteon switch, and a second insteon switch that you want to control, and be controlled by, the first switch. Correct? Did you create a scene that included both switches, and both as controllers?

I have created a few virtual switches to experiment around, seeing if they can be part of a solution to a problem with my use of an echo hub. I wante to use a virtual switch as a scene controller, but scenes to not activate in response to a change in status of the virtual switch. Am I missing something or is this not possible?

No. There is nothing hiding in there. As others have pointed out, green is an indication that this program last ran as TRUE and will stay green until (if ever) it runs false. Did you program run FALSE at 4:01? If not, you should not expect it to be back to red.

I am not sure how authoritative this is, but I understand that some z-wave devices may not broadcast status. I understand that different companies implement the z-wave standard differently, with varying capabilities and commands. But some DO send status messages and, for those, you can use status as a trigger.

Yes, to some degree. Unfortunately, at my house, program "control" is not triggered by z-wave devices...only "status". And sometimes not even status. It seems to depend on the make and model of the z-wave device. I, therefore, do not use z-wave devices in places other than as scene responders. YMMV.

I have a couple and they work fine, though I still have trouble creating z-wave scenes and using z-wave as scene controllers through the ISY. If, however, all you need to do is turn the device on or off or use it as an ISY scene responder, they work great.

I have the same issue and wondered also whether this was an indicator of some problem, but did not feel like trying to investigate any further. It is nice to know that I am not alone.

Theoretically, both, but this depends on whether your Insteon devices include power line, wireless, or both. If you only have power line devices, it is possible that you may be having communication problems between the legs of your electrical system. Do you have any phase couplers from your X-10 system?

Clarification: As far as I know, X-10 capability is still fully resident in the EISY. The basic EISY software does not pre-populate X-10 devices. No linking is needed nor possible and X-10 devices would not be part of your device list. X-10 devices were not part of scenes and one could not create X-10 scenes. X-10 addresses were (and still are) simply used in programs. One could, for example, create a program such as (syntax not exact): if Sunset then send A1 on At one point, and even possibly still, one could purchase (small fee) an update to the EISY software which would allow one to give names to specific X-10 addresses and have those names show up in the device list and be used by programs. It made creating the programs a bit more intuitive and made managing your system a little easier, but did not really add anything to the core capability.

I would look for two things. First, did you save all your program changes? (go back and save changes.). Second, do any of your programs have references to obsolete devices or programs? (Open the programs in question and see if there is some type of error embedded in any of the clauses.)

firther clarification….whether or not such a program would or could be true would be dependent upon the logical operator (and? Or?) and also upon whether there are other conditions within the IF statement.

We get these problems every spring and fall, it seems like. It has always fixed itself for me and I just learn to accept this and not to get too excited when thing are not quite right the first day.