GivEnergy - Battery/Inverter + home power things

ok. I found the ip by logging into the dongle and that showed me the MAC. I then reconfigured the docker-compose and re-ran but it constantly fails to start cleanly. I am in no doubt I’m doing somthing(s) wrong but am stumped atm.

My environment is an intel core-i3 running Debian Bullseye and I’m using compose with this file
(host mode is off because I have the IP and it would not start MQTT in that mode):

version: “3.5”
services:
givtcp:
image: britkat/giv_tcp-ma
container_name: givtcp
ports:
- “6345:6345/tcp”
environment:
- INVERTOR_IP=192.168.100.159
- NUMBATTERIES=1
restart: “no”

Attempting to bring it up gives me:
Starting givtcp … done
Attaching to givtcp
givtcp | /app/settings.py exists.
givtcp | Starting Mosquitto on port 1883
givtcp | Running Invertor read loop every 20s…
givtcp | Starting Gunicorn on port 6345
givtcp | 1645439329: mosquitto version 2.0.11 starting
givtcp | 1645439329: Using default config.
givtcp | 1645439329: Starting in local only mode. Connections will only be possible from clients running on this machine.
givtcp | 1645439329: Create a configuration file which defines a listener to allow remote access.
givtcp | 1645439329: For more details see Authentication methods | Eclipse Mosquitto
givtcp | 1645439329: Opening ipv4 listen socket on port 1883.
givtcp | 1645439329: Opening ipv6 listen socket on port 1883.
givtcp | 1645439329: Error: Address not available
givtcp | 1645439329: mosquitto version 2.0.11 running
givtcp | Traceback (most recent call last):
givtcp | File “/app/sched.py”, line 6, in
givtcp | from read import runAll
givtcp | File “/app/read.py”, line 8, in
givtcp | from HA_Discovery import HAMQTT
givtcp | ModuleNotFoundError: No module named ‘HA_Discovery’
givtcp | [2022-02-21 10:28:49 +0000] [9] [INFO] Starting gunicorn 20.1.0
givtcp | [2022-02-21 10:28:49 +0000] [9] [INFO] Listening at: http://0.0.0.0:6345 (9)
givtcp | [2022-02-21 10:28:49 +0000] [9] [INFO] Using worker: sync
givtcp | [2022-02-21 10:28:49 +0000] [10] [INFO] Booting worker with pid: 10
givtcp | [2022-02-21 10:28:49 +0000] [11] [INFO] Booting worker with pid: 11
givtcp | [2022-02-21 10:28:49 +0000] [10] [ERROR] Exception in worker process
givtcp | Traceback (most recent call last):
givtcp | File “/usr/local/lib/python3.10/site-packages/gunicorn/arbiter.py”, line 589, in spawn_worker
givtcp | worker.init_process()
givtcp | File “/usr/local/lib/python3.10/site-packages/gunicorn/workers/base.py”, line 134, in init_process
givtcp | self.load_wsgi()
givtcp | File “/usr/local/lib/python3.10/site-packages/gunicorn/workers/base.py”, line 146, in load_wsgi
givtcp | self.wsgi = self.app.wsgi()
givtcp | File “/usr/local/lib/python3.10/site-packages/gunicorn/app/base.py”, line 67, in wsgi
givtcp | self.callable = self.load()
givtcp | File “/usr/local/lib/python3.10/site-packages/gunicorn/app/wsgiapp.py”, line 58, in load
givtcp | return self.load_wsgiapp()
givtcp | File “/usr/local/lib/python3.10/site-packages/gunicorn/app/wsgiapp.py”, line 48, in load_wsgiapp
givtcp | return util.import_app(self.app_uri)
givtcp | File “/usr/local/lib/python3.10/site-packages/gunicorn/util.py”, line 359, in import_app
givtcp | mod = importlib.import_module(module)
givtcp | File “/usr/local/lib/python3.10/importlib/init.py”, line 126, in import_module
givtcp | return _bootstrap._gcd_import(name[level:], package, level)
givtcp | File “”, line 1050, in _gcd_import
givtcp | File “”, line 1027, in _find_and_load
givtcp | File “”, line 1006, in _find_and_load_unlocked
givtcp | File “”, line 688, in _load_unlocked
givtcp | File “”, line 883, in exec_module
givtcp | File “”, line 241, in _call_with_frames_removed
givtcp | File “/app/REST.py”, line 5, in
givtcp | import read as rd #grab passthrough functions from main read file
givtcp | File “/app/read.py”, line 8, in
givtcp | from HA_Discovery import HAMQTT
givtcp | ModuleNotFoundError: No module named ‘HA_Discovery’
givtcp | [2022-02-21 10:28:49 +0000] [10] [INFO] Worker exiting (pid: 10)
givtcp | [2022-02-21 10:28:49 +0000] [12] [INFO] Booting worker with pid: 12
givtcp | [2022-02-21 10:28:49 +0000] [11] [ERROR] Exception in worker process
givtcp | Traceback (most recent call last):
givtcp | File “/usr/local/lib/python3.10/site-packages/gunicorn/arbiter.py”, line 589, in spawn_worker

It says it can’t open 1833 for listening (nothing else is using that port and I am running as root) but then also says mosquito is running…

Appreciate it if you have any suggestions?

Thanks

Mike

Mike, my bad, I uploaded a duff docker image. I’ve reuploaded and its available on dockerhub now.
If you aren’t going to use MQTT then you can set MQTT_OUTPUT=“False” and it wont try to set up Mosqitto.

Thanks Mark,

I appreciate all the hard work you and others have put in to getting this to where it is and if there’s anything I can do to help, just say (for what it’s worth, I am a software developer of ~15 years, albeit with very little Python experience, so I’m fairly technical).

I’ve updated the givenergy-modbus library and applied the change to read.py in your codebase to handle the change to the enum. This has worked and I’m getting data through as expected. I am still intermittently getting ‘unavailable’ values in the HA sensors, with this error or similar errors logged (using debug logging) – the ‘IR:000’ value appears to be different each time:

{"result": "Error collecting registers: (<class 'KeyError'>, KeyError(IR:000), <traceback object at 0x8034cdb40>)"}

I also changed the state_class on the kWh-related sensors from ‘measurement’ to ‘total_increasing’ so that they work properly in the Energy Dashboard (I hope, still nothing showing yet but it has removed the error HA was giving me when I added them previously).

Thanks again!

Intermittant “unavailable” is an unsolved challenge. The low-level Modbus RTU over TCP appears mildly flaky and occasional clashes in calls to the invertor return garbage, something to live with I’m afraid.

Is there anything in the yaml we can do to stop updates unless the rest command returns valid data? I do this in my NR flow, to prevent data drops in HA

1 Like

Hi Mark. Major progress as the container now starts and remains up. There does seem to be an issue though because there is an error in the log which is repeated (with no other output) when calling /runAll in the browser

== Docker Log ==
Attaching to givtcp
givtcp | /app/settings.py does not exist
givtcp | Starting Mosquitto on port 1883
givtcp | Running Invertor read loop every 20s…
givtcp | Starting Gunicorn on port 6345
givtcp | 1645459086: mosquitto version 2.0.11 starting
givtcp | 1645459086: Using default config.
givtcp | 1645459086: Starting in local only mode. Connections will only be possible from clients running on this machine.
givtcp | 1645459086: Create a configuration file which defines a listener to allow remote access.
givtcp | 1645459086: For more details see REDACTED
givtcp | 1645459086: Opening ipv4 listen socket on port 1883.
givtcp | 1645459086: Opening ipv6 listen socket on port 1883.
givtcp | 1645459086: Error: Address not available
givtcp | 1645459086: mosquitto version 2.0.11 running
givtcp | [2022-02-21 15:58:06 +0000] [9] [INFO] Starting gunicorn 20.1.0
givtcp | [2022-02-21 15:58:06 +0000] [9] [INFO] Listening at: 0.0.0.0:6345 (9)
givtcp | [2022-02-21 15:58:06 +0000] [9] [INFO] Using worker: sync
givtcp | [2022-02-21 15:58:06 +0000] [10] [INFO] Booting worker with pid: 10
givtcp | [2022-02-21 15:58:06 +0000] [11] [INFO] Booting worker with pid: 11
givtcp | [2022-02-21 15:58:06 +0000] [12] [INFO] Booting worker with pid: 12
givtcp | ERROR:GivTCP:Error processing registers: (<class ‘AttributeError’>, AttributeError("‘Battery’ object has no attribute ‘e_battery_charge_total_2’"), <traceback object at 0x7f4f5a2cb140>)

== Browser Output ==
http://192.168.100.49:6345/runAll
{“result”: “Error processing registers: (, AttributeError(”‘Battery’ object has no attribute ‘e_battery_charge_total_2’"), )"}

== Compose ==
version: “3.5”
services:
givtcp:
image: britkat/giv_tcp-ma
container_name: givtcp
ports:
- “6345:6345/tcp”
environment:
- INVERTOR_IP=192.168.100.159
- NUMBATTERIES=1
- MQTT_OUTPUT=False
restart: “no”

Regards ignoring the unavailable state, I found a post with a possible workaround – I’ll try this and report back.

Another possibility, if the inverter’s response cannot be counted on, would be to enable one or more retries, at least in the case of the /runAll endpoint, although if the inverter normally takes a while to start behaving then this will likely result in the same.

Have GivEnergy given any feedback as to why it intermittently responds with garbage?

That’s odd, that’s an old error from a previous version. Can you pull the docker image tag dated today? And see if it’s still occurring. The 0.9.4 release of GivEnergy-modbus is the one to use

Took me a couple of goes to get it right, though if I’d have just read the documentation I would probably have managed it first time out the gate… e.g.

      - name: "GivTCP Battery SOC"
        unit_of_measurement: "%"
        device_class: battery
        state_class: measurement
        state: >
          {% if state_attr('sensor.givtcp','Power') is not none %}
            {{ state_attr('sensor.givtcp','Power')['Power']['SOC'] }}
          {% else %}
            {{ states('sensor.givtcp_battery_soc') }}
          {% endif %}

That will use the existing value if the REST call returned no data

1 Like

I pulled 2022.02.21 and it certainly changed. Unsure how to know what modbus it’s using?

== Log ==
Starting givtcp … done
Attaching to givtcp
givtcp | /app/settings.py exists.
givtcp | Starting Mosquitto on port 1883
givtcp | Running Invertor read loop every 20s…
givtcp | Starting Gunicorn on port 6345
givtcp | 1645466734: mosquitto version 2.0.11 starting
givtcp | 1645466734: Using default config.
givtcp | 1645466734: Starting in local only mode. Connections will only be possible from clients running on this machine.
givtcp | 1645466734: Create a configuration file which defines a listener to allow remote access.
givtcp | 1645466734: For more details see
givtcp | 1645466734: Opening ipv4 listen socket on port 1883.
givtcp | 1645466734: Opening ipv6 listen socket on port 1883.
givtcp | 1645466734: Error: Address not available
givtcp | 1645466734: mosquitto version 2.0.11 running
givtcp | [2022-02-21 18:05:34 +0000] [9] [INFO] Starting gunicorn 20.1.0
givtcp | [2022-02-21 18:05:34 +0000] [9] [INFO] Listening at:
givtcp | [2022-02-21 18:05:34 +0000] [9] [INFO] Using worker: sync
givtcp | [2022-02-21 18:05:34 +0000] [10] [INFO] Booting worker with pid: 10
givtcp | [2022-02-21 18:05:34 +0000] [11] [INFO] Booting worker with pid: 11
givtcp | [2022-02-21 18:05:34 +0000] [12] [INFO] Booting worker with pid: 12
givtcp | ERROR:givenergy_modbus:Did not receive expected response type: ReadInputRegistersResponse != ReadHoldingRegistersResponse
givtcp | ERROR:givenergy_modbus:Did not receive expected response type: ReadHoldingRegistersResponse != ReadInputRegistersResponse
givtcp | ERROR:GivTCP:Error collecting registers: (<class ‘KeyError’>, KeyError(IR:183), <traceback object at 0x7f8a3420b2c0>)
givtcp | ERROR:givenergy_modbus:Returned base register (60) does not match that from request (120).
givtcp | ERROR:givenergy_modbus:Did not receive expected response type: ReadInputRegistersResponse != ReadHoldingRegistersResponse
givtcp | ERROR:givenergy_modbus:Returned base register (0) does not match that from request (180).
givtcp | ERROR:GivTCP:Error collecting registers: (<class ‘KeyError’>, KeyError(HR:113), <traceback object at 0x7f06080b78c0>)
givtcp | ERROR:GivTCP:Error processing registers: (<class ‘AttributeError’>, AttributeError("‘Battery’ object has no attribute ‘e_battery_charge_total_2’"), <traceback object at 0x7f8a35b20040>)

== browser ==
{“result”: “Error collecting registers: (, KeyError(HR:013), )”}

== OR ==
{“result”: “Error processing registers: (, AttributeError(”‘Battery’ object has no attribute ‘e_battery_charge_total_2’"), )"}

Noticed there is a tag for tomorrow (2022.02.22) but that went up yesterday so I have ignored it

if you terminal into the docker and run pip list, does it show ‘givenergy-modbus 0.9.4’?

It does indeed - full list below

bash-5.1# pip list
Package Version


certifi 2021.10.8
charset-normalizer 2.0.12
click 8.0.1
crccheck 1.1
Flask 2.0.3
givenergy-modbus 0.9.4
gunicorn 20.1.0
idna 3.3
influxdb-client 1.26.0
itsdangerous 2.1.0
Jinja2 3.0.3
loguru 0.6.0
Markdown 3.3.4
MarkupSafe 2.1.0
mkdocs-material-extensions 1.0.3
paho-mqtt 1.6.1
pip 21.2.4
pydantic 1.9.0
pymodbus 2.5.3
pyserial 3.5
python-dateutil 2.8.2
pytkdocs 0.16.0
pytz 2021.3
requests 2.27.1
Rx 3.2.0
scapy 2.4.5
schedule 1.1.0
setuptools 57.5.0
six 1.16.0
typing_extensions 4.1.1
urllib3 1.26.8
Werkzeug 2.0.3
wheel 0.37.0
WARNING: You are using pip version 21.2.4; however, version 22.0.3 is available.
You should consider upgrading via the ‘/usr/local/bin/python -m pip install --upgrade pip’ command.
bash-5.1#

could it be my firmware revision on the GE dongle, battery or inverter? It’s only just installed for a couple of weeks so assume it’s current

Inverter Firmware Version: D0.450-A0.450

Last Update Time

Battery Firmware Version: 3005

Just for “fun” I spun the exact same compose file up on my Rpi4 and behaviour was identical unfortunately.

Sorry - have to reply here because I hit a limit…

No problem at all - I saw new dev and test versions earlier today but figured best to let you let me know when it was ready to try again. I’m over the moon to report that after a key error message, an F5 in the browser brought back all the values (I think).

This is what I get in the browser when it fails:
{“result”: “Error collecting registers: (, KeyError(HR:120), )”}

This is an example from the log:

[2022-02-25 18:41:56 +0000] [12] [INFO] Booting worker with pid: 12
ERROR:givenergy_modbus:Did not receive expected response type: ReadHoldingRegistersResponse != ReadInputRegistersResponse
ERROR:GivTCP:Error collecting registers: (<class ‘KeyError’>, KeyError(IR:183), <traceback object at 0x7f99b39e5900>)
ERROR:givenergy_modbus:Returned base register (60) does not match that from request (120).

Seems to happen occasionally but it’s looking very good now, thank you so much!

Tomorrow with a clear head I will try and get it into HA so I can start to make real use of it.

Have a great weekend.

Mike

Sorry for delay, didn’t get notification of reply. I have a new “test” version on dockerhub which should fix this. Can you try it for me and then I can push to “latest” if it resolves the issue

1 Like

For us mere mortals (and newbs to HA), what is the setup for us that don’t have docker?

James, there isn’t currently a simpler way than running the docker container… There is a custom_component in the works by others but it’s not yet available.

I’m working on the next version of the GivTCP which works with MQTT to integrate nicely with HA. But this will still need a docker container running somewhere on your network.

Test image isn’t working for me either, I get the same error. The 22 Dec version works OK.

I also can’t control my givenergy inverter - I’ve tried using a rest command and switch via HA, as below, but neither works. Trying to POST either of these commands in the terminal gives me a “method not allowed” error. Grateful for help!

rest_command:
pause_battery_discharge:
url: “http://192.168.0.12:49160/pauseDischargeSchedule
method: POST
resume_battery_discharge:
url: “http://192.168.0.12:49160/resumeDischargeSchedule
method: POST
pause_battery_charge:
url: “http://192.168.0.12:49160/pauseChargeSchedule
method: POST
resume_battery_charge:
url: “http://192.168.0.12:49160/resumeChargeSchedule
method: POST

#switch:

- platform: command_line

switches:

disable_battery_discharge:

command_on: “curl POST ‘http://192.168.0.12:49160/pauseDischargeSchedule’”

command_off: “'curl POST ‘http://192.168.0.12:49160/resumeDischargeSchedule’”

disable_battery_charge:

command_on: “'curl POST ‘http://192.168.0.12:49160/pauseChargeSchedule’”

command_off: “‘curl POST http://192.168.0.12:49160/resumeChargeSchedule’”

All,
Perhaps you might want to try out the dev version, which utilises HA MQTT auto discovery for read and control. It will create devices and entities and (in theory) should work much more seamlessly.
Docker Hub (using “dev” tag)

ooh brilliant! I’ll give it a bash. thanks

It’s work in progress so feedback welcomed