oberkc

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.

Make sure you respond to Brian H post earlier. Make sure your PLM is on a nice, clean circuit. I expect it is easy for most of us to plug in the PLM into the same circuit as the rest of that noisy computer stuff. A simple test would be to run an extension cord from another circuit to the PLM and see if this solves your problem. Lets deal with the easy sruff first.

I suspect that experience is pretty common. My theory is that this can happen when a combination of factors come together. This includes see an electrical environment where insteon communications are marginal coupled with some devices (such as furnace, appliances, water heaters, pumps) that are operating only part of the time that turn on and temporarily disrupt comms. The solution, in my mind, is to address the general environment, via filters, to ensure it is clean and fast.

Theoretically, once could turn on a light that is already on, so it is technically possible that this program could execute TRUE, but when one the lights are OFF and one turns them ON, this program will execute FALSE (not good). This will be the case 99+% of the time in the real world. Yes, eliminate the status checks is the step I would take.

I use a schlage lock similar to this (suspect cosmetic differences only). It works perfectly. Yes, you need the zwave module for the ISY.

If you want the light always to come on (or stay on) when motion is sensed, having no other conditions, then using a scene seems like a better idea to me. This is how I do it, and it seems to work well for me. You should experience a faster response and that is one less failure mode. Be sure to configure the motion sensor to send only ON commands. I notice, however, that you have a second condition for which you test before turning on the light: entry door program status is false. Using a scene will not allow you to check for this condition.

No