Add sensors for each cell voltage

[chedim]

Checklist

• [x] I have filled out the template to the best of my ability.
• [x] I have understood that this integration is only about battery management systems with Bluetooth Low Energy support.
• [x] This only contains 1 feature request (if you have multiple feature requests, open one feature request for each feature request).
• [x] This issue is not a duplicate of any previous enhancement requests.
• [x] I have checked out the latest release.

Please describe the enhancement you would like to have.

Please add a sensor for every cell voltage. The current solution that uses templates is unwieldy to create/recreate with my 24s battery and all that is needed in the add-on is a foreach loop. Thank you!

Additional context

Thank you a lot for developing the add-on! Except for this issue, it is amazing!

[patman15]

Let's see how many people like/support your request. Then I would consider it after a merge to HA core. The rules there are pretty strict so I'd like to get the core developers opinion first. You say you need to recreate them? Why that?

[krahabb]

I would too definitely like the addition. These additional sensors could be made initially disabled so to not clutter the HA state machine by default (only users needing them would then enable those) or, better, add a config option to create or not these entities.

[Teunhen]

I would love to have all the cell voltages.

[patman15]

@Teunhen you are aware that this is possible?

[!TIP] The FAQ describes how to add individual cell voltage sensors.

The discussion is about whether to add them automatically (initially disabled).

[Teunhen]

I can see them in the delta voltage in attributes but i see 32 of them of the 2 packs. Ill go see if I can get them out in a card. But it would be awsome if it was automaticly done.

[Teunhen]

Thanks for your reply, For pack 2 is it cell 16 till 31?

Op di 16 sep 2025, 21:37 schreef Volo Yan @.***>:

irokezzz left a comment (patman15/BMS_BLE-HA#441) https://github.com/patman15/BMS_BLE-HA/issues/441#issuecomment-3300094774

I solved this situation like this:

template:

sensor:

  name: "Battery1 Cell 1 Voltage"
  unit_of_measurement: "V"
  device_class: voltage
  state: >
  {% set cells = state_attr('sensor.Battery1_delta_voltage',
  'cell_voltages') %}
  {% if cells %}
  {{ cells.split(',')[0] | float }}
  {% else %}
  unavailable
  {% endif %}
  -

  name: "Battery1 Cell 2 Voltage"
  unit_of_measurement: "V"
  device_class: voltage
  state: >
  {% set cells = state_attr('sensor.Battery1_delta_voltage',
  'cell_voltages') %}
  {% if cells %}
  {{ cells.split(',')[1] | float }}
  {% else %}
  unavailable
  {% endif %}
  -

  name: "Battery1 Cell 3 Voltage"
  unit_of_measurement: "V"
  device_class: voltage
  state: >
  {% set cells = state_attr('sensorBattery1_delta_voltage',
  'cell_voltages') %}
  {% if cells %}
  {{ cells.split(',')[2] | float }}
  {% else %}
  unavailable
  {% endif %}
  .........
  - name: "Battery1 Cell 16 Voltage"
  unit_of_measurement: "V"
  device_class: voltage
  state: >
  {% set cells = state_attr('sensor.Battery1_delta_voltage',
  'cell_voltages') %}
  {% if cells %}
  {{ cells.split(',')[15] | float }}
  {% else %}
  unavailable
  {% endif %}

— Reply to this email directly, view it on GitHub https://github.com/patman15/BMS_BLE-HA/issues/441#issuecomment-3300094774, or unsubscribe https://github.com/notifications/unsubscribe-auth/AVV7XISRHFHV76YYVUMKR6D3TBRFXAVCNFSM6AAAAACDQO4TH6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGMBQGA4TINZXGQ . You are receiving this because you were mentioned.Message ID: @.***>

[patman15]

Thanks for your reply, For pack 2 is it cell 16 till 31?

Yes, that is correct. Best regards, Patrick

[patman15]

As an intermediate solution, the latest beta release 2.0.0-beta.5 now contains a maximum cell voltage and minimum cell voltage sensor.

[alexdns1]

I dont see why thats needed all necessary voltages are already included in prev stable 1.21.0 Ex. If anyone needs min/max

`

  - name: "XDZN_001_B871 Max Cell Voltage"
  
    unique_id: "a2c32d55-52e2-42e7-9c20-1e4c7e30c3a1"

    state: >-

      {% if has_value("sensor.xdzn_001_b871_delta_voltage") %}

        {{ state_attr("sensor.xdzn_001_b871_delta_voltage", "cell_voltages") | max }}

      {% else %}

        None

      {% endif %}

    unit_of_measurement: "V"

    device_class: voltage

    state_class: measurement

    availability: >-

      {{ has_value(state_attr('sensor.xdzn_001_b871_delta_voltage', 'cell_voltages')) }}

`

[avg-I]

My 2 cents as a new user. Ideally I'd like BMS_BLE_HA to provide all the available information as sensors. And, ideally, I'd like it to be compatible with sensor definitions in https://github.com/syssi/esphome-jk-bms. One of benefits would be compatibility with https://github.com/Pho3niX90/jk-bms-card (for instance). While getting data from attributes is not very hard, it's still some extra work (and pretty mundane one).

[krahabb]

I agree, in general, with the idea of exposing every available entity but this in turn would 'overwhelm' a lot of users which are not really interested in these additional entities. I think the best solution would be to provide a configuration option in ConfigEntry so that everyone could customize the component at configuration time (maybe with re-configure feature too). This way, every user could decide if he wants those cell voltages or not.

Also, technically speaking, having the voltages exposed through an attribute is putting some 'stress' on the recorder which needs to serialize all of the data to a secondary table every time it flushes a new state. Now, this by default happens only once every 30 sec but in my case I've modified the default polling by increasing its frequency and even though I don't see my raspi breaking down for this, I'm kind of inclined to think this is just useless since in practical terms there's no easy way to query attributes history. This in turn brings back the question: Expose the cell voltages or not?

• If Yes, then it's better to have split sensors which are easily and directly manageable in the UI.
• If No, then it's better to completely discard them (exposing them in an attribute alone is a bit of 'no use' in my opinion)

[Teunhen]

I vote for expose them, you can always hide them if you don't need/want them. Or like you said in a config.

[avg-I]

Some HA devices provide dozens of sensors with most of them being disabled by default. Those who don't need those sensors don't have to do anything, but those who want the sensors can simply enable (some of) them. I think that it is a good model.