oberkc

OK. This makes sense. Simple option is to tart the timer after motion is last seen. If Laundrylight is 1 Then Turn light on Else Wait 5 min Turn light off

Yes. Treat the ON and OFF buttons as a single insteon switch (apparently with the default name of "on", but it can be renamed anything you want). The progrm statement is no different than with any other switch.... If Control/status " on" is set off Then Do something

To expand upon jerlands suggestion, make sure you use CONTROL keypad is off. STATUS will not work here.

Is there a problem with temporarily unplugging the power strip? Plug the ISY into the other outlet. See if this works. Surge suppressor power strips can cause problems. Security systems? I don't know. Does the security system have a UPS?

Regarding breakers, I vaguely recall an option that yokes two breakers together in such a way that it would not be possible to disable only one.

My experience is that insteon is more robust than x10 and if x10 works, insteon will. The only exceptions that I can think would be if one has an x10 phase coupler that messes with insteon, or if one tries an insteon device in a new location. Regarding the latter exception, are there other gadgets or devices on the circuit that powers the PLM? If you put an x10 device at this exact location as the PLM, can you control it?

Do you currently have an x10 phase coupler? Some can interfere with insteon.

Ah...the real mystery comes out! I will start here. I know that I can stare at things and not see stuff, but it appears to me that the "IF Logic" is NOT the same. The variables in each are different, to start. The variables in one program start with $area_outdoor..... whereas the variables in the other start with $area_indoor.... I notice, also, that the FROM time in one is different (sunrise-9 minutes) than the other (sunrise). I notice, however, that the variables have not change since the day before, according to the variable list. I do not see this as a cause of the mystery logs, however, but thought I would mention it in case it rang a bell in your head. Like LeeG, I notice the indoor program last run time was after last finish time, yet the program is not active. Interesting (but I don't understand it). Does the "Device Control Programs" folder or the "Christmas" folder have any conditions associate with them? I agree that any changes in conditions should have affected both programs, so I don't see this as a factor. I don't see any real utility to the wait 999 hour statement in each program. The lights will cycle on and off many time before the 999 hours expire. Have you experienced times where the lights don't turn off as expected? These do not look like programs and variables from a "novice" programmer to me. Are your programs consistently working as expected, even if the program status table has these unexplained or misunderstood anomalies? Are the devices coming on and off as expected? I don't see anything programs that depends on knowing whether a program is active.

A pretty accurate summary, in my view.

I continue to struggle to understand why this is an issue. The whole discussion, while intellectually interesting, seems based upon a use case where one needed to know whether a program that included wait states was active and some improbable ways to mess this up. I remain confident that there is a programmatic construct that can be created that will meet most any need for which insteon is a viable solution. I am even more confident that this is am issue that the "common man" will even recognize, much less care about. Of all the impediments that I have seen that seem to be stumbling blocks to the person new to the ISY, this is not even close. I remain curious, however, what it is that you are trying to accomplish where this has become such a critical factor.

While I agree that there is no direct method for measuring active or otherwise, I must admit to having trouble appreciating the problems you are having with the variable method. While I trust the examples you gave will result in a state where the variables cannot be trusted, nearly all those examples took a manual intervention through the admin panel to achieve. Are you concerned that somebody might open the admin panel and mess things up without your knowledge?

State and integer variables, I believe, are identical in function when viewed as part of the logical condition. Integer variables differ from state variables only in that integer variable do not act as program triggers.

Remember, too, that the subscription is optional. I use mobilinc on Android with no annual fee.

I am glad you understand triggers. I view triggers separately from conditions, though both are based upon the same individual statements. Think of the condition (if statement) as a single entity, made up of multiple statements, OR, AND, and parentheses. Regardless of which statement triggers a program, the ENTIRE IF condition is evaluated, always.

MikeD, makes sense, yes. Was simply responding to a couple of your statements such as "The trigger for TIME condition are only evaluated..." (Triggers are not evaluated, in my mind). "The trigger for the CONTROL condition is valid during the whole time period" (triggers are moments in time, not over whole time periods.) I could not reconcile statements such as those with my own understanding of how things work. While I am confident that you and I understand things equally well, I believe that triggers is a fundamental concept of the ISY and it is important to be precise. Otherwise, results will be unpredictable. Perhaps that is the "gotcha" from all this?

MikeD, I would describe it a little differently. Triggers have no logical condition and triggers are not evaluated. Instead, I believe it more accurate to state that once an IF statement is triggered by one or more of the individual conditions contained therein, the ENTIRE logical condition is evaluated based on the logical state of each condition at that moment in time.

I have a copy of the old instructions. Unfortunately, they say nothing of the purpose of the red, green or black wires. The instructions are limited to a picture showing black goes to Sense and green goes to GND. Fortunately, it is easy enough to figure out. Polarity does not matter so there are only three combinations to check. Put any two wires in the IOLinc Sense and GND terminals and observe the response as the door opens and closes. NC will be the wire combination that results in green LED ON when away from the magnet and OFF when close to the magnet.

Because programs execute only when triggered. And, the conditions, themselves, are the triggers. In this case there are two conditions (to..from, and control...switched on). The first condition WILL trigger only twice daily: at sunset and sunrise+30. The second condition will trigger only upon receipt of an ON command (not triggered by OFF, DIM, BRIGHT, etc). Once triggered, the entire condition WILL be evaluated. Besides, there is nothing in the ELSE to run at all, let alone run continuously.

Technically, the ELSE will run twice every day...once at sunset, and the second as sunrise+30. In addition the ELSE will run any time the motion sensor is switched ON but not between the specified times.

You are speaking of Moblinc Connect Portal, correct? You have not been using it lately but now you want to start again? I understand that using mobilinc connect requires a module to be purchased ($1) for the ISY. Have you done this? Is it about the "module" you are asking. Once all things are in place, I would expect that you can connect to the ISY through the moblinc connect without breaking anything. I do not expect that purchasing the module will break anything. If your intention is security, you may want to get rid of the port forwarding rules once you are connecting via the portal.

Reboot?

An additional comment, for iOS users. Mobilinc app can provide a good phone interface to the ISY, as well as broad support for cameras. Hub app, I understand, can support a very limited number of cameras.

Insteon has never, in my experience, been widely available in stores. From time to time, I have seen a fewnstarter kits at Walmart or best buy, but not consistently. Yes, I understand that the hub (at least one of the versions) can interface with certain non-insteon devices such as the nest or ecobee). This is unique to the hub and not available on the ISY without some level of coding. On the other hand, the ISY zwave version can support a bunch of zwave devices not supported by the hub. The harmony remotes can also control one of the hubs, also, which could be valuable. I am unsure whether there is a list of compatible devices for the ISY, but I believe it safe to assume it is natively compatible withnall insteon devices and most zwave devices. Still, the ISY can exert some level of control over most devices that can be controlled via IP or IR. Unfortunately, there is a bit of setup and/or programming required. I would not describe the support as "native". If remote "control" via phone or tablet is your primary concern, and compatibility with certain key gadgets such as nest or sonos, I would favor the hub. If your priority is more into automation, insteon, and zwave, I would favor the ISY. Neither offer broad support for cameras, in my mind. I view cameras as a separate function and use separate apps for this purpose.

Look at this as more than the avoidance of programming errors. This is also a capability to exploit!

I would not describe WAIT or REPEAT statements as "interacting" with a program condition. Instead, I would describe such statements as an off ramp. If, for example, something triggers a program condition while that program is executing a wait or repeat, the program execution will halt and restart, based on the results (true or false) of the latest triggered evaluation.