oberkc

+1! +1!

I believe that, until the most recent NEC update, this was EXACTLY how the code prescribed. Black is always supposed to the the switched return. White (reidentified) is the supply from the fixture. Latest NEC update now requires neutral in all switch locations so I assume the need to use white as a line is eliminated.

So each of three fixture boxes has two cables, each with two conductors plus ground. Each of the three are controlled separately, and by a single switch. Each switch has connected to is a black and white cable? Some of the white cables have tape around them. This is starting to sound a lot like a switch loop for each of the three fixtures. I believe is is common, even standard, to use white (remarked as black) for the line connection in a switch loop. Black is typically the return to the fixture. Agree? If you have a white wire with black tape around it connected to all three switches, then the other wires are the load. Yes. This would be connected to the red wire of the insteon switch. The problem will be finding a neutral from this circuit. If I understand correctly, you don't have one in this switch location. I have found it often extremely difficult to describe wiring in words. I am hoping you can draw something up and insert the image or attach a file showing your wiring.

Sometimes you have to get creative. I have not needed to do this often, but I have sometimes tied hot and neutral together (obviously, no power) at at one termination point (box or panel) and measured resistance between hot and neutral conductors at the other end. Other times, I might add a length of conductor between one location and another so that I could reach both ends with the probes. Yes! Nice. Yellow identifies the circuit(s) powering only insteon switches. No lights. No refrigerators. I would imagine that you could even power a whole house' worth of unloaded insteon switches from a single circuit breaker. Yellow, then, becomes partly a control circuit. Sometimes, even electricians have good ideas.

The only knowledge I have of this would be part of the keypad literature. I think it is typically +/-10%, but you can check. My suspicion is that if your issues are connector related, it would be more about transient and intermittent conditions rather than just pure peak voltages. My suspicion, further, is that the conditions at your house are simply revealing some weakness (rather, lack of robustness) in the keypad design. Others have pointed to posts about similar problems and persistent failures, but I suspect a vast majority experience very limited and random failures. I take this as an indication that some houses have minor wiring issues that don't bother most electrical devices, but could affect those electronic devices designed without a lot of margin. Perhaps smarthome devices are one of the latter (pure speculation based on your experience here). Depending on how much work you want to put into this, and how comfortable you are with electrical, one option is to measure resistance between the switch location hot, and the circuit breaker. If possible, measure this resistance while moving the branch connector. My experience is that this resistance will be well below 1 ohm. Heed LeeGs advice here with regards to being careful. I also don't know why your electrician used yellow, but I understand that this is code compliant. Most of us are used to black and red because of this being the common colors in sheathed electrical cable, but I don't believe yellow is a restricted color (like white or green). Red, blue, black, yellow, orange, and red are, I believe, ungrounded conductors by code. That is how I would do it, being sure to make sure everything is cleaned and flux is applied. One thing I have found about wire nuts is that they work best when the wirenut threads engage EVERY conductor. With 4+ conductors, this can sometimes be tricky.

I have been watching this thread with interest. Most of the ideas that I came up with were addressed by others. Based on how I understand your wiring, while unusual, I see nothing that jumps out at me as a problem that would induce failures. I have no personal experience or have seen anything in this forum and others that leads me to think your experience is common. While other have had device failures, the numbers of failures that you have and the fact that it appears centered around a single location makes me suspect that there is more going on here than bad luck. While I think LeeG is correct that bad connections generally won't INCREASE voltage, I cannot help but suspect that loose connections can cause arcing, reduced voltage, frequency issues, rapid power cycles, and other things that could contribute to electronic device failure. None of these things can be good. You mentioned that the hot (yellow!?) wires originate from a breaker, then branch out to multiple switch locations. How are these branch connections established? Wire nuts? I read that you have temporarily disconnected some of those as part of troubleshooting, but this certainly strikes me as an area that could induce arcing and power cycles. If it were me, this is where I would be focusing. I might even be inclined to break out the solder gun if I had any reason to suspect faulty connections. Otherwise, I see nothing electrically unusual that would explain your batch of failures.

I don't know if you are mistaken about the neutral "phase" thing. Phase suggests that there is an alternating voltage. On a neutral there none. Phase means nothing relative to neutrals, as you stated. However, this should not be taken that one does not have to take care with regards to which neutral one uses. For each circuit, there should be a hot and neutral. Loads put on a circuit's hot should also be on that same circuit's neutral. You should not use the hot from one circuit and a neutral from another. This has nothing to do with whether there is a neutral phase (or leg). It has everything to do with ensuring that current on the neutral does not exceed the capacity of the conductor. If one starts putting loads from multiple circuits on a single circuit's neutral, then one could (theoretically) have the current of 30 or 40 amps on a wire rated for 15 or 20. If you have separate/dedicated neutral wires for each switch (and outlet) location, all going straight to the neutral bar, then this would preclude overloading the neutral wire, so long as all the switches in a given box are powered by the hot from a single circuit breaker. If this is the case, I don't see the neutrals being a safety issue or a cause of your switch failures.

Not by my experience

This question sounds similar to one that I asked a while back regarding an insteon ISY talking to a UPB (or was it Z-wave?) ISY. I recall being told that they could communicate via network module. More details I do not have, but cannot help but suspect that answer would apply to two insteon versions as well.

If a program sends an "on" command to the scene, all devices in the scene (keypad button and relay in your case) will both respond. I expect the keypad button to turn on (regardless of toggle setting), and the relay to respond based upon how the relay is configured (momentary a, b, c, latching) relative to "on" commands. Why do you see the need to add the "off" command? How is your relay configured (momentary A, B, or C? latching?)

My gut reaction is to swap the order of the "wait" and "Send" commands.

That was also my first instinct, but it did not appear to offer any benefit in terms of efficiency or lines of code or numbers of programs. In fact, it may have been more difficult (requiring an additional program to define a variable value based on "icondimmer1").

Having thought about this a bit more, I am now wondering if LeeGs two-program approach would work, as coded, with the only addition being to disable the second program (ensuring it does not self-trigger). It may not be necessary to split this into three separate programs.

Building upon LeeGs suggestion, how about: If Status 'TriggerLinc1-Opened' is On Then Wait 15 minutes Send Notification to 'ALL' content 'Custom with date' Run Program 'XXXX' (If) Else - No Actions - (To add one, press 'Action') Program XXX (must be disabled) Program YYY if Then Repeat 5 times Set 'ICON Dimmer 1' Fast Off Wait 1 second Set 'ICON Dimmer 1' Fast On Wait 1 second Else Repeat 5 times Set 'ICON Dimmer 1' Fast On Wait 1 second Set 'ICON Dimmer 1' Fast Off Wait 1 second

I am sorry, but I do not understand what you want to do.

Well...I can speak only of generalities at this point (away from home). This setup is for those who want to use a single KPL button to control a garage door, and simultaneously display its status. First is sensor position. It is arguably important to understand that the sensor has two states: on and off. If the sensor is physically located such that the magnet and sensor are adjacent to each other when the garage door is closed, then this state means "fully closed" and the other state means "not fully closed". In my mind, from a security standpoint, "not fully closed" is the same as "open". It is for this reason that I consider this the superior location for the sensor, rather than the alternative to mount is where the magnet and sensor are adjacent when the door is fully (or any other state of) opened. Second, I wanted my KPL button to be "off" when closed, and "on" when open (any degree). This means that the sensor must be wired so that its state is off when closed and on when open. I recall the instructions that came with the kit were less than clear on how to do this, but it had to do with using the correct two wires from the sensor, I think. I believe this also equates to the IOLinc LED being on when open and off when closed. Third, you must configure your KPL button to be non-toggle on. Since I was most concerned with being confident that the door was fully closed, indicated by KPL button being off, I did not want the ability to turn the KPL button off by manual presses. I wanted only one way to turn the KPL button off: by a command from the sensor. Fourth, you must configure the relay portion to respond to "on" commands only. Since the KPL is in non-toggle "on" mode, it would send only "on" commands. I wanted the relay (and connected opener) to respond to all KPL button presses, the same as the mechanical button in the garage. I don't recall the setting, but I think it was "momentary B", but you should look it up to be sure. The mode where relay response based on sensor position (momentary C?) won't work here. Lastly, create two scenes. One with sensor (controller) and KPL (responder). The second with KPL (controller) and relay (responder). I believe ALL these steps must be taken because how all this works together. I don't think you can pick and choose the options that you like without understanding how it all plays together. There are a lot of details. Hopefully, I was clear and did not forget any.

For this reason, it is important that the KPL button be configured in "non-toggle on" (of course, the relay has to be configured to respond to "on" commands). This way, the only way for the KPL light to be off is from a sensor command. Being configured in this way gives one a high confidence that KPL off means garage door closed. I am one of those that LeeG mentioned as a fan of the wiki approach.

My experience is that the ISY status remains pretty faithful to truth. To verify, the only way that I know is to run a query, as you have done. Unfortunately, the problems that cause it to be out of sync can also affect query results. There are, however, a few times that I have experienced problems. One is when experiencing communication problems. The other, if I recall, was associated with firewall and java issues (I don't recall specifically which). I have been swapping out browsers between chrome and explorer (currently using the latter) but each swap appeared to cause temporary issues with the admin panel status not keeping sync. Unfortunately, my methods with firewall and jave issues is trial-and-error rather than skill.

If, however, ons has easy access to the device, I find it quite viable (even preferable) to use the "start linking" button on the ISY admin panel and simply putting the insteon device into linking mode as responder. The ISY will populate address and device type quite well, thank you very much. You may still wish to change name to something meaningful. Of course, I enjoy moving around a bit, would rather walk than type, and am in no hurry.

I don't believe so, just as long as you pay attention to the priority between "and" and "or", putting parentheses in the appropriate places. Yup. You have some interesting conditions. I do, without observed problems. Apparently, my experience is different than bmercier, however. Possibly, but the use of scene tests, event viewers, and program status can often help figure things out. It is not always easy and sometimes frustrating. It sounds as if you have a lot more requirements in you head than I have attempted to address in the suggested programs. I apologize, but I also continue to be unclear about what your progam is, or is not, doing that is should not, or should, do to be able to offer more concrete suggestions.

I stand corrected. Brain dead. So you have a variable to indicate one, or both, doors are opened. That should work. You may need to create a second variable (I will call it IGarageLight) to track how your garage lights are last turned off and create a program to track. The logic would be something like: if ( control garage light is set off or control garage light is set fast off ) and status garage light is not on then Set IGarageLight = 1 <<< indicating light was last turned off manually else set IGarageLight = 0 <<< indicating light is either on or turned off other than manually Your main program would then look something like: if Status Program = "true" <<<IGarageLight = 0 <<< not last turned off manually then Set garage light on This is all theoretical an untested, but I hope it gives you enough ideas to move forward.

I believe your level of complexity just went one step higher. I don't have exact syntax memorized, so I will offer a conceptual suggestion, hoping that it will give you enough clues or ideas that you can fill in the blanks. Create an integer variable, call it IGarage. Modify the first program as follows: If Status Garage Door Sensor is On then wait 5 minutes set IGarage = 1 <<< a condition indicating that the door was open for at least five minutes Then notify me (garage is open) else run new program (if path) Create a new program, if IGarage = 1 then send notify me (garage is closed) set IGarage = 0 <<else set IGarage = 0 One could actually accomplish this logic without variables if that has value to you, but I see no reason not to take advantage of them given that they exist.

This is not a trivial set of criteria. So the plain-english condition would be something like: if either of my two garage doors are opened and garage light is off and garage light was not turned off manually then turn the garage light off I cannot help but suspect I am misunderstanding something.

It is good that you replaced your defective, and potentially defective, devices. quick confirmation of what I hope is understood: a. do you have access points or other dual-band devices to provide insteon communication between legs of your electrical system? b. have you plugged your PLM in, or on the same circuit as a UPS or surge suppressor? Do you have any of these devices? c. have you plugged your PLM into an outlet with lots of other computer stuff? d. do you have any X-10 devices?

This may actually be quite simple, given the way programs are triggered and how wait (and repeat) statements work with the ISY. How about: If Status Garage Door Sensor is On <<then wait 5 minutes Then notify me else The beauty of this is that if the status changes during the 5 minute wait period, the program execution will be halted and re-run, based on the newest evaluation and status.