Some help creating the right code?

[C00K50N]

Just wondering if anyone can help me translate some logic that I think makes sense into actual code? I think I'm nearly there but can't quite work out the last bit (and feel free to suggest something better if I'm barking up the wrong tree!)...

This relates to monitoring my batteries' SoC, which I've been keeping an eye on since we got our batteries in October. I added to some discussion in #58 if you want any more context, but basically I'd like to calculate what SoC should be based on a sum of battery charge and discharge, in order to compare that value to the stated SoC.

To that end, this is my current code:

• sensor:
  • name: "SoC Calculated"
    unit_of_measurement: "%"
    state_class: measurement
    state: >
    {{ ((18.2 + (states('sensor.bat_charge_sum')|float - states('sensor.bat_discharge_sum')|float) - 21.55) / 18.2 * 100) |round(1) }}

(18.2 being our theoretical max capacity, with 7 x HV2600 batteries)

I find my calculated value drifts away a little within a couple days, so I'd like to find a way to reset it each time the stated SoC reaches 100% (or maybe 99%). The reason being as far as I understand it a stated 100% is more likely to be accurate than a stated 11% due to the way LiFePO4 cells work.

So, below is the logic I'd like to work out. Can anyone brighter than me help me translate it into actual code?

if reported SoC = 99% or 100% [it doesn't always get up to a reported 100%]
then reset "SoC Calculated" to 100
from that point, use my maths above (+ charge sum - discharge sum) to update "SoC Calculated"
until reported SoC is next at 99% or 100%, then reset again

Currently I have to manually adjust the calculated figure in the code (above, the -22.55 at the moment)

[TonyM1958]

not sure this is a calculation you can do, as it appears you are trying to make the calculation stateful in itself by remembering the past history of SoC. Have you looked at the lastest code that now provide BMS kWh Remaining from the BMS and looked at tracking this? Also worth a look at BMS Cell High mV and BMS Cell Low mV as a means of checking the balance across your batteries.

[C00K50N]

I haven't looked at those other values yet, no. Thank you for pointing me in that direction, I'll take a look soon.

I'm hoping to track the stated SoC, and when it hits 100% (or if there's another value which confirms the whole pack is full) then change the calculated SoC (not the stated one) also to 100%. Do you think that's unfeasible?

[C00K50N]

Been trying to get my head around this again, and it really comes down to my lack of coding knowledge. I wonder if the below gives you some idea what I'm trying to achieve, though I realise it's not right and therefore not working...

I'd like to find a way to store the (variable?) I've called "dif" when battery_soc is > 99, and then use that "dif" when it drops lower than 99.

{% if (states('sensor.battery_soc') | float(default=0) ) > 99 %}
    {% set dif = (states('sensor.bat_charge_sum')|float - states('sensor.bat_discharge_sum')|float) %}
    return 100 and store dif
    {% else %}
    ((18.2 + (states('sensor.bat_charge_sum')|float - states('sensor.bat_discharge_sum')|float) - dif) / 18.2 * 100)
    {% endif %}

But naturally, "dif" is only set when it's above 99 and ignored / forgotten when it's below 99.

Can anyone help?