FYI: alternative SunSpec/Modbus TCP integration

[bolkedebruin]

Hi @HAEdwin,

First — thanks for maintaining this. It's been the de-facto APsystems integration for HA for a long time, and the binary-protocol decode work behind it is real reverse-engineering, not a wrapper around a vendor SDK.

I wanted to flag an alternative path that might be useful for some users — especially multi-microinverter sites, or people who also want the data in Victron Cerbo, Grafana,
Node-RED, etc.

I've published apsystems-sunspec — a small Go binary that runs directly on the ECU. It reads the same /home/database.db, /home/historical_data.db and /tmp/parameters_app.conf files your integration parses, and re-publishes the data as a standards-compliant SunSpec / Modbus TCP register bank. From HA's side you point the cgarwood/homeassistant-sunspec component at it.

A few practical differences vs. polling the ECU's HTTP / TCP-8899 endpoints from HA:

• One Modbus unit ID per microinverter — each shows up as its own HA device (system aggregate at unit 1, microinverters at 2..N+1)
• Per-panel breakdown via SunSpec Multi-MPPT (Model 160) — DS3 → 2 modules, QS1 → 4
• Event bits decoded from the ECU's Event table → standard SunSpec Evt1 alarm flags (Ground Fault, Over Temp, Anti-Island, etc.) plus raw bits in EvtVnd1..3
• Vendor model 64202 for the things SunSpec doesn't standardize (daily/month/year Wh, RSSI, polling cadence)
• Deploys via the ECU's own HTTP endpoint as a tar.bz2; auto-starts on boot via init script
• Optional bundled dropbear SSH in the same package, or skip it
• No effect on the device's ZigBee polling cycle — it just reads the cached state which the main process already writes every 5 min

Not at all meant to replace what you've built — yours is the simpler path for users who just want APsystems data in HA without managing another binary on the ECU. I'm sharing
in case it's a useful pointer for those hitting some of the protocol-quirk edge cases that come up in your issue tracker.

Happy to answer questions or take patches.

Cheers, Bolke

Links:

https://github.com/bolkedebruin/apsystems-sunspec/releases/download/v0.1.1/apsystems-sunspec-v0.1.1-dropbear.tar.bz2
https://github.com/bolkedebruin/apsystems-sunspec/releases/download/v0.1.1/apsystems-sunspec-v0.1.1.tar.bz2

Instructions:
https://github.com/bolkedebruin/apsystems-sunspec/blob/main/README.md

[HAEdwin]

Thank you! and wow - It is funny and coincidental that you bring this up. In fact, during a conversation with APsystems, this is exactly the modbus path we decided upon and APsystems is currently working on. The removal of the web pages was the trigger for this (due to security concerns).
The ECU-R (2160 series) do not have a upload facility AFAIK. Same goes for the ECU-B.
However, a warning is in order for anyone wishing to try this, as it will likely invalidate the warranty conditions I guess. Will firmware updates need to be blocked also?

For testing purposes I will wait for the official firmware update containing the modbus features.
Though I foresee a bright future for owners of APsystems equipment who are looking for easier local control and access to their data.
BTW cgarwood/homeassistant-sunspec must have made the repository private, I get a 404.

[bolkedebruin]

Absolutely on the other hand there are many many more security concerns and they are not all located in the web pages. I could argue that this package is quite a bit more safe 🙃

You can keep using firmware upgrades. They are incremental in nature and i am not in the way of those.

The package can also work on ECU-R. The updating mechanism is slightly different However that mechanism is available on all ECUs

[bolkedebruin]

This is the actual HACS sunspec https://github.com/CJNE/ha-sunspec

[bolkedebruin]

@HAEdwin if APSystems like it I could also explain what I've done. Maybe they'd like to adopt my approach that would make a lot of things easier. I have now implemented all SunSpec elements, including writable ones which puts them in the same space as Enphase / SMA etc. I understand how Grid profiles are applied (they are not writeable through my implementation for obvious reasons). I have reporting on if settings have been applied, are in flight, or have failed.

This all works on ECU-Rs (most likely also non PROs) and will work on ECU-C. As I dont have access to multi phase inverters or an ECU-C I have not implemented the extension available from that hardware.

What is different from your integration or not available:

1. lifetime_maximum_power , out of sunspec scope
2. CT-meter readings (production_ct_a/b/c, grid_ct_a/b/c, consumed_a/b/c) — ECU-C only. APsystems' on-board current-transformer measurements for grid/production/consumption. Maps to SunSpec
   Model 213 (Meter Multi-AC). I dont have that so can't verify
3. 3-phase voltages (Voltage L1/L2/L3) — for YC1000 / QT2 three-phase inverters. We currently emit Model 101 (single-phase) only.
4. ECUPowerLimitNumber — ECU-C "zero export" power limit (writes to set_zero_export / meter/set_meter_display_funcs). Different code path from per-panel set_maxpower. Not implemented; ECU-C only.
5. ZeroExportSwitch — toggles CT-meter-driven zero-export. ECU-C only.
6. Reboot ECU button — administrative; out of SunSpec scope
7. qty_of_online_inverters as a separate ECU-level count — derivable from per-inverter Online flags, but not aggregated in any single register as it is not in the spec.

Deliberately not exposed :

• GFDI clear / IRD reset / quick-boot — operator-recovery actions. Safety-adjacent, no clean SunSpec home.
• Trip thresholds (Models 707/708/709/710 writable) these are regulatory;

[HAEdwin]

@bolkedebruin That sure will be a good thing to do, I'll point them to https://github.com/bolkedebruin/apsystems-sunspec
If you can please add the above info to your readme.md if not already included and, also include the compatibility of the ECU-B (I'd aim for the full range of ECUs except for the ECU-3). 😉

The complete range of ECUs:

• ECU-B
• ECU-R (2160)
• ECU-R (2162)
• ECU-C

Thanks for your work!