HA GivTCP Battery Card help

11 comments started 2024-12-01 last 2024-12-12
Home AutomationHome Assistant
D
#1 Daveb01

Hi all, I have been looking at my AIO Battery card and it’s reading the full capacity of the Battery 16 kWh. Is anyone else seeing this with an AIO?

Has anyone got any ideas on how to fix this please?
Can I be reassured that this is not affection my Predbat predictions?

My card (you can only add the battery serial number to the card, you can not pick a sensor)

I think this card is getting the setting from MQTT but not the correct setting.




G
#2 geoffreycoan

Daveb01 You need to set a custom DoD %. The AIO reports total capacity not available capacity

D
#3 Daveb01

Hi all, I have been looking at my AIO Battery card and it’s reading the full capacity of the Battery 16 kWh. Is anyone else seeing this with an AIO?

Has anyone got any ideas on how to fix this please?
Can I be reassured that this is not affection my Predbat predictions?

My card (you can only add the battery serial number to the card, you can not pick a sensor)

I think this card is getting the setting from MQTT but not the correct setting.

Changing the DOD does not help

I think it is getting the top setting and it should be using the second one (calc)

This is what my GW is seeing, which is correct and being used in Predbat

T
#4 TX200

Daveb01 I think there's battery scaling percentage you can apply, think it's in apps.yaml?

G
#5 geoffreycoan

TX200 no, the apps.yaml scaling is for Predbat. The battery card has its own scaling in its config above

D
#6 Daveb01

geoffreycoan

I understand what you are saying and I did change the DoD to 83% to make it correct, however I was worried this may affect the battery readings that GivTCP was using and this then affect Predbat? So I put it back.

If your sure it is just a visual thing then I can leave it at 83%

What I would like to happen is the card to reflect the correct sensor (this can be selected in MQTT) but not by the card? Why is this?

With DoD Stats on

Tried 84% as well

G
#7 geoffreycoan

Daveb01 I understand what you are saying and I did change the DoD to 83% to make it correct, however I was worried this may affect the battery readings that GivTCP was using and this then affect Predbat? So I put it back.

If your sure it is just a visual thing then I can leave it at 83%

The GivTCP sensors report what the inverter says is the kWh capacity of your battery, and for the AIO (and my 5.2kWh battery) they both quote the total available capacity not the usable capacity.

There’s no way in GivTCP to reconfigure the sensor to apply a custom scaling factor so wherever you use the battery capacity you have to scale it. In Predbat via apps.yaml and in the GivTCP battery card. Changing apps.yaml doesn’t affect the battery card and vice versa, they are both independently scaling the capacity reported.

It is just a display thing, yes

What I would like to happen is the card to reflect the correct sensor (this can be selected in MQTT) but not by the card? Why is this?

It’s the way the card is constructed. It just needs to know what the battery serial number is and from there it works out all the other battery sensors it needs to use - SoC %, charge rate, battery power, etc. It makes the card simpler and more consistent to use like this.

J
#9 JasonF

Nothing to do with predbat. The scaling is only for this card.

D
#10 Daveb01

JasonF

Thank you all I have now set it to 82% and this looks correct, however I have just noticed the batteries are out of sync for the first time. Do you think I should contact GE and get my system firmware upgraded as I am on the Beta program as well for 2 x AIO’s?

G
#11 geoffreycoan

Daveb01 I suggest you just keep an eye on it. The gateway is supposed to balance the AIO’s and it looks like that is happening with AIO-2 discharging at twice the rate of AIO-1. If they stay persistently out of line or keep diverging then raise it with GE, but a bit of in balance is normal I’d think- the AIO’s will discharge and charge differently in respond to house load and SoC measurement is not perfect.