oberkc

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

I would simply turn it off at 11 without checking status. I have never perceived any harm in this. For the record, ON = 100%. One can also use NOT OFF as a condition, which is any percentage above zero.6IS RESPONDING will not accomplish your goal. This represents a condition that differentiates between when a device is communicating or not.

I suspect you wiring diagram is not correct. So, you have a single cable coming into switch box with black and white conductors, correct? I cannot tell from pictures, but do you have two cables at ceiling box, both with black and white conductors? If so, connect black and white conductors at ceiling box. To those, connect black and white from fanlinc. At the switch box, connect black conductor to black white from keypadlinc, and white to white. Cap the red wire. Back at the ceiling, connect whit from the fan to the bundle of other whites. Connect red from the fanlincnto the wire powering the fan. Connect blue from the fanlincnto to the wire powering the lights. You will also have to program (link) the keypad and fanlincnto.

When you put the ISY in "linking mode", is this the same mode you use to add insteon devices? For Z-wave, one must "add/include Z-wave device". Putting the ISY into linking mode will not work with Z-wave. My recollection is that one first must choose "add/include Z-wave device" then toggle the desired z-wave device. If this does not work, try first excluding the z-wave device. In case you have not checked, instructions are here http://wiki.universal-devices.com/index.php?title=ISY_Z-Wave_GenII_-_Instructions

I find variables an unnecessary complication in this case. I use a simple program such as: if control light switch is switched on an control light switch is not switched off then nothing else nothing Once a program like this is in place, I use the program status (TRUE or FALSE) as a condition to my motion program. Obviously, these additional complications eliminate the use of scenes between motion sensor and light, so it would all be done via programs. Also I assume the light switch controlling the motion program is the same one controlling the light. If not, there may be a few details different. Assuming I have it correct, only a manual activation of the switch, itself, will disable the motion response. Furthermore, if the light is on from motion and you turn on the switch, the timer is halted and the switch stays on indefinitely. Turning off the switch while the timer is active will, obviously turn off the light. if control motion sensor is turned on and status first program is false then turn on light light switch wait a little while turn off light else nothing

I must admit to being a little curious...in what way could it be more convenient? Put ISY in link mode, tap the devices, done. Are you looking to avoid the physical movement throughout the house? This can be done if you know the addresses for each device, but I have found it (personally) easier to simply tap the device.

If you have not already done so, draw the wiring diagram for the two switches and fixture. This is much easier to visualize than trying to do so in your head. Depending on your familiarity with these circuits, you may need to perform a web search. In case it is not obvious, RBW cables from both switch locations go to fixture box.

The trick, in my mind, on any of these three-way circuits is to identify where power is introduced...at the fixture, or at one of the switches (an which one). There sounds like a lot going on in that mudroom box, and I suspect it all comes in there. Are both of the fixtures controlled by switches in the same two boxes, kitchen and mudroom?