oberkc

I did not quite follow this either, but I did not try too hard. First, there is another way to add devices to scenes: right-click>>>add to scene. Regardless of which way you create and add device to scenes, I thought it resulted in a dialog box that gave you the opportunity to decide whether to add as a controller or responder. To do what you describe, I would think that you would want to create a scene with all switches/remotes as controller. Then, for those switches that you want to use fast-on as a trigger to suspend motion response, each would need to be an individual condition in the program, as you say.

When you "do" a fast on??? What does that mean? The answer to your question will depend on whether you want to respond to manual action (fast double-tap) or whether you want to respond to a device being turned "fast on" indirectly, such as being part of a scene or program response. "If control A is Fast On" will only trigger a program when A is acted upon manually. If you want the same thing to happen when B and C are acted upon manually, you would need to include those switches as well.

I have not used Home Assistant as a comparison, but I can say that I have never found the programming of the ISY to be a limiting factor. While I accept that some find it counter-intuitive, and I accept the possibility that other approaches might take less time to learn, I have simply never ran into a scenario where the programing limited my ability to do what I wanted. I would be quite surprised if there were things I could do on other platforms that could not be replicated on the ISY.

It seems to me that the definition for "scene" has evolved over the years, and has always depended on perspective. IIRC, "scenes" were originally defined within insteon as a controller with one or more responders. The ISY defined scenes that could include multiple controllers, including the PLM. In effect, ISY scenes could include multiple insteon scenes. I don't notice insteon using the "scene" term as much in more recent years. Perhaps this has caused some confusion?

I am not sure, but I would not be surprised if the responder settings are stored exclusively in the responder device. If so, you are not making any changes to the link records in the motion sensor.

I think this is exactly what is happening...and this is by design. Consider the "scene" as a controller (the ISY/PLM). Changing the scene only changes responses to when the scene is evoked by the ISY. It has no effect on scene responders to other scene controllers (such as a motion sensor or a switch). I don't know about "another" step. Rather, it might be a "different" step. Unfortunately, I don't know the larger context about what you are trying to do and how..how you are allocating tasks to scenes versus programs. Assuming that part of what you are trying to do is, via program, to configure the vanity lights turn to different levels in response to motion sensors scene command, you would need a statement such as: In Scene '1 - First Floor / Guest Bathroom / Guest Bathroom sensor' Set '1 - First Floor / Guest Bathroom / Guest Bathroom Overhead' 20% (On Level). If you want the reduced responder levels also to apply to the "overhead" controller, you would also need a similar program statement for the overhead device (I assume it is a switch). The generic form of this program statement can be thought of as: in scene 'scene controller device" set "scene responder device" XX% (on level).

That is a pretty advanced program technique, and it will likely be little more than speculation without seeing your programs and scenes, as well as knowing what, and how many of each, devices are involved. Given the time of the referenced post, it was most likely done on v4 software. Is this what you are running, or are you on the newer, v5 software? V5 software changes much in this area. regardless, it is pretty common for folks to fail to grasp the nuances of scene controller/responder relationships and how insteon can define different response levels for each controller. Adding the ISY into the mix does not make this any easier. My best seculation is that it is here where your troubles are rooted.

Yes, my mistake. I should have suggested this approach: if nothing then run open program (if path) <<< change else run close program (if path) <<< change

I suspect that when programs are run by alexa, it treats the program as a device to turn ON or OFF and runs THEN or ELSE causes, respectively. I assume when you command the programs to OPEN the door, it is running the THEN path. There may not be a way to run the IF clause from an alexa routine. You may need an intermediary program such as: if nothing then run open program (then path) else run close program (then path) Regarding the state of programs, this represents the last run path, no matter how long ago. If it last ran ELSE, it would show as FALSE. If it last ran THEN, it would show as true.

I don't know anything about 30-second rules or inputs to alexa being sensitive or broken connections (yet, but hopefully never). All I can say is that I wanted alexa to announce when doors were being opened and I used the appropriate door sensors as a trigger for verbal announcements. Works like a champ. Has not broken anything yet. And....no variables (for those allergic to them). I do not announce when doors are closed...the alexa trigger on the routine is sufficient enough to limit those occurrences. I trigger the routine only when the sensor is "open". I would have to create a second routine to announce when doors are closed.

The device added to alexa must not necessarily be a variable. I trigger alexa voice routines from those things that I add to alexa as a alexa category "device/sensor". In my case, I have added several of the insteon door sensors and IOLinc sensors to alexa and use those to trigger voice announcements. I don't know the limits of the devices that can be added as "sensors", however.

I am on the other side. Four fanlincs since they came out. One is in unconditioned space (screen room) that can get anywhere between -15 to +100F. No failures so far.

My experience is that zwave devices can be added to scenes, just like insteon. Having said that, zwave devices are better scene responders than they are scene controllers. In my few scenes with zwave controllers, the insteon devices do not respond. Also, I have had no luck using zwave devices to trigger “control” conditions in a program.

Also, check out para 8.5 of the wiki on portal integration https://wiki.universal-devices.com/index.php?title=ISY_Portal_Amazon_Echo_Integration_V3#Programs

Check status of IOLinc sensor. Some versions come with magnetic switch where ON=CLOSED and OFF=OPEN. Others can be reversed. Make sure you confirm which is the type you have and whether it matches your expectations. Another possibility is that Alexa "POWER ON" routines may automatically route to the THEN path of the program, where POWER OFF routines route to the ELSE path of the program. I don't recall if there is a way to call the program conditions directly from alexa. If not, you may have to create an intermediate program to call from alexa, such as: if nothing then run garage door open alexa (if path) <<<< will run when you call this program "power on" else run garage door close alexa (if path) <<<<< will run when you call this program "power off" I am not sure how @slimypizza got around this. Perhaps he knows an alexa trick that I am not remembering or never knew.

and yes

Regarding the programs, I have never knowingly run into a problem that I have associated with running simultaneous programs. On the other hand, I have come to suspect that the signal collision avoidance routines built into insteon are not as effective as I would have hoped. So...while the programs may run fine, if you have a lot of insteon commands blasting out at a given time, it seems that some can get lost or missed. Wait periods in programs can help with this problem, but they ca also introduce some unexpected problems if the program condition changes during a wait.

I suspect that having the IOLinc in Alexa, through the portal, will work, but that you may be unhappy with the commands and responses. I don't know that Alexa will automatically understand "open" or "close" commands, nor automatically recognize whether the door is already open or closed and conditionally respond (what happens when you tell alexa to "close" a door when the door is already closed.) Were this me, and if I wanted to be able to control a garage door via alexa (I don't), I would create two programs, both disabled. Functionally, the would look something like: if status garage door is open then close door if status Garage door is closed then open door I would add these two programs to alexa, then create two alexa routines, one routine for opening the door and another routine for closing the door. The routine would call the IF condition of the respective program.

I see nothing that mentions surge protection or other active electronics. I use several like that. Looks good to me.

Yes, a bit of overthinking here in my estimation. Ironically, it seems that it is often those with many years of programming experience that have trouble. It seems to me that many come in with assumptions about how the ISY works, based on experience with other operating systems and languages and, when the assumptions fail to hold up, confusion reigns.

Did not know that.

agreed.

Think of “next day” being relative to start time. Alternatively, consider the logic without “next day”...from 10:00pm to sunrise...would that suggest a start time AFTER the end time? remember, too, that there is a day-of-week aspect to this condition. Is not the full condition more like: on monday, from 10:00pm to sunrise (next day) Besides....it is less important what you believe and more important what the ISY believes. Even if you find it grammatically ambiguous, the ISY does not.

No need to do this. I don't believe there is any ambiguity. "Between 10pm and sunrise (next day)" is unambiguous. I do not see where lilyoyo1 claims it will "run else". Of course, your original conceptual program was pretty simple, but you have not posted the actual program. Furthermore, you later mentioned motion sensors which were not part of the original post. As programs include additional conditions, it can oftentimes be harder to figure out all the different triggers and logical conclusions.

There is a condition where an insteon device condition "responding is true/false" might be useful for such a program. I have not used it before, so I can only theorize. I am unsure how the ISY-994 would know whether a device is responding, but I assume that it would depend upon the frequency with which something has tried to communicate with a given device. There is also a "query" option for insteon devices. Perhaps a program running at some period of time (every hour, for example) you could query a device, hoping that frequent queries would quickly identify "non responding" devices. Then you would create a program to send a message based upon a condition that a device is non-responding.