Problems with GW15k-ET-20 (Cyber Security dongle)

[EnvironCMO]

Has anyone had problems with this inverter, too?

I added the identifier to the code:

MPPT3_MODELS = ('MSU', 'MST', 'PSC', 'MSC', '25KET', '29K9ET', '25KMT', '15KEU')

But it shows that the inverter is neither supported nor recognisable.

I tested several other things:

UDP Test Port 8899 (Device Frame):
{'ok': False, 'host': '192.168.178.54', 'port': 8899, 'error': 'timeout'}

UDP Broadcast Test Port 48899: {'ok': False, 'port': 48899, 'error': 'timeout'},

Async Test (8899):
{'ok': False, 'port': 8899, 'error': 'timeout'}.

Async Test (8899): {'ok': False, 'host': '192.168.178.54', 'port': 8899, 'error': 'timeout'
INFO: ConnectionRefused = Port closed or UDP service disabled.

When I force direct communication over port 502, I receive the data:
Registers 35100–35119:
35100 6410
35101 267
35102 6928
35103 5874
35104 102
35105 0
35106 5991
35107 4873
35108 102
35109 0
35110 4960
35111 0
35112 0
35113 0
35114 0
35115 65535
35116 65535
35117 65535
35118 65535
35119 514

Does anyone know what the problem is or how to fix it?

[EnvironCMO]

Feedback from GoodWe Support:

The reason that detection via UDP is not possible is that UDP detection is no longer supported with the new WiFi/LAN 2.0 Cyber Security.
All dongles without a Cyber Security chip support UDP detection.

[TheLordBaski]

@EnvironCMO is there a solution for this? Like buying GoodWe WiFi/Lan Kit 2.0?

[EnvironCMO]

@TheLordBaski you can use TCP directly instead of UDP.

[TheLordBaski]

I tried this:

# Connect using the protocol
        inverter = await goodwe.connect(
            ip_address, 
            comm_addr=0xf7,
            family="ET",
            port=port,
        )

but still can't connect to it.

[EnvironCMO]

Try:

inverter = await goodwe.connect(inverter_ip, port=502, timeout=5, force_tcp=True)

[TheLordBaski]

Increasing timeout doesn't work, I no force_tcp argument in the connect. But internally, I check, it's using TCP when the port is 502.

Also tried goodwe.search_inverters() but getting

Traceback (most recent call last):
  File "C:\Users\jakub\test.py", line 88, in <module>
    main()
  File "C:\Users\jakub\test.py", line 84, in main
    asyncio.run(detect_inverter(args.ip, args.family))
  File "C:\Users\jakub\AppData\Local\Programs\Python\Python310\lib\asyncio\runners.py", line 44, in run
    return loop.run_until_complete(main)
  File "C:\Users\jakub\AppData\Local\Programs\Python\Python310\lib\asyncio\base_events.py", line 646, in run_until_complete
    return future.result()
  File "C:\Users\jakub\test.py", line 28, in detect_inverter
    inverters = await goodwe.search_inverters()
  File "C:\Users\jakub\AppData\Local\Programs\Python\Python310\lib\site-packages\goodwe\__init__.py", line 127, in search_inverters
    result = await command.execute(UdpInverterProtocol("255.255.255.255", 48899, 1, 0))
  File "C:\Users\jakub\AppData\Local\Programs\Python\Python310\lib\site-packages\goodwe\protocol.py", line 457, in execute
    result = response_future.result()
goodwe.exceptions.MaxRetriesException

[Kveri]

@EnvironCMO is there a solution for this? Like buying GoodWe WiFi/Lan Kit 2.0?

I have goodwe wifi/lan kit 2.0 and face the same problem. Apparently the new wifi and wifi/lan kits (v2.0) adhere to much stricter cyber security regulations which ask for explicit encryption. I even got a nice printed certificate with the inverter saying that it's super secure.

I sniffed solargo communication with the inverter, the discovery works the same way as before - udp port 48899. After that there is a DTLSv1.2 session over udp.

Over the DTLS session the data exchange seems the same as before

For example:
Sent from phone to goodwe:
f7 03 88 b8 00 21 3a c1

f7 is address = 247, 03 is read holding registers, 88b8 is starting register, 0021 is count of registers, 3ac1 is checksum
so exactly as before.

Received from goodwe to phone:

aa 55 f7 03 42 00 02 27 10 00 fe 35 30 31 30 4b  .U..B..'...5010K
 45 54 55 32 33 36 57 30 35 32 35 47 57 31 30 4b  ETU236W0525GW10K
 4e 2d 45 54 20 00 0d 00 0d 00 e0 00 21 01 65 30  N-ET .......!.e0
 34 30 32 39 2d 31 33 2d 53 31 31 30 32 30 34 31  4029-13-S1102041
 2d 33 33 2d 53 30 30 84 08                       -33-S00..

reply starts with classic aa55, but after that it's classic modbus.

So the "only" thing what is needed to make this work is to add dtls layer in this project.

I put together a quick proxy setup so that I can capture the decrypted data. I have a linux server (router) in the middle of my network, both subnets are terminated on it.

1. put your phone to a different subnet than your goodwe

2. create certs: openssl req -x509 -newkey rsa:2048 -nodes -days 1 -subj "/CN=dtls-proxy" -keyout proxy.key -out proxy.crt

3. merge them: cat proxy.crt proxy.key > proxy.pem

4. run socat -d -d -v -x -T 60 -b 2000 OPENSSL-DTLS-SERVER:8899,reuseaddr,cert=proxy.pem,verify=0 OPENSSL-DTLS-CLIENT::8899,verify=0,no-sni,ciphers=ECDHE-RSA-AES128-GCM-SHA256,openssl-min-proto-version=DTLS1.2,rcvtimeo=1

5. install mitmproxy and run: mitmdump --mode reverse:udp://:48899@48899 --set tls_ignore_server_verify=true --set tls_version_server_min=UNBOUNDED --set termlog_verbosity=debug -v -v -v -v --ssl-insecure --set ciphers_server=ECDHE-ECDSA-AES256-GCM-SHA384,ECDHE-RSA-AES256-GCM-SHA384,DHE-RSA-AES256-GCM-SHA384,ECDHE-ECDSA-CHACHA20-POLY1305,ECDHE-RSA-CHACHA20-POLY1305,DHE-RSA-CHACHA20-POLY1305,ECDHE-ECDSA-AES128-GCM-SHA256,ECDHE-RSA-AES128-GCM-SHA256,DHE-RSA-AES128-GCM-SHA256,ECDHE-ECDSA-AES256-SHA384,ECDHE-RSA-AES256-SHA384,DHE-RSA-AES256-SHA256,ECDHE-ECDSA-AES128-SHA256,ECDHE-RSA-AES128-SHA256,DHE-RSA-AES128-SHA256,ECDHE-ECDSA-AES256-SHA,ECDHE-RSA-AES256-SHA,DHE-RSA-AES256-SHA,ECDHE-ECDSA-AES128-SHA,ECDHE-RSA-AES128-SHA,DHE-RSA-AES128-SHA,AES256-GCM-SHA384,AES128-GCM-SHA256,AES256-SHA256,AES128-SHA256,AES256-SHA,AES128-SHA@SECLEVEL=06.

I don't know if all those ciphers are required, didn't have time to optimize it.

make sure your fw allows udp/48899 and udp/8899 connections inbound. The reason I used mitmproxy was that at first I wanted to do both 48899 and 8899 using it, but after few hours of troubleshooting I couldn't make 8899 work, just the 48899. After that I resorted to using socat. Even socat was not simple, key argument is 'rcvtimeo=1', apparently goodwe is so slow to process incoming DTLS negotiation packets that mitmproxy is too fast for it and goodwe misses the 2nd clienthello, so it never replies with serverhello. Using socat with rcvtimeo=1 fixes that.

[botts7]

Hi — I have a fix for what looks like the same firmware issue on a different hardware variant (single-phase MS-family). Newer Kit-20 dongles encrypt local Modbus with DTLS over the same port; plaintext requests just get dropped, which matches the timeout you're seeing.

Could you confirm whether your dongle is the encrypted variant? Either:

Linux/macOS with nc:

echo -n "WIFIKIT-214028-READ" | nc -u -w 2 192.168.X.255 48899

Any platform with Python:

import socket
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
s.settimeout(2)
s.sendto(b"WIFIKIT-214028-READ", ("192.168.X.255", 48899))
print(s.recvfrom(2048))

If the reply contains dtls_port:8899, the branch at https://github.com/botts7/goodwe/tree/feature/dtls-transport should work for you:

pip install "goodwe[dtls] @ git+https://github.com/botts7/goodwe.git@feature/dtls-transport"
# then in Python:
# await goodwe.connect("<ip>", family="ET", dtls=True)

A reply with the discovery output (and ideally a quick test of the branch) would help. Thanks!

[rnagler]

Thanks botts7, works for me on a Goodwe GW15K-ET-20 with Wifi/Lan Kit 20!

[adamsteen]

This worked for me too on a GW10K-ET-20 with a WiFi/LAN Kit-20 dongle.

The discovery response included dtls_port:8899, and using the DTLS branch with an explicit family="ET" allowed me to connect successfully.

I put together a small helper repo while debugging this, mostly to document the autodiscovery fallback and DTLS behavior I was seeing: https://github.com/adamsteen/goodwe-autodiscovery

Thanks for the pointer in this issue. It helped me understand why plaintext local requests were timing out.

[adamsteen]

How can I use this fix with https://github.com/mletenay/home-assistant-goodwe-inverter, or any chance we could get a release to then have support there?