GivTCP - Energy: battery_charge_energy_total corrupted and frozen

I am running HomeAssistant on a HA-Green computer, and am running an automation that monitors the charge-total and discharge-total parameters to keep tabs on the cost of the charge currently stored in my home battery.
Three days ago, givtcp_xxxxxxxx_battery_charge_energy_total_kwh jumped up instantly by over 1100 kWh (!) and has not been updated since, in spite of the daily charge/discharge from the 9.5kWh battery. This results in the automation failing.
I have tried rebooting the battery/inverter, but no improvement. Rebooting HA has no effect either, of course.
Anyone else had this type of problem?
GivEnergy how can the correct lifetime total be restored?
GivEnergy how to stop this happening again?

SteveBu does the same jump show on the portal data? If not, can you be sure it's not a GivTCP problem?

@"SteveBu" I've been having a problem with GivTCP battery charge energy and battery discharge energy figures in Home Assistant for months. I'm still trying to find a workaround. However, the problem is not with GivEnergy - the figures are fine in the app. The problem is somewhere in GivTCP and Home Assistant - somewhere, somehow the database has been corrupted and even uninstalling GivTCP, using Mosquitto Explorer to delete all MQTT entries and re-installing GivTCP hasn't fixed the issue. GivTCP doesn't seem to find the original register entries for these two categories.
You could try a complete re-install from a backup or create two new sensors to store the total data.

SteveBu Same thing happened to me last year except they reset to zero. Its not GivTCP, its GE & they won't "fix" it (even if they weren't going bust).

Both Battery Charge/Discharge Total are nonsense on my system. Battery Throughput Total is still accurate as is AC Charge Total.

The equipment doesn't measure battery charge or discharge, so the figures you are using must be calculated. Why are you using calculated figures rather than doing your own calculation from measured values?

Is your system AC coupled or Hybrid?

AC coupled (AC3 or AIO) is simplest. It's just a box containing a charger and an inverter. The input to the charger is measured (AC Charge Total on the portal) and the output of the inverter is measured (Combined Gen Total on the portal). The input total should be greater than the output total; the difference being the losses. If you are trying to calculate costs, then these are what you should be using. You still have to pay for electricity even when you lose it as heat.

Hybrid is more complicated as you have to take account of extra charge from PV.

The six meter points are explained here.
https://givenergymonitor.wixsite.com/tutorials/portal-transfer

Rubikcube I'm somewhat cynical about the figures presented on portal etc for the simple reason that GE "double-count" battery cycles, so having input-output figures going amiss while maintaining overall throughput is convenient.

For clarity - most everyone else in the battery world thinks a "cycle" is charge-discharge. GE log a "cycle" as a full charge, and a full discharge as another "cycle" which was convenient for certain warranties. Not that it matters now anyway.

Vestas Lets just say GE battery firmware uses a non-standard definition of a cycle.

SteveBu Three days ago, givtcp_xxxxxxxx_battery_charge_energy_total_kwh jumped up instantly by over 1100 kWh (!) and has not been updated since, in spite of the daily charge/discharge from the 9.5kWh battery. This results in the automation failing.

There is a known intermittent bug with givtcp where it does this, one of the total sensors randomly jumps to a very high value and then gets stuck there.

The fix is to restart givtcp and the value will then revert to the correct value. Restarting HA doesn’t restart givtcp as it runs as a separate docker app.

I have this happen occasionally, maybe every 6 months or so. Took ages to work out what was causing it and what the fix was, to just restart givtcp.

I’ll share the automation I created to monitor for and restart givtcp if it detects a big jump up or down.

automation:

alias: GivTCP sensor jump alert
description: ""
triggers:
  - entity_id: sensor.givtcp_xxxx_battery_charge_energy_total_kwh
    trigger: state
    to: null
    variables:
      trigger_name: Battery Charge Total
  - entity_id: sensor.givtcp_xxxx_battery_discharge_energy_total_kwh
    trigger: state
    to: null
    variables:
      trigger_name: Battery Discharge Total
  - entity_id: sensor.givtcp_xxxx_import_energy_total_kwh
    trigger: state
    to: null
    variables:
      trigger_name: Import Energy Total
  - entity_id: sensor.givtcp_xxxx_export_energy_total_kwh
    trigger: state
    to: null
    variables:
      trigger_name: Export Energy Total
  - entity_id: sensor.givtcp_xxxx_pv_energy_total_kwh
    trigger: state
    to: null
    variables:
      trigger_name: PV Energy Total
actions:
  - variables:
      delta: >-
        {{ ((trigger.to_state.state | float(0)) - ( trigger.from_state.state |
        float(0))) | abs }}
  - condition: template
    value_template: "{{ delta > 10 }}"
  - action: system_log.write
    metadata: {}
    data:
      level: warning
      message: "{{ trigger_name }} changed by {{ delta }}"
  - action: script.notify_all_devices
    metadata: {}
    data:
      title: "ISSUE: GivTCP sensor value jump"
      url: " "
      message: >-
        Restarting GivTCP as {{ trigger_name }} has changed from {{
        trigger.from_state.state }} to {{ trigger.to_state.state }}
  - action: hassio.addon_restart
    metadata: {}
    data:
      addon: 533ea71a_givtcp
trace:
  stored_traces: 20
mode: single

SteveBu As Geoff says, this happens and a givtcp restart fixes it.

t will cease to happen when the numbers are actually higher than the jump too figure....

geoffreycoan Thank you!

It’s nuggets like this which warrants preserving the content of this forum…

ectoplasmosis arguably should have such a place (wiki?) regardless - a forum is a pretty dreadful place to try to find old information.

ectoplasmosis 👍️

If @hoggy can open up his wiki I am happy to copy/write this into his wiki

Maybe we should start a tagging mechanism for such items, ideally not too many, and strengthening the wiki is a good thing to do anyway

I don't think I switched off registrations but it is me manually approving people. I suspect the current list is littered with spammers so I'll probably just decline everyone who tried until today and start fresh. Apologies if you suddenly get booted out if anyone from back in the day gets kicked out - just re apply.

Old Post on how to join it:
https://community.givenergy.cloud/d/811-the-unofficial-givenergy-wiki

@"geoffreycoan" a GivTCP restart didn't and hasn't fixed it for me so something in the database must have totally corrupted. I've had to resort to creating new 'lifetime' sensors based on daily figures and using Developer Tools to set the correct starting value (obtained from the GivEnergy app itself).
I'm not sure now when my problem first started but it was quite a while ago - may have coincided with a batch of power cuts!!!

Caerefail that is very strange. Can you install the BBC basic inverter app and what do you see for the total entries on that, do they match what givtcp is reporting?
Since the total all time figures are held in registers on the inverter, I suppose its possible that they have got corrupted in some way, but I’ve never heard of it happening. Usually the issue is that the total entities are reported by givtcp get a wrong high value and then don’t increment, and restarting the givtcp addon fixes this.