csowada / ebus

This library handles the communication with heating engineering via the eBUS specification. This protocol is used by many heating manufacturers in Europe.
Eclipse Public License 1.0
5 stars 7 forks source link

Telegram rejected when masterTelegram CRC=AA #28

Open pbanasik opened 3 years ago

pbanasik commented 3 years ago

Hello @csowada, Regarding the problem I mentioned on Feb 23 in the OpenHAB eBUS thread, i.e. this message is resolved: "FF";"50";"B5 13";"03 04 22 00 F4 00 0A 22 00 32 00 00 00 00 00 00 00 97 00 AA";GET > custom-50.custom.podlogowe_zadana while this one is not: "FF";"50";"B5 13";"03 04 15 00 55 00 0A 15 00 19 00 0A 00 90 01 78 00 C7 00 AA";

I was able to find out that in the matchesCommand method of the EBusCommandRegistry class, the masterTelegram is built differently in both cases. In the latter case, the following masterTelegram is built: 00 00 B5 13 03 04 15 00 A9 01 Looking at the 2 last bytes, it seems that the computed CRC value is AA and the AA byte escaping makes the whole masterTelegram one byte longer. The logic which gets the slave response length from the message looks one byte further (slaveLenPos is incremented by one). In the end, slaveLen equals 21 (should be 10), computedSlaveLen is 10 (correct), slaveLenPos is 11 (should be 10) and the message is rejected. I don't think I know the code well enough to propose the final fix, I wouldn't like it to be a dirty hack :-) I hope the information I provided will help you do that properly.

splatch commented 3 years ago

From what I remember the AA sequence is a magic one since it has a special meaning for bus participants. This is what you also found in code. Overall practice is to avoid AA in payloads if possible. Anyhow interesting that you get this in CRC. :-)

csowada commented 1 year ago

I'm currently working on this topic, please check the next release.

ogkita commented 5 months ago

Hi @csowada,

We are using this development and we have this issue.

When we try send a telegram with AA we have and error.

Error:

ebus resolve "01 FE 20 20 04 62 72 AA 00"


Error on checking telegram: Received SYN byte while receiving telegram! [ERROR: INVALID_SYN, DATA: 01 FE 20 20 04 62 72 AA] !!! Warning: All following results are wrong and only displayed for information purpose !!!


OK (changing AA by AB):

ebus resolve "01 FE 20 20 04 62 72 AB 00"

Check and unescape telegram


Original data : 01 FE 20 20 04 62 72 AB 00 Unescaped data: 01 FE 20 20 04 62 72 AB 00

Analyse the telegram


01 FE 20 20 04 62 72 AB 00 ^^------------------------ Source address | Type: Master | 01 ^^--------------------- Destination address | Type: Broadcast | FE ^^ ^^--------------- Command | | 20 20 ^^------------ Master Data Length | Length: 4 | 04 ^^ ^^ ^^ ^^ Master Data | | 62 72 AB 00

Where do you think is the problem?

Thank you very much!

ogkita commented 4 months ago

Hi @csowada,

More info. When we resolve a telegram with escape character it is working:

ebus resolve "01 FE 20 20 04 62 73 A9 01 00"

Check and unescape telegram


Original data : 01 FE 20 20 04 62 73 A9 01 00 Unescaped data: 01 FE 20 20 04 62 73 AA 00

Analyse the telegram


01 FE 20 20 04 62 73 AA 00 ^^------------------------ Source address | Type: Master | 01 ^^--------------------- Destination address | Type: Broadcast | FE ^^ ^^--------------- Command | | 20 20 ^^------------ Master Data Length | Length: 4 | 04 ^^ ^^ ^^ ^^ Master Data | | 62 73 AA 00

But if we send this telegram, we get an error:

ebus send "01 FE 20 20 04 62 73 A9 01 00" Send telegram with id -1065094082, waiting for response ... openhab> Status : FAILED -1065094082 Error : invalid argument [DATA: ]