oberkc

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.

If your only purpose is to turn lights off, I would have it in "non-toggle (off)" mode. Every press of the button sends an OFF command. But...this does not necessarily explain why it once worked and now does not, unless you think there is a possibility that this changed somehow.

I don't see anything in the programs that would cause the problem you describe. I am of the same mindset as apostolakisl...if pressing the keypad button does not turn it on/off, the button is either not in a correct toggle mode, or it has failed. I would take the steps he is recommending. Before that, confirm the button is in "toggle" mode or "non-toggle - off" mode. Additionally, open the event viewer and watch it while someone presses the keypad button. Does the event viewer register any commands? Does the keypad button flash when pressed?

This is consistent with my experience regarding how the app SHOWED the settings in response to a voice command. For me, however, I cannot control fan manually. Specifically, if I try to set the fan to medium, it starts at level 2, but reverts to level 1.

I am also more an Alexa user, but do have a single google home device. As near as I can tell, Google Home routines are triggered exclusively by voice or time. I do not see a trigger based upon a device or variable.

It appears to me that there are two sets of wire pairs coming from this device. One pair connects to the opener. The other wire pair connects to a dry-contact button. In essence, it looks like an additional wall remote where someone has already soldered leads to the buttons.

I notice that the second-generation insteon motion sensor has the option to power via usb. I did not know that battery motion sensors did not update status properly.

In addition to the response from lilyoy1, I would add that (unfortunately) not all z-wave devices have light sensors. At least, the couple that I purchased do not. Maybe others do. For the desire to trigger lights based at dusk, a couple of ideas come to mind. One, you could trigger them based upon time relative to sunset or, two, you could use an insteon motion sensor in a protected location to detect darkness (such as near a window). I have used insteon motion sensors outside for several years. I do, however, take care not to expose them directly to precipitation. I also have mostly first-generation sensors. I have experienced one failure of a motion sensor. I replaced it with a second-generation sensor. I absolutely recall that it was claimed to be rated for exterior use. I wonder what changed.

I take it from a lack of response that most, like me, cannot find a programmatic reason why your program would run true under the set of conditions described. I guess one must conclude that it is possible that something else is calling the program (then path?), that somehow the conditions from darksky are not correctly translating, or there is a bug in the ISY software. Is this program disabled? Is this program last run consistent with with the specified time at night when are calling it? When is your "$RainTodayAmountz" reset back to zero each day?

Well, I suspect this is why it has not happened. It takes more resources to complete and sustain than would be available from such a small community.