Battery Capacity Tracker

Post Reply
Dave Foster
Posts: 822
Joined: Thu Oct 13, 2022 7:21 pm

Following a discussion thread on BMS recalibration, I mentioned I have a sensor that rather than rely on SoC alone which is notoriously difficult to assess at a single time point on LFP batteries, attempts to work out how much capacity the battery would have if it were fully charged and keeps track of it throughout the day.

The end result is a sensor that confirms the kwh capacity of your battery, and more importantly it helps answers the question ‘am I getting the kWh I paid for’ I used it to see the impact of temperature on capacity.

For this sensor to work effectively you must charge your battery each day on an eco tariff such as Octopus GO, as it works on the logic that the amount of power the battery discharges divided by the reduction in battery SoC will give the estimated capacity the battery should have.

Battery Capacity = battery discharge / (drop in SoC /100)

e.g. daily battery discharge is 5.2kwh, and the soc has dropped from 99 to 66% so : 5.2 / (.33) = 15.76 kWh

This code example is based on Octopus GO times with start charge at 12:30 and ending at 4:30 but it will work on any eco tariff that starts and ends in the same day i.e. Flux 2am-5am, or Eco7 12.30-7.30am

The sensor gets more accurate as the day progresses and helps to smooth out any SoC recalibrations, it is useful to compare changes on a day by day basis - for example it shows temperature effects reducing capacity.

The extra complexity comes when the battery gets charge during the day from solar when the SoC will increase - to deal with this it records the charge put into the battery at the end of the charge period (when soc is full) and subtracts it from the current daily battery charge - this gives the amount of solar charge which is then deducted in the battery discharge sum.

For accuracy it’s necessary to capture the battery discharge between midnight and 12:30 as when it finishes charging at 4.30am, the SoC will be full but the bat_discharge_daily sensor will already have had 30 minutes of house load, I keep a track of the discharge in the battery_off_peak_discharge helper and remove it in the calculation.

And so the final calculation becomes:-

Battery Capacity = (battery discharge - solar charge - battery off peak discharge) / (drop in SoC /100)

To calculate this I use a template sensor, an automation and 4 helpers.

EDIT: This latest version will reset the counters if the battery reaches 100% during the day from solar charge, this will improve it's accuracy during the summer months when grid charging is not normally used.


The following code is based on the latest BMS reporting SoC of 100%.

To start firstly create the helpers (HA Settings, Devices & Services, click ‘Helpers’ at the top and ‘+Create Helper’ in the bottom right corner, select ‘Number’) - the helpers should be named

battery charge off peak

The minimum value should be 0, maximum value should be 30, Display mode should be 'input field', Step Size should be 0.01, and Unit of Measurement should be kW
bcoffpeak.jpg
then create the next helper

battery off peak discharge

The minimum value should be 0, maximum value should be 2, Display mode should be 'input field', Step Size should be 0.01, and Unit of Measurement should be kW
bopdischg.jpg
Then create the helpers for the start and end of your ECO tariff (i've named them Octopus GO start/end which is 12:30 and 04:30 but if you are on Flux just set them to 2am and 5am)

Octopus GO Start
gostart.jpg

Octopus GO End
goend.jpg
Click on each helper and set the start and end times to your Tariff start and end times i.e. for Octopus Go it is 12:30 start, 04:30 end, for Flux it would be start 02:00, end 05:00

Finally create the helper that contains the actual storage size of your battery pack
bkwhcap.jpg
Once created click on it and set the actual storage size of your battery pack, for example if you have 4 * HV2600 batteries it is 4*2.56kwh = 10.24kWh.


Then add the sensor code to your configuration.yaml in the Templates section (usually towards the bottom)

Code: Select all

  - sensor:
      - name: "Battery Track"
        unit_of_measurement: "kW"
        state: >
          {% set kwhtotal = states('input_number.battery_kwh_capacity') | round(2,0) %}
          {% if  states("sensor.bat_charge_daily") not in ['unknown', 'unavailable', 'none'] %}
              {% set batsoc = states("sensor.battery_soc")|float(0) %}
              {% if batsoc > 99 %}
                  {% set calcbattery = kwhtotal | round(2) %}
              {% else %}
                  {% set batUsed = ((100-batsoc)/100) %}
                  {% set dischgLessSolarChg = ((states('sensor.bat_charge_daily')|float(default=0) - states('input_number.battery_charge_off_peak')|float(default=0)) * 1.1) %}
                  {% set calcbattery = (((states("sensor.bat_discharge_daily")|float(default=0)) - states("input_number.battery_off_peak_discharge")|float(default=0) - dischgLessSolarChg) / batUsed) |round(2) %}
                  {% if calcbattery == 0 %}
                      {% set calcbattery = kwhtotal | round(2) %}
                  {% endif %}
              {% endif %}
              {% if  states("sensor.bat_discharge_daily") not in ['unknown', 'unavailable', 'none'] %}
                  {% if states("input_number.battery_charge_off_peak")|float > 0 %}
                        {% if calcbattery > (kwhtotal*1.1) %}
                            {{ (kwhtotal*1.1) | round(2) }}
                        {% else %}
                            {% if calcbattery < (kwhtotal*(batsoc/130)) %}
                              {{ (kwhtotal*(batsoc/130)) | round(2) }}
                            {% else %}
                              {{ calcbattery |round(2) }}
                            {% endif %}
                       {% endif %}
                  {% else %}
                    {{ 0|float }}
                  {% endif %}
              {% endif %}
          {% endif %}

Then create a blank automation (HA Settings, ‘Automations and Scenes’, click ‘+Create Automation’ in bottom right corner, and Start with a blank automation, click on the 3 dots in top right corner, select ‘edit in yaml’ and overwrite the blank code with this yaml code then save.

Code: Select all

alias: Battery Check
description: This updates the helpers for battery check charge sensor
trigger:
  - platform: time_pattern
    minutes: /5
  - platform: time
    at: input_datetime.octopus_go_end
condition: []
action:
  - if:
      - condition: template
        value_template: |-
          {% set start = states('input_datetime.octopus_go_end') %}
          {{ now().strftime('%H:%M') == start[:5] }}
    then:
      - if:
          - condition: numeric_state
            entity_id: sensor.battery_soc
            below: 100
        then:
          - service: input_number.set_value
            target:
              entity_id: input_number.battery_charge_off_peak
            data:
              value: >-
                {% set bcd=(states('sensor.bat_charge_daily')|float(default=0))
                %}  {% set battkwh=( states('input_number.battery_kwh_capacity')
                | round(2,0) ) %} {% set
                batsocused=(100-(states('sensor.battery_soc')|float(default=0)
                ))/100 %} {{ ((bcd + (battkwh * batsocused))*1)|round(3) }}
        else:
          - service: input_number.set_value
            target:
              entity_id: input_number.battery_charge_off_peak
            data:
              value: >-
                {{ (states('sensor.bat_charge_daily')|float(default=0)
                )|round(2) }}
      - service: logbook.log
        data:
          message: Set charge off peak at Eco Tariff End
          name: Battery Check
      - service: input_number.set_value
        target:
          entity_id: input_number.battery_off_peak_discharge
        data:
          value: >-
            {{ (states('sensor.bat_discharge_daily')|float) | round(2,default=0)
            }}
      - service: logbook.log
        data:
          message: Set off peak discharge at Eco Tariff End
          name: Battery Check
    else:
      - if:
          - condition: time
            before: input_datetime.octopus_go_end
            after: input_datetime.octopus_go_start
        then:
          - service: input_number.set_value
            target:
              entity_id: input_number.battery_charge_off_peak
            data:
              value: 0
          - service: logbook.log
            data:
              message: "Set off peak charge to zero "
              name: Battery Check
      - if:
          - condition: time
            after: input_datetime.octopus_go_end
            before: input_datetime.octopus_go_start
        then:
          - if:
              - condition: numeric_state
                entity_id: sensor.battery_soc
                above: 99
            then:
              - service: logbook.log
                data:
                  message: SoC reached 100% in day, reset counters
                  name: Battery Check
              - service: input_number.set_value
                target:
                  entity_id: input_number.battery_charge_off_peak
                data:
                  value: >-
                    {{ (states('sensor.bat_charge_daily')|float(default=0)
                    )|round(2) }}
              - service: input_number.set_value
                target:
                  entity_id: input_number.battery_off_peak_discharge
                data:
                  value: >-
                    {{ (states('sensor.bat_discharge_daily')|float(default=0)
                    )|round(2) }}
mode: single
Finally go back to configuration.yaml and add the filter sensor which smooths out step changes in SoC, it should be added in the platform section near the top with other platform sensors, the code is

Code: Select all

sensor:
  - platform: filter
    name: "Battery Track Smooth"
    entity_id: sensor.battery_track
    filters:
      - filter: time_simple_moving_average
        window_size: "00:15"
      - filter: lowpass
        time_constant: 10
        precision: 2
The new sensors can be loaded in HA by going to Developer Tool, and on the YAML tab, click on 'TEMPLATE ENTITIES', then click on 'FILTER ENTITIES'

The new sensors will now be available to add to a dashboard, they are called

sensor.battery_track
and
sensor.battery_track_smooth

The 'smooth' sensor is simply a filtered version of the sensor.battery_track which smooths out the step changes as SoC changes, it is much easier to visualise.

When you first setup this code the helpers won’t contain any values as they are set by the automation at 4.30am so the sensor.battery_track value will be wrong, you can either wait for the next day when the automation will set them or just add an entity card on a dashboard with the following entities:-

Input.number_battery_charge_off_peak

and

Input.number_battery_off_peak_discharge

They helpers can be modified in the dashboard display, to get the sensor working set input.number_battery_charge_off_peak to the same value that is shown in sensor.bat_charge_daily and set input.number_battery_off_peak_discharge to 0.25 (this assumes your average load is 500Wh)

Please note this code relies on having two utility meter sensors already working, and depending on how you interfaced the Inverter you may (or may not have these), the sensors are sensor.bat_charge_daily and sensor.bat_discharge_daily.

If you do not have these sensors please add the following code to your configuration.yaml -

These are the Riemann sums that feed the utility meters

Code: Select all

  - method: left
    name: bat_charge_sum
    platform: integration
    round: 2
    source: sensor.battery_charge
    unit_time: h
  - method: left
    name: bat_discharge_sum
    platform: integration
    round: 2
    source: sensor.battery_discharge
    unit_time: h
And these are the utility meters that go in the utility_meter: section

Code: Select all

  bat_charge_daily:
    source: sensor.bat_charge_sum
    cycle: daily
  bat_discharge_daily:
    source: sensor.bat_discharge_sum
    cycle: daily
The sensor will show the calculated capacity of the battery it will start out very inaccurate and as the day progresses and the SoC drop gets bigger the accuracy improves - it is most accurate at the end of the day 23:59:59

And that's it, please feel free to use or modify it to suit your eco tariff times and if you can suggest any improvements, please let me know.


I have attached a couple of images of the sensor from my system (an 18.2kWh battery).
btsmooth2.jpg
btsmooth1.jpg
Last edited by Dave Foster on Wed Aug 16, 2023 10:19 am, edited 11 times in total.
User avatar
Will
Site Admin
Posts: 197
Joined: Thu Oct 13, 2022 5:56 pm

Fantastic write up, thanks for the contribution
Community Admin / FoxESS Professional

Buy me a coffee or Book a zoom meeting for remote consultancy

FoxESS Tri Inverter Installation
2 x KH Series Inverters
24 x HV2600 (62.4kWh)
32 x 490w across 4 arrays
Dual Tesla Household
Heatpump & Low Carbon Housebuild
calum
Posts: 389
Joined: Fri Feb 24, 2023 11:00 am
Location: Stockport

Yep thanks Dave, this is really interesting. If I can get this working I can pull it into Grafana and use the "last" selector to record the value each day, then graph that over time, see if it changes as a result of temp, battery aging, etc.

I need to fix my weird SoC issues first though...and before I ask for the BMS firmware to be updated, I need to move over to RS485 for data logging so I can take advantage of Master / Slave firmware updates without losing connectivity....aren't dependency chains a joy!
H1-3.7 / 6xHV2600 / 14x400W / RS485 Modbus->HA
FoxESS Modbus HA Integration
Contact Fox here
calum
Posts: 389
Joined: Fri Feb 24, 2023 11:00 am
Location: Stockport

I've just set this up in my HA, now I need to give it a few days to see what the results are like. I have 15.6kWh nominal capacity (6xHV2600) and a 15% min SoC, which in theory gives me ~13.26kWh of usable capacity, but my best estimate is that we're getting about 11.5. Not sure if this is the BMS wonkiness that also apparently leads to large unexplained drops in SoC, or something else. I'll set up a Grafana panel to track the "last" value for each day, hopefully it will tell me something useful!

One thing that struck me as I was setting it up, shouldn't the unit of measurement be kWh rather than kW?
H1-3.7 / 6xHV2600 / 14x400W / RS485 Modbus->HA
FoxESS Modbus HA Integration
Contact Fox here
Dave Foster
Posts: 822
Joined: Thu Oct 13, 2022 7:21 pm

calum wrote: Wed Mar 22, 2023 2:25 pm
One thing that struck me as I was setting it up, shouldn't the unit of measurement be kWh rather than kW?
It should indeed - i’ll do a fix and update the notes.

I also need to make a change for the people that don’t charge to 100% every day as that breaks the calculation - i’ll post in a couple of days when i’ve updated it. :)
calum
Posts: 389
Joined: Fri Feb 24, 2023 11:00 am
Location: Stockport

also need to make a change for the people that don’t charge to 100% every day as that breaks the calculation
Ah yes - that would include me at the moment - experimenting with the Max SoC setting to ensure I have enough room to capture the excess generation in the middle of the day and minimise what goes back to the grid.
i’ll post in a couple of days when i’ve updated it.
I'll look out for it with interest, as no matter what I do I can't get this board to send me emails for replies to topics!
H1-3.7 / 6xHV2600 / 14x400W / RS485 Modbus->HA
FoxESS Modbus HA Integration
Contact Fox here
Dave Foster
Posts: 822
Joined: Thu Oct 13, 2022 7:21 pm

calum wrote: Wed Mar 22, 2023 5:19 pm
also need to make a change for the people that don’t charge to 100% every day as that breaks the calculation
Ah yes - that would include me at the moment - experimenting with the Max SoC setting to ensure I have enough room to capture the excess generation in the middle of the day and minimise what goes back to the grid.
i’ll post in a couple of days when i’ve updated it.
I'll look out for it with interest, as no matter what I do I can't get this board to send me emails for replies to topics!
Ok, I have modified the code to support partial battery charge at the start of the day, in effect it works out how much charge would have been needed had it been at 100% and removes that from the sensor.

The only change is to the automations first test (battery SoC not 100%) - if you have already created the automation it is probably easier to overwrite the old automation code with the code from above - but note you have to tell it what the maximum capacity your battery should have in my case 7*HV2600 = 7*2.56kwh = 17.92kwh.
calum
Posts: 389
Joined: Fri Feb 24, 2023 11:00 am
Location: Stockport

I've set up your updated sensor on my HA, so far the results are not promising, at midnight last night the reading was just below 9kWh when it should be closer to 13! (6xHV2600 & 15% Min SoC).

@Dave Foster, can I ask what battery firmware versions you have? My working theory is that my BMS (which is on 1.07, batteries on 1.05) is doing a poor job of judging SoC and is not using the full pack capacity as a result. I've managed to get my installer to update the inverter firmware but for whatever reason updating the BMS and battery firmwares seems more difficult!

Edit: As an aside, the BMS kWh Remaining value does read a little over 13 when the battery is full...some part of the system "knows" - what the capacity is, or should be.
H1-3.7 / 6xHV2600 / 14x400W / RS485 Modbus->HA
FoxESS Modbus HA Integration
Contact Fox here
Dave Foster
Posts: 822
Joined: Thu Oct 13, 2022 7:21 pm

calum wrote: Tue Apr 11, 2023 10:10 am I've set up your updated sensor on my HA, so far the results are not promising, at midnight last night the reading was just below 9kWh when it should be closer to 13! (6xHV2600 & 15% Min SoC).

@Dave Foster, can I ask what battery firmware versions you have? My working theory is that my BMS (which is on 1.07, batteries on 1.05) is doing a poor job of judging SoC and is not using the full pack capacity as a result. I've managed to get my installer to update the inverter firmware but for whatever reason updating the BMS and battery firmwares seems more difficult!

Edit: As an aside, the BMS kWh Remaining value does read a little over 13 when the battery is full...some part of the system "knows" - what the capacity is, or should be.
9kwh is not such a great reading, it normally reads a little high - and you would hope the kwh remaining would be much nearer 15.4 at full (mine is very accurate now). I would normally suggest you do a full grid charge cycle but if they are V1’s get the latest firmware first.
The batteries on mine are Master(BMS) 1.016 and 1.013 slave (Batteries), if you have the latest inverter firmware I would definitely recommend you get the batteries updated - this version has big improvements in SoC stability, tracking and battery charge absorption over 1.07/5. - it also does away with soc being limited to 99%, now reporting full range to 100%.
The battery firmware has to be upgraded in a slightly different screen to the inverter remote upgrade (battery remote upgrade) which could explain why they missed it, but it is really worth getting it done.

UPDATE: FoxESS have just releases 1.018 and 1.015 - as usual no release notes, a few comments that suggest it was about soc tracking issues - so i'll update now and see how that goes.
calum
Posts: 389
Joined: Fri Feb 24, 2023 11:00 am
Location: Stockport

This was working well for me and showed that the recent BMS and battery firmware updates were definitely helping. However unfortunately it stopped working, and I'm not sure why. Here's the log:

Code: Select all

Logger: homeassistant.helpers.event
Source: components/sensor/__init__.py:583
First occurred: 10:38:46 (27 occurrences)
Last logged: 10:55:03

Error while processing state change for sensor.bat_charge_daily
Error while processing state change for sensor.battery_soc
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/sensor/__init__.py", line 581, in state
    numerical_value = float(value)  # type:ignore[arg-type]
ValueError: could not convert string to float: '14.5\n             \n      \n    \n\n\n      # calculate cell imbalance as % using the difference between min and max cell voltage'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/event.py", line 287, in _async_state_change_dispatcher
    hass.async_run_hass_job(job, event)
  File "/usr/src/homeassistant/homeassistant/core.py", line 607, in async_run_hass_job
    hassjob.target(*args)
  File "/usr/src/homeassistant/homeassistant/helpers/event.py", line 1133, in _refresh
    self.hass.async_run_hass_job(self._job, event, updates)
  File "/usr/src/homeassistant/homeassistant/core.py", line 607, in async_run_hass_job
    hassjob.target(*args)
  File "/usr/src/homeassistant/homeassistant/helpers/template_entity.py", line 348, in _handle_results
    self.async_write_ha_state()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 585, in async_write_ha_state
    self._async_write_ha_state()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 649, in _async_write_ha_state
    state = self._stringify_state(available)
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 591, in _stringify_state
    if (state := self.state) is None:
  File "/usr/src/homeassistant/homeassistant/components/sensor/__init__.py", line 583, in state
    raise ValueError(
ValueError: Sensor sensor.battery_track has device class None, state class None unit kW and suggested precision None thus indicating it has a numeric value; however, it has the non-numeric value: 14.5
             
      
    


      # calculate cell imbalance as % using the difference between min and max cell voltage (<class 'str'>)

I'm not sure why the logs are showing up the "calculate cell imbalance" thing, I do have that in my configuration.yaml below, but that particular line is commented out with "#", above the cell imbalance sensor that I added after the discussion in my other thread (I'd commented that out as well as part of my troubleshooting - predictably, doing so hasn't made any difference).

The relevant bit of my configuration.yaml looks like this:

Code: Select all

      
    - name: "Battery Track"
      unit_of_measurement: "kW"
      state: >
        {% if  states("sensor.bat_charge_daily") in ['unknown', 'unavailable'] %}
          {{ 0|round(0) }}
        {% else %}
            {% if states("sensor.battery_soc")|float > 98 %}
               {% set batUsed = 0.01 | float%}
            {% else %}
               {% set batUsed = ((99-states("sensor.battery_soc") | float)/100) %}
            {% endif %}
            {% set dischgLessSolarChg = ((states('sensor.bat_charge_daily')|float - states('input_number.battery_charge_off_peak')|float) / 1.1) %}
            {% set calcbattery = (((states("sensor.bat_discharge_daily")|float) - states("input_number.battery_off_peak_discharge")|float - dischgLessSolarChg) / batUsed) |round(2,default=0) %}
            {% if  states("sensor.bat_discharge_daily") in ['unknown', 'unavailable'] %}
              {{ 0|float }}
            {% else %}
              {% if states("input_number.battery_charge_off_peak")|float > 0 %}
                     {% if calcbattery > 24 %}
                        {{ 24 | round(2) }}
                     {% else %}
                        {{ calcbattery |round(2,default=0) }}
                     {% endif %}
              {% else %}
                {{ 0|float }}
              {% endif %}
            {% endif %}
        {% endif %}
        
#      calculate cell imbalance as % using the difference between min and max cell voltage
#    - name: "Battery Cell Imbalance"
#      unique_id: foxess_calculated_battery_cell_imbalance
#      unit_of_measurement: "%"
#      state: >
#        {% set cell_high = states('sensor.bms_cell_mv_high') | float(default=0) %}
#        {% set cell_low = states('sensor.bms_cell_mv_low') | float(default=0) %}
#        {% set imbalance = (cell_high-cell_low) / (cell_high + cell_low) * 200 if cell_low > 0.0 else 0.0 %}
#        {% set imbalance = 0.0 if cell_high < cell_low else imbalance %}
#        {{ imbalance | round(2) }}

I am 99% sure I've not made any changes that would directly cause this, I'm wondering if recent HA updates might have introduced some sort of bug?
H1-3.7 / 6xHV2600 / 14x400W / RS485 Modbus->HA
FoxESS Modbus HA Integration
Contact Fox here
Dave Foster
Posts: 822
Joined: Thu Oct 13, 2022 7:21 pm

I copied and pasted the sensor test you posted into my template editor and it all worked fine so it looks like your templates are getting confused.

Did you reload your templates in developer tools after commenting out the cell imbalance sensor?

The log looks like the templates are merged, perhaps there is a ‘hidden’ format character before or in the imbalance text that is messing up the template. I think i’d be inclined to delete that imbalance text entirely (for now) and reload your templates to see if that clears the fault and then work back from there.
calum
Posts: 389
Joined: Fri Feb 24, 2023 11:00 am
Location: Stockport

As suggested I removed the cell imbalance YAML code and restarted. Went to look at the sensor and it had just started working again yesterday afternoon, apparently without my intervention!
The only thing I can think of is that I restarted HA to get some HACS updates to take effect, but I'm very much in the groove of restarting HA whenever I change configuration.yaml and I remember doing so several times after I'd commented out the cell imbalance code and being baffled that the text from the start of it was still appearing in the error message.

Chalk this one up to HA weirdness or me fluffing something I guess. Still puzzled about why it seemed to be trying to execute / use a commented out line, though.

Overnight the sensor was showing 14.6kWh which is much better than the 9-11kWh I was seeing but still suggests something is not quite right. I'll do my best to do a full-empty-full cycle next week, might have to abuse things a little by draining the house battery into the car. Seems very likely that at least some of the loss vs nominal capacity would be down to balancing. The rest of it probably down to temp differences which are going to be tricky to resolve without adding some active heating, and as things stand I'll have to alter the insulating box to do that.
H1-3.7 / 6xHV2600 / 14x400W / RS485 Modbus->HA
FoxESS Modbus HA Integration
Contact Fox here
chris01942
Posts: 15
Joined: Sun Nov 06, 2022 8:34 am

Hi Dave, with winter looming, I'll be force charging & looking at capacity tests. Before I go ahead & get your tracker up & running I have ECS2900 V1 on the latest firmware (SoC hits 100%) are there any changes to the tracker code needed. Oh, I'm on Flux at the moment (off peak 02:00 - 05:00).

Cheers
Dave Foster
Posts: 822
Joined: Thu Oct 13, 2022 7:21 pm

chris01942 wrote: Wed Aug 09, 2023 4:46 pm Hi Dave, with winter looming, I'll be force charging & looking at capacity tests. Before I go ahead & get your tracker up & running I have ECS2900 V1 on the latest firmware (SoC hits 100%) are there any changes to the tracker code needed. Oh, I'm on Flux at the moment (off peak 02:00 - 05:00).

Cheers
Hi Chris,

The code will need a bit of a refresh to deal with the 100% SoC (all batteries now report that), but I could probably do with changing it so you can set the eco tariff start/end time as it assumes Octopus Go at the moment.

It works best with force charging over winter as even with the latest firmware there's still a margin of drift in the SoC when it only receives charge from solar, that's not an issue with the batteries rather just the granulation nature of the SoC as a 1% change can hide a considerable amount of charge/discharge if it's cloudy - with force charge and then normal discharge it's much more accurate.

Do you have any kind of automation running at the moment for your Flux?, if so I can modify the code to use the names of the helpers you currently have - if not i'll update the code and add a couple of helpers to deal with different start and end times.

Shouldn't take long to update and test it (a week?), then you'll be good to go and copy it.
chris01942
Posts: 15
Joined: Sun Nov 06, 2022 8:34 am

Dave Foster wrote: Wed Aug 09, 2023 5:14 pm
chris01942 wrote: Wed Aug 09, 2023 4:46 pm Hi Dave, with winter looming, I'll be force charging & looking at capacity tests. Before I go ahead & get your tracker up & running I have ECS2900 V1 on the latest firmware (SoC hits 100%) are there any changes to the tracker code needed. Oh, I'm on Flux at the moment (off peak 02:00 - 05:00).

Cheers
Hi Chris,

The code will need a bit of a refresh to deal with the 100% SoC (all batteries now report that), but I could probably do with changing it so you can set the eco tariff start/end time as it assumes Octopus Go at the moment.

It works best with force charging over winter as even with the latest firmware there's still a margin of drift in the SoC when it only receives charge from solar, that's not an issue with the batteries rather just the granulation nature of the SoC as a 1% change can hide a considerable amount of charge/discharge if it's cloudy - with force charge and then normal discharge it's much more accurate.

Do you have any kind of automation running at the moment for your Flux?, if so I can modify the code to use the names of the helpers you currently have - if not i'll update the code and add a couple of helpers to deal with different start and end times.

Shouldn't take long to update and test it (a week?), then you'll be good to go and copy it.
Hi Dave thanks for getting back to me. No, I won't be using any automation, simply setting the force charge times. I'll be definitely looking at when I'm sure there's no solar charge influencing the discharge for a capacity test over any very poor winters days.

Cheers, Chris
Dave Foster
Posts: 822
Joined: Thu Oct 13, 2022 7:21 pm

chris01942 wrote: Thu Aug 10, 2023 9:59 am
Hi Dave thanks for getting back to me. No, I won't be using any automation, simply setting the force charge times. I'll be definitely looking at when I'm sure there's no solar charge influencing the discharge for a capacity test over any very poor winters days.

Cheers, Chris
Hi Chris,

I've updated the code and instructions above, i've made a number of improvements whilst I was there, the first is to add a start and end time for the charge period (i've called it Octopus Go for now but you can just set the time to whatever your charge period is).
The second improvement is to add the 'actual' capacity of your batteries, you'll need to set this to whatever your expected kwh is.

And the main change is that as this was originally intended to work effectively during winter months when you charge every night, it was quite inaccurate with just solar charge - so I have improved that by resetting the counters whenever solar achieves a 100% charge (much like a grid charge) and it works quite well on just solar as well.

Hopefully everything above is now updated, i'm running this version fine but if you have any problems let me know.
chris01942
Posts: 15
Joined: Sun Nov 06, 2022 8:34 am

Dave Foster wrote: Wed Aug 16, 2023 10:12 am
chris01942 wrote: Thu Aug 10, 2023 9:59 am
Hi Dave thanks for getting back to me. No, I won't be using any automation, simply setting the force charge times. I'll be definitely looking at when I'm sure there's no solar charge influencing the discharge for a capacity test over any very poor winters days.

Cheers, Chris
Hi Chris,

I've updated the code and instructions above, i've made a number of improvements whilst I was there, the first is to add a start and end time for the charge period (i've called it Octopus Go for now but you can just set the time to whatever your charge period is).
The second improvement is to add the 'actual' capacity of your batteries, you'll need to set this to whatever your expected kwh is.

And the main change is that as this was originally intended to work effectively during winter months when you charge every night, it was quite inaccurate with just solar charge - so I have improved that by resetting the counters whenever solar achieves a 100% charge (much like a grid charge) and it works quite well on just solar as well.

Hopefully everything above is now updated, i'm running this version fine but if you have any problems let me know.
Hi Dave, thanks for that. I seem to have got that working as there is data for battery track/smooth, but can't test fully until the battery hits 100%. Quick question, in the image for "battery off peak discharge" it's showing a max value of 2. Am I correct in thinking that should be 30 as in "Battery Charge Off Peak" helper?

Cheers, Chris
chris01942
Posts: 15
Joined: Sun Nov 06, 2022 8:34 am

chris01942 wrote: Fri Aug 18, 2023 3:00 pm
Dave Foster wrote: Wed Aug 16, 2023 10:12 am
chris01942 wrote: Thu Aug 10, 2023 9:59 am
Hi Dave thanks for getting back to me. No, I won't be using any automation, simply setting the force charge times. I'll be definitely looking at when I'm sure there's no solar charge influencing the discharge for a capacity test over any very poor winters days.

Cheers, Chris
Hi Chris,

I've updated the code and instructions above, i've made a number of improvements whilst I was there, the first is to add a start and end time for the charge period (i've called it Octopus Go for now but you can just set the time to whatever your charge period is).
The second improvement is to add the 'actual' capacity of your batteries, you'll need to set this to whatever your expected kwh is.

And the main change is that as this was originally intended to work effectively during winter months when you charge every night, it was quite inaccurate with just solar charge - so I have improved that by resetting the counters whenever solar achieves a 100% charge (much like a grid charge) and it works quite well on just solar as well.

Hopefully everything above is now updated, i'm running this version fine but if you have any problems let me know.
Hi Dave, thanks for that. I seem to have got that working as there is data for battery track/smooth, but can't test fully until the battery hits 100%. Quick question, in the image for "battery off peak discharge" it's showing a max value of 2. Am I correct in thinking that should be 30 as in "Battery Charge Off Peak" helper?

Cheers, Chris

Hi Dave, first off all seems to working correctly the helpers updated properly at 5am following the end of the Flux off-peak period. Second, I've worked out why battery off peak discharge helper has a max number significantly lower than the charge off peak helper. So, all is good.

Thanks for your efforts with the battery tracker it's going to be useful this winter. No more manually trying to figure out actual capacity via capacity discharge tests.

Thanks, Chris
Dave Foster
Posts: 822
Joined: Thu Oct 13, 2022 7:21 pm

chris01942 wrote: Sat Aug 19, 2023 5:49 am Hi Dave, first off all seems to working correctly the helpers updated properly at 5am following the end of the Flux off-peak period. Second, I've worked out why battery off peak discharge helper has a max number significantly lower than the charge off peak helper. So, all is good.

Thanks for your efforts with the battery tracker it's going to be useful this winter. No more manually trying to figure out actual capacity via capacity discharge tests.

Thanks, Chris
Hi Chris, yes you beat me to it, the lower value for off-peak discharge is to catch the usage between midnight and when your low tariff starts, in your case it’s 2am so if you think your house load will be more than 2 kWh you’ll need to increase it (I guess unlikely apart from New Years eve :) )
Any problems, or suggested improvements, just let me know
Post Reply