oberkc

There are certainly three-wire cables involved in any 3-way configuration, but a switch loop does not have a neutral present. These types of original circuits can present some challenges for insteon retrofit. This forum is full of examples over the years of this type of problem.

Unless it was a switch loop, without any neutral present in the switch boxes. In such a case, certainly a micro module could be employed.

I don't want to think too hard tonight, but I doubt that this would be possible. Why do you think one switch has a neutral, but the other does not? If there is a neutral present at one switch location, it seems to me very likely that you could repurpose some of the wiring and use standard insteon switches here. Feel free to describe the wiring in both boxes, including cable bundles, conductors, colors, and how they currently hook up to switches.

Great. So the problem was NOT with the reliability of scenes, but the possibility that they were not configured correctly. I stand corrected.

I was responding to your post stating that you had trouble with scenes working, yet individual devices worked fine. This, to me, is a potential indicator of marginal communications. If true, then I get concerned that this could get worse as existing electronics age and as new electronics are added.

Possibly true. I hope that it stays true. Unfortunately, my fear would be that the reliability of the system will not be as consistent as the customer expects. Communication problems rarely get better, often get worse, and manifest themselves in unexpected ways. What will happen as the customer starts plugging new things in, like phone chargers, new lights, other electronic gadgets? In an environment with marginal communications, things can stop working suddenly. Hopefully, you won't get a call-back and hopefully the customer will be happy and a customer for a long time.

I think you are making this too complicated and getting hung up on logs and event viewers and stuff. I admire your interest in understanding these logs, but not at the expense of solving your problem. You need to break this problem into smaller parts, and fix the parts that are broken. Controlling individual devices tends to be more robust than controlling scenes. I understand that controlling individual devices includes responses and retries, whereas controlling scenes does not. The fact that individual devices respond does not make it necessarily true that scenes will respond equally reliably. This is indicative, in my mind, of a comms problem. This needs to be solved.

You need to narrow down the description of your problem. You ariginally seened cconcerned that scenes were not working. Later you introduce programs into the question. Is there a relationship between the programs and the faulty scenes? Are the faulty scenes used in the programs? Are you suggesting that the scenes worked fine when part of the program? It is unclear to me whether your scene is not working, a program is not triggering when you expect, a program is not running as expected. Lets focus on the problem that concerns you (orignially stated as devices in a scene not responding). How do you activate the scene when it does not respond as you expect?

It should work great. The only problem I see is if there are communication problems. If not, it'll work great. Make sure you use "status" for the button you choose.

Not sure what this means. Do you want run THEN (start) or ELSE (stop) in a program? Do you want to initiate a program path that has a wait state (or loop) that you want to later stop? Enable or disable programs as suggested by lilyoyo1? That is how I would do it I tend to pick a couple of the buttons in the scene as the canary. Keep in mind that (with all due respect to Mr Kohanin) I think you will need to use "status" rather than "control" in this case, just in case you use one of the scene buttons that is not specifically called out in your program. Of course, if your program condition includes ALL your buttons in the scene, "control" conditions could work: if ( control buttonA I s on or control buttonb is on or.....rest of buttons ) and ( control buttonA is not off control buttonB is not off or....rest of buttons ) then start program (whatever that means) else stop program (whatever that means)

I am not sure one can make this conclusion. Direct actions on an insteon device can be, I understand, more robust due to repeats and acknowledgements. I don't believe that these exist in scene commands.

The only downside that I would consider is the reliance on the cloud for setup and operation. So long that smartlabs stays in operation you are probably fine, but you need to ask yourself if that consideration is important. Of course, you could consider other options later, if anything happens to smatlabs.

You can safely assume all insteon switches are compatible. Many z-wave switches will be also, if you have the zwave version of the ISY. Cannot say regarding black switches.

If no light, use the on/off switch to control another fixture or light in the room. Lamps? Overhead?

Like kclenden, I took it the other way also. Made no sense to me either. Better to wire the fanlinc to constan power. Use the KPL on/off buttons NOT to control “power to the fan” (direct quote) but use these buttons (rather than pull chains) to control the light

Yes, I believe this is under “power” options. One can modify the power-on and power-off sequences to include additional commands.

I think jec6613 correctly diagnosed the problem. I don’t know that variables are the simple solution, however. What about modifying your original program: - disable it - remove the first condition (if ir006 is pressed) Then, add a second program such as: if if ir006 is pressed then run modified IR 06 program (if path)

I think this is good advice. The only downside to this is that, IIRC, many around here claim that the alarm is a GREAT repeater...a better repeater than other z-wave devices. Even better would be if you have a need or interest in an alarm. Given that I purchased the aeotec alarm, I went ahead and created a simple program to trigger it under certain conditions. It gives my wife some level of comfort when I am gone.

That has been my experience. I understand that z-wave is a mesh system also, thought I also understand it tends to established fixed routes as devices are added. In my case, the additional z-wave devices resulted in a better z-wave network. Another thing is that, apparently, some z-wave devices can use secure communication and some cannot. Also unlike insteon, z-wave repeaters need to be added to the ISY994. It seems many have recommended the Aeotec alarm as a good repeater. I have one, along with the Aeotec repeater, and am happy to recommend them also. Get a couple, install them first, the install the door lock. Sometimes it can be necessary to program the lock while near the ISY, then install it, but I suspect you will be able to make it work. One thing I suspect you will like about the z-wave locks is that, unlike the morninglinc, they report status. Now, when you unlock the door from the keypad or knob, the ISY will know it. Added bonus: you may find some z-wave devices you like that don't have counterparts in the insteon world. Now you will be ready to incorporate them into your house.

As far as I know, the morninglinc is the only insteon lock version available. The practical options remaining are, in my mind, zwave. Perhaps you could use a wifi lock such as a homekit or google lock, but most of those are deadbolts, I think, and would require some special network instructions or nodelincs or polyglot or one of those other systems I know little about. I don't know how far away is your lock from the ISY, but my guess is that the odds are pretty good you can make that work, with one of the z-wave range extenders. Whether or not there is one with knob/handle I don't know.

Check your other topic

Such a program never “checks” status. Instead, the program is triggered when status changes. If the door was always ON, the program would never run.

Do the instructions define a specific connection for line/load? Like you, I would have expected voltage only one place. Are both the same voltage? If you remove the light bulb, does the voltage go away on one conductor?

That is one option. I think harmony has codes for the he ISY also, but I assume that you would have to teach the ISY Oir somehow dowblaod those codes into the ISY. Some harmony remotes have dedicated "smart home" buttons. These buttons, I believe, work independently of an activity. Given this, I suspect it is best to load a dummy device that falls under the smart home category. Otherwise, harmony will only use that device as art of an activity.

The IR capability can be added to an existing ISY.