Elk two way wireless

mikefamig

Senior Member
I have searched around cocoontech and haven;t been able to find any strong opinions one way or the other on the elk two way wireless tranceiver and devices. I am a DIYer designing my first system and like the benefits of two-way comm but am disappointed by the small number of devices available.
 
Now that the technology has been around for a while I'd like to hear from anyone who has the system or has installed it. Pros and cons opinions etc.
 
Mike.
 
drvnbysound said:
I'm looking forward to using it soon... I only wish their flush mount contact would be available before the fall.
I plan to wire my window sensors but would like to see door locks and flood detection and some of that neat stuff. I haven't bought yet and may go with Honeywell ademco 5800 instead of the Elk. I'm still undecided.
 
I'd also like to hear from anyone who has experience sith X10 wireless technology. I've been reading that it is becoming obsolete but it is built into the Elk controller and may serve my purposes. What are X1-'s shortcomings and why has it lost popularity?
 
Mike.
 
X-10 lost popularity due to some quirks....noise issues, etc.

The largest reason has been, as of late, QC and devices not being manufactured anymore.
 
DELInstallations said:
X-10 lost popularity due to some quirks....noise issues, etc.

The largest reason has been, as of late, QC and devices not being manufactured anymore
Well then I won't plan on using X10 as a long term solution but I may buy a keyfob and a couple of window switches to get me by while I study the other technologies.
 
DEL - do you have knowledge of the zwave adapter for the Elk M1? I was told by an Elk rep that it was one way communications being output only. Do you know if this is true and if two-way fully operational zwave is possible on the M1?
 
Mike.
 
One way only.
 
The M1 was engineered before Zwave was really even on the radar. There's plenty of application notes and hardware notes from Elk about their integration and what can and can't be done and the caveats.
 
You need to determine what the HA devices are intended on being used for or if security devices fit the application better.
 
The X10 window sensors aren't suitable for security and won't recognize like "Zones" on the elk - you need to go with one of the elk-supported wireless technologies for wireless sensors.
 
X10/Insteon/UPB/Z-Wave are for automation, not security.
 
Work2Play said:
The X10 window sensors aren't suitable for security and won't recognize like "Zones" on the elk - you need to go with one of the elk-supported wireless technologies for wireless sensors.
 
X10/Insteon/UPB/Z-Wave are for automation, not security.
But I read something that led me to believe that X10 was built into the Elk controller. I didn't look into it because it is an older technology that seems to be going away. Back to the books.
 
Yeah, the M1 has a special port onboard just for X10 PIMs but it's kinda irrelevant.  You can just as easily add an XSP serial port to the M1 to tie in UPB/Z-Wave/Insteon just the same.  Its true that the heart of the M1's lighting automation was built around X10 primarily but it's been adapted to work with the newer technologies.  In fact, what you'll find is that the M1 has one set of lighting addresses it can handle - a total of 256 because that's how many total X10 device ID's you could have in a home.  As they've adapted it they've created mappings of where ZWave or UPB devices fall into those same 250 based on their IDs.  In fact, if you're running more than one technology, you have to take care to ensure there's no overlap in any device ID between them or you'll have multiple devices responding to the same command.  I've very rarely seen this as an issue that comes up though - just because by the time someone adds a second protocol, they know their way around the system well enough to know the implications, and usually one technology is the majority of the devices, with the other being added to support specific things light door locks or thermostats keeping device numbers minimal.
 
I personally do still use a little X10 - but not the powerline, just the RF using a W800RF32 X10RF receiver to RS232 - I have that hooked into another automation controller translating commands into UPB so I can use some cheapo X10RF handheld remotes and motion sensors in a couple areas.
 
If you want to see more about the specifics of the lighting addresses, there's a lot of info in the XSP manual.  You can google the PDF easily enough since you wouldn't have a login to the Elk site yet.
 
It seems like Elk's two-way wireless might serve a couple purposes:
1.  Reduce energy consumption by battery powered devices by enabling transmit power to be throttled so that "just enough" is used.
2.  Allow interconnected smoke alarms, where if one goes off, then they all go off.  This is an NFPA requirement, and it can't be met if smoke alarms are transmit only.
 
mikefamig said:
Well then I won't plan on using X10 as a long term solution but I may buy a keyfob and a couple of window switches to get me by while I study the other technologies.
 
DEL - do you have knowledge of the zwave adapter for the Elk M1? I was told by an Elk rep that it was one way communications being output only. Do you know if this is true and if two-way fully operational zwave is possible on the M1?
 
Mike.
 
 
DELInstallations said:
One way only.
 
The M1 was engineered before Zwave was really even on the radar. There's plenty of application notes and hardware notes from Elk about their integration and what can and can't be done and the caveats.
 
You need to determine what the HA devices are intended on being used for or if security devices fit the application better.
 
Zwave is two-way; the Elk can control devices, and devices can report their status.
 
Yes, Zwave is 2 way, but the polling response times and required scans slow the panel down to a creep. 1/2 devices, sure, but for a loaded up network, there are issues. This has been covered in their white pages for years.
 
The 2 way smoke detectors do not completely meet code to replace interconnected smoke detectors. The tandem portion is still dependent on rules and wireless transmission and the detectors are not a peer to peer communications route. As I stated elsewhere, I'd have to go through the latest adopted NFPA, but there are a ton of requirements for tandem ring and wireless detectors to meet before they'd be allowed to replace a required system. I've yet to see or read documentation that states if the units trip each other or if it's driven through rules.
 
I'd need to know a lot more details from engineering before I'd say this is compliant to replace a tandem ring system.
 
Sure, but you don't have to poll if the devices support instant status reporting. Personally, I poll once a day and just live with the rest (until I can upgrade or switch to something else).
 
My point was mainly to acknowledge that Zwave is 2-way; my deadbolts and thermostat report automatically.
 
Back
Top