Elk M1 and Zwave Sensors

[mikei-ma]

I was reviewing the M1XSLZW instruction manual and couldn't find
reference to using zwave sensors. Does anyone know if the M1 supports
adding other sensors using the XSL+VRC0P+3?
 
There's a whole host of sensors now available (specifically from Aeon Labs) and
I'm wondering if they can be used with the Elk. I've attached their ECEDIA Brochure for referece.
 
Mike
 
 
https://dl.dropbox.com/u/16259564/Aeon_Labs_CEDIA_2013_brochure.pdf
 

 

[electron]

Very good question, someone is going to try this.  From a technical point, there shouldn't be an issue (guessing you might be able to treat temp sensors as thermostats, I/O sensors as appliance modules).  If you don't get an answer, let me know and I'll ping the ELK folks.

 

[crossbar]

I know is an old thread but I can't find any references to z-wave sensors being used as inputs to an ELK M1 system via the ELK-M1XSLZW with VRC0P+3.  Does this setup support z-wave inputs and if so how?  It does not even seem to support reading the state of z-wave output modules.
 
Also does anyone know if ELK has any plans to make an up-to-date system (the M1 is very deprecated)?

 

[Del91574]

The M1 and Zwave is/was intended to only provide an output from the security panel to the Zwave device, not vice versa. If you have any item, not just the M1, constantly poll and look for Zwave data changes the entire response is going to be very slow.
 
Zwave shouldn't be considered as an input or trigger to the M1 directly. If you wanted to offload the Zwave to a 3rd party and go that route, sure, but otherwise, not really.
 
None of the security panel manufacturers out there support Zwave as an input. Just not secure and reliable enough.

 

[crossbar]

So no way to use Z-wave sensors? 
Or to read back the power draw of an attached device (many of the z-wave modules will measure the power draw of a device).

 

[tadr]

What exactly do you want to do?  I use the Elk M1 plugin on my Vera ZWave controller and it works very well.  For example, I use a button on an elk keypad to trigger a zwave appliance module.  I also use a motion sensor connected to the Elk to trigger a light.  You can just as easily setup a rule in the Vera to turn an output on the Elk M1 on/off and then write a rule to respond to that on the Elk.
 
Edit: I see you mentioned power monitoring.  You can set the Elk counters from Vera, so I would think you could have the Vera write the value to a counter and then react to that via the Elk.  I'm not sure why you'd want to do this, though.

 

[Del91574]

What exactly do you want to do?  I use the Elk M1 plugin on my Vera ZWave controller and it works very well.  For example, I use a button on an elk keypad to trigger a zwave appliance module.  I also use a motion sensor connected to the Elk to trigger a light.  You can just as easily setup a rule in the Vera to turn an output on the Elk M1 on/off and then write a rule to respond to that on the Elk.
 
Edit: I see you mentioned power monitoring.  You can set the Elk counters from Vera, so I would think you could have the Vera write the value to a counter and then react to that via the Elk.  I'm not sure why you'd want to do this, though.

He mentioned using Zwave as a system input to drive a M1 output or similar. Your examples are 100% the opposite.....M1 inputs driving Zwave outputs.
 
The OP would need to spell the application out and hardware, but for the majority of intents and purposes, Zwave inputs are NOT going to drive an M1 to provide output reliably 100% of the time. IE: Zwave motion trigger the M1 to send email, push text out the keypad, etc.

 

[crossbar]

Z-Wave Sensors as inputs - I.E. Z-Wave Tilt sensor for garage door sensor.  Z-wave Motion sensor, Z-wave door sensor?
 
The power monitoring would be nice to see when the attached device has shutdown (i.e. a gas water heater, file server, etc) and then safely turn off that device.  Then it can be turned  back on as needed.
 
It would be nice to do this with only the M1.
 
Also I have not tried this yet but it looks like a UP command can be sent to the VRC0P and then it should receive the status of the Z-wave module(s).  Will the M1 then update the Lighting ouput state per the status responses or does this have to be done manually by looking for the serial strings from the VRC0P?

 

[Del91574]

You're not going to get Zwave inputs to natively talk to the M1 without a third party unit and some creative programming.

 

[crossbar]

Ok Thanks.  Very disappointing.  And very misleading by Elk.  The M1 sure is a kluge (hardware and software).   I can't believe the M1 is still their primary product.  The hardware design and software are at least a decade old (maybe 2) and they still don't have a new product that is up todate?
 
I will see what I can do manually with the VRC0P serial messages.

 

[Del91574]

I would disagree wholeheartedly Crossbar. It appears you're reading far more into the product that what was ever documented: http://www.elkproducts.com/partner_manufacturers.html  and here: https://www.youtube.com/watch?v=FF6ikgmWizE  Straight from Elk themselves.
 
Integration would mean you have a Zwave output (or almost any other manufacturer out there) and would like the M1 to integrate/control. Integration is not a bidirectional street for every product or manufacturer out there.
 
The M1 was released around '04-05. It is as up to date and relevant as any other manufacturer's product out there, even more so than it's contemporaries. It's had multiple firmware updates and some basic hardware updates/additions over the years. For example, Honeywell, DSC and DMP can't even do half of what the M1 can do via Zwave.
 
What are you trying to do via a Zwave input that can't be done via other means.

 

[crossbar]

I did in fact choose the M1 (recently) over all the other options currently available so I am not saying there is anything better out there.   But that is not to say that there couldn't and shouldn't be much better options.
 
I am an Electronics Engineer and I programmed ZigBee devices (many years ago now) among other things.   So far I have run into a number of system bugs, poor system implementations, limitations, and just an "old" system.
 
It seems time for a new hardware design integrating all the missing pieces into a single box (XEP, serial expanders, interfaces to automation protocols).    Z-wave and all new protocols are two-way (even x-10 is two-way).  A one-way implementation is just a hack.  And support for only a single protocol is again just not moving your product forward.   I understand the "build on old existing hardware and software idea" but you need to also move ahead.  And many times that means a major if not complete redesign.   Continue to support and update the old design but build a new design going forward.  Now maybe the market is not there to support it I don't know.  And maybe the M1 does not have the resources to support full implementation of the z-wave protocol but then it would be good to state:  Z-wave output only support.  Does not support Z-wave sensors or any other z-wave device feedback (switch state, power measurements, etc).
 
Yes you can almost always do things another ways but that is not a good long term solution.

 

[Del91574]

Without getting too off topic,
 
I work with plenty of EE's and SWE's in my daily business. I think you might be just missing the component of the industry and what the equipment actually is and sold as, which would be a security system panel. The industry and market are always going to be conservative and especially on an embedded platform, not going to jump quickly into the bleeding edge. The industry can't because of UL and related, required listings.
 
What part of your complaint of wanting a complete package takes away the difference between an M1 and an OPII. The M1 is modular and items can be purchased as needed or desired, where to get the same basic level of functionality out of an OP, you need to buy the flagship product (at 3X the cost upfront) and are limited on serial port location vs. the M1's option anywhere along the bus. The manufacturer would be shooting themselves in the foot in the marketplace if they put a product out that forced everyone to buy the entire expansion or capabilities up front.
 
Think about it. I can buy a M1, very capable, for sub-$500. The OP is 3X that. Say I don't need the 5 the OP has. There's $75-100 each on the sticker right there. Same goes with ethernet. While it'd be great if every panel out there had a TCP programming or web connection, that's a $100 line item right there on the panel itself. So basically, I already ran up roughly $600 worth of "trade" cost on the panel itself to match the OP on those single line items. Say you want a 3rd party support for X powerline protocol....now you're adding the line item pricing for that on top of it.
 
The long term solution would be yes, a redesign or upgrade, but it would need to be tempered with reality. Even something as trivial as a $2 on board relay is going to add expense that is passed down to the end integrator and further down to the end user. If you can't justify it needs to be there for every install, it's pricing your product out of the market for another competitive unit.

 

[crossbar]

I do understand and agree with a modular approach.  However things like the XEP should be either a plug-on module or included.  I think the only reason people don't have an XEP is the high price.  To add Ethernet to the board should be <$50.  To add additional serial ports to the board should be <$10.  Remote serial modules are a good option when needed.  Even the XEP module is very limited for example there is no way to include dynamic information in e-mail alerts (like zone that triggered an alarm etc).

The current system is a kluge and I understand why (additional functions added on to the original hardware over time).  But there are just some basic implementation issues with the M1.  For example the way Whenever rules are implemented you need 2 or more to do most anything so there should be a way to group rules.  Also Outputs, Lights, etc should be virtual and then have the ability to "map" them to a hardware output.   A Rule should be able to read the actual state of a bypassed input but can't.  And to add insult to injury the Whenever Zone x becomes secure And Zone x is not bypassed Then rule actual does not work this is a bug (where is a good place to report bugs like this anyway).

As an alarm/automation system it should implement Z-wave as an input to be able to use Z-wave sensors, not just outputs.  You would think you could use a Z-wave garage door tilt sensor with the M1 just like any other Wireless garage door tilt sensor.

So back to the original topic - I am seeing other places that it appears the Z-wave implementation does at least support switch feedback.  However it appears that unless the remote device autonomously sends the feedback the M1 has no way to request it.  As I questioned previously the "UP" ASCII command sent manually to the VRC0P should request all the modules to report back their current state.  This should then update into the M1.  I say should.  I have not had a chance to try this yet.  I was hoping someone would have some insight into this approach already.

 

[crossbar]

I was able to test the Request and Update commands of the VRC0P+3.  The Update command does nothing for updating the M1 lighting status (the VRC0P+3 documentation is somewhat unclear about this but does correlate to Updating other controllers not actually requesting an update form devices).  The Request command ? does indeed update the lighting status of the M1.   It can be implemented as a single device request or multiple device requests (I have not yet found a configuration that does all device).  To implement this create a text string with ">?N" then add the devices to update spaced with commas and end with a CR+LF (i.e. ">?N2,3,7,8^M^J" to update devices 2 3 7 & 8).  Create a Whenever rule to send this text string to Serial port 1 (or the address # of your ELK-M1XSLZW).  This command will have to be executed before you want to check the state of a M1 "lighting device".  Also it can take a few seconds to update so a delay should be implemented before reading.

Now the question is can you configure a Z-wave sensor as a M1 "lighting device" and have it update the status of that device based on the sensor feedback.   I don't know how any of this is implemented in the ELK-M1XSLZW and VRC0P+3 so I don't know if this would work or not.  And I don't yet have any Z-wave sensors.  I will update if/when I get one to test this.