Repository navigation
support: MarsRock controller detected through EyeBond collector but no driver matches #43
Description
Activity
Thanks for the archive. It confirms that Home Assistant can identify the collector, but there are no successful replies from the controller yet.
At the time the archive was saved, the collector was disconnected. Its cloud server address had already been read, so the capture blocker at that point was the connection, not a missing driver. The earlier “callback address” message is misleading; it actually refers to the collector's configured server address.
Could you share the exact MarsRock controller model or its communication manual, and confirm whether SmartClient previously showed live readings from it? There is no need to re-add the logger for now. A Home Assistant debug log covering one failed capture attempt would also help establish what happens to the session.
Thanks. I can provide more details now.
The currently installed inverter/controller was sold to me as a 22–65 V, 3 kW wind grid-tie inverter, but SmartClient reports an installed capacity of only 1.0 kW.
The wind turbine is connected directly to the inverter with 3 wires / 3-phase AC from the turbine.
Based on the official MarsRock G2 wind inverter manual, this seems to match the SUN-1000G2-WAL-M family:
- three-phase wind turbine input
- 22–65 V input range
- 1000 W max / 900 W continuous
Official manual:
https://marsrock.com.cn/u_file/2405/09/file/G2SeriesMicroinverterWindUserManual.pdfBefore this inverter, I used another unit sold as a 1000 W, 48 V / 45–90 V wind inverter. Externally both units look almost identical.
One unit has a MarsRock label and a serial number, but that serial number did not work in the MarsRock app. Both units did work in SmartClient.
Yes, SmartClient previously showed live readings from the currently installed unit. I have a screenshot from 8 September 2026 showing:
- Installed Capacity: 1.0 kW
- current power
- generation graph/history
I can attach that screenshot if useful.
I have not re-added the logger to SmartClient, as requested.
If you want, I can now also produce a Home Assistant DEBUG log while reproducing one failed capture attempt.
I enabled Home Assistant debug logging for EyeBond Local, opened
"Capture collector cloud traffic" and reproduced the not-ready/failed capture state.I then disabled debug logging immediately afterwards.
I attached a filtered debug log containing only EyeBond Local entries.
The full Home Assistant debug log also contained unrelated integration credentials,
so I removed all unrelated integration lines before attaching it.During the attempt, the collector connection was reset at around 18:09:05
("Connection reset by peer") and reconnected about one second later.The Proxy Capture page still did not offer "Start proxy capture".
Hey — quick note in case it's useful while you're stuck on
framed_fc4+ no matching driver.The debug style that unblocked me on a similar "SmartValue works, HA doesn't" path was pretty crude but effective:
- SmartValue Historical Data in a rooted Android emulator (adb screencap / swipe) for wall-clock cloud ground truth
- HA over SSH at the same time — entity dumps + logs
- And, when you can, a collector↔cloud proxy capture while SmartValue is showing live readings (that's still the highest-value artifact)
#45 is an Anern short-ASCII driver, not a MarsRock/wind driver — so it may help you move capture/session work forward (callback/admission hardening + better FC4 vs bare
aabbdiscrimination on the callback socket), or it might not help at all for your controller. Sorry in advance if it's a red herring. If a capture shows something other than FC4 short-ASCII, you'll still need a dedicated path.Happy to compare notes if a capture lands.
Cheers,
MikeThanks Mike, that's useful.
In my case the collector is identified as eybond_framed / framed_fc4, but no driver matches the MarsRock controller.Unfortunately Proxy Capture is currently the blocker: the integration never offers Start proxy capture, even when the collector reconnects and is identified correctly.
I also don't currently have the logger added back into SmartClient/SmartValue, because I want to avoid changing its configuration.
I have already provided the developer with a support archive, SmartClient screenshots showing live/history data, and a Home Assistant DEBUG log covering a failed capture attempt.
If I manage to get a proxy capture later, I'll be happy to share it with you.
- added a commit that references this issue
on Sep 16, 2026 Thanks for the log and the model details. The log shows repeated collector reconnects. I also found that the capture screen could stay blocked on an offline snapshot instead of offering a direct connection retry. We haven't established what causes the resets yet.
I've added a Reconnect and start capture option to the code in
main. It tries the collector connection directly without needing to identify the inverter first. The current server address must still be read successfully before anything is redirected.Please install the updated code from
main, restart Home Assistant and try that option. If capture starts, let it run for about 10 minutes and share the saved ZIP. If it cannot start, send the exact message shown. There's no need to re-add the logger to SmartClient or repeat the same debug log at this point.I installed the current main branch (commit 13dc45b) and restarted Home Assistant.
I changed Control mode from Read-only to Auto so collector actions are allowed.
“Start capture” then became available, but starting the capture failed. The HA log shows a timeout while reading the collector server endpoint:
CollectorManagementTransportError: TimeoutError
followed by:
RuntimeError: cloud_tool_collector_not_connectedAfter the failed attempt, the Capture screen now says exactly:
“The last check found no collector connection. Choose Reconnect and start capture to try again. Home Assistant will first connect to the collector and read its current server address, then temporarily redirect traffic through Home Assistant. If those checks fail, capture will not start and the address will not be changed.”
However, the “What to do” dropdown still only contains:
Start capture
Refresh live log“Reconnect and start capture” is not offered in the dropdown.
I have not re-added the logger to SmartClient and have not repeated the debug log.
Thanks, I found why the instructions and the dropdown disagreed: they were using different connection snapshots. That is now corrected in the test code in main, including after a failed start.
The endpoint-read timeout is still a separate question. Start capture and Reconnect and start capture run the same live checks; changing the label alone won't resolve it. If HA cannot read the collector's current server address, it stops before changing it.
Please install the updated main code and fully restart HA. If capture still fails, could you attach a Support Archive created just afterwards? That should help us check the collector session and the failed endpoint read. No need to change the endpoint manually.
Updated to the latest main, fully restarted Home Assistant, then tried Start capture again.
The capture still failed while reading the collector's current server endpoint.
I created this Support Archive immediately afterwards, as requested.
I did not manually change the endpoint.- added a commit that references this issue
on Sep 24, 2026 Thanks, the archive shows that the collector connects, but the connections are
repeatedly reset. Capture stops because HA cannot read its current server
address. The cause of the resets is still unclear.I’ve added diagnostics to the test code in main
that show which part of that read fails and whether the connection changes
during it. Please update, restart HA, try capture once and create a Support
Archive immediately afterwards. That adds information the previous archive
couldn’t provide. There’s no need to change the endpoint manually.Updated to the latest main, fully restarted Home Assistant, tried capture once, then created this Support Archive immediately afterwards as requested.
Capture still failed during the endpoint read.
I did not change the endpoint manually.Thanks for trying again. I found why the extra details were still missing: they were recorded internally but weren't included in the Support Archive. Sorry about the extra round trip.
I've corrected the export in the test code in main and tested the actual archive download. This doesn't fix the connection resets yet, but it will show which endpoint read fails and whether the connection changes during it.
Could you update main, restart HA, try capture once and create a Support Archive immediately afterwards? Please leave the endpoint unchanged.
Updated to the latest main, fully restarted HA, tried capture once, and created this Support Archive immediately afterwards.
Endpoint was left unchanged as requested.
This archive should now contain the newly exported endpoint-read diagnostics.- added a commit that references this issue
on Sep 25, 2026 Thanks — the new diagnostics confirm that reading the server address itself
times out. I also checked your earlier debug log: the collector answered that
same command repeatedly. So this isn't simply a command it doesn't support.
In that log, inverter requests then went unanswered and the connection was reset.Could you enable debug logging for EyeBond Local, try starting capture once,
then disable debug logging and attach the downloaded log? This will show the
request/reply sequence around the failed capture attempt, which the archive
summary cannot show. Your currently installed main build is sufficient for this;
there's no need for another update or to change the endpoint manually.Debug logging enabled, capture attempted once, then debug logging disabled.
I attached a filtered log containing only custom_components.eybond_local entries because the raw Home Assistant log contained unrelated credentials from another integration.
The same FC2 endpoint command (payload=15) succeeds earlier in the same session, then times out during the capture attempt after the inverter probes stop receiving replies. The collector later resets the connection, reconnects, and the same FC2 command succeeds again immediately.
Endpoint was left unchanged.- added a commit that references this issue
on Sep 28, 2026 I found an overlap in our code: normal polling could still be running while traffic capture or active device learning was preparing the collector connection. The test code in
mainnow waits for that poll to finish and prevents new polls from interrupting preparation or its recovery.This fixes the overlap, but it doesn't yet prove what causes the collector's connection resets. Please update from main, restart HA and try starting capture once. If it still fails, send a Support Archive straight afterward so it includes that attempt.
This time the capture successfully ran for the full 10 minutes.
I have attached both the Support Archive created immediately afterwards and the Collector Capture bundle generated by Home Assistant.
The capture bundle shows that HA restored dtu_solar.eybond.com:18899 and received AT+CLDSRVHOST1:W000. The capture then ended automatically.
The capture screen itself did not appear to refresh after the 10-minute timeout.
I did not change the endpoint manually.01M25W7BM20EFRD8W537YSBRAS_20260928T144654396030Z.zip
01M25W7BM20EFRD8W537YSBRAS_20260928T145154350713Z.zipThanks, this capture worked. I checked the traffic: it contains three complete
rounds of register reads, and the collector acknowledged restoration of its
cloud address when the timer expired. No need to repeat the capture.The open capture screen doesn't refresh automatically in this version. Use
Refresh or reopen it to see the final state; that doesn't restart the timer.
The stale screen doesn't mean the capture kept running.The controller still needs a matching register map, so this doesn't yet complete
its support. One quick check: did readings in the manufacturer's app continue
updating after the capture? The archive confirms the restored address, but not
that the app was receiving fresh readings afterward.I can’t verify that at the moment.
To avoid interfering with the Home Assistant/EyeBond testing, I had previously removed the logger/device from SmartClient.
So I currently have no manufacturer-app live readings to compare after the capture.
I have not re-added it yet.Thanks, that explains why we can't compare the app readings now. You don't need
to remove the logger from the manufacturer's app for the integration or capture
to work. If you re-add it later, we can use it for comparison, but there's no need
to repeat the capture — the one you sent is usable. The controller's register
map is still the missing part of local support.
Preflight
Home Assistant version
2026.9.1
EyeBond Local version
0.3.0-beta.5
Support Archive filename
01M25W7BM20EFRD8W537YSBRAS_20260911T130921100311Z.zip
What kind of support issue is this?
Unsupported hardware
Inverter / collector model
MarsRock wind turbine controller used with SZ-48V-5B 3 kW wind generator + EyeBond Wi-Fi collector
What is missing or broken?
The EyeBond collector is detected and connected correctly, but the MarsRock controller behind it is never identified.
The runtime driver remains "driver_unbound" and no controller telemetry entities are created.
EyeBond Local identifies the collector connection as:
However, the supported protocol/driver probes do not match the MarsRock controller.
Extra context
The collector was previously used with the SmartClient mobile app.
The SmartClient account still works, but I removed the device/logger from the SmartClient project while testing SmartValue. I do not want to re-add it because I want to avoid changing the current collector configuration.
Proxy Capture is also unavailable even while the collector has an active local session. The UI reports:
"Capture cannot start yet: the current collector callback address is not available yet."
The original cloud endpoint is known:
dtu_solar.eybond.com:18899
The collector firmware is 8.50.8.18 and the collector itself communicates correctly with Home Assistant.
01M25W7BM20EFRD8W537YSBRAS_20260911T130921100311Z.zip
Where did you hear about EyeBond Local?
No response