Overview

Rather off-topic, but I’ve been doing a dive into the TCP networking of the GivEnergy inverter which is the heart of our recent solar panel installation. The inverter connects to the solar panels and battery, converting DC to AC, and routing the power to/from the the battery as required. There’s a very handy app for your mobile, a web-based dashboard for monitoring and control, and it also integrates nicely into Home Assistant systems.

However, it’s not perfect. I get frequent “Inverter Timeout” errors when trying to update settings from the web portal, and I’ve also seen blatantly ‘wrong’ data arrive in both Home Assistant and the portal. Given that this is all over TCP/IP which is reliable and mature, I was curious about what’s happening. Time for a deep dive..,

Hardware

The inverter is a Gen 2 model – which means it has built-in ethernet and Wi-Fi, rather than needing a separate USB to Wi-Fi dongle like the Gen 1 model. The inverter and battery are in the garage, and I’m running this via ethernet powerline adapters back to a Unifi switch in the house.

The first step is to find the IP address of the inverter. The mobile app has a handy option to do this, so lets start there.

Let’s also take a look in the router’s DHCP settings to find what address was allocated, and the MAC address.

Let’s find the vendor for that mac address, using a lookup tool like https://macvendors.com/

Connect via Browser

OK, let’s try connecting to the inverter IP address with a browser. We’re presented with a HTTP Basic Auth login prompt – luckily the username and password are well documented in GivEnergy Wifi dongle setup guides, as admin/admin.

And, we’re in!

The obvious things to note are that this doesn’t look remotely like an inverter control page. There’s no GivEnergy branding. What, exactly are we talking to? The clue is in the MAC Address, and the hostname “HF-A21” we saw earlier. Googling the vendor and hostname, you’ll end up here which allows you to download the manual for this device.

I’d recommend NOT changing any parameters via the Web UI unless essential. There are hidden settings that can’t be changed from the Web UI and you’ll be in a world of pain getting it running properly again.

An HF-A21 is a UART to Wi-Fi/Ethernet module: It claims to converts a serial port (UART) to a TCP connection, but such devices are far from ideal.

Looking at the HF-21 manual and web interface, there are two main modes of operation which they call AP and STA. In “STA” mode, the module acts as a TCP client, and establishes a connection to an external TCP server. The server IP address doesn’t appear to be configured in the Web UI.

In AP mode, the module acts as a TCP server itself, allowing clients to connect to it. This is configured as listening on port 8899. Importantly, there’s also an AP + STA mode – although this can only be configured via the module’s serial port.

How does this work for the Inverter?

The inverter’s controller is connected to the serial side of the HF-A21 module. The inverter must place the module into the AP+STA mode, and sets the remote server address to an Amazon AWS address running the backend of the GivEnergy portal. Update: the HF-A21 actually uses DNS to find an IP address for comms.givenergy.cloud. I can’t see any mention of how this is possible from the HF-A21 manual, so my best guess is that the HF-A21 has been customized to perform this function.

All commands and data are sent using a variant of MODBUS protocol over TCP , which defines the layout and meaning of each command.

When the module starts, it opens a TCP connection to the Amazon server, and every five minutes the Inverter sends out a block of data to the AWS servers to update the web portal. Similarly, any changes to settings made in the portal are sent via AWS to the inverter. On it’s own, this will all work fine.

AP Mode

So, if the connection to the portal uses STA mode, how does the “local connection” option in the mobile app work? This is where AP mode (server mode) comes in. The HF-A21 acts as a TCP server, accepting connections on port 8899 and forwarding TCP data to/from the inverter UART.

But, we’ve now got multiple TCP connections to the HF-A21: What happens if both the AWS server and the mobile app send a message at exactly the same time? Luckily this doesn’t present too much of a problem. Although TCP is stream-based rather than packet-based, careful programming will ensure that MODBUS commands are sent as single TCP packets, so no interleaving of data on the UART occurs.

The real problem is when the inverter/UART side of the module receives data, and needs to send it over TCP. It can’t know which TCP connection to send it to, so instead, it sends the data to all current TCP connections.

For example, if you have the mobile app running in ‘Home’ mode, every ten seconds the app will ask the inverter for data. The inverter must send this data to both the app, and to the AWS server! You can see this clearly with a packet monitoring tool like Wireshark. Add Home Assistant into the mix, and every message from the Inverter must now go to three locations, regardless of who requested it.

I suspect that the “Inverter Timeout” messages are due to the portal software sending a command and expecting a reply – but instead, getting a reply that’s really intended for another client. Of course, it should be possible to ignore these, but maybe this isn’t happening.

More to follow…