Hmm doesn't look to be the case, in my case it's literally the combined BMS unit with balancer onboard.. The commands I captured over BLE are for the balancer as well as BMS, they share the same request and corresponding response headers for BMS and balancer functions, that seems to be consistent across all the observed protocols.
The binary values of the respective headers are mostly just alternating 0101 or 1010's so maybe the 1st byte is just to tell the BMS whether it's intending to communicate via BLE or RS232/RS485, then the next byte of alternating 0101/1010's is probably just a rudimentary baud rate sync/checksum.
I've attached what I've data logged as the "commands" that the the app sends to the BMS for each of the respective settings in the Advanced menu (whilst the phone app requires a password "123456", this appears to be purely at the app level, that password is not in any of the comms logged)
The enum I've coded is in C# so their order is inversed.. eg: getCellData is 0x0096, the actual command is therefore 0x96, 0x00, add header and padding + checksum and it becomes
AA 55 90 EB 96 00 00 00 <pad zeros to 19 bytes> XX
Header
Command
Parameter for the command (if any, have been observed to be always 2 bytes, see comments in code
Checksum (I'm assuming you already know how to calculate this)
Total command string is 20 bytes (fixed).
If the command is successful, the BMS returns
AA 55 90 EB C8 01 01 <pad zeros to 19 bytes> XX
If command is rejected, the bms returns
AA 55 90 EB C8 01 00 <pad zeros to 19 bytes> XX
So it seems the C8 01 is fixed, then the next byte is either true or false for the previous command sent.. There is no reference to the command code in the response itself so if you send multiple commands before you get a response, you wont know what the BMS is responding success/failure to. This is probably why the app does this modally too.
The main advantage I've found with using BLE over RS485 protocol is that, under BT5.0 multipoint connection, I can connect to multiple BMS's simultaneously with a single BT adapter and therefore only use one USB port (or none, if BT is built-in), whereas RS485 will require a dongle purchase for each BMS and I have a few, and I don't have enough USB ports (and don't want to use a hub) because I also need the ports for my inverter.. I've actually written up my own dotnet code to do this because jblance's code creates a connection on each request, gets a single response then closes connection, whereas my own .netcore code can just open the connection, keep the BLE characteristic open and listen for an ongoing stream, and log all of it to influxdb, and only reconnect if a connection is dropped (or the BMS shuts itself lol).
