Repository navigation
support: Unknown collector – WFBLE.DTU.Bar (GOOTU JSY-H4862E120-D) #18
Description
Activity
Danke für das Archiv. In beta.1 wurde hier ein „Pending Device“ gespeichert, obwohl noch keine bestätigte Collector-Sitzung und keine PN vorhanden waren. Dieses Verhalten wurde in v0.3.0-beta.4 entfernt: ein nicht identifiziertes Gerät wird nicht mehr als fertiger Eintrag gespeichert; stattdessen bleiben Wiederholen und Hintergrund-Erkennung verfügbar.
Bitte aktualisieren Sie auf beta.4 und versuchen Sie die bekannte IP erneut. Wenn der Collector erkannt wird, läuft die Inverter-Erkennung anschließend im normalen Runtime-Pfad. Falls weiterhin keine PN/TCP-Sitzung erscheint, erstellen Sie bitte ein neues Support Archive. Dann müssen wir zuerst klären, ob diese DTU.Bar-Firmware einen kompatiblen lokalen Callback anbietet; das ähnliche GOOTU-Modell aus Issue #21 reicht allein nicht als Identitätsnachweis für Ihr Gerät.
Hey — just a small breadcrumb, not a claim that this is fixed.
There isn't a ton of evidence that #45 will help your DTU.Bar / GOOTU case yet (Maksym's pending-device / identification notes on this thread still look like the first gate). If you later get a live FC4 session and a proxy or raw capture that shows short-ASCII commands (
MD/Q1/F/RB, or bare5AA5/aabb), then a short-ASCII probe from that PR might be worth trying. Needs more diagnostics first.Sorry if that's noise — figured the I2000-style PN + "unknown collector" combo was worth a pointer.
Cheers,
Mike"Hi! I've captured a fresh traffic dump while running the direct data request. Here is the .zip containing the .pcap file (47.239.230.129:18899 communication). Does this information help you analyze the I2000 / DTU.Bar protocol?"
Yes, this helps — thank you! The capture contains valid Modbus RTU requests and replies: device address 5, reading register blocks starting at 4501 and 4546. It is a different exchange from the short-ASCII commands discussed in #45, so I wouldn't assume that driver fits your device.
This gives us concrete protocol evidence to work with. What it doesn't show is the collector's initial identification or its connection to Home Assistant, since the capture is from an already-running cloud connection.
Could you try adding/probing the collector with the current main test build, then attach a fresh Support Archive and the result shown by HA? The earlier HA archive was from beta.1, so this will let us separate the current connection/identification problem from the inverter protocol. No need to repeat this cloud capture.
Many thanks for your valuable and expert help!
For the time being, I have tried Beta 4 without success.
Support Archive:
01M2NF90J6XDN1B20A8192MDA4_20260916T163617553723Z.zipAfter that, I installed the "current main test build" and created a support archive:
01M2NF90J6XDN1B20A8192MDA4_20260916T174954294417Z.zipI hope this helps us!
- added a commit that references this issue
on Sep 17, 2026 Thanks for testing both builds. I checked the archives: the existing entry still has no confirmed collector identity, so it cannot attach to the collector session. That needs to be resolved before we can test the inverter map.
I've updated the repair flow in main. Please install it, restart HA, and use Reconfigure from the existing EyeBond entry's three-dot menu. No need to delete and add it again.
If the collector connects but stays silent, the repair screen now offers an explicit identity query. In that case, please try Silent collector: query with EyeBond framed protocol once. This only reads the collector identity; it does not restart it or change inverter settings. If the connection has already closed, use Probe again first.
Please send the result shown and a fresh Support Archive afterward. This is a fix for the repair step, not a claim that the GOOTU inverter map is already supported. I still have your useful Modbus cloud capture — no need to repeat it.
Hello Groove-max and thank you very much for your reply
Have loaded, unpacked, moved, restarted, reconfigured, then came this message:The collector did not call back during this attempt. Your existing entry has not been changed. If a silent-collector option is offered, choose a protocol only when instructed. The next attempt sends one read-only identity query; it does not restart the collector or change inverter settings.to know if the dongle is even capable of an answer, I do the following:
aprender@aprender-MacBookAir6-1:~$ docker exec -it homeassistant ping -c 3 192.168.1.175 PING 192.168.1.175 (192.168.1.175): 56 data bytes 64 bytes from 192.168.1.175: seq=0 ttl=64 time=410.054 ms 64 bytes from 192.168.1.175: seq=1 ttl=64 time=127.442 ms 64 bytes from 192.168.1.175: seq=2 ttl=64 time=44.431 ms --- 192.168.1.175 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 44.431/193.975/410.054 ms aprender@aprender-MacBookAir6-1:~$Unfortunately, I did not succeed with a connection, here is the support archive:
01M2NF90J6XDN1B20A8192MDA4_20260917T135901137113Z.zip
i don't find:
silent collector: query with EyeBond framed protocol
where is that supposed to be? Will it also be displayed if the dongle does not answer at all?I am very grateful for your help, but I can understand if we have to give it up...
Best regards from MozambiqueThanks for testing again — I don't think we need to give up. Your earlier cloud capture already gave us useful protocol data; we now need to find out why the collector's connection isn't reaching Home Assistant.
The new archive shows HA listening on port 8899, but no incoming collector sessions. Ping confirms that HA can reach the dongle; it doesn't test the reverse TCP connection the dongle needs to open. Docker networking is one possibility, but the archive doesn't establish the cause.
Could you run these on the Linux machine hosting Docker, not inside the HA container?
First, please share the output of:
docker inspect --format 'network={{.HostConfig.NetworkMode}} ports={{json .NetworkSettings.Ports}}' homeassistantThen start this short capture:
sudo tcpdump -ni any -s0 -w eybond-callback.pcap 'host 192.168.1.175 and (udp port 58899 or tcp port 8899)'While it runs, try Reconfigure once. Wait for the result, stop tcpdump with Ctrl+C, and attach
eybond-callback.pcapin a ZIP. Also, is192.168.1.106still the LAN address of your HA host?This should show whether the callback request leaves HA and whether the collector tries to connect back. No need to reinstall, change the collector endpoint, or repeat the cloud capture you already sent.
run:
aprender@aprender-MacBookAir6-1:~$ docker inspect --format 'network={{.HostConfig.NetworkMode}} ports={{json .NetworkSettings.Ports}}' homeassistant network=host ports={} aprender@aprender-MacBookAir6-1:~$ sudo tcpdump -ni any -s0 -w eybond-callback.pcap 'host 192.168.1.175 and (udp port 58899 or tcp port 8899)' [sudo] Passwort für aprender: tcpdump: data link type LINUX_SLL2 tcpdump: listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes ^Z [2]+ Angehalten sudo tcpdump -ni any -s0 -w eybond-callback.pcap 'host 192.168.1.175 and (udp port 58899 or tcp port 8899)' aprender@aprender-MacBookAir6-1:~$File:
eybond-callback.zipi start the Reconfigure 2 times... i was wondering why.... sorry ;-)
IP HA still:
192.168.1.106Namaste
Thanks — that confirms Docker is using host networking, so a missing Docker port mapping isn't the issue here.
I checked the ZIP:
eybond-callback.pcapis 0 bytes. Your terminal output shows Ctrl+Z, which pauses tcpdump rather than finishing the recording. The empty file doesn't tell us whether packets were exchanged.Could you repeat the capture on the HA host with this command?
sudo tcpdump -U -ni any -s0 -w eybond-callback-new.pcap 'host 192.168.1.175 and (udp port 58899 or tcp port 8899)'Run Reconfigure once while it records. When Reconfigure finishes, press Ctrl+C, wait for tcpdump to print the packet counts, then ZIP and attach
eybond-callback-new.pcap.Running Reconfigure twice earlier wasn't a problem. No need to change any settings or repeat the cloud capture.
Sorry my mistake, I reconfigured ctrl+C and therefore simply used ctrl+Z at this moment.
Here again with data:aprender@aprender-MacBookAir6-1:~$ sudo tcpdump -ni any -s0 -w eybond-callback.pcap 'host 192.168.1.175 and (udp port 58899 or tcp port 8899)'
tcpdump: data link type LINUX_SLL2
tcpdump: listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
^C48 packets captured
48 packets received by filter
0 packets dropped by kernelThanks, this capture is usable now. It shows Home Assistant sending the callback request to
192.168.1.175, asking the collector to connect back to192.168.1.106:8899. The requests look correct, but there are no UDP replies or incoming TCP connection attempts in the recording.We still need to distinguish between the request not reaching the collector and the collector receiving it but not responding. This does not mean your collector is unsupported.
One limitation of our previous capture filter: it excluded ICMP messages, which could contain a useful error such as “port unreachable”. If we need another capture, we’ll include those rather than repeat the same test.
I also noticed that the earlier cloud capture used the local address
172.20.10.8, whereas the collector is now at192.168.1.175. Was that recording made on a different network or through another device?For now, please run these two commands on the Linux machine hosting Docker, not inside the Home Assistant container, and share the output:
ip route get 192.168.1.175 ip neigh show 192.168.1.175
They will show the actual route and the neighbour entry for that address. No settings need changing, and there’s no need to repeat the capture yet.
If you’re comfortable with temporary remote access, Tailscale is another option that could help us investigate faster without exchanging commands and captures at every step. It’s entirely optional — we can continue here too. If you prefer that route, message me on Telegram:
@groove_max.Hi Max
Thank you for your contact details!
I will contact you via Telegram, but I am now a few days away from the server and the systemBut still there today:
Answers from the terminal:aprender@aprender-MacBookAir6-1:~$ ip route get 192.168.1.175 ip neigh show 192.168.1.175 192.168.1.175 dev wlp3s0 src 192.168.1.106 uid 1000 cache 192.168.1.175 dev wlp3s0 lladdr b0:81:84:27:5d:a8 REACHABLE aprender@aprender-MacBookAir6-1:~$Thank you again for all your help!
All love and see you soonThanks! That confirms a direct Wi-Fi route and a reachable neighbour entry,
though it doesn’t yet explain the missing callback. No need to run anything
else while you’re away — message me on Telegram when you’re back and we’ll
continue from what you’ve already collected.
Preflight
Home Assistant version
2026.7.0
EyeBond Local version
0.3.0-beta.1
Support Archive filename
01KYD930GWYA00NPAHNYGRMWD9_20260725T184249970752Z.zip
What kind of support issue is this?
Unsupported hardware
Inverter / collector model
What is missing or broken?
Hardware
Network
Status in EyeBond Local (v0.3.0-beta.1)
Support Archive
(siehe angehängte ZIP)
01KYD930GWYA00NPAHNYGRMWD9_20260725T184249970752Z.zip
Extra context
No response
Where did you hear about EyeBond Local?
Search engine (Google, etc.)