oberkc

If 'breezeway light' is a scene, and turning on that scene activates only some of the devices in the scene, I would look and try a couple of things. - manually run (then path) the program. Does the problem persist? - manually turn on the scene. Does the problem persist? - check the ON levels for the devices in the scene. Are any set to zero? - consider the possibility of communication problems. I don't see a programmatic problem here if, in fact, "breezeway light" is a scene.

yes, which really limits the usefulness of these devices for me and those that live with me. I am not really interested in having to memorize and pronounce a bunch of exact phrases (turn on TV? Watch TV? Tell harmony to turn on TV? Watch Roku? Watch family room TV? ) and even less so are the others in the house. It is simply easier to push the remote button or to toggle a switch. Besides, they are cloud based, so I view them as secondary.

good luck with this. I have had mixed luck with Alexa recognizing devices. I suspect that there are reserved names and phrases that can cause ambiguity with alexa. Additionally, I have come to suspect confusion by alexa when I have devices with similar names or names having common words (living room TV versus Family room TV, for example). If you discover anything interesting, let me know.

lilyoyo is probably correct about Alexa forum. Having said that, my experience is that alexa can only control a single harmony hub per account. Do you have a single hub with multiple apple TV devices linked to it, or separate harmony hubs?

I am not sure what this means to "install" a trigger.

I am sure you have a better sense of all this than I. I admit that I don't understand the frequency that programs are checked, the impact of having 24 conditions versus a few, nor the load on the CPU of checking programs versus running programs. In a practical sense, I would actually be surprised if it was noticeable either way. I just thought about throwing out an idea for a completely different view on this problem for consideration.

I would prefer avoiding having programs that automatically run every 20 seconds unless I had a functional reason to justify it (which I do not). My temptation would be to keep it simple, even if a little inelegant. if time is 12am time is 1am or time it 2am or time is 3am etc.... or time is 11pm then do stuff

If you truly want some help, you will have to provide a little more detail.

I think he mentioned this, but this runs the risk of changing the light and thermostat settings of an already-occupied house...something he is trying to avoid, as would I.

I would describe the WF2IR and, I assume, the IP2IR more as a "learning" remote, whereas the hub I would describe as "programmable". So long that the Hub has the device you are trying to control in their library, great. (Perhaps it can "learn" as well, but I have no experience with that aspect of the hub). It has been a while since I have tried, but I believe there is also a way to sniff out the commands to then send from the ISY to the hub, but I do not recall this part of it being as slick as with the WF/IP2IR. The IP2IR can (and must, if you don't have known commands) learn your commands from the existing IR remotes. Furthermore, if I recall, the method for learning will give you the commands needed to plug into the ISY network module. It takes a bit of time and there was a small learning curve and experimentation for me, but not too bad. Of course you need the original remote control and the network module. The hub is probably larger and has a built-in blaster. I think the IP2IR (if like my WF2IR) has to have connected IR emitters.

Fair enough. For me, though, I automate things so that I don't have to manually go through the house and turn off lights. I guess, on the other hand, if the automation is viewed as backup to manual control then, yes, the harder-to-see and easier-to-forget switches are the most valuable automation candidates.

In my mind, the problem with the two-wire dimmer is concerns over how it would work with low-power loads (will they glow or flash) and how well it works with loads other than incandescent. I also understand that they communicate via RF only, and my experience so far is that this is not as robust (at least, with insteon). yes, an electrician may only charge $120, but he is just as likely to leave you with with a couple of holes that I have to fix or hire done for another $120. For me, at least, I find the cost (whether time or money) of a micro module to be less than the cost of running a wire. Besides...I dont know how it is where you live, but it takes almost as much effort getting an electrician to come than it takes to do it yourself.

In which case, I start to wonder if it is even worth automating. Regardless, it would be worth the expense, to me, to replace the dumb switch with insteon so that nothing is ever out of sync and up is always ON and down is always OFF.

I was wondering if that was the case. I would find that more obnoxious than flipping the switch up to turn the lights off (aka being out of sync).

But, if the switch is in the "OFF" position and something else (a program, a scene, etc) turns the light ON, would not your switch now be out of sync?

Well, if you are opposed (for whatever reason) to adding a device in the ceiling box, you are stuck with a limited selection of switches. With insteon, there is the "2-wire" switch, but I suspect it is rated only for incandescent loads. I am not sure how it would work with other types of loads.

If it were me and I wanted insteon (or z-wave or similar) at the switch location and all I had was a switch loop, I would go to the fixture box (where the switch loop is initiated) and repurpose the wires to the switch as hot and neutral. In the fixture box I would add a micro module, to which the load would be connected and by which the load would be controlled. At the switch box, I now have hot and neutral and I would install a standard insteon switch, capping off the red "load" wire. Once everything is installed, I would link the switch to the micro module. Done. No wires. No mess. No fuss.

I also suspect it could depend on whether the “device” you added, and are now trying to control, is an individual device or a scene (or an alexa group).

This would probably require some type of variaable. Without thinking too hard (it is a Sunday afterall) and without worrying too much about exact syntax, perhaps this could provide a useful starting point for you: if button is pressed then lock door wait a little bit query lock run check program check program (disabled) if door is unlocked and variable is less than some number then query lock increment variable Run this program again (if path) else run notification program notification program (disabled) if door is unlocked then reset variable send message else Reset variable

I would want to experiment around here, but I wonder if there is a place for a query action? An early conceptual approach could be something like: if button is pressed then llock door wait a couple of seconds query door run check program check program (disabled) if Door is unlocked then send notification

Usually, that forces one button within the group to be on, and all others off. Also known as “mutually exclusive”. I would not expect this to solve your problem. I guess I was wrong.

If the button light comes on when you press it, watch the admin panel from the ISY. Does the status of that button change as you toggle it from off to on? If so, I dont think you have a bad switch. I am still leaning towards comm issues given your belief that the scenes are properly configured.

Re-read my earlier post. Already answered. Anything is possible. I suppose the little switch behind the button could have failed.

I would probably remove them from the scene and delete the devices if you don’t use them, but I am doubtful that this is the source of your problems.

Which suggests to me that it is NOT a device failure. I would focus on - faulty scene definition - corrupted links - commnication problems