I have installed v1.14.0 and, unfortunately, I am still getting the message ‘Modbus Error FC 0x3 timeout’.
In addition, I carried out the following actions and tried again:
It’s still not working.
I have implemented a new setting to allow you to configure the Modbus Unit ID (Slave ID) for the inverter.
By default, GoodWe inverters use ID 247 (0xF7), but some configurations (especially those using a LAN module instead of Wi-Fi) use ID 1.
How to fix it:
That’s great. However, nothing can be done based on such information.
I am sorry if you provide it already, but what is your device, what driver you are using and what exactly did you do to test if it is working (like modbus test, etc.)?
No problem Michal,
I have a gw10K-et-20 with a Wi-Fi / LAN 2.0 dongle and three battery racks, all running the latest firmware. The dongle is connected via the LAN port. The cloud connection works perfectly.
I have enabled Modbus TCP in the Solar-Go app, but I cannot configure any further settings there;
I have checked via the terminal whether port 502 is open
I hope you can help me; if you need any further information, please let me know
Thank you for the very detailed information and the connection test. It helps to identify the issue.
The problem is a protocol mismatch:
• The Inverter: Your Test-NetConnection confirms that port 502 is open and listening for TCP connections.
• The Homey App: This app currently uses UDP (specifically designed for the default GoodWe port 8899).
Even if the IP and port are correct in the settings, a UDP request sent to a TCP port will always result in a Timeout because the inverter is “listening” for a different type of handshake. This is why it works for others; most Wi-Fi dongles use port 8899 which operates over UDP.
What you can try now:
Check Port 8899: In your Homey device settings, change the port from 502 to 8899.
◦ Many GoodWe dongles support both protocols simultaneously. If your dongle still has the UDP service active, it should start working immediately.
Verify Unit ID: If you use port 8899, keep the Modbus Unit ID at 247 (or 1 if that fails).
Please let me know if switching to port 8899 in the Homey settings solves it for you!
Hi Michal,
Unfortunately, it still isn’t working, and I get the same timeout message on port 1 and port 247
I’ve also checked whether port 8899 is open and I get the following message:
Is there anywhere I can check whether the UDP service on my dongle is still active? To be sure, I disconnected the WiFi/Lan 2.0 dongle from the power supply for 10 seconds.
Just to be clear, I’m using the Modbus ET, not the EX-30 version in your app.
Do you have any other suggestions?
Hi, I think I may have found the reason why your solution doesn’t work with my setup.
My WiFi/LAN Kit 2.0 is communicating via Modbus TCP on port 502, while your app uses the UDP protocol on port 8899. I tested a GoodWe UDP/8899 request directly against my inverter, but got no response, while Modbus TCP on port 502 works perfectly.
So I suspect the difference is simply the communication protocol supported by my particular WiFi/LAN Kit. Your approach may work perfectly with other GoodWe dongles, but apparently not with mine.
At least now I think we understand why I could never get your app to connect. 
Hi @Michal_Stranik do you have any other suggestions or solutions? Unfortunately, I can’t get it to work, and I’m out of options.
Hello, please report all issues here:
If you’ve been hitting “You have wrong login data (Username, Password, UID) or the Goodwe cloud is down” on the existing GoodWe app — that message is wrong on all three counts. The SEMS Portal login response stopped including the api field that app relied on to find its server, so it fails for everyone, not just you.
I built a new app from scratch against the current SEMS Portal API, with proper Homey Energy integration — GoodWe wasn’t being counted as generation before, and now it is.
What it does:
Flow cards:
Setup: just your SEMS Portal email/password and station ID (found in the SEMS Portal URL) — no API keys, no partnership requirements.
Compatibility: built on GoodWe’s shared SEMS Portal API, not hardcoded to one inverter — should work for any grid-tied GoodWe inverter on SEMS Portal. Tested on a GW3600D-NS (single-phase, no battery). Hybrid/battery models (ET/BT/EH series) will connect and show power/yield fine, but battery data isn’t exposed as capabilities yet — I don’t have one to test against, so if you’ve got one and want to help, I’d love a hand.
Status: submitted to the Homey App Store, currently in certification (up to 2 weeks). Test link works right now: GoodWe SEMS | Homey
That appears to be a session token. I would recommend you to remove this from your post, since anyone can use that to access your account
Hi @Michal_Stranik, could you help with a local Modbus transport issue in GoodWe Inverter v1.13.19?
My existing GoodWe Modbus (ET) device on Homey Pro times out with port 502. With a temporary listener accepting both TCP and UDP at exactly port 502, I captured three requests from Homey. All were UDP, with the same payload:
f7 03 88 b8 00 21 3a c1
This is unit 247, FC03, register 35000, count 33, with a valid RTU CRC. The app was restarted after saving the listener address.
Separately, with the Homey GoodWe app stopped, standard MBAP-framed Modbus TCP reads directly from the inverter succeeded with unit 247 for all four blocks:
The inverter refused the same read-only identification request over UDP on both ports 502 and 8899. After restoring the direct inverter address, port 502 and 60-second polling, and restarting the app, Homey still reports an FC03 timeout after three attempts.
Is there a supported way for this existing driver to select MBAP-framed TCP? If a correction is needed, could you share the relevant v1.13.19 transport/response-decoder source or point me to a fixed release?
For a possible read-only compatibility bridge, does the driver expect bare Modbus RTU replies or an AA55-prefixed envelope, and exactly which bytes are covered by its CRC check? I do not want to assume the separate Python goodwe library uses the same response format as this app.
No device was deleted or re-paired, and no battery-control writes were made. The temporary listener is stopped and the direct inverter address restored. Thanks!
I have a GoodWe GW3600D-NS and I would be happy to help test local support for the DNS/D-NS series in your Homey app.
Initially local communication did not work. SolarGo detected the inverter but returned “Connection failed”, and the inverter did not respond on UDP port 8899.
GoodWe support has now upgraded the ARM firmware of my inverter.
After this upgrade:
• SolarGo connects locally successfully
• SolarGo shows live inverter data
• The inverter responds locally on UDP port 8899
• A GoodWe UDP request returns a 153-byte response
Inverter: GW3600D-NS
Serial: 93600DSN193W0081
Local IP: 192.168.68.66
UDP port: 8899
Homey: Homey Pro 2026
If you are interested in adding local D-NS support, I’m happy to test a development/test version and provide diagnostics or raw responses from the inverter.
Good morning,
Since this morning, no data is coming through from the Goodwe inverter in Homey. Is this a known issue, and is there a solution for it? Thanks in advance for your help!
Kind regards,
Stefan
Same here,… I guess it’s because the Sems Portal (phone)app isn’t working anymore. The homey app used this to log in….. I don’t found a way to get it working again. I tried solar accu op maat, but then I need an api?
Hope there will be a solution fast… loved to use it
Goedemorgen,
ik heb hier het zelfde probleem. ik krijg geen gegeven via de homey GOODWE app. Bij rechtstreeks inloggen via internet wel.
Met vriendelijke groet,
Peter
Hier hetzelfde probleem sinds vandaag.
@TheWiZZz Binnen jouw app ervaar ik hetzelfde trouwens, gisteravond zag ik de eerste melding die iets vermoedde.
[PV] Verdachte meting genegeerd — Zonnepanelen omvormer: 100W buiten zonsopgang/-ondergang (7.7u–19.6u) — fysiek onmogelijk, waarschijnlijk een vastgelopen/verbroken koppeling (19 uur geleden)
Ik heb bij Goodwe Support ook even een ticket aangemaakt met het verzoek om hier naar te kijken, omdat het iets te toevalig is dat het bij talloze mensen tegelijkertijd niet meer werkt op hetzelfde moment.
Hey; De oude Semsportal apps werken niet meer. Ik heb hem geupdate naar de Sems+ cloud versie.
My verison works with Sems+ cloud. let me know your feedback
