-
-
Notifications
You must be signed in to change notification settings - Fork 130
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for crc8 checksum fields in messages #167
Comments
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. |
It's a CRC8 based on the value 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 |
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. |
Nice! Can you create a PR for the ebus-configuration repo so I (and others) can use it, too? |
if the wolf devices ignore tha checksum, then why should we add a special data type for that one? |
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? |
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 |
Sorry for bumping an old issue but it seems that my setup indeed requires a correct crc8 checksum for at least one dataset. 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. |
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 |
Unfortunately, I couldn't calculate it for myself yet. I was just reply previously sniffed CRCc |
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. |
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 |
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). |
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 parameterHG 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 parameterHG 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?
The text was updated successfully, but these errors were encountered: