Feature request: Deliver the local API for the Gen3 MAIN 40 — and stop removing local access via forced firmware updates before a replacement exists

[Xieo]

Feature request: Deliver the local API for the Gen3 MAIN 40 — and stop removing local access via forced firmware updates before a replacement exists

TL;DR

Gen3 MAIN 40 owners currently have no working local API of any kind. The old REST endpoints don't exist on Gen3, the official MQTT/Homie API is MAIN 32–only, and the one community integration that worked was disabled by SPAN's own firmware update (7.2.0) before any official replacement shipped. Because firmware auto-updates cannot be declined, SPAN effectively removed a capability from panels owners had already come to rely on — without consent and without an alternative. I'm asking SPAN to (1) commit to a firm date for the MAIN 40 local API, (2) provide an interim local-access path until then, and (3) give owners real control over firmware updates.

---

My panel / context

• Model: SPAN Panel MAIN 40 (Gen3)
• Use case: Local, cloud-independent monitoring and circuit control (e.g., Home Assistant), on my own LAN, on hardware I own.

The facts (timeline)

1. Gen3 dropped the REST API. The endpoints that earlier SPAN integrations depended on return HTTP 502 on Gen3 panels, so every existing REST-based integration is dead on the MAIN 40.
2. The community filled the gap. A local-only, gRPC-based integration (talking to the panel on port 50065, no cloud, no API key) was built and shared, delivering real-time per-circuit power/voltage/current, main-feed aggregates, and breaker status — ~100+ entities on a single panel. It worked entirely on the LAN, exactly the way panel owners want.
3. SPAN then closed that door. Firmware 7.2.0 disabled gRPC access entirely — every gRPC method now returns UNIMPLEMENTED. The community integration stopped working overnight.
4. The official replacement isn't here. The official SPAN API (MQTT/Homie over eBus) launched for MAIN 32 only. MAIN 40 support is described as targeted for the "second half of 2026," an estimate only and not binding on SPAN.

The net result: the local interface was taken away before the promised one was delivered.

---

Why this matters — the core problems

1. A capability was removed from hardware I own, without my consent.
Firmware 7.2.0 didn't just change SPAN's own software — it removed a functioning local interface that owners were actively using. This is a reduction in what the product can do after purchase. On a piece of permanently installed home electrical infrastructure, silently narrowing what the owner can do with it is not a neutral update.

2. Auto-updating firmware makes that removal non-consensual and irreversible.
Owners cannot decline, defer, or roll back firmware. That means SPAN can push a change that disables local access and there is nothing the owner can do about it. "You don't get to choose whether the capability you rely on keeps working" is the definition of lock-in. Combine that with (1) and the update mechanism becomes a tool for removing owner functionality, not just fixing bugs.

3. The timing looks deliberate, and either way the outcome is the same.
Disabling gRPC required an intentional engineering change; it doesn't happen by accident. Whether the motive was security hardening, protocol migration, or steering users toward a future paid/cloud path, the effect is that SPAN removed the only working local interface for Gen3 and left owners with nothing. If the intent really was security, the correct sequence is ship the replacement first, then deprecate — not the reverse.

4. "Coming in H2 2026, non-binding" is not an acceptable substitute for a working interface today.
A deprecation with no committed replacement date isn't a roadmap, it's an open-ended gap. Owners paid for premium hardware in part on the promise of local, cloud-independent integration. Removing the community stopgap while the official one remains an unbound estimate leaves that promise unmet for an entire product generation.

5. Local access is a core reason people buy SPAN.
Cloud dependence is a liability for critical electrical infrastructure — outages, account changes, service sunsets, and privacy all argue for local control. The community's willingness to reverse-engineer the protocol is direct evidence of real, unmet demand. Blocking that demand instead of serving it pushes exactly the customers who care most about the platform toward competitors.

---

What I'm asking for

1. A committed, public date for the MAIN 40 (and other Gen3: MLO 48 / MAIN 16 / MLO 24) local API — MQTT/Homie eBus + REST v2 — not a non-binding "second half of 2026."
2. An interim local-access path until the official API ships, e.g. one of:
   • Re-enable the gRPC interface (or provide a documented, supported version of it) on Gen3, or
   • Release the MAIN 40 official API as an early/opt-in beta the way it was done for MAIN 32.
3. Do not remove local access before a working replacement exists. Deprecation should never precede the replacement it points to.
4. Give owners control over firmware updates — the ability to review, defer, decline, or roll back updates, and clear release notes when an update removes or disables any owner-facing capability.
5. Publish the OpenAPI / protocol contract for Gen3 so the community can build against a stable, supported interface rather than reverse-engineering one you can disable at will.

Bottom line

SPAN blocked the community's working local integration for the Gen3 MAIN 40 via a forced firmware update, and has not delivered the official replacement for that model. That leaves paying owners locked into auto-updating firmware with no local API at all, on hardware marketed on its local, cloud-independent capabilities. Please close this gap with a firm timeline and an interim path — and stop shipping updates that remove owner functionality without consent or an alternative.

[mwilson71]

I only recently had Span panels installed (MAIN 16 and two MLO 48s), but am interested in using the API. Could we get an update on where things stand with launching for the other panels? I see where the MQTT broker seems to be present, but the local API endpoints are missing or disabled and return 502s.

[cecilkootz]

Any updates on availability?