Open pbanasik opened 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. :-)
I'm currently working on this topic, please check the next release.
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!
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: ]
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.