Support ANT BMS (legacy BLE protocol)

[krahabb]

This PR addresses an issue I'm having with an ANT BMS.
After searching the net I've seen through https://github.com/syssi/esphome-ant-bms that it looks like there are 2 versions of these devices at least on the protocol/software side and the 'legacy' one is nicely managed in the repository (the *_old_ble source files)

By using the advertised data of my ANT BMS I've come around a slightly different matcher with the following keys:

{
  "local_name": "ANT-BLE*",
  "service_uuid": "0000ffe0-0000-1000-8000-00805f9b34fb",
  "manufacturer_id": 1623
},

where, as can be seen, the difference with respect to the actual ANT matcher lies in the manufacturer_id key
I hope this is enough to cover any other ANT implementing this protocol but we'll see...

I've checked ruff and mypy on the code but I'm still in a 'draft' stage at the moment (missing tests for sure)
This early submission is to make you aware I'm working on this and I'd like to discuss some adjustments regarding the BaseBMS model.
More specifically, I've added some custom keys to the _FIELDS definitions in order to leverage the automatic parse of the frame done by BaseBMS._decode_data but these keys are not defined in the BMSsample TypedDict (hence mypy complaining).

If these keys prove to not be relevant in the overall integration architecture I'd quickly cleanup the _FIELDS and do the int.from_bytes locally in the custom plugin.

The keys I'm talking about are:

• cell_high_voltage
• cell_low_voltage
• total_cycled_charge

I think the cell_high_voltage and cell_low_voltage could be interesting for the general architecture. They're related to delta_voltage but providing those two would give more insights about the cells without the need to expose the full array of cells (See #441)

The total_cycled_charge instead is a somewhat duplicate of cycles. It carries the total amount of charge exchanged by the battery/bms in its life and it is then related to cycles with:

cycles = total_cycled_charge / design_capacity

If you like them we could better define these new key names or, if not, as stated, I'll just drop them from the _FIELDS and use them only in internal decoding.

[patman15]

Hi! Thanks for your contribution. Just a quick feedback as I'm low on time at the moment: yes, the high/low voltage was already in my thoughts as well, so let's introduce them, but I will need to implement them also for other BMSs (the readout, not the backup). Same for cycles, I do agree, that this calculation makes sense.
Let's put those basic changes into a separate branch/PR from the addition of the BMS.
I restored my PR checks that were somehow disabled. What I need is full test coverage using real-life recorded BMS answers. If you are motivated, please have a look at the other test files on how I did it.
I'll do a review of your PR a bit later.

[krahabb]

Hello Patrick,
Thank you for your feedback, and also for this nice integration that finely supports, in a single component, all of the different BMS implementations: this is a great 'pain reliever' for the HA community I guess.

I've taken a bit of time to look at the tests and I see they follow a common structure so I'll just copy/adapt to the new protocol the existing implementation(s). I think I'm going to push this sooner than later so that I can 'pop' this from my tasks stack ;)

BTW, I also have some ideas/requests about the component functionality (i.e. adding BMS config features) but we'll discuss this in a dedicated thread. I see this repository has no 'Discussions' enabled so I'll maybe open an issue for the matter.

Davide

[patman15]

Code already now looks pretty good to me, thanks for the great work! I'm still a bit unsure about the 'data' variables in your _notification_handler but after a hard week I miss the energy to understand your logic. I'll probably come back to that one or fix it later myself. Thanks again and I only request a few changes.

[patman15]

Hey, for the cycles calculation you could use the changes from #476.
Regarding the min/max voltage, I will add a diagnosis sensor for each of them, but the value can be gathered from the cell voltage array. I do not see a need for another value in the array, as I could not find (so far) any BMS that provides min/max but not the individual ones.

[krahabb]

mypy should still be complaining but once the code from #476 will be merged in it should be ok.

[patman15]

@krahabb if you give me a final "go" for the changes I pushed (mainly this commit 15f657e) I would merge ...

[krahabb]

Good to go!
Thank you

[patman15]

@krahabb I moved all plugins to a new library https://github.com/patman15/aiobmsble/
Do you want to be named as an author of this library in the pyproject.toml? I'll move the thanks section in the README anyway. If so, please let me know what to put there!

[krahabb]

Thank you @patman15,
I would be honoured but at the time my contribution is so tiny.. Let's see in the future, the README mention is enough at the moment ;)