oberkc

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.

I suspect the reason that LeeG did not address this concern is that it appeared you had already figured that part out when you said: That is certainly how I interpreted this post. Regardless, and ironically, there is a current thread on the same topic: http://forum.universal-devices.com/viewtopic.php?f=27&t=7552

Based on your description, I expect your program to work and can either conclude that I don't understand your program correctly, or that there is something else going on unrelated to program logic. I have a program much like LeeGs and yours. I have a secondary keypad button, set to non-toggle off. Because one cannot directly control secondary keypad buttons from a program, I created a scene, with only the secondary keypad in it. I then created a program such as: if status "light 1" is not off <<or status "light 2" is not off or status "light 3" is on <<then set "scene with secondary KPL button" on else set "scene with secondary KPL button " off It works great for me.

In other words, you want the program to evaluate as false ("don't want to run true") if you switch the garage light off? Status 'Main Floor / Garage Light' is not On This particular condition will be TRUE if you switch the garage light off. (This is not a dimmer, is it? Only two conditions: on and off?) This sounds to me exaclty the opposite of what you want. If you want a condition that will be false when you switch the garage light off, try: Status 'Main Floor / Garage Light' is not off I apologize, but besides "I don't want to run true if I switch the garage light off , I don't see where you describe what it is that you want your program to do.

Nice! I am glad you found the better solution. Have you not checked out the mobilinc threads, under third-pary apps?

Yes, and of scenes and room folders . the ISY-99 and the "my lighting" tree are not, in my estimation, intended as user interfaces for the purpose of turning on lights and activating scenes. As such, the idea of accidently hitting "all the lights" is near non-existent. Use the ISY to create scenes and programs. Scene controllers should be insteon switches or keypads or android apps or iphone apps or.... Unfortunately, I don't use mobilinc so I cannot help with how to set this up to make user friendly. I cannot help but strongly suspect there are better options than renaming the lighting tree.

Sorry, but I missed any mention of prior experience with smartlinc. I have not memorized part numbers and your mention of "2412" just went right over my head. My earlier suggestions were based upon having failed to catch that little tidbit. Generally, I agree with the logic that if a PLM location worked for smartlinc, it should work for ISY. I vaguely recall posted suspicions that the new, dual-band, PLM may not communicate as well as the older versions. I suspect that smarthome would not admit to this being the case, if true (and it may not be). Glad it is all working now. Sometimes computers simply need rebooted.