Add support for crc8 checksum fields in messages

[msteiger]

I admit that this an odd request, but I think that it's required to support write support for Wolf proprietary messages. This is how it works:

The command xx yy 5023 09 d8 4201 04 00 5d010000 sets parameter HG 07 to 4 minutes.

The value 5023 is the main Wolf write command.
Then 09 is the number of bytes to come (as usual).
The d8 is a CRC-8 checksum of the 8 bytes that follow.
The 4201 indicates the parameter HG 07 as described by the user manual.
The value is in the two bytes 04 00 in LL HH format.
The rest of the message seems to be a constant suffix.

In order to specify those messages in CSV I would need to be able to define the checksum field somehow. I have a short C snippet that computes the CRC8 (tested successfully) I can share. Does that make sense?

[baycom]

What kind of CRC algorithm is being used for that? In my case it does not make any difference what value the first byte of the message has. The components still answer / ack the request if the first byte is 0x00. Here are my findings - I think we should consolidate the whole Wolf stuff.
https://docs.google.com/spreadsheets/d/1S0difDnnMiqyjwa7TPG0M8KY0L4JfTgNukiMdSh7rx0/edit?usp=sharing

[msteiger]

It's a CRC8 based on the value 0x5C. It's what I discovered what the ART and the BM devices use. I just tried out what you say and I can confirm it: the checksum value is really ignored by my heating unit (CGU-2K).

I still think that we should implement it correctly instead of sending a constant dummy value.

I agree that we should consolidate the data for Wolf! All of the HG parameters I know are proposed here: john30/ebusd-configuration#96

[baycom]

Today I took a little time and extracted the remaining parameters for all Wolf heat pump types (air, water, split, etc.). Now there is nothing left undocumented for heat pumps. Further I can confirm that the crc8 polynom 0x5c works for all messages.

[msteiger]

Nice! Can you create a PR for the ebus-configuration repo so I (and others) can use it, too?

[john30]

if the wolf devices ignore tha checksum, then why should we add a special data type for that one?
just make it IGN:1 and that's it.

[msteiger]

Yes, that's a very valid point. We could just ignore it and carry on, because it will work for the CGU-2K at least.

That said, just because it works, doesn't mean that it's correct ... and it isn't. We're just exploiting the fact that some heating units don't verify the checksum. The controlling devices ART and BM do send the checksum to the heating units, so chances are that some units will require it to be correct.

The good thing is that the hard part has already been done: the meaning of the value has been identified, the algorithm is implemented and even tested on two real devices. Integrating it into ebus is the last piece of the puzzle. Why not complete it?

[john30]

sure, but someone has to develop the data type and the tests for it. I don't have time for that right now, but I'll keep this issue as a reminder/TODO

[kopierschnitte]

Sorry for bumping an old issue but it seems that my setup indeed requires a correct crc8 checksum for at least one dataset.
I'm talking about "HG15" (water hysteresis) on a Wolf CGW-20.

Every other command I've tried works with 0x00 or any other crc but this one doesn't. It works if I manually calculate it and use the hex-command.

[MaciekIzdebski]

kopierschnitte could you please give me some informations how do you calculate crc? I'm trying calculate with crc8 polynom 5c and results are wrong

[kopierschnitte]

Unfortunately, I couldn't calculate it for myself yet. I was just reply previously sniffed CRCc

[msteiger]

There are several CRC7 or CRC8 available which slightly differ. Maybe you could provide some "valid" checksums, so we can identify the correct implementation? Should not be too hard.

[FanDjango]

Here are the python routines I use for my Wolf ebus code concerning crc fields, for incoming and outgoing:

def crc(b, crc):
    for i in range(8):
        if crc & 0x80:
            p = 0x9B
        else:
            p = 0x00
        crc = (crc & 0x7F) << 1
        if b & 0x80:
            crc = crc | 0x01
        crc = crc ^ p
        b = (b << 1) & 0xFF
    return crc

def crc_check(data, check_crc):
    calc_crc = 0x00
    for i in range(len(data)):
        calc_crc = crc(data[i], calc_crc)
    return calc_crc == check_crc

def crc_make(data):
    calc_crc = 0x00
    for i in range(len(data)):
        calc_crc = crc(data[i], calc_crc)
    return calc_crc

[lildadou]

The CRC is calculated on PSPB and the ID on 2 bytes. Both are "static" data. The CRC can therefore be calculated in advance, without precluding the possibility of changing QQ, ZZ and DD. This is what has been done in ebus-configuration

In this example, the ID is announced over 3 bytes and the first byte actually contains the CRC.

To calculate my CRCs, I used a project that implemented the calculation on a complete telegram (it'll reassure you that changing QQ, ZZ or DD doesn't change the CRC).