ebusd

ebusd copied to clipboard

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?

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

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: https://github.com/john30/ebusd-configuration/pull/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? just make it IGN:1 and that's it.

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