More about the Remeha protocol

This evening i spent some time on trying to figure out the meaning of all the bytes that make up the response. I already knew where to locate the information inside a packet by a brief analysis of the packets a few days ago, but to make things a bit more stable, I knew I had to dig a bit deeper to find out as much as possible. Cause the more you know, the more checks you can build into the software which results in less chance that invalid packets slip through that could possibly crash the system.

When I started analyzing the responses from the boiler, I started with the Sample command. Here’s an example:

0201FE064802018C145A140080008080F3008003100080401F
701700800000000000BC020000006400000010C20B1000FFFF
00000000FFFF1700BC0200000000000000000000002C4303

I already found out that the part marked in blue contains the payload e.g. the ‘interesting stuff’ some days ago, so let’s focus on the remaining bytes:

0201FE06480201 and 2C4303

The 02 at the beginning and 03 at the end are common values for start- and end bytes, so let’s assume this is the case here also, so now the unknown bytes left are:

01FE06480201 and 2C43

The size (2 bytes) and the position inside the packet (at the end) made me think that the 2C43 could very well be a checksum, and it is: it’s the CRC16 (Modbus variant) of the complete packet without the start- and end byte (and of course the checksum value itself); so based on the packet above the bytes of which the CRC is calculated are:

01FE064802018C145A140080008080F3008003100080401F
701700800000000000BC020000006400000010C20B1000FF
FF00000000FFFF1700BC020000000000000000000000

The Modbus variant of CRC16 calculation differs from a “standard” CRC16 calculation in that the initial value isn’t 0 (zero), but $FFFF. Being able to validate the checksum is very valuable and adds a lot to the robustness of this interface.

So now all that’s left are these leading bytes:

01FE06480201

To understand the 01FE part, I looked at some outgoing packets, these look like this:

02FE010508020169AB03

Again, after removing the start- and stop byte and the checksum we see this:

FE0105080201

Compare this  with what is still unknown from the response:

Incoming: 01FE06480201

Outgoing: FE0105080201

The first two bytes seem to be the addresses of the source and destination device; this is not that strange as it seems; although this is a 1:1 communication, since there seems to be some Modbus inheritance in this protocol (the CRC16) and knowing that Modbus allows for more devices to be on the same bus, it ain’t that strange at all. Looking at other packet types (blockings, lockings, counters) I always see these 2 bytes coming back, so it’s fair to assume these are used for addressing. Now we’re down to 4 bytes:

06480201

$48 = 72 decimal. Packet size! Another important item to validate the incoming data stream.

Believe me, (I won’t bore you with examples of all the other packet types) 0201 is the function code or command code or whatever you like to name it. It identifies what the payload is about. 1 byte left, the 06. Protocol version? I don’t know yet. Maybe some day I will…