Reply To: Ascii output from M1 xep hex length wrong

[Kevin Wilson]

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.