oberkc

This makes me wonder how long will the PLM be available. I don't think there is any smarthome device or software that uses the PLM. Only third-party devices use the PLM, right? Ugh.

Agreed. Just responding to the question about whether there was any documentation on this. Exceptions also include "repeats", I understand.

Regarding controlling alexa via the harmony remote....I do not recall that this is possible. I believe one can add the harmony skill to alexa which enables one to control a hub via alexa, but I don’t recall the reverse (controlling alexa devices via the hub) being true. Hopefully, others can correct me if I remember incorrectly.

There is some discussion of this in the wiki. A quote: "What this means is that if a program's Then clause changes a condition which causes the program's overall condition to become false (or if the program's Else clause changes a condition which causes the program's overall condition to become true), the current atomic statement group will complete, and at that point execution will transfer from the Then clause (or the Else clause) to the Else clause (or the Then clause)."

I second the recommendation for the hue emulator (as opposed to the hue node server). I found it a little counterintuitive, but it works great once you get your head around the concept. I am also assuming you are using a harmony hub device. In my mind, the hue emulator simulates a hue hub (even if you already have an actual hue hub, which I do). The harmony remote hubs can find hue hubs and control them. In this case, you want to link the harmony remote to the hub known as the hue emulator, not the real hue hub (if you even have one.) Once linked, the harmony app can find the devices in the hue emulator. IIRC, ISY devices can be added to the hue emulator by assigning a "spoken" command to those devices you want to control. Once they are added to the hue emulator, add the hue skill to your harmony and try to find your hue emulator (harmony thinking it is finding an actual hue hub.) Once found, the devices added to the hue emulator (those having "spoken" assigned) will show up as devices that can be controlled via your harmony remote and assigned to your light or outlet buttons. I have likely omitted a few details, but the hue emulator is one of the node servers that I definitely like.

I have a scene just like CJVann is trying to create. KPL-B button is controller. Other devices responders. KPL button in "non-toggle (off)" mode. Pressing the button causes all the responders to turn off and the button light flashes a couple of times and turns off. Works great. @CJVann ... it sure sounds as if you are doing things like I did. The only thing coming to mind is that yours is likely a newer keypad and it seems to me that smarthome can sometimes make "feature" changes over time. Given the same results when manually configured, my best guess is that this is an issue with the keypad, itself. Were this me, I would remove and factory reset one of the switches. Once reset, manually configure the button. If the button stays on when toggled, I would conclude this to be a new feature or faulty device (however you look at things.) If it turns off when toggled, I would factory reset again, add back to the ISY, and configure the button via the admin panel. Does it still turn off when toggled? If so, add the scene members. Do things change? I would be breaking this into small steps to identify at what point the behavior deviates from the expected.

When you press the button (regardless of the LED backlight), does the ISY think it turns on or off? I wonder if you could configure this manually. I see instructions in the user manual.

To be honest, I am unsure about this. I doubt that it would hurt, but I suspect that it would not change anything in the context of a motion sensor.

With ISY, "controllers" are, by default, also "responders". I guess this is a residual from that definition, even though it make little sense for a motion sensor to be a scene responder. I do not believe there is a way to define something as only a controller. I also believe it does not matter here...motion sensors do not listen and are unaffected by controller action. I would ignore this.

There are a lot of folks around here that are good with variables. I recall that alexa is looking for a value of 1 = on, so it is pretty simple. I think I use this technique in a couple of places. You will pick it up quickly.

Well, lets start breaking this down into smaller pieces. Does the keypad button turn on/off when the door is open/closed? (close it via wired button or car remote for testing purposes.) If not, either the sensor is not changing state, the scene between sensor and relay is not set up correctly, or there is a comm problem. Does the LED light on the IOLinc turn on/off when the door is open/closed? Does the ISY recognize the change in state of the IOLinc sensor (the admin panel should show true state)? Double check the scene definition (sensor is CONTROLLER, button is responder, correct?) Start looking for clues. I assume that the "relay follows input" setting would cause the relay to close when the sensor is activated, and vice-versa. I do not think you want that option checked. you should want relay and sensor to operate independently.

DJBoombox... I don't do this regularly enough to know for sure, but I recall a possibility that alexa routines can only be triggered by ISY devices if they are sensors or variables. If you want to trigger a routine from an insteon switch, you may have to create a method in the ISY to toggle a variable when the switch is toggled. Then, trigger an alexa routine from the variable. FWIW, none of my switches or scenes show up as options in the "when this happens" dialog. Edit...I wonder if an insteon switch can be added to alexa as a sensor

I understand that you want the garage lights to come on only as you transition the radius boundary, and only during certain times of the day (sunset-to-sunrise). That was my assumption. Thanks. My suggested approach stands.

What LED is failing to light up? The one on the IOLinc? The one on the keypad button? Another? did you create two scenes? One would have the sensor as controller and button as responder. The second scene would have button as controller and relay as responder.

Assuming that I understand what it is that you are trying to accomplish, I would tackle this problem with two programs... first program: if occupied is true then run second program (if path) second program (should be disabled): if time is from sunrise to sunset (next day) then turn on garage lights wait 30 minutes turn off garage lights

My thoughts, also. So far, the phenomenon has been repeatable. It definitely does NOT seem random.

I do not claim to fully understand the relationship between insteon, z-wave, and the ISY-994. I have a scene with almost my entire interior devices that I use at the end of the day. Most are insteon, but more than a few are z-wave. I just added a new z-wave outlet the other day and added it to this scene. I noticed that, when I turn off this scene, the newly-added device is the last device to turn off, and it is likely 5-10 seconds before doing so. It makes me suspect that the ISY runs through each of the zwave devices within the scene and turns each off individually. This one is the last added, and is alphabetically the last zwave device in the list. I cannot help but wonder if re-ordering the devices somehow would result in response times being different for various devices.

I have not had luck with this approach. It may depend on the brand or version of switch one is using. It may also require the creation of a "button press node" and using that as a control condition. I am still not satisfied with z-wave switches as much as I am with Insteon. I also experience measurable delays in zwave devices. I just live with it. Most of my zwave responders are outlets, and they turn off at the end of the day. Delays do not bother me that much.

A couple of observations.... I don’t think the PLM (or lack thereof) will affect the ability to find and log into to ISY. you say that you are plugged directly into the comcast modem. Unfortunately, I have never used such a modem, but I cannot help but wonder if this modem is also a router. Do you knw?

I am not sure whether this will help (my guess is that you have something more sinister going on here), but I have almost universally had to run the alexa discovery process TWICE eac time I try to add new devices. I also think it might be worth mentioning...I recall a “refresh” button in the portal for alexa connectivity. It might be worth a try.

I think this confirms your problem. This program runs once per day, always runs TRUE, and never runs FALSE. The status of this program will always be true. Given this, your first program will always execute true when triggered at sunset.

Generally, I would say your understanding is correct. If it is sunset, sunrise, or anywhere in-between, the program should run true only if one (or more) of your lights are switched off. The one exception that catches my attention is your condition: "'timer bedtime shutdown' is true" Of course, you did not post that particular program, so I can only speculate at this point.... Keep in mind, a program being "true" is not the same thing as a program running. A program status will be true based upon the last action executed being true and remain true indefinitely or until it runs again and runs false. Look at the status of that program right now. Is it currently true? Have you ever seen a false status for that program? Feel free to post that program and let us confirm this as a potential problem (or not).

Yes, but you also said you use the "default" alerts. (Unfortunately, you have not shown the notification or program.) Rather than using the default text, why not create your own notification, using whatever language you desire? Trigger this notification from a "trouble" condition.

unfortunately, I don't use an elk. Were this me, however, I would be experimenting a bit. I would have two programs: one triggered by "trouble" and a second triggered by "violated". I would watch to see when each program is triggered and whether it is consistent with actual elk status. If so, then I would simply create specific notifications for each type of occurrence and be happy.

The syntax does not look familiar to me, but the first thing I would look at is the content of your notification called out in THEN action. What notification are you sending? As an aside, why are you waiting zero seconds in the ELSE action?