oberkc

I was in the same situation a few months ago. Had the new zwave card. Desires to have the latest versions of everything. I went ahead and upgraded. As near as I could tell, everthing went well. Backups seemed to restore. Zwave software version reflected newer version. Programs and scenes appeared to be in order. What I quickly observed, however, was that most of my zwave devices no longer had the same ability as before. While I could control them from the ISY, they no longer updated thier status as before. No program that I had based upon status of zwave swithes worked. (Programs based upon zwave motion sensors appeared to work fine.) I could exclude and include devices. New nodes showed up where there were none before. No communication errors noted. Everthing appeared, at least to me, as if it were working normally. Still, what worked before the upgrade (specifically, program triggers) did not work as before. I do not have a lot of zwave devices (one schlage lock, a handful of motion sensors, five switches, and about as many outlets) so I ended up excluding, factory resetting, and re-including some of them. I also replaced one of the zwave switches with a newer one. At this point, everything is working as before. After that, I replaced a failing insteon switch with a zwave version. Suddenly, perhaps coincidentally, an existing zwave device started failing communication with the ISY. I had to remove it from the box to move closer to the ISY, then excluded/included it. It now works as before. Summary: if you don’t have a lot of zwave devices and are willing to risk the possibility of having to exclude/include,go ahead. On the other hand, I did not see any immediate benefit to the upgrade, do I would advise to delay if you are heavily into zwave or don’t want to to risk spending several hours on the transition.

I agree with the others...this is NOT the best approach. Linking multiple insteon devices (aka scenes) is a powerful feature. Want to control and outlet with a switch? Use a scene. Want to have a bunch of devices come on at night? Put all the devices in a scene and use a program to turn on the scene. In other words, exactly like simplex tech and goose66 said. The documents of which I am aware are the wiki, the user manual, and the cookbook. The "gotchas" that come to mind are related to program triggers, the difference between "status" and "control", and program interruptions when "wait" and "repeat" statement are present. Also a topic of much discussion...motion sensors: programs or scenes? General things to consider: - naming convention for devices - organizing devices by room or function (folders) - folders for programs that are seasonal or otherwise limited to certain times Take the time to develop an understanding of scenes, ON levels, controllers, responders. Take the time to play around with programs and understand what triggers a program to run and when a program condition is true or false (logic conditions, AND, OR, IS NOT, IS...). Start small. Take the time to decide WHAT you want to do before you start doing it. I have not seen anything written that allows one to skip the steps of practice and experimentation.

Understand, too, that this concept (controllers being responders, by definition) is unique to the ISY. In a pure insteon sense, one would have to create multiple scenes (or links) to define multiple controller/responder relationships.

@TheHarbinger I would put a slightly different spin on things. The first question you should answer is how you envision the human interraction between you and your system that “away” mode has begun or ended. (the programming question can really only be addressed one you establish this interraction method.). Assuming you are interracting via Insteon devices (certainly there are other options) you must decide which...switch?... Keypad?... motion sensor? Door sensor? ISY admin panel? Combination? Other? Spend some time deciding how YOU want to initiate this mode. After that we can talk about programs, program triggers, variables, node servers, etc...

I could be missing something, or misunderstanding the explanation from blueman2, but I perceived the design is NOT necessarily to set everything to 0.1/100, but (rather) to set everything to the scene parameters, whatever they may be. It just so happened, perhaps(?), that your scene levels were 0.1/100 when you added the new controllers. This design choice, if I understand it, seems like a viable decision to me.

I do mine only with scenes...no programs. Button is ON when door is open and OFF when door is closed. General concept: - sensor is wired to be ON when door is open - configure button to send only ON commands - create scene with button as controller and relay as responder - create scene with sensor as controller and button as reponder - configure IOLinc as momentary, responding to ON commands. hopefully, I have not forgotten something. There is a very good set of instructions in the wiki.

IIRC, alexa routines can be triggered by ISY if a "sensor" or a variable. I suppose you could try, as suggested, adding the switch to alexa integrations as a sensor. Alternatively, you could create a program, triggered by the switch, that sets a variable value and use that variable to trigger an alexa routine.

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.