-
-
Notifications
You must be signed in to change notification settings - Fork 13
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
Read config settings #18
Comments
I don't want to provide sensors here. A service to read and write on address on demand should be sufficient. |
I could really use the request/response format for reading/writing BMS paramaters on the 2021 version. |
Do you own an ANT-BMS and would you do some testing? |
sure but it's not for the esphome...it's for an ev application. it's a web app using (web bluetooth api) and all my protocol configs are in yaml (not hardcoded). i've only gotten as far you. on the pre-2021, i've pretty much got all the functionality. |
here is the read request for ParameterConfig > CellHighProtect: request: 7e a1 02 00 00 02 19 a0 aa 55 7e - start response command always seems to be request command + 0x10 (ie. 0x02 -> 0x12). it looks like the param id's are all different from the pre-2021 ver. the pc app doesn't play nice with my serial port monitor and freezes after a few minutes making decoding verrrrry slow :( |
|
Good job! |
Do you like to share some details about the pre-2021 version to read the settings? I would like to collect all protocol details to be able to extend the component. |
sure no problem. read parameterrequest: [0x5A, 0x5A, address, 0, 0, address] address is the parameter id (uint8). value is uint16. simple crc1 checksum (8bit) is calculated on [address, value]. byte order is big endian. i've provided the list of parameters (id's are decimal values NOT hex). write parameterrequest: [0xA5, 0xA5, address, value, crc, 0xA5, 0xA5, 255, 0, 0, 255] parameters
|
i've got it working now for the new protocol. haven't tested the write parameters yet but it should be straight-forward. read parameterrequest: response: note: value is uint16 in all cases except for: PhysicalAH, RemainingAH, TotalCycleAH (these are uint32 datalen 4). i've verified all the values, scales and decimals match those in the Android App. Thanks for sending me the Windows version--that helped a lot. I ended up creating a bluetooth serial port on my PC to connect to the bms. BTW, it seems you need to send the first read parameter request twice or it gets dropped. Subsequent requests do not need to be repeated.
|
Just for completeness: Could you provide a traffic capture of some commands? Having some PDUs by hand speeds up the implementation and can be used as fixtures for testing. Thanks in advance! You did a great job extracting all these details. |
here's a dump of all the Voltage read parameters from top to bottom, left to right column in the PC app.
|
dump after opening com port. i've tried to decode 0x01 system update but the datalen is 142 (as opposed to 140 in old ver) and probably in different order. for now you can stick with the old protocol.
|
some sample write parameter commands from Current tab:
|
SystemInformation dump:
|
If there is anything more specific you need let me know. |
This is completely sufficient for now. It will take me a while to get the new information into the code. |
here is my device config yaml. hope this helps. also parameter config with hex values: [start, start, command, address16, datalen, crc16, end, end]
|
it responds with the value written but i still can't figure out what the extra 6 bytes are (in square brackets). anyone care to take a guess?
|
The second half is called "second packet" at the
The uint16 |
ok that helps. checksum passes using the first crc (0xe3e1). in the pc app, write responses always returning 10 for the error code whether or not it is authenticated. i've tried both 000000000000 and 123456789abc for the level 5 password and still get the same result. so...either it can't get the chip id or it isnt authenticated properly. in either case, it still writes the value.
in a possibly newer version of the app, this is what i found:
|
I came here searching for a description of the 0x7e 0xa1 0x01 and found bchiu on Oct 26, 2022 describing that message. Mentioning it is 142 bytes long. However, the format given here is not correct, it looks as if between the message length and cell voltages some other values were inserted. |
Did you see the attachment (ant-bms-device-16zm.zip) above? It does contain some (but unused) descriptions:
73 de DO2KSM |
Yes, I saw this - and it is the think I mean with "there is a gap" 7E A1 11 00 00 8E 01 01 02 10 00 00 00 00 00 00 Highlighted is 0x8e, message length, and 0x3b 0x0c which is the first cell voltage.
There should only be 4 bytes between message length and the first cell voltage, while I count 28. Or do I bascially misunderstand something? Regards, Guenter |
I tried to visualize the gap.
|
Thanks, let me see if I can get that into a little piece of Python. |
I've removed some of the
|
You are absolutely right. My guess was wrong. Could you explain why do you prefer the status request of the new protocol instead of using the "well known" status request of the old protocol? |
Just give it a try. This is the https://github.com/syssi/esphome-ant-bms/blob/main/components/ant_modbus/ant_modbus.cpp#L148-L159 |
This component uses the old protocol (for both BMS versions) for reading (like the Android app). If it comes to writing you have to choose the appropriate protocol version or the BMS doesn't accept the commands. |
Nope, my BMS does not answer anything when triggered with 0x5A, 0x5A, 0x00, 0x00, 0x01, 0x01 |
Good to know. :-) In this case this implementation/project isn't compatible yet. ;-) |
I have a bad feeling about this definition: |
@dl4mea I've decoded the status frame of the new protocol:
|
I checked some values around those I already had in my decoder, and they all look pretty fine. |
I started to add some more details about status flags and bitmasks here: |
https://github.com/klotztech/VBMS/wiki/Serial-protocol#parameter-addresses
The text was updated successfully, but these errors were encountered: