rleidy

There's nothing like empirical data - thanks for the confirmation LeeG.

Let me take another stab at my question. I am describing a scenario where the OFF button press triggers a program. The purpose of the program is to check to see if the OFF was pressed while the device was already OFF and then perform some action. (something similar was discussed here recently: http://forum.universal-devices.com/topic/16937-bathroom-fan-with-timer/?do=findComment&comment=150121). So, suppose the switch is currently ON and I press OFF. The OFF press triggers the program. If it was the case that the device status had already been updated to OFF by the time the program executes, then the program condition would always be true and it would never be detect "switch is OFF and OFF is pressed". Since that condition *can* be detected, it seems to me that the update of the device status must lag the processing of the control event. So, when the switch is ON and I press OFF, the program must see the previous state (status of ON) after the first OFF press. If that is accurate, then what happens when the lagging status is finally updated from ON to OFF. Does that trigger the program a second time? If not, why not?

Forgive me if this has been asked before - I could not find the answer with a search. I've seen some posts suggesting that you can define a program condition such that you can detect an OFF when the device is already OFF or detect ON when it's already ON. Essentially, detect a slow double tap. The code snippets I've seen look like: if control x is switched off and status x is off then ... Suppose the light is ON and I switch it OFF. The control condition will be true. But, the only way the entire condition can evaluate to false on the first OFF tap is that the device status must not be set to OFF yet. It must still be in its ON state. Does the ISY process status changes after it has run all programs triggered by control events? If so, what prevents this program from being run a second time once the status has been updated to OFF? Obviously, the technique works for detecting the double-OFF. I would like to get an understanding of why it works.

Thank you for this clarification!! I've been struggling to understand why some programs included both SWITCHED ON and NOT SWITCHED OFF conditions. I had assumed that NOT SWITCHED OFF simply meant "if any signal other than OFF occurs." (e.g., ON, FAST ON, FADE UP, FADE DOWN, etc.) I think that the choice of language syntax naturally leads to that incorrect assumption, but now that I understand how thinks work, I can move ahead more confidently. Incidentally, I've been programming in various languages for 30 years, and ISY programming has thrown me some unexpected curve balls, with this particular one not the least of them. Kudos, LeeG, for setting me straight!

Thanks everyone for the great info - it was a great help.

Teken - thanks for the reply. When you say that you've not had any problem with these type of surge alarm outlets with Insteon, do I take it that you mean with Insteon communication in general? Not that you're using them for the PLM with no problem, correct? I guess I'm asking when would using the surge alarm outlets be okay and when would they cause Insteon issues? Thanks!

I'm setting-up a structured wiring enclosure with some surge-protected receptacles (these). The PLM quick start guide says not to use an AC line filter to power the PLM - would these receptacles be considered filters? I didn't think so, but the I get intermittent communication issues when the PLM is plugged-in to one of the surge protected outlets. In an unprotected outlet, I don't seem to have the issue. Just wondering if surge suppressor outlets "ought" to work with the PLM. (Signalinc is installed at the breaker panel)