oberkc

If I may make another observation, you may also benefit from a scene. If you were to create a scene (giving the name of you choice) that includes the family room and kitchen lights, as responders, with 55% on levels each, then your program could be even more simplified. It might even be more responsive. if time if from sunset + 45min for 2 hours then set scene on else set scene off

The major decision you need to make is whether you want your remotelinc in 4-scene or 8-scene mode. In four scene mode, buton C and D are the ON and OFF buttons for the same scene. In eight scene mode, button C and D control different scenes, toggling between ON and OFF. Is this your current "upstairs on" scene? Responding to button C? I will assume this is the case. Is this your "upstairs off" scene? Responding to button D? I will assume this is the case. Unfortunately, I am unfamiliar with using the ISY with a thermostat. What do you observe when you turn the thermostat ON versus OFF? Are there adjustable ON settings (50%, for example) is it just ON and OFF? If you are willing to configure your remotelinc into "8-button, non-toggle (always on)" mode, the best solution in my mind is to use scenes to control what you want, and make the respective remotelinc button controller of your two scenes scene. Of course, it is possible that your intended use for the other buttons makes this configuration unworkable. If you must leave your remotelinc in 4-button mode (C=on, D=off), the I would approach this problem with two programs? The first program, in pseudo code: if control buttonc-d is turned on then set "upstairs on" to on else Second program if control buttonc-d is turned off then set "upstairs off" to on else You could also try this with a single program such as if status buttonc-d is on then set "upstairs on" to on else set "upstairs off" to on This second approach may work, but I hesitate to predict, being concerned with what happens if the button is neither fully on, or fully off. Try it, however. It is not overly complicated. Beware, too, that I understand pressing and holding keypad buttons sends not an ON or OFF command, but a BRIGHT or DIM command. These programs may not respond to this. Also, a FAST ON/OFF is also possible, to which these programs may not respond.

OK. This tends to suggest that the ISY is seeing the command from the remotelinc. I misunderstood your original statement. No problem. This tends to suggest a potential problem with your programs. OK. This does not sound good to me. When your press the remotelinc ON button, program one will run the "then" path (turn "upstairs on" fast on) and program 2 will run the "else" path (turn "upstairs off" fast off). If you have common devices in both scenes, it is hard to predict which statement will win out. Perhaps the better approach here is to describe what it is you are trying to do, and what response to various button presses you are trying to generate. What do you want to happen in response to an ON command? To an OFF? Good. For now.

The status, as displayed in the ISY admin panel, does not change in response to button presses? This suggests to me that the ISY is not hearing the command, for some reason. How confident are you that you are within range of an access point or other dual-band device, and that you have access points on both legs of your electrical system, and that the PLM can hear all the devices? Regarding your programs, one thing that concerns me about your programs is the possibility that the scenes "upstairs on" and "upstairs off" include some of the same devices. Is this the case? If so, I suspect your two programs are giving conflicting direction to these common devices. Another question: is your remotelinc button a controller of either of those two scenes? I am not confident that changing "status" to "control" will solve your problem, but I might not fully understand yet, what your problem is.

simonw, I have nowhere near the modules you have. My only one is the X-10. Assuming the general concept is the same, I can tell you that it was painless for me. I asked for my module to be transferred. Once done, I plugged in the -994, and into the PLM and network. Updated the firmware to the latest (which you have already done), restored my system from a backup (which you have already done), and I was running. The downtime was the time it took to plug things in. I don't recall, but I may have had to reload the little icon app that finds and opens the new ISY, but that was pretty trivial. I found the whole process to be the most pain free technology transfer I have ever experienced. My experience with phone, reader, tablet, operating system, routers, computers, streamers, and all that has made me a bit gun shy regarding change. If your experience is like mine, just do it.

Personally, I think I would maintain a double box. This give you more flexibility for future considerations, should it be necessary to pull out a keypad. I believe there are available double plates with a blank half. Regarding which insteon switch to control a fanlinc, I would go with 6-button KPL. Use the "main" button for lights, and use buttons a/b/c/d for off/slow/medium/full fan speeds.

xathros, thanks. I vaguely recalled that there was a way, but had never spent the brain cells trying to research it, or figure it out.

Like LeeG, I don't believe this is possible. I would certainly like to know if I am wrong. That is how I do it. I once thought there was, but have never been able to find this ability. Thinking about it, I don't know that this even makes sense. Since a given controller can be controller only of one scene, copying a scene could violate that basic insteon tenet.

yes, it is. I was just trying to avoid sounding too confident.

I understand and agree. Our example, however, has two "things" in the condition section, one of which is triggered by ON. The individual "NOT" condition would be evaluated as "TRUE" when the combined program conditions were triggered based upon receipt of an ON command. Perhaps another way to attempt to make a point, similar to a truth table: condition A: control x is switched on (triggered by ON) condition B: control x is not switched off (trigger by OFF) tigger conditionA conditionB AorB AandB ON TRUE TRUE TRUE TRUE OFF FALSE FALSE FALSE FALSE In the end, whether you use AND or OR makes no difference in this case.

Normally, I would agree. Perhaps a better way of putting it is that both conditions could never be TRIGGERED at the same time. Your second condition (not off), however, is always true by default at any point that the program is triggered, except that split second point in time upon receipt of an OFF command. So, if an ON command is recieved, BOTH conditions are true, because it DID recieve an ON command, and because it simultaneously DID NOT recieved an OFF. It is starting to sound a lot like a double-negative. My head hurts.

Did your program somehow get disabled? Have you looked at your program code and confirmed that it is still as you left it? I really don't have any idea why a program would quit working after a version update. I could only poke around and confirm everything looks good still, hoping to find some clue.

I have never had a new release cause a program to stop working. I also don't know of any workaround. The concept of a "scene" status has no meaning in the insteon world, so one must query individual devices. As to why your program stopped working, I can only speculate. How do you originally add the devices? When you select each device, does it show a version? Does it show a status? If you manually turn on ta given device, does the ISY status change?

Yes, it is not always obvious that the introduction of the ISY renders a good part of the instructions obsolete. Once you figure that out, things are mucheasier. Don't forget to check out the universal devices wiki. There is also an ISY user manual.

OK. That is the key finding. One of these needs to be connected to red output (switched power) of one (does not matter) of the switches. The other needs to be connected to a neutral. It is best if you can identify the proper conductor for hot. Normally, in a fixture, hot should be connected to the little tab in the bottom of the light bulb socket. If you can identify which of the wires (either 3WW or 3WR) feeds this little tab, then connect that wire to the switched output of one of your insteon switches. The other end should be tied into your neutral bundle. This is a code requirement, I understand. The purpose is to avoid energizing the shell of the sockets and minimize the risk of sjock when changing bulbs.

REmove all the bulbs from the ceiling fixture. If the fixture is between any of your switches, I would expect that you will be able to detect this because your restance measurement would go from short to open on some of your 3-conductor wires. I agree that the outlet is sure an interesting addition to your wiring. I don't believe it could be there if this were "normal" three (and four-way) way switches.

I had missed the outlet mentioned in your original post. Was the outlet controlled by the switches, also. This strikes me as quite strange. My only theory is that, as you say, someone added the outlet, but only after adding the X-10 devices. I have trouble understanding how one could power an outlet from a four-way switch box location that does not have power. Given this better understanding, considering the possibility that the fixture is, indeed, wired between one of the switches, did you take your measurements (impedence) with the fixture and bulbs in place? Have you removed the fixture to confirm the existence of two, 3-conductor cables?

I don't believe this is your setup. The 2-conductor cable in box 2 runs to the fixture. I don't believe you travellers route through the fixture box.

I believe that you can assume one of your 2-wire cables is supply, and the other goes to the fixture. If you believe (you should measure this to be sure) box one includes supply, then the cable in box 2 goes to the fixture. If the routing of the 2-wire into the bottom of the box makes you suspect that it does not go to fixture, this makes it even more important to measure things. Does the 2-wire in box 1 come into the top or bottom of the box? In box 1, you state that "travelers" (plural) are not connected. Which are the travelers? In box 2, you state that switch red is to red. Which one (are there not two?) Regardless, this would be incorrect. If, as I suspect, box two has the feed to the fixture, then switch red should be connected to the black from the 2-conductor cable. How did you confirm this? As I understand your wiring description, red would NOT be neutral...white would be. Your lighting circuit does not work because it is not wired correctly. None control the light, because you have none connected to the light. I suggest removing everything and starting over. Expose all the wires, none touching another. Temporarily energize the circuit and measure which have power. Identify where the remaining wires go. Diagram it on paper. ONce you understand the wiring, reconnect everything, keeping black as supply, white as neutral, using red where necessary.

The reason to use control condition is that a control will trigger a program evaluation upon EACH receipt of the anticipated command. Unlike control, a "status" condition will trigger an evaluation only after a CHANGE in status. If a device status is off, and you turn it off again, the status has not changed and no program evaluation will take place.

I assume box 1 includes supply (2-conductor), box two has the 3-conductor cable from box 1 and box 3, plus the switch power to the fixture, and box three is just the end of the three-conductor cable. I am hoping you can confirm these assumptions on site. If so, in box 1, connect supply black (hot) to 3-conductor black and to switch black. connect supply white to 3-conductor white and switch white. Cap red from switch. Cap 3-conductor red. In box 2, you now have supply provided by the black and white from the 3-conductor cable from box 1. Connect this to the other 3-conductor black and white, as well as to the switch black and white. Connect 2-conductor white to the other whites. Connect 2-conductor black to switch red. Cap remaining red conductor. In box 3, you now have supply provided by black and white conductor from box 2. Connect switch black and white. Cap red from switch and cable. ALL switches must be insteon if you want control from all three locations. All bare grounds should be tied together in each box. Again, confirm the wiring on site. Best to use a volt meter.

Certainly a factory reset on the devices will eliminate all traces of your PLM and ISY. My suggestion is to try a quick attempt at establishing communication with your plm. Try moving it to where you had your smartlinc. Feel free to use an extension cord, if necessary. Hopefully, it will work better. If it does work better, you can try "removing" each device from the ISY. It is hard to know if this will work. The difficulties you have experienced may have corrupted some of your devices. If removing the devces does not work, a factory reset of each may be your only option.

Make sure you put your smartlink back in its original location. I suspect it, too, will have difficulty at the location where you added your ISY. Were you to put the ISY where you had your smartlinc, you may find the problems go away.

I am with LeeG on this. I, too, believe you have a communication issue between your PLM and rest of your system. This tends to suggest that the PLM is plugged into an outlet or circuit with other things that don't play well with insteon. My impression is that the most common cause of this is plugging in the PLM into outlets near computer stuff, including surge suppressors, UPS, and lots (and lots) of other gadgets. If you are having trouble communicating with the PLM, then...yes...it will probably be easier to manually link your devices and ignore the PLM. Once you figure out the PLM, however, I respectfully disagree that this method is easier. I assume that you transitioned in order to exploit some capability in the ISY that is lacking in the smartlinc. I am curious, however. Did you install the ISY/PLM in the same location as the smartlinc?

I don't mean to overly stress these types of questions, but I think it worth spending time thinking through how you intend this sytem to work. Answers to these questions will affect how you program things, and you can waste a lot of time coming up with programs that you quickly discover "don't work" as you intended, because you didn't give enough attention to your "intentions". It is a lot like "ready, fire, aim". What if the livingroom lights are at some setting other than 50% because someone manually adjusted them for some reason? what about 10%? 80%? 1%? Do you want the living room lights to go full on only if they at that magical 50% level, or any level greater than zero? Or any level greater than 50%? Most of the program suggestions so far are based on the first option. OK...you bring up another consideration...do you want the livingroom lights to respond to kitchen lights only if they are at 50% AND only if they reached that state in response to the kitchen lights turning on? Or do you not care how the livingroom lights came to be on, whether manually or in response to a program? There are a variety of conditions one can use to check for such things, but one condition that does NOT exist is "scene status". There is not status for any scene, such as your livingroom scene. Typically, one would have to check for the status of a selected device within that scene as a representative status. Another condition that could prove to be handy here is in program status (true or false). This represents the results of the most recent evaluation of a given program. For example, if you have a program who's else statement turns on livingroom lights as a result of kitchen lights, if that program status is currently "true", then you know that the most recent execution of that program turned on the livingroom lights. I believe it worth spending more time understanding your needs and intentions before writing a lot of programs. Your particular situation is, in my mind, has a lot of subtle variations.