oberkc

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.

While a single condition cannot include nested IFs, one can create an equivalent condition using multiple programs. For example: If A is tuned on Then run next program Next program: If sky is blue Then do something Obviously, these are conceptual examples with inexact syntax. Also, as the others suggests, use of parentheses and exploitation of the various statements at or disposal will allow darn-near any logical construct. Like others suggest also, two programs that would be triggered by a given event would be run essentially simultaneously. If program order becomes important, one could control this by a series of prograns, with each subsequent program being called by the previous.... If some condition exists Then do something, then call next program Next program... And next, and next..

Yes, you could set up some program conditions and/or variables where the scheduled program would not run if you have already manually executed the scene, but this is does not fully respond to your original problem as I understand it. It may, however, be a reasonable compromise.

Another factor: to my knowledge, most here are enthusiasts without direct knowledge of the inner workings of smarthome or universal devices. Few know what smarthome thinks or what they document or tell UDI. Questions of this nature will generally go unanswered.

Your problem may be solveable, but it may take an entirely different approach. I am unaware of any way to evoke a scene command, excluding certain devices from the scene. I also am unsure the condition you want in order to exclude a given device response. Is it only when a given device is NOT OFF to you want it to to be excluded from the scene response? Unfortunately, the method that is coming to mind is purely brute-force approach that will get ugly if there are a lot of devices. My idea would be to delete your current program and replace it with multiple programs, one program for each device in the scene. Each program would be the same, except the device would vary... If time is sunset - 3hrs and status deviceX is not off then set deviceX to certain level else nothing

!!!??? You found out that this was a characteristic of older switchlincs. A couple offered suggestions regarding ways you could exploit the ISY to help mitigate the risk. You learned that the ALL OFF feature has been eliminated and suggestions on alternatives. What is it that you want folks to say at this point? What questions do you have that are not answered?

Getting out of bed has risk. One cannot be alive without risk. Still, there have been some good points to consider here.

In the end, if there were a more serious fire, I would guess that this would have been identified as the ROOT cause. All other factors, including the insteon "features" would have been secondary, or contributory. It sounds as if the lesson has been learned. No doubt, others will have to learn it the hard way, as well.

That is surely an interesting story and I appreciate you sharing it. It is quickly obvious that the solution will cover multiple fronts. If I may offer a simple (even if small) part of a solution. Create logical main scenes of devices. My major groups, for example, are ALL INTERIOR, and ALL EXTERIOR. I have found it useful to have simple programs that run in the middle of the night that simply turn everything off automatically. In most cases, these programs are redundant, but it is wonderful peace of mind. Certainly you did not spend thousands of dollars on insteon devices and controllers to continue to operate the devices as you did before: manually. Take advantage of that automation power that you already have. Unfortunately, it sounds as if you will have to abandon the "all off" approach you currently employ.

Yes, tough at times. I understand. Much can change in two years. More chargers and gadgets. Incandescent lighting replaced. Aging electronics. Neighbors. Who knows. To be clear PLM needs to be on separate circuit BREAKER. I would still filter all computer electronics. All my computer stuff (and it is a lot, consuming 20 outlets, probably) is on a filter. If something changed suddenly, consider also the possibility hat some link records became corrupt somehow. For a troubled device, show the link records, then "compare" to the ISY. Failing the easy stuff, I have no secret tricks. Divide and conquer. Unplug and de-energize. Trial and error.