GivEnergy - Battery/Inverter + home power things

Share your Projects! Custom Integrations
, ,
143

Is there a know issue with GivTCP as for the past through weeks, I have discovered that my GivTCP stops collecting information from my GivEnergy invertor, and log the following error. this only resolves itself, after I do a restart on the Addon.

I have installed the Addon for Mqtt version 6.1.3 and GivTCP Version 2.0.6 into my Home Assistant.

Log from GivTCP

2022-12-17 10:26:11,839 - read - [ERROR] - Error collecting registers: (<class ‘KeyError’>, KeyError(IR:183), <traceback object at 0x7f125d213d80>)
2022-12-17 10:28:30,239 - sync - [ERROR] - Connection to (192.168.40.2, 8899) failed: timed out
2022-12-17 10:28:35,175 - GivLUT - [CRITICAL] - Consecutive failure count= 1
2022-12-17 10:28:35,175 - read - [ERROR] - Error collecting registers: (<class ‘KeyError’>, KeyError(IR:000), <traceback object at 0x7f125d20f900>)

I did see a post about deleting the .PKL files, but I have no ideal were to find them in HA

and when I restart the GIVTCP I get the following results

2022-12-17 12:37:58,068 - startup - [CRITICAL] - Config directory already exists
2022-12-17 12:37:58,068 - startup - [CRITICAL] - Running Redis
2022-12-17 12:37:58,072 - startup - [CRITICAL] - Running RQ Dashboard on port 9181
2022-12-17 12:37:58,072 - startup - [CRITICAL] - Setting up invertor: 1 of 1
2022-12-17 12:37:58,080 - startup - [CRITICAL] - Recreating settings.py for invertor 1
2022-12-17 12:37:58,081 - startup - [CRITICAL] - Removing old invertor data cache
2022-12-17 12:37:58,081 - startup - [CRITICAL] - Removing old battery data cache
2022-12-17 12:37:58,082 - startup - [CRITICAL] - Running RQ worker to queue and process givernergy-modbus calls
2022-12-17 12:37:58,082 - startup - [CRITICAL] - Running Invertor read loop every 5s
2022-12-17 12:37:58,087 - startup - [CRITICAL] - Subscribing Mosquitto on port 1883
2022-12-17 12:37:58,092 - startup - [CRITICAL] - Starting Gunicorn on port 6345
2022-12-17 12:37:58,104 - startup - [CRITICAL] - Setting daily charge target forecast job to run at: 00:20
[2022-12-17 12:37:58 +0000] [16] [INFO] Starting gunicorn 20.1.0
[2022-12-17 12:37:58 +0000] [16] [INFO] Listening at: http://0.0.0.0:6345 (16)
[2022-12-17 12:37:58 +0000] [16] [INFO] Using worker: sync
[2022-12-17 12:37:58 +0000] [19] [INFO] Booting worker with pid: 19
[2022-12-17 12:37:58 +0000] [20] [INFO] Booting worker with pid: 20
[2022-12-17 12:37:58 +0000] [21] [INFO] Booting worker with pid: 21
RQ Dashboard version 0.6.0

  • Running on 0.0.0.0:9181
  • Serving Flask app ‘rq_dashboard.cli’
  • Debug mode: off
    2022-12-17 12:38:00,889 - sync - [ERROR] - Connection to (192.168.40.2, 8899) failed: timed out
    2022-12-17 12:38:07,632 - GivLUT - [CRITICAL] - Consecutive failure count= 1
    2022-12-17 12:38:07,632 - read - [ERROR] - Error collecting registers: (<class ‘KeyError’>, KeyError(HR:013), <traceback object at 0x7f599fb1b600>)
    2022-12-17 12:38:12,923 - read - [CRITICAL] - First time running so saving AC Charge status
    2022-12-17 12:38:12,924 - read - [CRITICAL] - Publishing Home Assistant Discovery messages
    2022-12-17 12:40:16,062 - GivLUT - [CRITICAL] - Consecutive failure count= 1
    2022-12-17 12:40:16,062 - read - [ERROR] - Error collecting registers: (<class ‘KeyError’>, KeyError(HR:013), <traceback object at 0x7f599fb1f240>)

I have checked my MQTT and goggle the results and it looks like it is heathy

2022-12-27 12:03:48: New connection from 192.168.1.7:45413 on port 1883.
2022-12-27 12:03:48: New client connected from 192.168.1.7:45413 as GivEnergy_GivTCP_1 (p2, c1, k60, u’mqttuser’).
2022-12-27 12:03:48: Client GivEnergy_GivTCP_1 disconnected.

but I am not able to result why I have to repeat restart the addon for it to start to collect the information each day and popular my database and dashboard

144

I have slight twist to the topic. I’m trying to achieve automatic charging period based on target rates. I eventually figured out triggers and all works perfectly with Zappi, but the force charge option does not sink in to Givenergy system. Checked if I can change it manually from device level and also it doesn’t do anything.
I’m on HAOS and using Mosquito as a broker.
Did anyone else achieve charge control over HA in recent iteration of GivTCP?

145

I know this is a relatively old thread but I thought I might post this anyway for anyone having a similar problem with some of the sensors giving random zero values for whatever reason.

I tried a few different methods to clean up the data using the Filter platform but nothing quite gave me a clean result.

In the end I found a template sensor storing the last known good value in an attribute and substituting that when a zero value was received gave the cleanest result.

The example below is for the battery’s remaining capacity and I also created a more reliable (and slightly more accurate) battery percent sensor from that data - be sure to change the value of 9.5 to whatever kWh capacity your system has.

I have my Template sensors in an included templates.yaml file so if you have all your sensors defined in in configuration.yaml you need to put the code in your “template:” section.

Hope this helps someone :slightly_smiling_face:

- sensor:
    - name: Sanitised Battery Remaining Capacity
      state: >
        {% if (states('sensor.battery_remaining_capacity')|float) > 0.0  %}
        {{ states('sensor.battery_remaining_capacity') }}
        {% else %}
        {{ this.attributes.last_good_value }}
        {% endif %}
      device_class: "energy"
      icon: mdi:battery-high
      attributes:
        last_good_value: >
          {% if (states('sensor.battery_remaining_capacity')|float) > 0.0  %}
          {{states('sensor.battery_remaining_capacity')}}
          {% else %}
          {{ this.attributes.last_good_value }}
          {% endif %}
      unit_of_measurement: "kWh"

- sensor:
    - name: Battery Percent Calculated
      state: "{{ [([(((states ('sensor.sanitised_battery_remaining_capacity')|float) / 9.50 * 100.0)|round(1,'common')), 0.0]|max), 100.0]|min }}" # Rounded to 1 decimal place and clamped between 0 and 100
      unit_of_measurement: "%"
      device_class: "battery"
      icon: mdi:battery-50
146

Has anyone tried @britkat 's latest version (2.1.3) which was released 5 days ago? I have my V2 Hybrid invertor being commissioned on Friday (with two batteries) and would love to know if anyone is having issues (or successes) with it.

@britkat - do you have a “buy me a beer” link or equivalent? If I get this working, you need at least a little thankyou from me (and a big thank you from GivEnergy as I only went with this system knowing there was a local API).

147

I am using 2.1.3 (it was actually released a couple of weeks ago), it’s working fine for me.

I had to delete my MQTT entities, and have them recreated, but otherwise, all good.

148

Thanks @lxalln. Good to know. I did think it had been released a little while a go but the “official” release tag in github was only 5 days ago so thought I was mistaken.

1 Like
149

@britkat this is great but I’m difficulty with solcast.
Got all the api keys and tariff times entered but it always charges to 100%.

All the entities seem to be there.

Error messages from log are

1682758826: Error: Address in use
2023-04-29 10:01:26,360 - startup - [ERROR] - MQTT Broker process died. Restarting…
2023-04-29 10:01:26,360 - startup - [CRITICAL] - Starting Mosquitto on

Thanks

1 Like
150

I get this as well, think it’s because I have mqtt running for a ring doorbell as well but I can’t find any documentation about sorting it out??

151

@flyingorthopod and @philipmather
Apologies for the delay! I’m distracted these days with a small child. :sweat_smile:
With the help of @britkat a while back, he got me up an running on the latest. I wasn’t checking breaking changes and got a similar error to what you had above there.
So breaking change for me was the ability to have more than one inverter, so I needed to add: _1 to the end of inverter_ip in the environmental variables. And boom it worked. That may be the cause of your error @flyingorthopod ? Unles you’ve solved it already.
@philipmather and Mr Orthopod, the MQTT - err, not sure, but I doubt ring is the problem. It may be an authentication problem with MQTT? It may be the server address?

in case it helps, here’s my docker compose config, ymmv:

  givEnergyLocal:
    image: britkat/giv_tcp-ma:latest #2022.03.12 #britkat/giv_tcp-dev:dev #britkat/giv_tcp-ma:2022.03.12 #devtest #1.1.4 #:buildx-latest #britkat/giv_tcp-ma:1.1.3
    hostname: givEnergyLocal
    container_name: givEnergyLocal
    ports:
      - 6345:6345
      - 9181:9181
      - 8899:8899
    environment: 
      - TZ=Europe/London
      - LOG_LEVEL=Error #Debug
  #    - DEBUG_FILE_LOCATION=/config/logs/giv-debug.log
      - INVERTOR_IP_1= #your ip addresss here < --- this is the one that messed me up. There was a change to allow multiple inverters, so _1 was added :) 
      - NUMBATTERIES=1
      - SERIAL_NUMBER= #your serial number here
      - MQTT_ADDRESS=mosquitto #or change to the host name of your mqtt server instance
      - MQTT_USERNAME=postman
      - MQTT_PASSWORD=postman
      - MQTT_TOPIC=givenergy/local
      - MQTT_OUTPUT=True   
      - HA_URL=homeassistant
      - HA_TOKEN= #your token here
    volumes:
      - ./givenergy/log/:/usr/pi/logs/:rw
    depends_on:
      - mosquitto
152

Thanks! Mine started working this week
No idea why as I didn’t change anything, it just decided to start playing one day

1 Like
153

I had the system running through HomeAssistant MQTT but there was a recent upgrade to the GE inverter and now all of the values are showing as Unknown. Strange thing is the GivTCP status is showing as ‘online’. MQTT is working as I have another integration that is working, I am assuming that something in the internals with the inverter has changed. Is anyone else having problems?

154

I had this all running nicely until a week or so ago when it stopped working, assumed the IP of the inverter must have changed but it looks correct.

I’m currently getting this error:

2023-08-05 13:48:13,302 - Inv1 - read        -  [ERROR   ] - Consecutive failure count= 4 -- (<class 'Exception'>, Exception("Garbage or failed inverter Response: ERROR:-(<class 'KeyError'>, KeyError(HR:243), <traceback object at 0x7fb0f414c0>)"), <traceback object at 0x7f90004900>)
2023-08-05 13:48:28,473 - Inv1 - read        -  [ERROR   ] - Consecutive failure count= 5 -- (<class 'Exception'>, Exception("Garbage or failed inverter Response: ERROR:-(<class 'KeyError'>, KeyError(HR:243), <traceback object at 0x7fb0f45440>)"), <traceback object at 0x7f90005200>)

Anyone know what I need to do to fix?

Much appreciated.

155

You should be able to deduce what the IP address of your inverter is by connecting to your router and viewing ‘connected devices’, and determining whether the inverter’s current IP address differs from that set in HA.
The procedure for this depends very much on the router you have.
Inverter IP Address is a parameter in the GivTCP AddOn configuration settings which you can change should there be a misalignment.
There is a method of giving the inverter a fixed IP address, though I’ve not found that necessary and I’m not familiar with the process.
Hope this helps

156

This happened to me using 2.3.0 of GivTCP. I had to rollback to 2.2.4

157

I’m still using 2.1.13, I’ve not seen any benefit in updating.

158

In the latest givtcp, there is a setting to toggle on old firmware for your inverter I had to do that to stop those messages

159

Thanks guys, I will try this toggle, or rolling back :+1:t2::+1:t2:

160

I think it’s on by default in the latest one now

1 Like
161

I would like that I just updated my givtcp addon from 2.1.11 to 2.3.3 and I discovered that to duplicated all my sensors and started a new set, which is not ideal. so I have return back to my old version.

I also discovered that when I look in my log file I see the following

2023-08-17 09:42:49,045 - read - [ERROR] - Consecutive failure count= 3 – (<class ‘Exception’>, Exception(“Garbage or failed Invertor Response: ERROR:-(<class ‘KeyError’>, KeyError(IR:000), <traceback object at 0x7f96bc73c780>)”), <traceback object at 0x7f97e41f68c0>)
2023-08-17 10:57:06,371 - sync - [ERROR] - Connection to (INVIDER IP, 8899) failed: timed out
2023-08-17 11:01:30,238 - sync - [ERROR] - Connection to (INVIDER IP, 8899) failed: timed out

is this a known issue. ?

the good news is that with the old version, my sensors are back up and running, and I am collecting data.

162

All working again now, turns out there was also a firmware update I hadn’t noticed for the inverter.

1 Like