Can't Get GivTCP to work

I have HomeAssistant running on a Raspberry Pi 5. Dashboards setup, all sorts of other stuff working fine.

I've installed Mosquitto MQTT broker and GivTCP as per Speak to the Geek video/instructions.
Both Add-ons configured and started.
Only seeing a single GivTCP entry in devices.
GivTCP Log shows the following:

2024-01-14 21:47:49,572 - startup - [CRITICAL] - HA MQTT Service has been found at core-mosquitto
2024-01-14 21:47:49,577 - startup - [INFO] - Supervisor Timezone: Europe/London
2024-01-14 21:47:51,585 - startup - [CRITICAL] - Scanning network for GivEnergy Devices...
2024-01-14 21:47:55,406 - startup - [CRITICAL] - Inverter CH2315G354 which is a Gen 1 - All in One has been found at: 192.168.10.154
2024-01-14 21:47:55,606 - startup - [CRITICAL] - Inverter GW2315G128 which is a Gen 1 - Gateway has been found at: 192.168.10.155
2024-01-14 21:47:55,607 - startup - [INFO] - Searching for Inverters again
2024-01-14 21:47:55,612 - startup - [CRITICAL] - Running Redis
2024-01-14 21:47:55,618 - startup - [CRITICAL] - Setting up invertor: 1 of 1
2024/01/14 21:47:55 [notice] 69#69: using the "epoll" event method
2024/01/14 21:47:55 [notice] 69#69: nginx/1.20.2
2024/01/14 21:47:55 [notice] 69#69: OS: Linux 6.1.63-haos-raspi
2024/01/14 21:47:55 [notice] 69#69: getrlimit(RLIMIT_NOFILE): 1073741816:1073741816
2024/01/14 21:47:55 [notice] 69#69: start worker processes
2024/01/14 21:47:55 [notice] 69#69: start worker process 74
2024/01/14 21:47:55 [notice] 69#69: start worker process 75
2024/01/14 21:47:55 [notice] 69#69: start worker process 76
2024/01/14 21:47:55 [notice] 69#69: start worker process 77
2024-01-14 21:47:55,646 - startup - [CRITICAL] - Running RQ worker to queue and process givernergy-modbus calls
2024-01-14 21:47:55,646 - startup - [CRITICAL] - Running Invertor (192.168.10.154) read loop every 15s
2024-01-14 21:47:55,650 - startup - [CRITICAL] - Subscribing MQTT Broker for control
2024-01-14 21:47:55,656 - startup - [CRITICAL] - Starting Gunicorn on port 6345
[2024-01-14 21:47:55 +0000] [81] [INFO] Starting gunicorn 21.2.0
[2024-01-14 21:47:55 +0000] [81] [INFO] Listening at: http://0.0.0.0:6345 (81)
[2024-01-14 21:47:55 +0000] [81] [INFO] Using worker: sync
[2024-01-14 21:47:55 +0000] [82] [INFO] Booting worker with pid: 82
[2024-01-14 21:47:55 +0000] [85] [INFO] Booting worker with pid: 85
[2024-01-14 21:47:56 +0000] [86] [INFO] Booting worker with pid: 86
2024-01-14 21:47:56,419 - Inv1 - mqtt_client - [CRITICAL] - Connecting to MQTT broker for control- core-mosquitto
2024-01-14 21:49:36,528 - Inv1 - mqtt_client - [ERROR ] - No serial_number found in MQTT queue. MQTT Control not available.
Traceback (most recent call last):
File "/app/GivTCP_1/mqtt_client.py", line 402, in <module>
client.loop_forever()
File "/usr/local/lib/python3.10/site-packages/paho/mqtt/client.py", line 1756, in loop_forever
rc = self._loop(timeout)
File "/usr/local/lib/python3.10/site-packages/paho/mqtt/client.py", line 1164, in loop
rc = self.loop_read()
File "/usr/local/lib/python3.10/site-packages/paho/mqtt/client.py", line 1556, in loop_read
rc = self.packet_read()
File "/usr/local/lib/python3.10/site-packages/paho/mqtt/client.py", line 2439, in packet_read
rc = self.packet_handle()
File "/usr/local/lib/python3.10/site-packages/paho/mqtt/client.py", line 3039, in packet_handle
return self.handle_connack()
File "/usr/local/lib/python3.10/site-packages/paho/mqtt/client.py", line 3138, in _handle_connack
on_connect(
File "/app/GivTCP_1/mqtt_client.py", line 386, in on_connect
client.subscribe(MQTT_Topic+"/control/"+GiV_Settings.serial_number+"/#")
AttributeError: type object 'GiV_Settings' has no attribute 'serial_number'

It is finding the AIO ( & GW for that matter) at the correct IP address, just can't figure out why its not working.

treborUK
It's a bit of a black art. Have a look at https://github.com/britkat1980/giv_tcp/issues to see various people's solutions (including mine)

Make sure you have these settings

Is it an AIO = yes
Is it on old firmware = no
Number of batteries on inverter 1 = zero

(Yes, weirdly, zero batteries).

Changed batteries to 0 and it wasn't showing any errors but still no devices detected after 20 mins.
Rolled back to HA backup from yesterday before I'd installed MQTT & GivTCP.
Installed MQTT and it wouldn't start. Uninstalled, rebooted and reinstalled, still wouldn't start.
Rolled back to yesterday's backup again, then rebooted, then installed MQTT & GivTCP and all seems to be working now!

Thanks @TX200 & @PianSom
I think the root cause was the batteries being left to the default 1. No idea why changing just that didn't work or what went on with MQTT not starting and having to reboot after a backup restore. I'm only on Day 3 with both Raspberry Pi5 and HomeAssistant so learning curve still pretty steep ! This is the first day I've not ended up re-imaging with the base HAOS and starting from scratch so I guess I'm going to say I'm making progress 😃

Hi there, I’m really struggling so want to see if others can offer some advice.
I've recently got a second inverter installed - I have a Gen 1 (previous one) and a Gen 2 - commissioned about a week ago.
With the first inverter I had no issues with GivTCP, now that I have the second one, I cannot get GivTCP to recognise both inverters together.
I've removed MQTT and GivTCP several times as well as removing the previously created folders etc but GivTCP will still only recognise one of the inverters.
GivTCP Current version: 2.4.3
Running HA on a local device, not in a docker container.
Any suggestions would be appreciated.

NiallKilleen have you tried setting the new firmware switch to on?

What error do you get in the logs?

https://community.givenergy.cloud/d/3624-givtcp-old-firmware

TX200
Thanks for this, it got me working.
Number of batteries = 0, who would have guessed, I tried just about everything before I found your post.

Thanks for the responses, my issue appears to be fundamental - I’ve fallen at the Wi-Fi hurdle. I need to get that sorted first and then get the connection with GivTCP sorted. Have asked a separate question about those Gen 1 dongles and if they could fail - as i've gone though a bunch of suggested fixes without any luck