oberkc

Still hoping for answers to these questions. If it is an 8-button keypad, the load is controlled by button A. If the keypad powers the light, then the flashing light will cause a flashing button. Is this acceptable. If it is a six-button, then the ON and OFF buttons will alternate when flashing. Is this acceptable?

My gut feel is to do this with a single ISY scene, including all the devices from scene 1 and scene 2. Buttons A and B would both be controllers in the scene. For button A, define the appropriate ON levels for the scene-1 devices. For scene-2 devices (and button B), define ON levels as ZERO (off, whatever). For button B, define the ON levels for scene-1 devices (and button A) as zero. Define the ON levels for scene-2 devices as you want. This requires a program. There is no scene capability that would cause a light to flash. How do you want to initiate the flashing? Pressing button B? How do you want to terminate the flashing? Toggle button B to off? Press button A? Is your keypad six- or eight-button? Is your light bulb powered by this same keypad?

Indeed. Great idea.

Besides suspecting that this is not the response being sought ("only the connected load turns on"), part of the discussion clarified "without linking the big on button".

That would have to be a program. There is no way to create a scene that only responds to OFF commands. Add everything (not including the "all off button") into a scene, all as responders. Write a program: if all off button is switched off then turn off everything scene. else nothing

I did not check, but I wonder if that is the part of the manual that describes the different ways to configure the IOLinc absent a hub-type device...all manually. Additionally, the connections would matter also. What does an "open relay" even mean...If the N/O connection is made, then the N/C connection would be open, and vice-versa. I believe that most of those configuration settings (I am assuming they are talking about the various momentary modes here) can be done via ISY and don't need to be done manually.

Yes, but I wonder the same thing as BrianH...perhaps the IOLinc settings are such that the IOLinc turns off in response to a scene-ON command. Also, scene commands can be more susceptible to communication problems than direct commands from the amin panel. Everything looks correct to me still. If there is something obvious, we are both missing it. I assume that you have tried temporarily removing the COM and N/O connections and tied them together, just to confirm that the lights work, correct?

I do see from the instructions that there is also the status LED, along with the sensor LED. The status LED should apparently be bright when the relay is closed and dim when the relay is open. Is this happening?

LED is, IIRC, based on the sensor input. Do you have anything connected to the sensor input? If not, it surprises me that the LED is lit under any circumstances. I also see that the relay is rated at 5A and 30V. That seems within what you are trying to accomplish, but not with a lot of extra capacity. It looks to me as if you have it wired correctly. Latching mode sounds correct also. Are you trying to control the relay or the sensor from the admin panel? Be sure to control the relay. Still I am not confident with using NO or NC contacts. I believe the NO contact would be open when OFF, which sounds right. What happens when you turn the relay OFF? Were this me, I would start probing voltages at key locations. 12V into IOLinc? 12V out of IOLinc? I would also measure resistance between NO and comm terminals, when the relay is ON and OFF. One should be near infinite. The other should be near zero.

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.