Goodwe integration: after HA update to 2025.11 some sensors only update every 20 seconds instead of 10

Configuration
1

I have updated HA to 2025.11 a few days ago (I’m not sure what the previous version was; I think I last updated some time in spring). Since then I have a weird problem with the Goodwe Inverter integration.
The default update rate for the sensors is 10 seconds, which works for some of the sensors like one called “sensor.active_power_total” for example.
But others like “sensor.active_power” or “sensor.back_up_l1_power” only get a new value every 20 seconds. The latter sensor is especially important to me, because I cross check it with other sensors from an esphome device that reports every 10 seconds. This desync in interval breaks one of my scripts.

Does anyone know where that doubling of the interval is coming from?

To add, although I doubt that it is related: I replaced the inverter’s WiFi dongle pretty much at the same time. It was a “WI-FI KIT” before and is a “WI-FI/LAN KIT 2.0” now. Is there a configuration option of the Goodwe integration that is dependent on the connection hardware?

2

The weirdness continues (TLDR: it changed back to how it was before without me actively changing any config setting except for disabling and enabling the integration’s automatic polling).

Previously (meaning just a few hours ago) the integration used TCP (port 502) to talk to the inverter. I saw with netstat three connections were opened every 10 seconds. I took a deep into the Goodwe integration source and the Goodwe Python library. The three connections should correspond to three queries for batches of modbus registers (the batches being “__all_sensors”, “__all_sensors_meter” and “__all_sensors_mppt” in the Goodwe Python library’s et.py file). All fine with that. The responses (it’s the contents of all modbus registers in one long string) were coming in every 10 seconds as expected. With the integration’s debug logging enabled the reponses to these requests are logged (in hex). When I checked the responses at the position of the “Back-up L1 Power” register (one of those that didn’t get updated), I saw that the value did indeed change only every second time (i. e. every 20 seconds). But the data were definitely new, because the register with the timestamp value changed every time (i. e. every 10 seconds). So the inverter wasn’t sending any new data apparently.

After I found that out, I switched off the automatic polling of the integration and created an automation, where I could set the update interval, like this:

alias: Goodwe read data trigger
description: ""
triggers:
  - trigger: time_pattern
    seconds: /10
conditions: []
actions:
  - action: homeassistant.update_entity
    metadata: {}
    data:
      entity_id:
        - sensor.active_power_total
mode: single

I wanted to find out, if the value only updating every second time is based on time or number of updates. First thing I found is that a trigger smaller than 10 seconds doesn’t even work. The automation triggers of course, but the integration will not query any faster than every 10 seconds.

And here the weird thing happened: somehow the integration switched over to using UDP (port 8899) to talk to the inverter (which I only found out, because the UDP data are apparently different from the TCP data and I couldn’d find the register in the debug log string anymore)! Shorter than 10 second intervals didn’t work as I said, but the register values were now updating every time even on a 10 second interval. I experimented a little just to check how things work, but eventually I switched off my custom automation and reenabled the automatic polling of the integration. And it is still using UDP now!

Someone please? How? Why? There isn’t even any option to set for the integration that selects the integration’s network protocol. Why did it change on its own? (ignoring the fact for now that the inverter doesn’t seem to send the same things back depending on the protocol you use, which isn’t HA’s fault).

3

Just found out that i have the same 20 second update intervall on some of the sensors. Did you find the solution for this issue?

4

I've had a similar issue, but I'm not using HA. I'm polling my ET inverter once a second and found some values change every update and some every 20s (data returned, it's just static for 20s). While setting up and changing the size of the requested block of registers, some values that were previously 20s started updating properly. I finally had some time to experiment and it turns out if a particular register is included in a requested block then all registers in the block update properly. The few registers I've found are total_inverter_power, battery1_power_1, battery2_power_2, meter_total_active_power. These are in sections of typically useful values and so I've been able to get most of the data I want at 1Hz without having too much unwanted data. Hope that helps.

5

Since the problem didn’t reappear (the integration continued using UDP where the 10 seconds updates work) I never tried further to fix it. But I am pretty sure the setting is HA’s /config/.storage/core.config_entries file. There is a line for the GoodWe inverter in there. The data property in that line looks like this for me:
"data":{"host":"192.168.179.2","model_family":"ET","port":8899}
8899 is the GoodWe protocol’s UDP port. If the GoodWe python library sees that port, it will use UDP for the protocol, otherwise TCP. I still have no idea why the integration switched to TCP after the update at the time in the first place, as UDP is the default anyway from what I can gather from the Python code.
So check that file. It should say "port":8899 or no port at all. Any other value for port would mean TCP (which is weird, because port 502 is the only one working for TCP). I’m not going to try out what happens :wink:. Be careful when editing that file. You can break HA, if you mess up its structure. Also HA has to be stopped while editing (ha core stop on the command line), because the changes only take effect after a restart, but HA also rewrites the file on shutdown.

Oh, that’s a nice find! That could also explain why there’s a difference between UDP and TCP, if the integration’s UDP commands query different registers to TCP (I have not checked if that’s the case). Does one of the registers you mentioned have to be in the requested block to get updated data, or does reading one of the registers update the data so that a following request that doesn’t include one of these registers still gets updated data?