This is a reverse engineered description of the IP signalling protocol used by Texecom’s Premier and Premier Elite COM-IP and COM-WiFi communicator modules. It has been derived by deduction based on observations of network traces, and without access to any official documentation. A Python implementation of a simple Alarm Receiving Centre (ARC) based on this work is available on GitHub.
Errors and omissions are likely at this stage, and there are aspects of the protocol that have not yet been investigated. In particular, no attempt has been made to investigate the encryption feature added to recent Premier Elite firmware, nor the mechanism for setting the system time/date in response to polling.
Texecom IP Wrapper
For polling and Alarm Transmission System (ATS) operations the alarm panel will periodically establish a TCP connection to the remote host and port specified in the Communicator ARC configuration and/or the global polling settings. The connection is only established when data needs to be sent.
Once the connection is established the alarm may send one or more <CR><LF> terminated packets with a fixed ASCII prefix describing the packet type as follows:
POLL : Polling request 2 : Ademco ContactID format ATS message 3 : SIA II format ATS message +++ : End of transmission
End of transmission packets do not include the <CR><LF> terminator and will be shortly followed by a TCP disconnection.
Other message types may be seen. For example, numerical packet types appear to match the order in the ARC protocol configuration menu.
The following special ASCII characters may be encountered:
<ACK> = 0x06 <CR> = 0x0d <LF> = 0x0e
POLLing requests
The system may be configured to poll a remote host at regular intervals. This is separate from the ARC configuration. These messages have the following structure:
POLL<account number ASCII>#<4 byte flags><CR><LF>
For compatibility with Ademco ContactID (see below) the account number should probably be set to a 4-digit value. It appears in the POLL request as an ASCII string.
The 4 flag bytes are usually 0x00, and could represent a 32-bit little-endian word. Bits were observed to become set in the first of the 4 bytes under certain circumstances. The following bit values have been determined by observation, or by assumption based on other system characteristics. It should be assumed that the named function of unverified bits may be incorrect at this time:
bit 0 - Line failure (not verified) bit 1 - AC failure (not verified) bit 2 - Battery failure (not verified) bit 3 - Armed bit 4 - Engineer logged on
The panel expects an acknowledgement response from the ARC. If the response is not received then the panel may retry, and will eventually disconnect and raise an ATS Fault.
Expected response:
[P]<0x00><1 byte polling interval in minutes><ACK><CR><LF>
Here, the square brackets are literal. The polling interval is a byte value, not an ASCII digit.
The next poll from the alarm will occur after the polling interval specified in the preceding response.
Montex allows the ARC to pass a time/date update back to the alarm. This has not yet been investigated.
Ademco Contact ID
These packets contain a standard Ademco Contact ID message as defined in SIA DC-05. The message is represented in ASCII and wrapped with Texecom’s packet prefix ‘2’ and a <CR><LF> terminator.
2<ContactID message><CR><LF>
The alarm expects an acknowledgement in response. If the response is not received then the panel will try again and will eventually raise an ATS Fault.
2<ACK><CR><LF>
The Contact ID message is encoded as a mostly numeric ASCII string. Detailed descriptions of this format as well as the values for the event codes can be found in the public domain.
AAAATTQEEEGGCCCS
A = 4 digit account number
T = 2 digit message type (either 18 or 98)
Q = 1 digit event qualifier:
1 = new event/open
3 = restore/closing
6 = status report
E = 3 digit event code (see published tables)
G = 2 digit group number (area)
C = 3 digit zone or user number (0 if no zone or user applies)
S is a check digit such that (sum of message digits + S) mod 15 = 0
For whatever reason a ‘0’ is sent as ‘A’ and valued as 10 for the purpose of checksum calculation, although this seems to be applied somewhat inconsistently.
A typical message (with the Texecom wrapper removed) looks like:
1AAA181412010029
This describes the following condition:
Account number 1AAA = 1000
Message type 18 (allowed)
Qualifier 1 = New event/open
Event code 412 = Download End
Area 01
User 002
SIA Protocol
This protocol offers enhancements over Contact ID, including ASCII text for usernames and zone descriptions. With the Texecom wrapper the message looks like this:
3<SIA record 1><SIA record 2>...<SIA record N><CR><LF>
The alarm expects the following acknowledgement in response:
3<ACK><CR><LF>
Observed messages contain either 3 or 4 sub-records depending on whether there is an additional text field. Each record in the SIA message is represented as follows:
<1 byte start + payload length> <1 ASCII character payload type> <N bytes payload> <1 byte checksum>
The payload length is in the least significant nibble of the first byte, with most records having the most significant nibble equal to 0xc0. The final record has the most significant nibble set to 0x40 and appears to be an end marker.
The checksum is the complement of the XOR combination of all bytes in the record, including the start byte and payload type.
A typical message (with the prefix and line terminator wrapper removed) looks like this (in hex):
c4233130303019c84e726931434c3030306c40308f0d0a
which can be broken down as follows:
c4233130303019 : <0xc0 | 4> '#' 1000 c84e726931434c3030306c : <0xc0 | 8> 'N' ri1CL000 40308f : <0x40 | 0> '0' 0d0a : <CR> <LF>
Payload type ‘#’ describes the ASCII-encoded account number for the message.
Payload type ‘N’ contains an SIA format event message, in this case ri1 indicates area 1, CL indicates system armed, 000 indicates no specific user ID (quick arm was used).
The 0x40 0x30 record is assumed to be an end marker.
Some messages may include an additional ‘A’ record containing ASCII text describing a zone or user name:
c4233130303019c84e7269314f503030317dc441557365724b40308f0d0a
c4233130303019 : <0xc0 | 4> '#' 1000 c84e7269314f503030317d : <0xc0 | 8> 'N' ri1OP001 c441557365724b : <0xc0 | 4> 'A' User 40308f : <0x40 | 0> '0' 0d0a : <CR> <LF>
Here ri1 indicates area 1, OP indicates systems disarmed, 001 indicates user number 1 with defined name ‘User’.