oberkc

I look forward to seeing whether this update solves the problems that I am having.

I don't know about most people, but I have posted more than a couple of times that my z-wave devices do not respond to "control" conditions, as well as opened a ticket with UDI about a z-wave device and made such a point. If this response was ever given, I have completely missed it. I consider myself mostly unknowledgeable on things Z-wave, including nodes, associations, groups, and whatever else applies. I have, simply, treated z-wave devices as I would have insteon and been less than fully satisfied with the results. Along with lack of control conditions, neither could I successfully use them as a scene controller. FYI...I followed your solution and, yes, I seem now to be able to use a z-wave device as part of a control condition in a program. I am still investigating whether I can use it as a scene controller. Edit update...So, the newly-added custom button press node sorta acts as a scene controller. I added it to a scene that includes a micro-module and a keypad button. The micro module responds to the z-wave node command, but the keypad button does not. Interestingly, the node does not act as a scene responder, so I must also keep the primary z-wave node/device in the scene, as well. Still not quite right, in my view.

Unless the program has changed, and assuming that it worked before, the only things I can imagine are: - time (or sunset location) on ISY has gotten out of sync - device failure - something unique to sunset that is now causing communication problems Yes, please post the program. Also, check the program status to see when it has last run, and whether it ran TRUE or FALSE. Was the last run time the most recent sunset? No, I would not expect comms problems to a single device to affect all other devices.

I have non-toggle off buttons that I turn on with a program. As far as I understand, the non-toggle mode is only applicable when physically pressed. Otherwise, such buttons can be controlled remotely as can any other button. I wonder if a longer wait would have worked.

And you came to understand that how? (I did not see this stated anywhere. Edit: never mind. I now see this.) This sounds correct to me. Like lilyoyo1, I would convert it back to 6-button and link the primary node to your lamplinc. I see nothing in your stated desires that makes me think this is not the optimum solution. I think non-toggle OFF mode has been eliminated from some of the newer keypads. Also, I am not sure that I am following that last sentence. Regardless, if you insist upon keeping it in eight-button mode for reasons that I am not fathoming, I do not believe you would require non-toggle-off mode. Buttons A, B, G, and H should all be in non-toggle-ON mode. The lamplinc response levels for buttons A and B would be whatever brightness constitutes ON. The response levels for buttons G and H would be zero. Also, you would need to determine why your programs are not working. I offered some suggestions and questions earlier, but you did not answer them.

I was wondering the same thing as lilyoyo1. To attempt to answer your question...I, too, am a little puzzled why this would not work. Are your keypad buttons in non-toggle mode? If this were me, I would attempt to isolate the problem. If you manually run the program (THEN and ELSE path) does the keypad respond as expected? If you toggle the buttons, does the ISY reflect the correct status for "master bedroom nightstand"? Is your program disabled?

Mine did not work until I performed a factory reset.

I had to move my lock close to the ISY to successfully exclude/include. I found, also, that the process assigned a new ZW-XX number to any device so excluded/included. In the case of my lock, a factory reset was also needed. If your ZW026 is the same ID as before, I suggest that your exclude/factory reset/include process was not entirely successful.

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.