Interesting. I wrote the integration library and never saw messages like that.
Where are you seeing the messages? What library? Does ElkRP work for you normally? What are you running the code on? Windows, Linux, …?
It seems like there is one garbled message following each good message. Could this just be a printing this?
What else can you tell us about your setup?
Im running it on an ESP8266 which Ive now simplified back to just receiving Web data (through the Ethernet connection to XEP) and forwarding it straight back out to Serial which is listening through a standard terminal on Windows. I did the mirror just to confirm what I was seeing and why!
Im doing an integration for SmartThings, which doesnt allow you to connect to specific ports and keep open connections, needed for an integration like this. The integration looked nice, hence I thought I would ask my question here!
For my integration the ESP just keeps the connection to the M1 open, and then forwards data to either ST or MQTT (it supports both) via JSON. However, the testing I am doing here is just the mirror between Web and Serial because my processing was failing to understand the messages (due to the garbage data!)! Im also doing this integration remotely (I dont have an M1!), as I felt like being a nice person, so testing is quite hard! Haha
Knowing that it isnt supposed to be there is useful to me, and I will do some more probing to find out what settings are used on the XEP, and what could be driving the dodgy data! I’ll also write the mirror code byte by byte, rather than byte array just in case that is reading something funky. Have you tested with the XEP aswell, or only with direct serial connection?
[We should take this convo off this thread, off topic]
Is this your setup:
ElkM1 Serial <-> XEP <-> ESP8266 Ethernet <-> ESP8266 Serial <-> Windows COM port
Which part is printing the log message? The ESP or Windows? Its almost as if when the message on the ESP is forwarded from Ethernet to the serial port that the write is writing too much. NUL terminated buffer? Wrong length?
In my experience, I have never had a problem with what the ElkM1 sends (and I receive). Mind you I’m running the latest ElkM1 software. If you are integrating with an older version there could be a problem.
Sorry for the late reply. I cant message you as I am new to the forum, but I will send a message as soon as I’m allowed. Just to confirm that representation of the setup is correct, have tried the ESP and Windows printing the log message but get the same results.
I think it must the connection between ESP reading characters from the XEP and serial buffers going awry. I will try adding a few extra yields/delays and see if that fixes things while the buffers fill/empty.
One question though please, what character(s) does the XEP use to terminate the send ASCII strings? I would assume /r/n based on what it needs during the send, but perhaps there is also a /0 ? That answer would save me doing some extra debugging if this doesnt work, as I can ensure I test it fully on my end!
Thanks again and sorry for the off topic chat (though hopefully useful for somebody at some point in the future…)
Terminated with CRLF (\r\n). Google “elk m1 ascii protocol” and you’ll find a PDF describing everything in great detail. There’s an older version from 2008 linked at the top of this thread, too, but it will likely be missing various updates.
You could verify some of your setup by simply skipping the ESP and connecting to the M1XEP directly with telnet (or similar) and see if you get the same garbage or not.
Not NUL terminated, just \r\n. If I were to guess you are printing beyond the end of the received characters. Just sayin 
Thanks both, have totally re-coded the (simple) code to read the serial data, so hopefully that will help with any weird incompatibility issues! (waiting for somebody to test it)
I just found it strange that the ‘extra’ garbage that appeared seemed to be semi-predictable based on what command had just been received - if it was overrunning a buffer/array then I would expect it to be very unlikely to return to the same garbage again! (also strange that the garbage seemed slightly intelligible with @[01] and [##] messages!)
Either way, fingers crossed this sorts it, and if not I might send you a PM. Thanks again!
@cjcharles - do you have any documentation on what you’ve done? I may be interested in it. The purpose of this was to integrate with SmartThings, right??
I am running into an issue. When HASS starts up with the Elk module I get the following error:
Error executing query: Object of type ‘Area’ is not JSON serializable
It appear that HASS gets loaded with my Elk Badges but they do not ever update in status so I assume the above error halts its progress.
Also does elks:// work with the latest branch? I see it in the documentation but I get the unknown error with it.
Have not yet merged the current code to master. You’ll need to use the gwww-elkm1-lib branch for now. Probably that will fix both your problems.
I did use that branch. I deleted rit again and just cloned that branch again to make sure and I am still getting the same error.
Yes elks:// works with the latest branch. Since you are having fundamental problems I suggest starting with elk:// (the non-secure connection). That should work. If not post errors from that.
Next check your Home Assistant config directory. Have you properly installed the gwww branch stuff under the custom_components directory?
So elk:// does not work either, only socket://x.x.x.x:yyyyy works for me. I am suspecting an issue with PyElk.
You have the wrong branch. You should have this: https://github.com/BioSehnsucht/ha-elkm1/tree/gwww-elkm1-lib
I think I see the issue, I just assumed the green button to get a cut-n-paste of the url for using int git would point to the branch you were looking at but that does not appear to be the case, how odd of an interface.
Thanks, that was this issue once I used git clone -b gwww-elkm1-lib …
It worked.
@BioSehnsucht @gwww
Having recoded the firmware for my integration it seems there is a bug in the Arduino library related to reading the serial info too fast and the buffer not emptying by the time you come back to read it again. Thanks so much for your help in identifying the problem! Enjoy the rest of your weekend.
@jon102034050 if you are interested have a look on the SmartThings forum and can discuss there as it’s probably more relevant there!
@BioSehnsucht Above we were working on not having the alarm trigger when the countdown is happening. I thought it was fixed but I believe it still isn’t. I can see the status is showing correct on countdown, but for some reason the automation that is waiting for “tripped” is set off when the status countdown is pending. It’s making my siren go off outside during the countdown.
Here is the automation that is triggering on countdown:
alias: Alarm System - Triggered Sound Outdoor Siren
trigger:
- entity_id: alarm_control_panel.elkm1_area_001
platform: state
to: triggered
condition: []
action:
- alias: ''
data:
entity_id: switch.switch_13
service: switch.turn_on
Strange, if you’re on the current code on the gwww-elkm1-lib branch that should work. Maybe your entry/exit timer messages are disabled in the Elk? They default to on (they all do) normally, but perhaps if your Elk is older an older firmware in the past didn’t default them to on.
Now that I review the protocol documentation, it doesn’t mention that this can be turned on and off like some messages, so perhaps your Elk firmware is older and it simply doesn’t send them? Need Elk firmware 4.1.12 or later or 5.1.12 or later, ideally 4.1.18 or later or 5.1.18 or later …
If you’re on a newer firmware (.18 or later ideally), and all the messages are enabled in the Elk (check w/ ElkRP2 in the Global Programming section, there should be a lot of options to dis/enable various messages), and you’re on the current version of code that’s on Github for this branch … then I’m stumped. It should work, I’ve tested it on our Elk.
I can test this on my elk when I get home later today for continuity. I’ll report back