Repository navigation
support: Maxinn Energy FBKS series (WFBLE.DTU.PlugProA-24-1) - collector connects but never sends data #26
Description
Activity
Thank you for the detailed report. The archive confirms your observation: the collector repeatedly opened TCP connections through the Docker/router peer, sent zero application bytes, and closed them. The old
collector_not_connectedsummary was therefore misleading.v0.3.0-beta.4 adds exact-session handling for silent collectors, separates the routed peer address from collector identity, and cleans up failed callback sessions deterministically. Please retest with the same advertised address and port.
If the collector still opens only zero-byte sessions, attach a fresh beta.3 Support Archive after two or three attempts. At that point the remaining question is whether this PlugProA firmware requires an active command before sending identity or simply does not expose its SmartValue protocol on the local callback connection.
Confirming v0.3.0-beta.4 fixed the "connects but sends nothing" part of this for me. My PlugProA collector (PN
I3000*********4598) went from opening zero-byte TCP sessions to a full handshake with real header/payload exchange and a confirmed session (eybond_framed, live session) on the first retest.One thing that turned out to matter in my setup, worth calling out in case others hit the same symptom on Docker: I run Home Assistant in a container, and it was on the default bridge network. In bridge mode, the container only sees its internal Docker IP (e.g.
172.18.0.4), which the collector on the LAN can never reach — so even with beta.4's improved session handling, the collector kept opening sessions against an address it couldn't actually complete a callback to. Switching tonetwork_mode: host(or otherwise making sure the advertised callback IP is a real LAN-reachable address, not the container's internal IP) resolved it.However, there's a second, separate issue once the connection itself works: driver/inverter detection never succeeds. With
driver_hint: auto, every built-in driver (pi30,eybond_g_ascii,smartess_local) times out with zero response, whilemodbus_smgandmodbus_catalogget a response, just a short/invalid one (response_too_short) on the identity read. I also tried forcingdriver_hinttomodbus_smgdirectly instead ofauto— same result, consistentlyresponse_too_shorton both identity registers (171 and 184), looping every ~7s withno_supported_driver_matched. So the collector's local callback channel is alive and well, but the inverter itself isn't answering active identity/register reads over it — matching what you guessed in your last comment about whether this firmware exposes SmartValue's protocol locally at all.The integration's own diagnostics agree: the support-archive button's status field reports
"support_workflow_level": "smartess_pending"with the summary "The collector exposed SmartESS metadata, but no local inverter driver is matched yet." I generated that support archive and will attach it in a follow-up comment.So: connectivity fix confirmed working, but this specific PlugProA/FBKS combination may need either a dedicated driver or an active-command sequence it's not currently getting. Happy to run any diagnostic command scenario you'd like against it.
- added a commit that references this issue
on Sep 8, 2026 Thanks for the archive! It confirms that the collector connection is now working. The remaining problem is getting usable replies from the inverter, so there's no need to repeat the Docker/network checks.
Please update to the current main test build and restart HA. It makes traffic capture available before an inverter driver is found. Could you try Expand device support → Capture collector traffic for about 10 minutes while SmartValue is showing normal readings, then attach the capture archive?
The form explains the temporary change to the collector's server address and its restoration. If capture can't start or the connection can't be restored, send that result and a Support Archive instead of changing the endpoint manually. The captured vendor requests should help us identify the protocol without guessing.
Updated to the main test build and captured collector traffic per your instructions. Session ran ~10 minutes with SmartValue open and showing normal readings. Capture completed cleanly, endpoint restore confirmed (
restore_confirmed: true, back toiot.eybond.com:18899).Attached:
proxy_capture.zip(anonymized JSONL trace + raw hex in each direction).Quick summary of what's in it, in case it's useful before you dig in: 80 events, mostly
AT+command/response chunks between the collector and its cloud —AT+DTUPN(identity),AT+FWVER,AT+ATVER,AT+SYST(time sync),AT+WFSS(wifi),AT+HTBT(heartbeat),AT+BTSSS,AT+UART,AT+ENUPMODE. No inverter register reads/writes appear in this window — it looks like this is the collector's own management channel to its cloud rather than SmartValue querying live inverter values through it, so I'm not sure this window caught what you're after. Happy to re-run with a longer window or a different trigger (e.g. pulling up a specific reading screen in the app) if that would help.Went through the raw hex in the capture (not just the anonymized ASCII view, since the binary frames get lossy through UTF-8 replacement chars there) and found the actual inverter protocol exchange. Posting the decode in case it saves time.
Framing: every exchange on this connection is
\x00<seq>\x02\xff\x00<len>\xff\x04<2-char cmd>\x01\rfor requests, and\x00<seq>\x02\xff\x00<len>\xff\x04\x01<payload>\x00\x03<checksum 2 bytes>\rfor responses. Three commands were sent in sequence, twice, 5 minutes apart (12:52:0x and 12:57:0x UTC):MD(model/firmware string, response is plain ASCII):S2-8127-240516-V7.00Q1(status line, response is plain ASCII, space-separated — classic Voltronic/PI-familyQ1shape):12:52 → 235.0 04 04 118.0 013 60.1 12.6 38.7 1000010 12:57 → 235.0 04 04 118.0 013 60.3 12.7 34.3 1000010Values shift between the two samples (freq-looking field 60.1→60.3, and two other fields), confirming it's live telemetry, not a cached/static string. First field (235.0) is in the same ballpark as the grid voltage ValueCloud reports; the field that looks like frequency (60.x) also lines up with ValueCloud's
grid_frequency.MP(response is packed binary, not text):12:52 → 010006048785050001f03c6984028c0a2d4169880100a0005000642d00000503002c883c04 12:57 → 010006048785050001f03c6984028c0a2d4169880100a0005000642d00000503002c883c04(identical both times — looks like static capability/config data, not a live reading)
There's also a second exchange pair on the same connection using a different envelope (
Z\xa5...request /\xaa\xbb...response, 21 bytes each) that repeats with small deltas between the two samples — could be counters/accumulators. Raw bytes if useful:12:52 query 1: 5aa502020000000000000000000000000000000004 12:52 reply 1: aabb02026404020c00001e01a401e0000164000083 12:52 query 2: 5aa502000000000000000000000000000000000002 12:52 reply 2: aabb020007cd001e01fe0186000001000108d8005c 12:57 query 1: 5aa502020000000000000000000000000000000004 (identical to 12:52) 12:57 reply 1: aabb02026404020c00001e01a401e0000164000083 (identical to 12:52) 12:57 query 2: 5aa502000000000000000000000000000000000002 12:57 reply 2: aabb02000862003202000137000001000108d900bbSo:
MDgives you the model string,Q1gives a readable multi-field status line on a 5-minute cycle,MPlooks static/binary, and theZ/aabbpair looks like a separate counter channel. Let me know if theS2-8127model string is enough to match this to a driver you already support, or if there's a specific follow-up capture (longer window, different app screen, etc.) that would help more.Hey — howdy from the peanut gallery.
I think this might be a true hit for #45. Your decode of the proxy capture (FC4
MD/Q1/MP,S2-8127-…, plus bare5AA5…02→aabb0200) looks like the same short-ASCII family I got working live on an Anern SPI-12000W (S2-8127-260108-V7.3B). If I'm reading it right, that PR may "just work" for you — or it may need a small layout tweak — but it should be close.Standard disclaimer, said sincerely: it might not bind cleanly on your Maxinn/FBKS combo, or Q1/aabb field meanings might differ enough that you get nonsense entities. Sorry in advance if you burn an evening on it and it flops. Still, I really hope it helps.
If you want to try: branch
mikehardy:feat/eybond-short-ascii-anern-spi12000, or the evidence pack on https://github.com/mikehardy/ha-eybond-local/releases/tag/anern-spi12000-evidence (proxy + HA↔SmartValue notes). A Support Archive after a try would be gold either way.Cheers,
MikeYour capture and Mike's work in #45 have given us enough to add a shared EyeBond Short-ASCII family profile to main. This is test code, not a new release.
Could you install it, leave inverter detection on Auto, and check whether the inverter is detected and its readings update? The generic family name is expected. This first version covers basic voltage, frequency, load percentage and temperature readings; optional BMS readings are available only where the device answers them. PV readings and inverter controls are not included yet.
Please attach a fresh Support Archive after the test, whether it works or not, and mention any readings that look wrong. No need to repeat the earlier traffic capture or Docker checks.
(Support Archive attached above.) Tested the main branch build with the new
eybond_short_asciiprofile,driver_hint: auto. It works — detection succeeded on the first poll after restart:Detected inverter driver=eybond_short_ascii protocol=eybond_short_ascii serial= confidence=highFirmware string matches my earlier decode exactly (
S2-8127-240516-V7.00). Live readings updating every ~10s (vs. the 5-minute ValueCloud cloud poll I was using as a workaround): grid voltage (~245-247V), output voltage (~123V), output frequency (~60Hz), load %, inverter temperature, plus binary status (mains connected, grid available, fault, battery low, PV controller present). All plausible.One thing worth a note rather than a bug:
inverter_temperaturereports in °F by default (109.94°F ≈ 43.3°C) — had me worried it was a scaling bug for a second, it wasn't. Just flagging in case °C is the intended default for non-US users.One actual question:
battery_reference_voltagereads ~12.5V — is that meant to be the real battery bank voltage, or an internal reference rail? My battery bank is ~50V per ValueCloud, so if it's supposed to reflect the bank, something looks off there.Confirmed
control_policy_summarycorrectly reports monitoring-only / no writable controls yet, as expected.- added a commit that references this issue
on Sep 17, 2026 Great, thanks for checking the readings and sending the archive! It confirms that detection and polling are working with the short-ASCII driver.
Battery Reference Voltage is the reference value returned by
Q1, not the full battery-bank voltage. We keep it separate rather than guessing a multiplier. Your inverter isn't answering the optionalRBBMS request, so this build cannot currently report the full-pack value seen in ValueCloud. A 12.5 V reference therefore does not mean the battery bank is at 12.5 V.The temperature in the archive is 43.3 °C. Home Assistant converts that to 109.94 °F according to its unit settings; the entity's settings also let you change the display unit. I've clarified both points in the documentation.
I'm closing the original connection/detection issue as resolved in
main. Additional short-ASCII readings are being reviewed in #45; controls aren't supported yet. If detection or the existing readings stop working, please let me know and we can reopen this.
Preflight
Home Assistant version
2026.7.4
EyeBond Local version
0.3.0-beta.1
Support Archive filename
01KZYKN9DVTVS8KVMB2E9HJXYS_20260813T224539788724Z.zip
What kind of support issue is this?
Unsupported hardware
Inverter / collector model
Maxinn Energy FBKS Series (split-phase hybrid inverter with MPPT) + EyeBond WFBLE.DTU.PlugProA-24-1 Wi-Fi/BLE collector (SmartValue app, com.eybond.smartvalue)
What is missing or broken?
Full local setup completed (HA reachable from the collector's LAN via routed VLAN, port 8899/58899 forwarded from Docker host, advertised_server_ip/advertised_tcp_port configured). Debug logs confirm the UDP discovery command is sent and acknowledged by the collector, and it does open real TCP connections back to the advertised listener, but every session immediately closes with zero bytes received before any identity/handshake data arrives. Create support archive → raw_capture.json reports capture_kind unsupported_or_failed, error collector_not_connected. Detection confidence stays none. Device stuck as "Collector only" / unconfirmed.
Extra context
Vendor SmartValue app works fine and shows live PV/battery/grid/load values for this same collector, so it's healthy and online. Collector local web UI (port 80) only exposes Wi-Fi config pages, no live data. Collector operation mode set to Cloud + HA.
home-assistant_eybond_local_2026-08-13T22-37-06.249Z.log
01KZYKN9DVTVS8KVMB2E9HJXYS_20260813T224539788724Z.zip
Where did you hear about EyeBond Local?
None