oberkc

Atholon, what you have here appears to me to be a switch loop. Box1Cable2 comes from fixture, I believe. White is supply, black is switched power back to the fixture. Unfortunately, you have no neutral at this box (at this time) which explains why none of your combinations worked. The RBW cable goes between your two switches, with red and black being the travelers and white being the switched power back to box 1 and, ultimately, to the fixture. There are two potential options here. One would be to use a micro module in the fixture box, linked to the two insteon switches. This would require the re-purposing of the various conductors (not too hard). The second option would be to steal neutral from box 2, but this assumes that there is a neutral AND (emphasis intended) that the other switch is powered by the SAME CIRCUIT BREAKER! If not powered by the same circuit breaker, you are likely limited to option 1.

Is it possible that you have a program triggered by the remote that is sending the x-10 command?

Just be aware. I am not sure that one should consider insteon, the ISY, the echo, and geofencing to be "security". While I would be comfortable having the ISY double-check my door locks, I would not rely on it as my primary method of ensuring doors are locked (still do this manually) when I leave the house. It is great for lighting (no big deal if it does not work on occasion) or other things unrelated to the security of the house. For locks...I am less certain.

Well, yes, I suppose you will have to tell the ISY you are home somehow. I agree it is a bit of a nuisance to announce it to alexa or to press a keypad button. Can you not think of another way? Open garage door? Open entry door? Geofence with your phone (the method I use)? Carrying the logic a bit further, I would consider it no less a nuisance to have to tell alexa (as it seems you are doing now) that you are leaving. For this reason, I have automated that task. I use phone location determine if house is unoccupied. With two people, I use the logic: if phone A is away from the house and phone B is away from the house then house is unoccupied. While I still have the manual methods (keypad button), I rarely employ it.

Well, I would create some way for ISY to track whether you are home or away. I use a keypad button (on = away). One could use a variable (I would use a state variable in this case). Once done, incorporate that condition in you programs. Change your alexa routine to switch the tracker status rather than turn off a scene directly. If I am away then set goodbye scene off if I am away and time is from sunset to sunrise (next day) then randomly turn on and off else turn lights off

There is no such thing as a scene "status" in the current definitions of insteon and the ISY-994, so there would be no scene condition available as a program condition. For the echo routine, could you not simply call a program such as: ---------------- if nothing then turn on goodbye scene wait 5 minutes lock door ----------------- For away status, I have used a couple of techniques. One way is to use a variable (1= home, 0 = away). The other way is using a device (keypad button in my case, on = away, off = home). Either of these methods yields a way to create a condition for program or folder: ---------------- if home variable = 0 and time is from sunset to sunrise (next day) then wait one hour (random) turn on some lights else turn off lights ------------------ Of course, these are all conceptual and I leave the details to you. If you have specific questions, I would be happy to answer. Hopefully, this will get your creative side pointed in the right direction.

The transformer is plug-in? (Inlinelinc is probably easier to connect to a hard-wired transformer)

Cannot see anything you are missing. Your dampers require power (on/off) only, correct?

I would expect typical setting for keypad button to be NON-TOGGLE ON, rather than off. I also expect that you will have to configure your relay to respond to ON commands. Momentary A should work, but changing that to ON rather than OFF. There is a tutorial on the wiki that gives a more thorough explanation.

The micro module can be used as a scene controller, which confirms that it broadcasts status. You could, with the ISY, either create a scene or a program triggered by the module. The module can also be used as a scene responder, or react to direct commands, confirming that you can control the level from the ISY. You will be happy with this purchase.

While I have not used the micromodule with a motion sensor, I think you will find the answer is YES to both questions.

I was not sure whether disabling the device would disable scenes. Apparently not. if important enough, you could remove the keypad-in-question as scene controller and, instead, trigger programs from the keypad buttons. Doing so would allow you then to disable the programs and, consequently, responses to button presses.

Barring a flaw in the ISY software, I see nothing in your program that would cause this behavior. A keypad button, when toggled off, will not come back on by itself, and I see nothing in this program that would do this. Does it appear to first turn off, then come back on? I would be looking at other possible causes. I remain curious if any of these two "different" keypad buttons are part of any scenes, and that they are, indeed, in toggle mode. I would also check to be sure that these buttons do not trigger other programs that have been forgotten. Press one of your two buttons, then look at the program log to see if programs have been triggered unexpectedly. Watch the ISY admin panel status of one of your two buttons when pressed. Does it turn off, then back on?

What are "Basement / Exercise / Exercise South.1" and 'Basement / Stairs / Bsmt Stairs Controller.1'? Are these also keypad buttons? Are they part of any scene? Are these possibly configured as non-toggle mode of some type? And...you claim that if you press one of them OFF, it does not turn OFF? I fear I am confused.

I don't believe that you can assume that the "run program 'calc temperature' (then path)" must complete before the variable is updated. A wait statement could work, but you may also try a third program: if time is 12am then run program calc temperature then path else nothing Add to the calc temperature program an action such as: "run third program (then path) Create a third program if nothing then $Variable = $Cur_Temp

Keep in mind that the "relay" part of the IOLinc does not report status (thus cannot be a scene controller). Compare this to the sensor, which DOES report status and CAN be a scene controller, but does not respond to commands. Given this, the status of the relay, as shown in the ISY admin panel, will be the last sent command, regardless of momentary/latching mode. If you last sent an ON command, the status will show ON until an OFF command is sent, even thought the relay turns itself off after 2 seconds. So, even though the relay shows ON, it may be off. Sending another ON command will toggle it again, given you have it properly set in momentary mode.

As near as I can tell, all looks good and proper. Based upon my experience, this should work. When in mobilinc, you choose the relay, itself, correct? You are NOT picking a scene, or another device by chance? Does the same thing happen when you select the relay from the ISY admin panel? Is it possible you have a program triggered by the sensor? Very strange. I am running out of ideas.

Does it behave this way if the space heater is unplugged? if you manually ran the query program, does the problem reveal itself?

In retrospect, I had it backwards. Momentary B responds to both. Momentary A responds to either (but not both). Do you have any other options checked? Specifically, do you have "relay follows input" selected? What is your momentary hold time? Mine is 2sec. Make sure it is not some extraordinary duration.

I have mine set to "momentary A" mode, responding to either (both) ON and OFF. If I send an ON signal, or an OFF signal, it is as if I toggled the factory remote. I use android mobilinc. Don't know if IOS is the same. From mobilinc, I choose the IOLinc relay, and press ON or OFF. It makes no difference in my case.

I've not experienced any problems with windows 10, using the Microsoft edge browser.

What is the problem with a program such as(?): --------------------- if control bathroom fan switch is turned on or control shower light is turned on then wait 20 min turn off bathroom fan switch else nothing --------------- such a program would only initiate (trigger) upon manual control of either switch. It would not respond to a morning program turning on the shower light.

I cannot help but suspect also that the dimmer outlet is a problem in this case. My approach, however, would be to temporarily unplug the cabinet lights and add a dimmable load and temporarily disable the program. Does the outletlinc stay on? If so, I would treat this as conclusive. While I would replace the dimmer outlet regardless, another factor: ramp rates and ON levels. Are they set to zero and full?

mikek, is the likelihood of primary and secondary programs becoming true simultaneously something that we need to worry about? (I assume not, based on your description.) It seems to me the simple approach is, conceptually:, adding a condition to the secondary program: if existing secondary conditions are true and primary program is false then run secondary actions else nothing Does the secondary program have any "wait" or "repeat" statements? If not, aborting the program has no meaning. If so, simply add an action in the primary program to halt the secondary program.

Depends on the factors that drive the prioritization. Only the operator can decide what those factors are. If the factors are those which can be tracked by the ISY (such as time, status of other devices, temperature, moisture, weather, etc...) then I don't see why programs could not be developed to reflect the operator's priorities.