oberkc

So...it looks like it last ran today, and ran TRUE, as expected. Given this, I expect that it runs consistently every day at sunset. I would focus on comm problems. Do all the lights come on when it works? Do all the lights not come on when it does "not work", such as yesterday? Your PLM....is it located on a circuit with lots of other electronic devices? Computers? Printers? Routers? Chargers? Power supplies? UPS?

After adding the parentheses, you will likely need to move these to the proper location in the program.

You will probably need some parentheses in your condition. Add them ahead of the first line and after the third.

I am assuming you are using insteon devices. For the bathroom, it sounds as you want motion detection to turn on light automatically, and off again in 5 minutes, when walking into a dark room. Additionally, you want a manual control of the light to disable the motion response, but the lights to automatically turn off in an hour when manually turned on. (I will not address the risk of someone walking into a fully-lit bathroom at minute 59 and the reaction when the lights go out at minute 60). You could use scenes and MS settings for some of this, but I will address entirely from programs, assuming there are no scenes involved. Forgive the inexact wording of the program language: Program 1 if control motion sensor is on then turn on light wait five minutes turn off light Program 2 if control light switch is turn on And control light switch is not turned off then disable program 1 wait one hour turn off light swith enable program 1 else enable program 1 For the driveway program, you do not state what you want to happen, if anything, when driveway motion is triggered and it is not late at night, so I will assume nothing. . Program 1: if control driveway motion sensor is triggered and time is from late at night to not late at night then run program 2 (then path) program 2: if nothing then enable program3 wait thirty seconds disable program3 Program 3: if front door is triggered then turn on hallway light wait 2 minutes turn off hallway light

This might work as well if you rely exclusively on programs, but for those who use scenes extensively, it may fall a little short. I have used the "replace device" function only a couple of times, but it has seemed to work for me. I would rather use this than manually delete the old device from the existing scenes, and manually adding the new device to those same scenes.

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.