oberkc

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.

Just reacted four times. No problems. Weird.

Never seen such a thing, but I dont often react to posts.

I also take hope in the fact that the ISY is not the only user of the PLM. I understand that those PC (or other computer)-based automation solutions (such as homeseer, openHAB, houselinc, things like that) also use the PLM. I cannot help but suspect that killing of the PLM will kill insteon and also suspect Smarthome recognizes the possibility.

@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...

Hopefully, somebody will confirm. It also may depend on the version of PLM that you have. In general, I would watch for a steady, dim, glow from the LED. I think that my LED is white, but I wonder if some versions can glow different colors (such as green).

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.

So...these are thing I don't often deal with, if ever. This is also by memory. Having given these disclaimers.... Check the cable between ISY and PLM and that the PLM is plugged into an outlet. Assuming this checks out, I recall a setting somewhere that addresses PLM status. Hopefully you can find this and that there is something there to try reconnecting. Given the history of th PLM, it is not hard to believe that failure is a possible cause. Does the PLM show any viible ign of life, such as LED indications? I don't believe the PLM is required for a backup.

Good that you have the desktop icon. This suggestes that you are running v4.6.2. yes, I would plug it into another router (preferrably, one that is working), along with your computer, and try that desktop icon again.

Do you know what version of software is running on the ISY? It seems that every version has its own finder app. If you could match that up, that might be all you need. Do you know how to get into router settings? If so, I expect you could identify the IP address of the ISY-994. Does the ISY seem to be running? Even without a network connection, I expect that programs would still be operational.

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.