Elk and Lighting

[rcharris]

All:

I have recently finished installing an Elk M1G, primarily for security. However, I chose the M1G because of the promise of automation capabilities, specifically lighting control. I am quite satisfied with the system so far, and am now deliberating which technology to use for lighting control. I am looking at three possibilities, all with varying degrees of support from Elk on the M1G: UPB, Z-wave, and Insteon.

I have been doing quite a bit of on-line research on these three (and others that have dropped off the short-list). Many thanks to you all on this forum, as I have learned a lot from the posts here. I have also culled some data from the Elk web-site equipment manuals. I have started a small spreadsheet comparing UPB, Z-wave, and Insteon with regards to how they interact with the Elk M1G. I would appreciate any feedback, corrections, or additional information that anyone can provide.

I've attempted to attach a copy of the spreadsheet (Excel converted to html). I will add any inputs into the sheet and include any other pertinent comparison data and re-post, keeping this current for others benefit. I am new to the forum, so please advise me if there is a better way to work with you all and / or post this information. I really am mostly interested in how these technologies interact with the M1G, but would be open to pertinent information for "hybrid" systems. (Example: M1G Elk coupled with Other automation controller either via serial or digital IO)

Looking forward to hearing from you all:

Best Regards,
Rod

 

[tech-home]

Nice work,

Elk is working on Polling feature for Zwave.

Newer Zwave switches will transmitt status.

 

[AutomatedOutlet]

Newer Zwave switches will transmitt status.

Don't think any of this is yet available.

 

[upstatemike]

You could list PowerHome as being the Insteon version of UPstart since it can be used to fill that function. The lower cost of Insteon switches will more than cover the price of PowereHome.

 

[IVB]

UPB: Modules do not send status in response to "Link" commands

I assume they do send status reports from individual and manual operations if "Transmit Changes" bit is set with UPStart

I'm contemplating UPB; I thought the switches will send status changes if you manually flip the switch - is that what your 2nd sentence means? NOt sure what "module" refers to.

 

[Steve]

Yeah, not sure about that. I get 2 way status on my UPB. I can watch my TS interface and if I change a switch manually I see it reflected almost immediately on the TS. In UPStart the device has "Enable Add/Delete Transmit Link feature", but not "Rocker 1 tranmits". I think the important one though is the checkbox for "Report light level after any button or rocker is pressed".

I do not have plain links setup right now but I believe they will work as well.

 

[AccessX10]

Under Other you list the following for INSTEON:

Cannot remove an individual device, must re-link all devices any time anything changes

Shouldn't this be under Z-Wave instead of INSTEON? You don't have to do this with INSTEON.

 

[toymaster458]

The way the Elk works with INSTEON if a device fails at Device location 23 and you get a replacement and want to keep the replacement at 23 you have to reset your M1XSP and relink all the devices in the same order or another option is link the replacement and the replacement gets the next unused Insteon Device location. Then you need to reprogram anything you had pointing to device location 23 on the Elk to the new Device location number.

This is because the Elks Lighting Database was not designed with the idea that a light switch could not be asigned an address. With X10 and UPB you can tell the switch what ID it is with INSTEON you can not.

Elk realy needs to add a column in the Lighting Database for Device ID this way it will make it possible to put devices where you want them instead of entering them in the way you want it.

 

[Spanky]

I agree with Toymaster that all lighting devices should be individually addressable. When one fails, you want to reassign the address to that particular device. Insteon is not the only one that has the problem!

But I think all the advanced lighting systems are too complicated!!


Wife factor: If my wife can install a Christmas tree light control without my help, then its good.

 

[upstatemike]

I agree with Toymaster that all lighting devices should be individually addressable. When one fails, you want to reassign the address to that particular device. Insteon is not the only one that has the problem!

Insteon does have individual addressing. It is in the xx.xx.xx form and is written right on the front of the switch. Replacing a failed switch should just be a matter of going into a controller and overwriting the old address xx.xx.xx with the address of the replacement yy.yy.yy

I don't think you can blame the switch for the fact that it is not that simple. A lot of software seems to want to map Insteon addresses to some sort of pseudo X-10 formatted address or to displace one of the 256 valid X-10 addresses.

X-10 is on it's way out so just let it go. Instead of trying to deal with some pre-defined table of addresses and then force eveything into one of those slots, why not declare devices as you need them and then assign them the actual hardware address?

 

[elcano]

Elk realy needs to add a column in the Lighting Database for Device ID this way it will make it possible to put devices where you want them instead of entering them in the way you want it.

This look familiar to me. Isn't this the way that the Wireless Expander works? You just enter the device ID whereever you want it.

 

[Digger]

That does sound like the RF setup and would be a breeze to setup. I just set up a serial module today and one insteon switch and it worked perfectly. I can see how this can be annoying to setup a large amount of switches (especially if you have to re-enter everything again at a later date).

I then tried to setup (note tried) the ethernet module and now my panel no longer recognizes the RP Access Code (the default was never changed from the 246801). Now I cant access th panel via a serial cable or the ethernet so I am high and dry so to speak (and I had plans to setup everything this weekend due to the snow etc.).

Anyone have any ideas??????? HELP!!

 

[Spanky]

Digger,
Goto keypad installer programming, 07-Globals, 45-Reinitialize to Factory Defaults, Enter 99. The M1 will be reset back to factory settings after about 2 minutes. The status LED will blink 4 times while it is resetting to defaults.


Using ELKRP, go to the M1XEP menu and FIND your M1XEP on the network. Then Click Use These Settings. Try connecting again. You will have to at least open up ports 2601 on the M1XEP menu and on your router to access the system from the outside world. Read the instructions on how to open the ports.

Keep us informed of your progress. I will be around this weekend to help.

 

[rcharris]

All:

Thanks for all the help and input. I've attached an updated comparison spreadsheet, please have a look and review it. UPB seems to have the fewest performance compromises, but Z-Wave and Insteon have some very attractive dollar-costs.

Some specific questions I now have, and some assumptions I would like to verify:

For UPB:
1) Can an M1G automation rule be triggered by a manual switch operation? (Example, if I turn on the porch lights by hand instead of by automation, will I be able to sense that as a trigger and turn on another light?)

For Z-wave:
1) Since manual switch operations are not reported by the switch to the M1G, I assume that I can not trigger an automation rule in the M1G based on a manual switch operation. True?

For Insteon:
1) I understand I can use PowerHome to set up device-to-device links between Insteon devices (switches). I assume there is no way to use this to set up the necessary link tables into the M1XSP. True?

2) I assume that if multiple Insteon devices (example: switches) are linked to each other, and if one or more of them are linked to the M1XSP, then M1G can control the linked device ensemble by controlling one of the individual linked devices. True?

3) Insteon devices reportedly do report status if turned on or off, (not dim-levels). Then can automation rules be triggered by a manual switch change to the on or off state?
If I implement devce polling in the M1XSP, can I trigger automation rules based on the status that (ultimately) comes in as a result of the poll?

Thanks for all the help. I am getting excited about buying switches!

Regards,
Rod

 

[Spanky]

For UPB:
1) Can an M1G automation rule be triggered by a manual switch operation? (Example, if I turn on the porch lights by hand instead of by automation, will I be able to sense that as a trigger and turn on another light?)

Yes, UPB can report the status back to the M1 if properly setup.

For Z-wave:
1) Since manual switch operations are not reported by the switch to the M1G, I assume that I can not trigger an automation rule in the M1G based on a manual switch operation. True?

Currently, due to a patent problem you cannot update status in the M1 from a manual switch, but there are some new Zwave systems coming out that should give you more options.

For Insteon:
1) I understand I can use PowerHome to set up device-to-device links between Insteon devices (switches). I assume there is no way to use this to set up the necessary link tables into the M1XSP. True?

You have to link the switches back to the Insteon interface module to the M1 for manual switch status. There is a thread on Cocoontech in the last week on how to do this.

2) I assume that if multiple Insteon devices (example: switches) are linked to each other, and if one or more of them are linked to the M1XSP, then M1G can control the linked device ensemble by controlling one of the individual linked devices. True?

I believe that is True, but I have not set up that configuration.

3) Insteon devices reportedly do report status if turned on or off, (not dim-levels). Then can automation rules be triggered by a manual switch change to the on or off state?
If I implement devce polling in the M1XSP, can I trigger automation rules based on the status that (ultimately) comes in as a result of the poll?

Yes, when a device changes its on/off state, a Rule can fire. Polling will have the same effect, when the state changes, a Rule can fire.