Elk M1 Serial port 0


On the Elk it allows the reception and sending of text out the serial port. Does anyone know what the format is or point me to a description of how this works. Does the input and output text still follow the protocol with LL(CMD)DATA00(CRC) with data being the actual text or is it just the exact text in and out that you request or send? Also, I notice I can get changes in keypad temperatures but not my remote temp. Is there a way to send out the remote temp when it changes also?

Sending ASCII strings out to port 0 will be just that, just the string, no CRC/Checksum will be included.
The serial protocol does not talk about custom messages. I guess I do not have a need to send custom messages to the Elk but I was hoping that receiving them would follow the protocol (since I have to handle the format already).

Would be nice for Elk to add a custom command out the serial port so when I have a task that has been activated I can send out info out the serial port.

Any suggestions on remote probe temp updates out the serial port?
The M1 has the ability to send and receive your custom ASCII strings.

To receive an ASCII string set up the string to be received in the TEXT String section of Automation programming in ELKRP. Then write a Rule that fires when the string is received to do whatever THEN you want. Make sure the received string has a carriage return or line feed at the end (0x0D or 0x0A). This marks the end of the received string.

As stated above when you send and receive these custome ASCII strings, no protocol is attached. What you build in the string is what is sent.

You can build a string in the TEXT Strings that will embed the temperature of the remote temperature sensors, keypad temperatures, or thermostat temperatures. Send it as desired.
Task activations are reported through the regular serial protocol, so you should be able to monitor that already. Not sure about the remote probes, but I will find out soon, mine is arriving tomorrow.
Spanky said:
Make sure the received string has a carriage return or line feed at the end (0x0D or 0x0A). This marks the end of the received string.
Do I have to put a carriage return line feed on text going out the serial port or will that be tacked on?

You will have to add it yourself. This is only needed if the software you are using is not processing any of the incoming data until a CR or LF has been received.
Thanks. It makes it easier to keep it consistent so if i am looking for other elk commands with a cr lf on the end it i will tag it on with my own custom messages.

One thing I did not realize is that the M1 will push out a null character after a custom message. That might be good to document in the serial protocol document. I needed to look for that and strip it out.

Thanks for your help
electron said:
Where is the null character located? I never ran into that problem.
Well it was showing up after the custom strings I was sending out. So if it had a <CR><LF> on the end it would also push out a 00 null char after it. The non custom messages did not have this problem. I had to add code to strip away any CR LF and 00 nulls at the end of a message before looking for another one, otherwise my next message would think the 00null was part of the next message and error out. It is working well for me now. I have two buttons F5 and F6 which kick off a task 05 (all lights on) and a task 06 ( all lights off). The tasks then kick out a custom message out the serial port. I look for these messages and then turn on or off all the lights(Zwave hooked up using controlthink SDK). It works well. Since I have a server pc box that I use for other purposes, it was just cheaper to keep it hooked up to the Elk M1 and monitor the serial port.

Thanks for your help