oberkc

I understand. There has been an ongoing debate about that around here, and also about the security risks associated with having an automation system having this ability. I assume yours has the safety interlocks built in, so it should not close on a child or pet. Since you seemed concerned mostly with critters (probably my biggest risk as well), it seemed you were well suited to an automatic solution. Thanks for satisfying my curiosity. Hopefully, the interlocks will also come into play here. They certainly work well for my doggies.

That would certainly bother me. Sounds like you have succeeded. In case it is not obvious, it will send you two notifications, regardless of whether you close the door after the first message. Personally, I just have the ISY close the garage door (as I thought you were originally trying to do).

This program will be triggered only once per day. It will be triggered at 10:00. It will be triggered regardless of value of variable. Once triggered, whether it runs true or false will be based upon both conditions. Since it was triggered at 10:00, that part of the condition is, obviously, true. Whether or not the variable condition is true will depend upon whether it is a "1" (true) or anything else (false). Both conditions must be true (logical AND) for your THEN clause to run. Otherwise, your ELSE clause will run. Why do you have two notifications, separated by a minute?

Of course, with the elimination of the variable, this program will trigger every time the door changes state, regardless of time. Each time it is triggered by the sensor changing state, it will run false and send you a notification. Is this what you want? This is one advantage a variable may offer in your case. Integer type variables do not trigger programs (which was the reason a couple of people suggested using them here). I am assuming you want this program only to run once per day, at 10:00, correct?

Kentinada, in my mind your program is pretty simple and should work. At 1000, it will trigger and, depending on value of variable, run THEN or run ELSE. I see no problem with this particular program. The only thing that I might be cocnerned about is if the door was open, and your program closes it at 10:00, the variable state chanes in a few seconds, retriggering the program. For this reason, please ensure your variable is the type “integer”. if you are getting unexpected results, try narrowing down your problem. Right-click on your program and choose to run the else path. Did you get your reminder? The answer to this question could point you in a particular direction. Have you confirmed that an open door results with a variable=1? Have you confirmed that a closed door results in a different value? Do you know how to confirm whether the program ran at 10:00, or whenever it last ran? Do you know how to determine whether it ran TRUE or FALSE? If so, check that out next time the clock strikes 10. is it possible that your program is disabled, or in a folder that is disabled?

Don't forget credit to palaymans "guess" in the second post.

For what it is worth, I expect both programs to honor the time condition ONLY in conjunction with the last OR condition. The first two conditions should without any time constraint. If either of the first two conditions are true, in either of the two programs, your program will run the THEN clause. If you find yours doing anything different than this, I would be extremely surprised. This is standard Boolean logic. Parentheses around the cluster of OR conditions is the solution.

Maybe. In fairness, it is perfectly safe and, until the advent of smart switches, perfectly functional.

No, it would not.

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.