Fix non-END 0x16 leading to early frame termination

[yzhang318]

Hi,

I'm submitting this PR to solve a bug that leads to occasional checksum failures.

Issue Description

The 2nd-last byte of a frame is CS (Checksum), and the last byte (END) is a fixed 0x16. When CS happens to be 0x16, it is taken as END to terminate the frame. Later checksum verification fails since the framedata[-2] is mistaken as CS.

Another potential problem could be that there is 0x16 in addr section. However, it could be circumvented by using the broadcast address.

Solution

A state machine is written to recognize the 0xFE -> 0x68 -> addr -> 0x68 -> ctl_code -> data -> CS -> 0x16 format.

8 states are provided:

0. start, looking for 0xFE
1. [optional] awaken received, looking for 1st 0x68 (b_start)
2. 1st 0x68 received, looking for 2nd 0x68
3. 2nd 0x68 byte received, next byte is ctl_code
4. ctl_code received, next byte is length
5. length byte received, set counter to find CS
6. CS byte received, waiting for b_end
7. b_end received

Verification

The fixed code is applied to read from a real meter. Before this fix, occasional frame checksum errors can be observed. After implementing the proposed modification, no more checksum errors are encountered.

---

Thank you for your great effort to provide this library! ☕️

[hrbonz]

Only just saw this PR, my apologies for the delay. Could you merge both your commits as the second one seems to rewrite the first one anyway.
The biggest effort was to read the standard in Chinese!

[yzhang318]

@hrbonz Hi! It's great to be able to help! I've reviewed the branch and am merging the two commits you mentioned. I totally get it - reading the documentation takes a lot of effort. Thanks so much for all your hard work!