How to interpret 0% SOC as an issue

[Young-Grandad]

I had an issue yesterday when the circuit breaker tripped between the battery and the inverter. The Givenergy App was reporting the SOC as 0% but GivTCP in HA showed the SOC as 37%. What brought this to my attention was that my IHD was showing that I was consuming 2kW from the grid when that should have been taken care by the battery. In the GivTCP log I can see that there was an ERROR and so the 0% reported was going to use the previous value (37%). What I would like to do is set up some automation so that if SOC == 0% then I send a message to my iPhone as a possible fault. Is there a way this can be done when reading the SOC from the Givenergy cloud, since it did show the SOC as 0% at that time?

Kind regards, Steve

[gcoan]

I wrote a script to detect failures in givtcp, it either stopping (going offline) or not updating the last update time. It uses a notification group to alert my iPad and iPhone

In your particular circumstance it probably wouldn’t have worked as it sounds like givtcp was still running, just not reading the battery soc properly. Assume you have an AIO? You could create a template sensor to read the GivEnergy portal version of the soc and extend this monitor ?

alias: GivTCP activity monitor description: Alert when communications to GivTCP have ceased for 30 minutes trigger:

• platform: state entity_id: sensor.g_xxxx_last_updated_time to: null for: minutes: 30 variables: inv_id: inverter 1 (G)
• platform: state entity_id: sensor.h_yyyy_last_updated_time to: null for: minutes: 30 variables: inv_id: inverter 2 (H)
• platform: state entity_id:
  • sensor.g_xxxx_status from: online for: minutes: 30 variables: inv_id: inverter 1 (G)
• platform: state entity_id:
  • sensor.h_yyyy_status from: online for: minutes: 30 variables: inv_id: inverter 2 (H) action:
• service: notify.all_devices data: title: GivTCP communication issue message: > {{ now().timestamp() | timestamp_custom('%-d %b %H:%M') }} ISSUE: No GivTCP update received from {{ inv_id }} for the past hour. data: tag: GivTCP_issue visibility: public persistent: true push: sound: name: default critical: 1 volume: 0.8 mode: single

On 22 Nov 2023, at 14:02, Young-Grandad @.***> wrote:

 I had an issue yesterday when the circuit breaker tripped between the battery and the inverter. The Givenergy App was reporting the SOC as 0% but GivTCP in HA showed the SOC as 37%. What brought this to my attention was that my IHD was showing that I was consuming 2kW from the grid when that should have been taken care by the battery. In the GivTCP log I can see that there was an ERROR and so the 0% reported was going to use the previous value (37%). What I would like to do is set up some automation so that if SOC == 0% then I send a message to my iPhone as a possible fault. Is there a way this can be done when reading the SOC from the Givenergy cloud, since it did show the SOC as 0% at that time?

Kind regards, Steve

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.

[Young-Grandad]

Thanks and I appreciate your thoughts. I'm new to HA, GivTCP etc so I assume that AIO means All IN One (installer). I didn't use that as far as I know. I put a HA image onto a SD card and use a Pi 4 as the server and carried out the rest of the install, add-ons etc from a laptop. I looked at the "GivTCP Last Updated Time" and can see that I was getting regular updates (20-30 seconds apart) during the issue time, so I'm not sure if your suggested code would work for me. The obvious solution (to me) is for Givenergy to build an alert for my type of issue. I can see that from the battery information in the Givenergy web portal battery charge and temperature are zero, and voltage is 2V during the time of my issue. I'm wondering if it is possible to use a script to grab those values, or maybe GivTCP could have some further sensors added. I see that it does have a voltage and temperature for each cell but I missed the totals.

Kind regards Steve

[gcoan]

Thanks and I appreciate your thoughts. I'm new to HA, GivTCP etc so I assume that AIO means All IN One (installer). I didn't use that as far as I know. I put a HA image onto a SD card and use a Pi 4 as the server and carried out the rest of the install, add-ons etc from a laptop.

I looked at the "GivTCP Last Updated Time" and can see that I was getting regular updates (20-30 seconds apart) during the issue time, so I'm not sure if your suggested code would work for me.

Hi Steve, if you are getting regular updates from the inverter but not the battery then the script I offered wouldn't work and at the moment there isn't an easy way to detect it without going to the GivEnergy portal values via api calls. You could look for the battery soc not changing for a period of time but this could give you false alerts so would need thinking about how and when it triggers. Maybe a future change to givtcp to raise an alert if no battery comms after an extended period of time?

The question about AIO was asking if you had a,GivEnergy all in one battery system as to whether that was the cause of the breaker tripping. I've got hybrid inverters and the only switch between the battery and the inverter is an isolator switch, it's not a circuit breaker that can trip, you can only physically turn it off. As far as I know that's the normal way of wiring GivEnergy batteries so was wondering why you had a trip switch installed, which might be the case with the AIO

[Young-Grandad]

Hi Geoffrey, thank you for confirming that I was right that your suggested wouldn't work for me. As I said, I'm new to all of this, but not to issue analysis - assuming there is data/statistics to look at! Regarding the AIO; it makes sense now why you ask that question. I'm not using an AIO. I had some solar PV panels installed a couple of years ago without any batteries. This served me well until some analysis I did showed that over that period I was exporting 20% of energy generated by the panels, so I had some batteries installed a couple of months ago. Then I installed HA to get some automation working. So basically I have 2 inverters that have no direct connection with each other (different makes).

Maybe the GivTCP author could consider an enhancement request regarding lost comms with the battery?

Kind regards Steve

[britkat1980]

As the inverter should never (in theory) report 0% SOC the code assumes its an error. Perhaps the code could show that value if it persists for a defined duration?

[gcoan]

Just to throw another scenario in; that of no battery connected to the inverter.  At the moment GivTCP determines that no soc can be found and sets soc to 1% then on each subsequent poll battery soc is reported as 0% and so the previous value of 1% is used. Apart from the  log filling up with these messages this doesn't currently cause an error to be logged and I suggest it shouldn't in future either. On 23 Nov 2023 at 22:06 +0000, britkat1980 @.***>, wrote:

As the inverter should never (in theory) report 0% SOC the code assumes its an error. Perhaps the code could show that value if it persists for a defined duration? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

[Young-Grandad]

Yes that's what I observed but in a different way. When no SOC can be found by GivTCP it shows an ERROR in the log and leaves the SOC at the previous detected value. In my case that was 37%. In a way that is correct. However, there is no discharge (or charge) occurring so the battery is reported as IDLE. My view is that we need something that says we've lost the heart beat (or connection) to the battery. At the moment you can sort of get this information from the portal cloud; battery temperature and charge are zero, but I feel a more robust solution is needed, either by GivTCP or GivEnergy.

Regards, Steve

[gcoan]

Looking at my HA statistics as one of my batteries has had to be removed recently, battery temperature or battery cells going to unknown is a reasonable proxy for the battery going offline. Think I’ll add this to my givtcp monitor

Geoffrey

On 24 Nov 2023, at 13:14, Young-Grandad @.***> wrote:

 Yes that's what I observed but in a different way. When no SOC can be found by GivTCP it shows an ERROR in the log and leaves the SOC at the previous detected value. In my case that was 37%. In a way that is correct. However, there is no discharge (or charge) occurring so the battery is reported as IDLE. My view is that we need something that says we've lost the heart beat (or connection) to the battery. At the moment you can sort of get this information from the portal cloud; battery temperature and charge are zero, but I feel a more robust solution is needed, either by GivTCP or GivEnergy.

Regards, Steve

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.