Elk M1G RS-485 Messaging Spec?


Active Member
Hi All,

Since it appears that Elk has pretty much given up on receiving any status signals from Z-wave devices that "weren't sent from the Elk Zwave controller" I decided to do a little experimenting...

I have several Z-Wave motion detectors that are enrolled and copied over to the Elk Z-Wave controller (in addition to all of the other devices). This is a straight copy from my "master" handheld controller.

Elk states that the M1 Z-Wave controller cannot see status signals unless it sent out the request in the first place (light on/off, etc). This would seem to rule out the Z-Wave motion detectors since nothing is ever sent to them to change state.

ANYWAYS; I installed an RS-485 signal sniffer on the bus and began examining the data coming across the bus (Keypad, Zone Expander, Z-Wave interface, etc) and lo-and-behold. There IS data being generated from the Z-Wave interface to the Elk when the Z-Wave motion sensor is being tripped!

My question is; the data stream is not in an easily recognisable format and I'm not sure exactly how the Elk's firmware is set up to respond to it since I don't have the messaging spec for it. Is it available or is it a proprietary spec?

I have been able to, by examining the data, discern which of the (currently two) motion detectors is being tripped so my next project will be to program a BASIC STAMP to examine the data across the RS-485 bus, see if a motion detector was tripped and then trigger one of two zones on the Zone Expander to signal the motion.

To be sure, it IS a hack-job but since Elk appears to have given up on the Z-Wave expander, this is the only way I know how to get the Elk to respond to the motion detectors. Today I'll be ordering some of the two-way Z-Wave switches (that send back status codes) and see if there is traffic generated for that as well. If so, the Basic Stamp will be re-programmed to handle those as well. Instant and Correct status reporting with no polling!

All of this would be totally unneccessary if the Elk would simply respond to the codes being sent from the Z-Wave expander when the motion detectors go off. As a programmer, this would seem quite easy to implement in the firmware (as opposed to my hardware-hack workaround). Why doesn't Elk do this? :)

Regardless, I'll be programming and wiring up the Basic Stamp this weekend and will send pics if anyone is interested.

Just thought I'd let the Z-Wave crowd in on "The New Hope".

Here is the Zwave scoop.

Current Zwave RF plugin board which is mounted on the M1XZW does not have enough program room to implement the code required to do the status update from a wall switch. ELK has a sub contract company doing a new RF module with a separate micro that has the room to implement the status update software. We are waiting on prototypes.

Any data you observed from the M1XZW was probably polling data from the M1. I can assure you, if the Zwave status data was there, it would be available and already implemented.
Spanky said:
Any data you observed from the M1XZW was probably polling data from the M1.

Thanks for the "inside scoop" on the M1XZW. Please excuse my curiousity but a question or two if I could:

1) If the data I am seeing is polling data for the Z-Wave motion detectors (I can see the identifiers for the 2 motion detectors) then why would the controllers not then, in turn, send the status data back to the XZW since it originated the request?

2) If I look for only a data stream from Motion Sensor #1, sit still and then move 5 minutes later I'll see a data stream for that identifier. If I do the same thing and wait 12 minutes (as a test) then, and only then, will I see this same datastream coming across. (I am sniffing for just these packets, nothing else). As I have varied the times, it would seem unlikely that the Elk would be polling the interface at just that moment.

I'm not trying to be difficult or anything, but to me, this sure seems like a sure-fire way for the BASIC stamp to reliably trigger off of the motion events. In addition, a rule or two in ElkRP could toggle a "flag" on or off depending on the outputs from the stamp for a fail-safe way to check the status.

I feel for Elk with regards to the embedded controller memory limitation, I live with this type of limitation every day in my programming work.

Thanks again,
I asked our Zwave guru about what you were seeing on the data bus. He said that he has not tried a Zwave motion detector and does not know what type of data it is sending. Perhaps it is sending data to the M1XZW Zwave Secondary Controller since it is not a light switch and not subject to the Lutron patents.

This requires further investigation.

Thanks for the heads up.

How are you coming on the Basic Stamp and protocol?

The reason I ask is I'm doing the same work but with an Ethernut board.

I'm coming from a fully homegrown world running under a QNX/Linux mix and migrating to Elk because, in the long run, it has a better resale value and accomplished easily some of what I've wanted to do for years but never had the time. That said, I still didn't want to loose a lot of what I had and the Elk provided "basic" functionality in some areas.

I'm doing the RS-485 sniffing but I have a background in embedded processors also and jumped head-first into the Serial Expander/Freescale processor because I see it as the best long-term "integration" environment if you don't need Ethernet.

This has been a weekend project so I'm more than willing to share to move forward faster.

- Ethernut Packet deliniation (Request, Response, Notify)
- Checksum calculation ** this was the hardest **
- Heartbeat/Status/Notify packet decode/response
- Light Change request/response
- Relay Change request (no response)
- Telnet interface to bi-directional packet data
- Decoded Serial Expansion "binary" for creating downloads
- Stated basic docs on a lot of "global" transmissions - little details
- Headers/docs for what I've decoded

To Do:
- Thermostat packets
- Input Expansion packets
- Decode arm state
- Timesync packets
- Text string transmissions (needed for some programming)
- Bootstrap code for Serial Expander for "custom" implementation
- Decode "General Serial Expander" so I can directly inject commands (relay off)

I am working to accomplish the following:

- ALC (all lighting) appears to have a problem with rapid-fire changes and transmission delays. Open issue with Elk but the problem is delayed echos - may not have room in the module to fix;

- ALC doesn't send dim levels with local changes;

- RCS doesn't provide any information on the mechanical status (fan, ac, heat, zone dampers, etc - all as "inputs") or allow activation of setback (relay output) - I do MRTG tracking of a lot of points to watch electric bills and this was a bin one to loose;

- Full tracking of "changes" and event injection even when RP is active - I almost lost a sprinkler pump because a PC was running "sprinklers" and I left it in program mode... argh.

I see the Elk as a *great* platform to build on - any help welcome. I plan on making whatever I learn available for those that have the need - "Unsupported by Elk" as a fair warning.

What hardware / software is required to do RS-485 sniffing?

Is it just a RS-232 to 485 converter running with something like hyperterm?


In theory you can use a 485/232 converter but the format is non-standard and since it's pure binary Hyperterm can't help you.

The basics:
- 38,400 baud, No parity, 9-bit word length and 1 stop bit
- Packet deliniation is done by idle detection

Note the 9-bit word length - that excludes a lot of "normal" options and forces you do have an advanced serial IO board or microcontroller/PIC development hardware.

While today I'm using an Ethernut development board with a modified serial interface driver I did get good captures for starting my decode process using a DigiOne 232/484 to Ethernet bridge running in 8-bit mode and sending UDP packets (watch end-of-packet timinigs) to do idle detection.

I did start with a Front Line Equipment Comm Protocol decoder but it didn't handle 9-bit and gave me all framing errors.