oberkc

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.

My process was, simply, trial and error. Start unplugging things. Start removing light bulbs. Turn off circuit breakers. After each, determine if comms got any better (scene tests, things that once failed now worked, etc...). I never found a magic troubleshooting method. My hot water heater is gas fuel, but uses electric for control system. I simply plugged it into a filterlinc. I had two access points (range extenders) originally installed about two feet (actual wire distance) from the panel. Over time, I added enough dual-band devices that I decided to remove the remove the access points to see if they mattered any more. They did not. On the other hand, others report good results with the passive phase coupler (signalinc?) which is mounted very near the panel in most cases. In my mind, near the panel makes sense, but I cannot say my experience either confirms or denies that theory.

I certainly did, and this forum has more than a couple of examples of others with similar experience. Ultimately, besides the basics (phase coupling, clean circuit for PLM), I needed to identify the big culprits causing this problem. For me, it was some home theater stuff, an on-demand hot water system, an electronic keyboard. There were probably other things, but filtering these helped a lot. Like stusviews said, one must positively identify the culprit(s). This is rarely easy.

Unfortunately, things are looking bad for your comms. Could it be a bad PLM (maybe)? Could you have something on your electrical system that is really fouling things up (maybe)? The trick, of course, is trying to narrow it down a bit. I remain curious about my unanswered questions: whether you have tried moving the PLM, and what other devices you have on your circuit including the PLM. Answers to these questions can provide some clues. I wish I had a nice, easy process for figuring this out. Unfortunately, all I know to do is create hypotheses based on others experience and test them out by unplugging, turning off circuit breakers, and moving things.

And you want these levels to be something other than defined by the scene? Create a second scene having the same devices, with other desired ON levels. Use a program to turn on the second scene. Regarding keypad button, that is one of those silly secret tricks: create a scene having only the KPL button. Turn that scene on or off.

There is a process described in the manual for most of the dual-band devices. Generally, it consists of rapidly pressing the "set" button of one device four times, and observing the response of the other dual-band devices. You should perform this test to be sure.

On what do you base your understanding that the programs quit working? Lights don't respond? Program log "last run" is incorrect? A failed PLM would not cause the programs not to execute, as far as I know. Is it possible that, somehow, your programs became disabled?

I do not suspect ISY. Maybe PLM, but I more suspect random comm problem. Have you confirmed communication between legs of your electrical system? What other electrical gadgets are on same circuit as PLM? Have you tried moving PLM to another circuit?

Stusviews approach of splitting the program into two is probably good. I am not convinced, however, that this has been the cause of your problems. The only thing I see that could interrupt your wait statement (short of being triggered by another program) is the sunrise condition. (Closing the door should not trigger or interrupt the program, (assuming ON is OPEN)). Definitely check the program logs. If, after five minutes, the lights remain on (and it is not sunrise) check the status of the program. Is it true or false? False would be an indication that your program was interrupted. True would suggest a comm problem.