Skip to content

support: Anenji 12kW white — collector OK, driver not detected (SMG timeout/no_match) #49

Open
Open
support: Anenji 12kW white — collector OK, driver not detected (SMG timeout/no_match)#49
Labels
supportHardware support, diagnostics, or Support Archive review

Description

@txau
txau
opened on Sep 27, 2026

01M3HJ97ZF75NHMDX4SR43VXEF_20260927T142753214579Z.zip

Preflight

  • I generated a fresh Support Archive for this report.
  • I will attach the ZIP file to this issue or the first follow-up comment.
  • I searched existing issues first.

Home Assistant version

2026.9.3

EyeBond Local version

0.3.0-beta.5

Support Archive filename

01M3HJ97ZF75NHMDX4SR43VXEF_20260927T142753214579Z.zip

What kind of support issue is this?

Unsupported hardware

Inverter / collector model

Anenji 12 kW white hybrid Exact model: GES48120M250-500P (GES-500 / split-phase hybrid family; SmartValue / EyeBond stick)

What is missing or broken?

Inverter / collector:

Inverter: Anenji 12 kW white hybrid (SmartValue / EyeBond Wi‑Fi stick)
App: SmartValue — live data works on phone
Collector firmware: 8.50.18.3
Collector hardware: 8.0.0.1
Collector serial: I30000251830279039

What works:

Collector discovered and added in HA
Reverse TCP to HA on 192.168.13.200:8899 confirmed (full handshake + data)
Collector device entities present (Wi‑Fi, firmware, etc.)

What doesn’t:

No inverter device / sensors
Runtime Driver State: Driver not detected
Poll Context: stuck on Inverter detection

Log excerpts:

Driver detection failed: no_supported_driver_matched
Driver detection failed: modbus_smg:probe_timeout
Driver detection failed: modbus_smg:no_match
Driver detection failed: smartess_local:probe_timeout
CollectorManagementTransportError: TimeoutError

Tried:

Drivers: Auto, SMG/Modbus, SmartESS 0925/Modbus (and others) — no bind
Manual setup / inbound (“device connects on its own”)
HA upgraded (Docker ghcr.io/home-assistant/home-assistant:stable)
Attach: Support Archive ZIP (+ cloud evidence / Analyze device data if you ran it)

Extra context

No response

Where did you hear about EyeBond Local?

Home Assistant Community

Activity

  1. txau
    added
    supportHardware support, diagnostics, or Support Archive review
    on Sep 27, 2026

  2. groove-max commented on Sep 28, 2026

    @groove-max
    groove-max
    on Sep 28, 2026
    Owner

    Thanks for the detailed report and archive. The collector is connecting, but the inverter hasn't matched a supported protocol. The full scan has already run, so there's no need to repeat it or keep forcing the SMG driver just because this is an Anenji.

    Could you share the device-information screen from SmartValue, including any inverter type or protocol/version fields it shows? If you have a communication protocol or register-map document from the supplier, that would be especially useful. You can hide the serial number and account details.

    A recording of the working cloud connection would also help. Capture is currently blocked because your setup leaves the collector's server address under external control; that is separate from inverter Full Control. Before suggesting a temporary reroute, is that address managed by another service that needs to remain untouched?

  3. txau commented on Sep 29, 2026

    @txau
    txau
    on Sep 29, 2026
    Author

    Thanks — I’ll stop forcing SMG / full rescan.

    1. SmartValue device-info screenshots attached (serial/account blurred).
      Model: GES48120M250-500P (Anenji white 12 kW split-phase).

    2. I don’t have an official register map from the supplier yet.
      Community notes for this model family mention Modbus around 0x7530;
      I’ll attach a PDF if Anenji sends one.

    3. Collector server address: managed only by SmartValue / ValueClouds.
      Nothing else (no Solar Assistant / other redirect) needs to keep control.
      Temporary reroute for a cloud-connection capture is OK — please restore
      cloud afterward (or tell me the exact steps). Happy to run Expand device
      support → Capture collector cloud traffic when you say so.

    Image

  4. txau commented on Sep 29, 2026

    @txau
    txau
    on Sep 29, 2026
    Author

    SmartValue Debug — Modbus probes (through the collector)

    I used SmartValue’s Debugging screen to send raw Modbus RTU hex (read-only). Slave address 0x01, function 0x03.

    Failures (wrong map — matches why local SMG detection failed)

    A) Classic low addresses:
    Request: 01 03 00 00 00 0A C5 CD
    Response: 01 83 02 C0 F1 → exception 02 (Illegal Data Address)
    D) ~0x1004 area:
    Request: 01 03 10 04 00 0A 80 CC
    Response: 01 83 02 C0 F1 → exception 02

    Success — holding registers at 0x7530 (Anenji / Sumry-style map)

    B) Request: 01 03 75 30 00 0A DF CE
    Response: 01 03 14 02 03 00 00 00 41 00 00 00 00 00 00 04 C9 04 A7 02 3E 01 11 D2 BB
    C) Request: 01 03 75 30 00 14 5F C6
    Response: 01 03 28 02 03 00 00 00 41 00 00 00 00 00 00 04 CF 04 A4 02 17 00 FC 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CE EA
    Decoded (using the common GES/Anenji 0x7530 layout, ×0.1 where applicable):

    • 0x7530 = 515 → 51.5 V battery voltage
    • 0x7531 = 0 → battery current
    • 0x7532 = 65 → 65% SOC (inverter-estimated)

    Mains / grid (0x756A) — for “grid present”

    Request: 01 03 75 6A 00 0A FF DD
    Response: 01 03 14 04 CB 00 15 17 6E 04 A7 00 1D 04 A7 00 00 01 01 01 59 00 00 E4 C3
    Decoded:

    • 0x756A = 1227 → 122.7 V mains L1
    • 0x756B = 21 → 2.1 A mains L1
    • 0x756C = 5998 → 59.98 Hz
    • 0x756D = 1191 → 119.1 V mains L2
    • 0x756E = 29 → 2.9 A mains L2

    AC output (0x7548)

    Request: 01 03 75 48 00 0A 5F D7
    Response: 01 03 14 04 CD 00 0E 17 6E 00 03 00 6C 00 B1 00 00 00 00 04 A7 00 1D 09 F1
    Decoded:

    • 0x7548 = 1229 → 122.9 V output L1
    • 0x754A = 5998 → 59.98 Hz
    • 0x7550 = 1191 → 119.1 V output L2

    Protocol notes

    • Local EyeBond probes that hit classic SMG / low holding addresses fail with exception 02 on this unit.
    • Working telemetry is the 0x7530+ holding-register map (same family as community docs for this hardware):
    • I do not have an official Anenji PDF from the supplier yet; I can attach one if they send it.
    • UART: I have not changed baud in Debug; I can report the exact UART string shown in SmartValue if useful (likely 9600 8N1 for this family).
      Happy to run more read-only register dumps or your proxy capture once you say how to clear the “server under external control” block.

  5. groove-max commented on Sep 29, 2026

    @groove-max
    groove-max
    on Sep 29, 2026
    Owner

    Thanks — these replies give us a much clearer starting point. The packets are
    valid, and the battery, output and grid readings match the 0x7530-based protocol
    you linked. This needs a separate profile, not another forced SMG scan.

    I also rechecked your archive: the capture blocker is Read-only control mode,
    not evidence that another application is controlling the server address. Sorry
    for the confusion. Read-only also prevents the temporary collector address
    change needed for capture.

    With the current main test code, change Control mode to Auto in the
    integration settings and leave the connection in Cloud + Home Assistant.
    Full Control isn't needed. Then open Expand device support → Capture collector
    cloud traffic     and run a 10-minute capture. Starting it temporarily routes the
    cloud connection through HA; it restores the saved address afterward. Leave
    inverter settings unchanged and attach the Saved result ZIP when it finishes.
    Please also check that the app resumes updating. If starting or restoration
    fails, send that error and a Support Archive rather than repeating it.

  6. txau commented on Sep 29, 2026

    @txau
    txau
    on Sep 29, 2026
    Author

    Thanks — I tried to run the 10-minute capture but couldn’t complete it yet.

    Blockers

    1. Configure dialogs blink/close (Collector connection and cloud, Capture collector cloud traffic). Status stays Not available; clicks don’t stick.
    2. While the entry is enabled, logs show continuous driver detection (fast/deep), with Debouncer lock is already acquired, waiting and long coordinator cycles (~1–2 min). That seems to starve the options flows.
    3. I don’t see a separate “Cloud + HA” toggle under Polling; Collector connection and cloud never stays open long enough to confirm/change the profile.
    4. I’m on 0.3.0-beta.5. You mentioned “current main test code” — should I install main before retrying capture?

    What still works

    • Collector stays connected; SmartValue live data OK.
    • SmartValue Debug Modbus @ 0x7530 / 0x756A / 0x7548 still valid (prior comment).
    • Auto detection still probes other maps (SMG etc.), gets exception 02 / timeouts — no 0x7530 probe yet.

    Next

    I’ll disable the integration when I have time, retry capture (or update to main if you say so), and attach the Saved result ZIP + confirm the app resumes. Until then I won’t manually rewrite the collector server.

    Any preferred order: update to main first vs disable/retry on beta.5?

  7. groove-max
    added a commit that references this issue on Sep 30, 2026

    Add 09C1 telemetry and complete issue support follow-ups

    bfa08af

  8. groove-max commented on Sep 30, 2026

    @groove-max
    groove-max
    on Sep 30, 2026
    Owner

    Please update from main
    and restart HA first; the version label can still say
    0.3.0-beta.5 with newer test code installed. Keep the integration enabled —
    disabling it also stops the connection needed for capture.

    I found that Refresh in the capture window could wait behind the long inverter
    search. That's been separated now. The windows closing by themselves isn't
    explained yet, so I don't want to promise this fixes that too.

    Cloud + Home Assistant is under Collector connection and cloud, not Polling.
    If the window still closes after the update, please send the HA log from that
    attempt; there's no need to keep repeating the full scan.

  9. txau commented on Oct 1, 2026

    @txau
    txau
    on Oct 1, 2026
    Author

    Updated from main manually (HACS only offers tagged releases through 0.3.0-beta.5; typing main is not allowed). After replace + HA restart the UI still shows 0.3.0-beta.5, as you noted.

    Blocker
    Configure → Collector connection and cloud still only blinks — the dialog never opens.
    Configure → Diagnostics → Create support archive works; archive from this attempt is attached.

    I did not disable the integration.

    Collector / runtime state (while reproducing)
    Collector IP: 192.168.13.28 (online)
    Collector PN: I30000251830279039
    Collector Operating Profile: Custom configuration
    Collector Server Endpoint: iot.eybond.com,18899,TCP
    Collector Cloud Family: valuecloud_at
    Connected Wi-Fi: R001 (signal Good)
    Poll Mode: Manual, 300 s
    Poll Context: Inverter detection
    Last Error: startup_detection_pending
    Runtime Driver State: Driver not detected
    Logs / detection behavior
    After reload, Fast detection loops on the wrong hint:

    Starting inverter driver detection depth=fast hint=srne_modbus
    Driver detection failed: srne_modbus:no_match
    Earlier also saw long signature/probe timeouts across several drivers, Debouncer lock is already acquired, waiting, and mixed/raw fragment parse noise from the collector. Changing protocols in the UI did not unlock Collector connection and cloud.

    01M3WN70SHBKVJPZTWES7N8TN9_20261001T215040335792Z.zip

  10. txau commented on Oct 2, 2026

    @txau
    txau
    on Oct 2, 2026
    Author

    I was playing around with AI and implemented the changes in a fork. It is working great for me, all sensors match the inverter screen, so eyeball tests at least are passing =) It is all based on public community mappings.

    Just a draft for now: txau/ha-eybond-local@main...feat/ges48120-sumry-battery-voltage

    If this is going in the right direction, I can try to complete it and open a PR. Please let me know.

  11. groove-max
    added a commit that references this issue on Oct 2, 2026

    fix: qualify PV3300 controls and 09C1 channels, restore collector setup

    9984dc4

  12. groove-max commented on Oct 2, 2026

    @groove-max
    groove-max
    on Oct 2, 2026
    Owner

    Thanks for the archive and the fork — both helped.

    The menu problem is fixed in the main test build. An unclassified collector was being treated as local-only, which sent the connection dialog straight back to the menu. After updating and restarting HA, Collector connection and cloud should open even before the inverter is recognized.

    Your separate Sumry/GES map is a useful direction. I checked the captured registers against the protocol document and retained a tested read-only subset. Automatic GES detection is not enabled yet: plausible battery voltage and SOC aren't reliable identifiers. Also, a grid-power total shouldn't silently become one leg's power if the other reading is missing.

    Could you read these two identity ranges with the same SmartValue Debug tool you used earlier? Complete slave-1 Modbus requests, including CRC:

    • Model and product class: 01 03 C7 38 00 02 78 B2
    • Protocol version: 01 03 C7 68 00 01 38 A2

    These only read registers; they don't change settings. Please paste each complete request and response, including an error response if either fails. Another full support archive isn't needed for this particular gap.

    A focused read-only PR would be welcome; let's establish the identifier first so we can recognize your inverter without accidentally assigning its map to another device.

  13. txau commented on Oct 2, 2026

    @txau
    txau
    on Oct 2, 2026
    Author

    Here are the SmartValue Debug captures (slave 1, complete frames including CRC):

    Model / product class
    Request: 01 03 C7 38 00 02 78 B2
    Response: 01 03 04 00 2D 00 0A EA 3D
    → holding 0xC738 = 0x002D (45), 0xC739 = 0x000A (10)

    Protocol version
    Request: 01 03 C7 68 00 01 38 A2
    Response: 01 03 02 00 DC B9 DD
    → holding 0xC768 = 0x00DC (220)

    Inverter: Anenji GES48120M250-500P (split-phase). Happy to help with a focused
    read-only PR once you suggest how you want those identity anchors expressed
    in the catalog. Also noted on the one-leg grid/mains total fallback — will fix
    that so a total is only published when both legs are present.

  14. groove-max commented on Oct 2, 2026

    @groove-max
    groove-max
    on Oct 2, 2026
    Owner

    Thanks — both responses pass the CRC checks. These give us the model/class/protocol values we were missing, tied to your GES48120M250-500P.

    A focused read-only PR would be welcome. Please base it on current main: the qualified subset already lives in protocol_catalogs/register_schemas/sumry_ges_7530/base.json, so we can reuse it through the existing modbus_catalog driver without adding another Python driver or transport path.

    For the catalog entry, I'd use three exact-match anchors, for example:

    "anchors": [
  {"key": "identity.sumry_ges_model_code", "equals": 45, "cost": 1},
  {"key": "identity.sumry_ges_product_class", "equals": 10, "cost": 1},
  {"key": "identity.sumry_ges_protocol_version", "equals": 220, "cost": 1}
]

    Populate those evidence keys with two normal catalog FC03 read actions: 0xC738, count 2, and 0xC768, count 1. The fields are single unsigned 16-bit words. JSON register addresses are decimal: 51000 and 51048. All three values must match; missing, invalid or different values must not select this entry. Keep 220 as the raw protocol value — we shouldn't infer a dotted version or assume the whole V2.6.3 document applies from that alone.

    Bind the entry to a separate read_only: true surface using the existing schema, with no write profile. For this first PR, let's wire up that qualified subset; we can review the additional split-phase readings separately. Please include your captured responses in the tests, plus cases where each identity value differs, a response is missing, or the CRC is invalid. The current research-only tests will need updating to cover the new binding rather than simply removing their safeguards.

    Thanks also for fixing the one-leg total fallback in your fork.

    One quick check: after installing the latest main and restarting HA, does Collector connection and cloud now open normally?

  15. txau commented on Oct 2, 2026

    @txau
    txau
    on Oct 2, 2026
    Author

    Just to confirm on the quick check: "Collector connection and cloud" is working as intended now, thanks.

    I'll work on the PR according to your instructions.

  16. txau commented on Oct 2, 2026

    @txau
    txau
    on Oct 2, 2026
    Author

    Ready: #55

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    supportHardware support, diagnostics, or Support Archive review

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions