-
Notifications
You must be signed in to change notification settings - Fork 8
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
Telegram rejected when masterTelegram CRC=AA #28
Comments
From what I remember the |
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] ** 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 Analyse the telegram 01 FE 20 20 04 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 Analyse the telegram 01 FE 20 20 04 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" |
Should be fixed with Release v1.1.12 |
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.
The text was updated successfully, but these errors were encountered: