Time Since Last Full Charge for Victron

[Danie10]

The problem is that if the battery is not regularly fully charged, it tends to have imbalanced cells, and this leads to incorrect SOC being shown. It happened to me during Winter that I ran the battery down to 30% for some weeks it never got a full 100% charge. One night the system just shut down and the SOC was actually around 35% I think. The installers said I should ensure that at least weekly I make sure it has a full 100% charge (and at 100% to balance the cells ie. until the charge current actually reaches close to 0A). This will usually be achieved in Summer months by solar alone, but in Winter it may require a manual switch to Ensure Battery Life, or similar mode, to get charged. I'm not sure yet about whether to automate that process, but I'll start with a warning alert.

The theory will be to start a counter running in Automations when SOC is 100% and the current to battery has dropped close to 0A. Then if that counter has elapsed 7 days, to give a warning. The counter just needs to restart every time the trigger conditions happen, as it may get a full charge every day even.

I'm aware there are registers that show a cell imbalance, for example, but no data seems to be changing or extracted from these registers. So part of this exercise will be to also have a relook at all available registers that provide any meaningful data.

[Danie10]

So after a few hours of looking at it, it still does not look like any of the intended Modbus registers for 'time since last full charge' ie. slave 225 register 289, returns anything except a 0 value. A pity as that would be nice to just pull.

So two possible ways are now explored, with both being an Automation triggered by Battery SOC = 100% AND Modbus slave 100 register 844 for Battery State = 0 (Idle = current stops flowing into battery). Normally the battery will be charging (Battery State = 1) until it gets to SOC 100%, and it will keep charging until it goes into Idle mode which means cells should be fully balanced etc. I'm going to also monitor Modbus slave 246 register 31 for Ve Bus State = 4 (Absorption), 5 (Float), 7 (Equalise) just to see if they show anything conclusive at full charge. The latter is because it may be that balancing only happens a time after Idle mode has started.

It would be great to have a timer running on how long Idle mode has been on, but if any heavy appliance is run, there is sometimes a Discharge and that would interrupt the Idle mode timer (it was, say, 5 minutes). So I'm intending to set a very short time for the Idle mode like say 5 or 10 seconds to trigger full charge. Likewise a timer on the 100 SOC may not be reliable depending on how long the battery must charge at 100% to reach Idle mode.

The two ways of storing the last full charge time and then counting down 7 days (168 hours) are:

1. HA Timer - this has been tested with timer initialised at "168:00:00", and the Automation simply does a timer.reload whenever the trigger is true. This displays easily as a card showing HH:MM:SS as it counts down to 0 hour. The idea is to pop up a persistent alert.
2. Custom Component Var - this was an AI suggestion I must explore. The idea is to define this as a persistent variable. Whenever trigger is true, it saves current now() time to the variable. A card will display diff between variable and now(), which counts upwards in terms of time elapsed from last full charge time. This has the advantage that it keeps counting past zero hour (versus timer that stops as finished) so you can see if it is now 8 or 9 days elapsed.

Supposedly, both the timer and variable method should survive restarts (must be tested - update: timer does survive a restart of HA). The Var method offers a further advantage of being able to write it to a file in case it does not survive reboots. Also, the Var method better supports timedelta calculations, as I'm noticing by default the timer does not show as a number for a nice gauge view.

But I'm aiming to finish the middle first (saving the full charge time and resetting it on trigger), then finalise card display and warning, and last actually define the trigger condition.

[Danie10]

An update on timer attributes: You can extract duration, remaining and finishes_at, but the remaining time attribute (the one I'd want) ONLY updates when the timer is paused. Not sure if it is practical to pause and restart the timer every hour or so....

remaining = {{ state_attr('timer.fullcharge', 'remaining') }}

Other alternative is to calculate the diff between now() and finishes_at as the remaining time left. That would countdown the whole time, and would recalculate if the end time was adjusted.

seconds_left = {{ (as_timestamp(state_attr('timer.fullcharge', 'finishes_at')))-(as_timestamp(now()))|int }} and that updates once every minute (if the timer is active).

[Danie10]

In the end, I decided to go with a variable instead of the timer. So the basic steps were:

1. Defined it as a date and time as a Helper in the GUI under Settings / Devices and Services / Helpers - that creates an input variable, and you can also set it manually here if you wish.
2. Created an Automation triggered by Battery State changing from Charging to Idle for at least 15 secs, with Condition Battery SOC is above 99%, and that does an Action of setting the input Helper to now() as a timestamp. In other words, whenever the battery stops charging after reaching 100% set that input Helper as time now.

  alias: Restart Battery Last Full Timer
  description: Watches for when battery is above 99% (fully charged to 100%) SOC and
    battery current changed to Idle for 15 secs. Then resets the Battery Last Full
    Date helper.
  trigger:
  - platform: state
    entity_id:
    - sensor.battery_state
    from: '1'
    to: '0'
    for:
      hours: 0
      minutes: 0
      seconds: 15
  condition:
  - condition: numeric_state
    entity_id: sensor.battery_soc
    above: 99
  action:
  - service: input_datetime.set_datetime
    data:
      datetime: '{{ now() }}'
    target:
      entity_id: input_datetime.battery_last_full_date
  mode: single

3. I then defined a custom sensor to calculate the integer of days difference between that input Helper and time now, in days:

    # This calculates the difference in whole days since the solar battery was last fully charged. It calculates based on the
    # value of the Helper called Battery Last Full Date's state. There is an Automation that triggers a reset of the Helper
    # when SOC is 100% and the battery current has changed from Charging to Idle. Less than a day will output 0.
    battery_last_full_days:
      unit_of_measurement: "Hours"
      icon_template: mdi:battery-charging-100
      value_template: >-
        {% set battery_last_full_date = as_timestamp(states.input_datetime.battery_last_full_date.state)|int %}
        {% set now_full_date = as_timestamp(now())|int %}
        {{ ((now_full_date - battery_last_full_date)/86400) | int }}

4. Created a simple gauge on the dashboard to show the days elapsed since the last full battery charge (displays that calculated days difference from step 3), with the scale turning orange at 7 days, and red at 10 days.
   

5. Created an Automation to just warn me by audio alert, and text notification to my phone, that the battery has not been fully charged for 7 days, triggered by the calculated sensor being above 6 (days).

So I'm going to just run this a few days and need to wait also until there is a full charge, so I can test the trigger to reset the charged time, then I'll upload the new code if all is good. As we have a few more rainy days ahead, I may also see if I get the 7 day warning for no full charge done. Today is day 2 already.

[Danie10]

Interesting observations today after the battery SOC reached 100%:

• The correct trigger is battery=Idle for about 9 secs, because if you trigger on SOC it only passes once from 99 to 100, and then does not test the automation again as it never triggers again unless the SOC drops to 99 and again passes to 100%. So every time the battery idles for 9 secs, it will check if SOC is 100%, then trigger action.
• Battery Idle is between -30W and +30W current on my system. It seemed that 15 secs on Idle was too long as it never idles that long.
• Battery full appears to be 56.10V on my system.
• The system sits for a good 30 to 35 mins on 100% before it gets to battery idle for 9 secs. From the time it gets to 100% the system changes to Absorption mode with around 3A average current, the while dropping lower to 2A then 1A. It cycles through gentle charging, discharging, idle, and so on. Idle is around less than 0.5A.
• I'm not seeing my system actually reach Float mode (Ve.Bus State=5). It's been over an hour at 100% already. Maybe I'll see this further into Summer, as then the battery is hitting 100% after 13:00.
• The last charge counter is counting up nicely as I saw it change from 2 days to 3 days today, at the correct time.

For now I think this is good enough. If Float mode turns out to actually work, then I'll re-assess whether the trigger should rather change to Ve.Bus State=5. It is one simple change to the trigger of the automation, as everything else stays the same.

[Danie10]

Here is the response from my installer regarding why I'm not seeing the Ve.Bus State enter Float Mode with the Lithium battery:

It will never show float as with the Lithium battery the Absorption and float voltage is the same, so when it is in idle mode it is in float (full), but as both voltages are the same Victron will still say absorption. The battery has a fixed charge voltage.
I would set the time to 1 hour, so that the battery when full, is full and charges at full for 1 hour in a 7 day period. In this hour the battery will balance.

So the test being done for battery idle mode for 10 secs at 100% SOC seems to be the best one for establishing it is at a properly fully charged state. But I'm going to do another test on a sunny day and time exactly what happens during an hour after absorption mode starts, to see if it correlates with the idle time changes.