recommendations for light switches

I would like to have my M1 turn on exterior lights if an alarm is triggered. I currently have motion sensor lights on all four sides of our house. Even at their highest sensitivity, I can walk around the house without triggering them. The groups of lights are also wired with a single pole switch in multiple locations as shown below

# of Fixtures # of Switches Location
North 4 2 Kitchen, Basement
East 2 2 Kitchen, Basement
South 2 2 Front Door, Garage
West 4 2 Entry, Garage

I would like to have all exterior lights turn on if any zone is triggered. Also, I have an outdoor furnace that I feed nightly during the winter. I would like to be able to turn on the North and or East side lights from the kitchen.

IM not against replacing the fixtures. I don’t think they like me too much. Any time I need to turn them on with the switch, they turn off within 5 mins (longest setting on the fixture). If Im not outside, the lights will stay on indefinitely. When I need them, they turn off. Its almost comical.

I don’t have any lighting automation at this point Im open to any system compatible with the M1. Im not sure what type of switches I need, additions for the M1 panel or if my fixtures need to be changed.

Elk M1G will sync with UPB, Insteon, Z-wave and all will do the job for you. It is quite easy to write the simple rules that it would take to do what you want.

I have Insteon, M1G, and and ISY. For that to work you need the Elk ethernet module. If you are only doing a few lights and don't want the ISY, you will need the Elk xsp unit (ethernet unit not necessary doing it this way). Both ways require the Insteon powerline modem. IF you are only doing a handful of switches, I suggest using the dual band switches.

UPB works similarly.
I don't know much about getting zwave linked to an Elk.

I'm a big fan of UPB - you can read the link in my signature about some of it. I have all kinds of rules going on through the elk when doors are opened, etc.

I have found UPB to be awesome as well for reliability. The more I look at Zwave the more I think it will be the dominant player in lighting automation (as well as other automation). I just find UPB so easy to set up compared to Zwave but I think that Zwave has more applications.

I agree completely with Digger... ZWave is definitely more accessible lately - being sold in Home Depot and Radio Shack - and a little cheaper.

What scares me is the stories I've read where a network has learned a path through a device that's portable or has been moved and people having to reprogram their whole networks over again - but I don't have enough first hand experience to speak to it. The fact that it doesn't need powerline sure does make it easier to get door locks and thermostats communicating as well. I'll be sticking with UPB but I know it won't be long before I support both.

Work2Play said:

I'm a big fan of UPB - you can read the link in my signature about some of it. I have all kinds of rules going on through the elk when doors are opened, etc.

Click to expand...

How have you integrated UPB with the Elk, Elk XSP and a serial port PLM (or the PCS PIM w/ XSP built in) or something else? If you are using the XSP + serial port PLM or the PCS PIM, how do you find the status tracking? I've read that it doesn't really work well and you need to go to a dedicated controller or home automation software to have proper status tracking.

I do the XSP with a Serial PIM. The PCS one wasn't available at the time I did mine.

There's a piece in the UPB article in my signature that explains the issue with status tracking. Basically any direct commands will track correctly; any time you use a link, it won't. This is inherent to the UPB protocol itself because the switches aren't aware of each other. All they know is "If this button is pressed, do XXX" and "If I see Link XX, do XXXXX" - they have no idea how many other switches are responding to that same link - it could just be one, or it could be 250. Also the switch sending the link has no idea which switches are listening for it - it just sends the command. For that reason they couldn't tell the switches to transmit their status after responding to a link because there's no way of knowing if it's going to be a single switch that responds, or 250 - clogging up the network.

The way controllers get around this is by learning the behavior of the link and after it's executed, they query each affected switch one by one to get their updated status. Unfortunately that's just too much for the Elk to handle.

I currently have the Elk integrated with the lights as well as Elve (I use two separate PIM's - one for each) - Elve tracks status perfectly.

Work2Play said:

I agree completely with Digger... ZWave is definitely more accessible lately - being sold in Home Depot and Radio Shack - and a little cheaper.

What scares me is the stories I've read where a network has learned a path through a device that's portable or has been moved and people having to reprogram their whole networks over again - but I don't have enough first hand experience to speak to it. The fact that it doesn't need powerline sure does make it easier to get door locks and thermostats communicating as well. I'll be sticking with UPB but I know it won't be long before I support both.

Click to expand...

Think of the Z-Wave network as a mini-internet (we'll call it 'house'). If you move a core router to a different state (room), the routing will change as well. That said, I can't think of too many occasions where I had to move my UPB hardware to different location (appliance module testing is the only thing I can think of), so it really shouldn't be that scary.

At this time I'm using Z-Wave only for external appliance and lighting modules with my HAI OPII. I have no issues with reach in the network; I see occassional delays.

I am using UPB for internally mounted wall switches (in metal boxes with metal conduit thruout the home).

I do remember writing some "stuff" years ago about root bridges and spanning protocals. It seemed if there were issues it was always related to the algorithms and how they were utilized. Sometimes what worked well was a circumvention of these said algorithims; later developing even more granular approaches "lumping" groups of devices achieving some QOS. There have always been "camps" of thought relating to a logically "flat" created network versus a 3D like automatically created network relating to servicibility. Its easier to sometimes fix what you see than make assumptions based documention relating to the algorithms or what you think you see.

That said routing paths can change; as Dan noted above.

RF takes the whole endeavor to a different prospective with the introduction of propagation properties.