DS3 inverter sensors unavailable since APsystems web interface shutdown announcement (ECU otherwise responsive)

[dhevy-hub]

Setup: ECU-C, firmware ECU-C-Z_C1.2.24E, 3× DS3 micro-inverters, integration version 2.14.0 (HACS), installed 2 years ago, previously working fine.
Symptom: The ECU device itself responds normally — Power Limit slider, Query ECU switch, etc. all work fine. But "Inverters" = 0 and "Inverters Online" = 0. All 3 DS3 inverter entities show "Unavailable" (no temperature, voltage, current, frequency, signal). "Current Power" and "Today Energy" also show 0/unavailable.
When it started: Right when APsystems announced the shutdown of the ECU web interface.
Already tried: Rebooted both the ECU-C and Home Assistant — no effect.
Question: This timing strongly suggests it's linked to the security tightening on APsystems' side mentioned in the README. Is the inverter discovery/online-status query a separate protocol call that might be specifically blocked, while the general config/query calls still work? Any workaround in the meantime, or is this expected to only be resolved once the Modbus/SunSpec path is implemented?
Thanks !

[HAEdwin]

My ECU-C with the same setup does not show these signs. Are you able to Enable Debug Logging for the integration and show me part of it? Does the Home Assistant log show any signs of error?

[dhevy-hub]

Good morning. Thank you for this quick response. And sorry, I had people over. here is the requested "Debug Logging" on APsystems. No particular error to report on HA 2026-06-28 12:58:55.877 DEBUG (MainThread) [custom_components.apsystems_ecu_reader.gui_helpers] Parsed data: {'power1': [{'time': 1782597817000, 'powerA': 0, 'powerB': 0, 'powerC': 0}, {'time': 1782598117000, 'powerA': 0, 'powerB': 0, 'powerC': 0}, {'time': 1782598419000, 'powerA': 0, 'powerB': 0, 'powerC': 0}, {'time': 1782598719000, 'powerA': 0, 'powerB': 0, 'powerC': 0}, {'time': 1782599019000, 'powerA': 0, 'powerB': 0, 'powerC': 0}, {'time': 1782599319000, 'powerA': 0, 'powerB': 0, 'powerC': 0}, {'time': 1782599620000, 'powerA': 0, 'powerB': 0, 'powerC': 0}, {'time': 1782599921000, 'powerA': 0, 'powerB': 0, 'powerC': 0}, {'time': 1782600222000, 'powerA': 0, 'powerB': 0, 'powerC': 0}, {'time': 1782600522000, 'powerA': 0, 'powerB': 0, 'powerC': 0}, {'time': 1782600822000, 'powerA': 0, 'powerB': 0, 'powerC': 0}, {'time': 1782601123000, 'powerA': 0, 'powerB': 0, 'powerC': 0}, {'time': 1782601423000, 'powerA': 0, 'powerB': 0, 'powerC': 0}, {'time': 1782601725000, 'powerA': 0, 'powerB': 0, 'powerC': 0}, {'time': 1782602026000, 'powerA': 0, 'powerB': 0, 'powerC': 0}, {'time': 1782602327000, 'powerA': 0, 'powerB': 0, 'powerC': 0}, {'time': 1782602629000, 'powerA': 0, 'powerB': 0, 'powerC': 0}, {'time': 1782602931000, 'powerA': 0, 'powerB': 0, 'powerC': 0}, {'time': 1782603231000, 'powerA': 0, 'powerB': 0, 'powerC': 0}, {'time': 1782603532000, 'powerA': 0, 'powerB': 0, 'powerC': 0}, {'time': 1782603663000, 'powerA': 0, 'powerB': 0, 'powerC': 0}, {'time': 1782603963000, 'powerA': 0, 'powerB': 0, 'powerC': 0}, {'time': 1782604264000, 'powerA': 0, 'powerB': 0, 'powerC': 0}, {'time': 1782604565000, 'powerA': 0, 'powerB': 0, 'powerC': 0}, {'time': 1782604865000, 'powerA': 0, 'powerB': 0, 'powerC': 0}, {'time': 1782605165000, 'powerA': 0, 'powerB': 0, 'powerC': 0}, {'time': 1782605465000, 'powerA': 0, 'powerB': 0, 'powerC': 0}, {'time': 1782605765000, 'powerA': 0, 'powerB': 0, 'powerC': 0}, {'time': 1782606065000, 'powerA': 0, 'powerB': 0, 'powerC': 0}, [...] 2026-06-28 12:58:54.659 DEBUG (MainThread) [custom_components.apsystems_ecu_reader.ecu_api] ECU 192.168.x.xx raw inverter data: 415053313130[...]3230303031000020260628125500454e440a [...] 2026-06-28 12:58:53.872 DEBUG (MainThread) [custom_components.apsystems_ecu_reader.ecu_api] ECU 192.168.x.xx connection established on attempt 1/5 2026-06-28 12:58:54.645 DEBUG (MainThread) [custom_components.apsystems_ecu_reader.ecu_api] ECU 192.168.x.xx connection resources released 2026-06-28 12:58:54.646 DEBUG (MainThread) [custom_components.apsystems_ecu_reader.ecu_api] ECU 192.168.x.xx raw basic data: [...]1333030303132313530303030373134363130310000cc530000000000000000202606281257030000000031303031364543552d432d5a5f43312e322e3234453031[...]70652f506172697380971b0be4f4ac482d13a668303000000000000000000000454e440a I've redacted part of the "raw basic data" hex string (likely contains my ECU serial number) — let me know if you need the full unredacted trame, I can send it privately instead. Thanks

[dhevy-hub]

Good morning.
Did you have time to look at my log ? Do you have a solution ?
Do you have the same configuration as me but not these problems with feedback to 0? (ECU-C + Ds3). So you have the temperature information for your micro inverters for example ?
THANKS 👍😉

note: Could you give me more details on your configuration please? (in private if you want):

• version of your ECU-C,
• region of installation (or even date) [mine is installed in France]
• special handling? (reset, downgrade, etc.)

[HAEdwin]

I've got an ECU-C with same firmware. I don't think the integration is to blame because it only queries the ECU-C and when it receives all zero's. Try to check the ECU-C configuration using the EMA manager app, are all the inverters in sync?

[dhevy-hub]

Good morning.
You think there is a bad communication between my ECU-C and Ema app ??
Yes, my DS3s are visibly synchronized, as evidenced by this capture.
Why these 0 then

? I even turned off my ECU-C for a while before turning it back on, but to no effect. And HA is restarted during major modifications. I even tried this script to check (aps2mqtt), but without successstill no datas

[HAEdwin]

I'm not sure, the above only shows the CT-clambs (and working condition of the inverters) but somehow their data is not showing up. Try to reload the 2150 series integration. And monitor the ECU manager, using the ECU-Cs AP, for correct configuration.

[dhevy-hub]

Are you talking about this data? I cut the capture so as not to send the reference of my ECU-C in public 😉.
"Try reloading the 2150 series integration" < I don't understand, sorry: I'm still a bit "newbie" with all this 😊. do you mean "reinstall my integration" ? (HA)
or reinstall my ECU-C ? (which starts with 2150xxxxxxxxx)
ECU-Cs app ? I can't find it on Google Play (French). I have EMA app & Ema manager
Thank you 😉

[dhevy-hub]

as a reminder:

• ECU-C firmware: C1.2.24E
• HAEdwin integration version: v2.14.0

I also checked the EMA (cloud) app configuration: data reporting there is working perfectly (production, consumption, export/import all consistent - see attached screenshots). This suggests the issue is isolated to local API access on the ECU, not the general ECU-C configuration itself.

If you have any leads related to the 2150 serial prefix, I'd appreciate it.

[dhevy-hub]

Hi HAEdwin,
Tracking the problem "Inverters=0 / Inverters online=0" with ECU Reader on my ECU-C (firmware ECU-C-Z_C1.2.24E, 3x DS3).
Actions taken so far:
Complete reinstallation of integration to rule out possible stale config/cache issue on HA side (uninstalled via HACS, config entry removed, reinstalled fresh) — same result: Inverters: 0, Inverters online: 0.
Regression caused by the reinstallation itself: before the uninstallation I had 3 individual entities per inverter (sensor.xxx_70xxxxxx etc.), stuck at 0 (temperature, power...) because of the bug - but at least present, probably created when the ECU was still responding correctly. After the clean reinstallation, these entities per inverter no longer exist at all: the device displays 22 entities but none are linked to individual DS3s. My guess: the integration creates the inverter entity list from the ECU's response at setup/installation time, and since the ECU currently reports 0 inverters, no per-device entities are created on a new installation.
→ Would a simple reload of the integration (instead of a complete uninstall/reinstall) preserve/recreate these entities once the ECU starts reporting inverters again? Or is a complete reconfiguration necessary one way or the other once the underlying ECU problem is resolved?

Verified via the EMA Manager application (cloud path, not local):
The 3 DS3 inverters are correctly listed and coupled to the ECU (704xxxxx, x3).
The daily production graph (Toroids of Measurements) is complete and coherent: 16.11 kWh produced, normal bell curve, consumption/export/import everything followed correctly.
This confirms that the ECU↔inverter communication and cloud reporting are both perfectly healthyThe problem appears to be isolated specifically to the local query path used by the integration - this is not a DS3 sync issue, nor a PV system fault.
Since you mentioned having the same ECU-C+DS3 setup without this symptom, is there a way to compare specific firmware subversions or configuration settings (query interval, retries, cache count) that may differ between our setups? I'm also happy to test the SunSpec/Modbus TCP path mentioned in discussion #139 if there is an early version to try.
Let me know what logs/diagnostics might help narrow this down.
Thanks !

[HAEdwin]

Hard to tell what the issue is in your situation, you're one of the unlucky ones where the ECU does not respond. In most cases it just works.
Are these switches on?

I would recommend trying the following:

• Remove the integration via HACS (the entities will be removed as well but will return with the same name - do check if all entities are gone after removal)
• Restart Home Assistant.
• Start the installation process again (including restart of Home Assistant)

Check whether all entities are detected now, though I am afraid that won't be the case. An error may have occurred during the firmware OTA update causing this.

[dhevy-hub]

Hi HAEdwin,
Quick update in case it's useful — you may already know this, but wanted to document it clearly.

Like others, I accessed the ECU-C's native local web page directly (http://<ECU_IP>/index.php/realtime, bypassing Home Assistant entirely). The page loads fine and shows the "Real Time Data" table with the expected columns (Inverter ID, Current Power, DC Voltage, Grid Frequency) — but no data rows appear at all, exactly the same symptom as Inverters: 0 in the integration.

This rules out the integration's query protocol (port 8899) as the point of failure — the ECU's own built-in web UI, querying its own internal data store, returns nothing either. So whatever changed, it's affecting the ECU's internal inverter data collection/storage itself, not just the external API surface.

One more data point: the onset roughly coincided with an EMA App update (new UI). Not sure if that's a meaningful correlation (cloud-side change triggering something) or just timing, but flagging it in case it matches other reports you're seeing.
Given this now points pretty clearly at ECU-side firmware/internal state rather than anything network/API related, I'll hold off on further troubleshooting on my end and wait for the Modbus/SunSpec path you're working on with APsystems.

Let me know if there's any diagnostic (logs, ECU export, etc.) that would help in the meantime.

I sent an email to APsystems, waiting for response.

Thanks