Bad checksum and incorrect message length

I'm seeing the following ascii coming out of my Elk M1:



The 14IDRF line indicates it has a hex length of 14 (20), but it is hex 15 length (21).

The 3DRF looks like a bad checksum.

Anyone have any idea what's going on.
The strings are being generated quite frequently.
It has something to do with elk two-way wireless zones.
I was able to stop the messages by turning off the undocumented global 44 "55555" option.
That option tells the M1 to send the RF communication data in ascii thru port 0 so you can see RF traffic thru putty or hyperterminal.

In my case, i had turned the option on years ago. Then when i recently started experimenting with Home Assistant, HA's log files kept filling up with error messages from the M1 where the Hex length was incorrect and another that had a bad checksum. Like hundreds of times every day.

HA is correct in that the hex length isn't what it should be and the checksum doesn't calculate properly.
So it's logs were just filling up with these messages.

Anyway, by telling M1 not to send the messages, now it won't see the messages and report that it doesn't know what to do with them.

The solution was easy.
But figuring out a solution was not!
Why is the global 44 "55555" option not documented in the Elk M1 ascii book?
Why are the RF ascii codes not documented?

I had thrown in the towel on HA because of this.
It's no fun trying to evaluate something with logs full of errors.

But now i can revisit HA and the Elk integration.
It is pretty awesome. It is worth looking at.
You can create dashboards that show doors open, temperatures, last user, troubles, outputs on and off.
You can turn outputs on and off from the dashboard.
Create automations, use elk zone changes and output changes as triggers to change things on other hubs.
It sends emails and has a killer phone app.
HA integrates with everything - literally.
If the price of tea in china were to change, you could tell HA to tell Elk to speak something.
I didn't know there was a way to send RF communication data through port 0. But I'm puzzled. Global 44 is documented in the manual as a read only location. How are you setting it to 55555?

[edit] I found the answer to my question in this old post from Spanky:

Last edited:
I pasted this from an old post back in 2008.
It's the only place that mentions this.

From the M1's keypad enter installer programming, go to Globals G44, right arrow, enter 55555 into the a: field, press ***.
Every transmitter transmission received will be sent out the RS-232 serial port in this form:


A2 = address of receiver on the RS-485 keypad data bus
Z21 = zone number of transmitter enrolled in M1
A29B68 = Serial number of transmitter
LB0 = battery in transmitter is OK, LB1 = battery in transmitter is low
B0 = button data from transmitter, usage will vary according to type of transmitter
L11 = hardwire loop 1 is violated, L10 = OK, usage will vary according to type of transmitter
L20 = hardwire loop 2 is OK, usage will vary according to type of transmitter
R0 = Reed switch in tranmitter is closed, usage will vary according to type of transmitter
Tp1 = tamper switch is violated, usage will vary according to type of transmitter
Tb0 = test button is OK, usage will vary according to type of transmitter
M1 = Manufacturer of transmitter = GE, M2 = manufacturer of transmitter is Ness Security
CrB0 = CRC byte of data received at RF receiver. This is verified by the M1 when the RF data is received by it.

You can view the data with HyperTerminal or the M1SDK program connected to the RS-232 bus or the data coming out of the M1XEP Ethernet connection.

If the M1 is powered down or reset the RF data will stop until the procedure above is repeated.