SPAN API beta officially released.

[sargonas]

As some folks involved in this project may be aware, SPAN has reached out to several of us last week in preparation to announce a new API exactly for our needs rolling out today. Initially the API is only for SPAN 32 via firmware r202603, purely for a logistics reason in that its a minor update to the SPAN 32 software stack on top of what is already there. They have, however, already made a direct commitment to us to add it for all other SPAN panels on the newer stack, by the end of the year (most likely at some points doing H2 2026).

Full details can be found on their blog post here: https://www.span.io/blog/introducing-span-api-and-span-home-on-premise-public-beta

And full API info is here: https://github.com/spanio/SPAN-API-Client-Docs

In short: this means current issues with SPAN 4X support will be resolveable as time goes on, and access to this local api is added to those devices... and a better, well documented and official access is now available for the original 32 devices via firmware r202603 which is in the process of rolling out now, and will be generally available to all by end of month!

However this does mean that all previous undocumented, unsupported SPAN Panel MAIN 32 APIs and local access that we have been relying on up until this point will be deprecated as of December 31, 2026 at the end of year firmware release, so we need to ensure folks are migrated over to the new system by then.

(Along side all of this, it's interesting to note they have also added Span On Premise, a locally run web UI on all devices for home users as well)

[cayossarian]

Also nice to see them address access to SPAN drive, etc which folks were after.

[cayossarian]

Lots of interest in this new API, need to decide how these other efforts overlap. (https://github.com/electrification-bus/span-netbox-importer)

[dcj]

I wrote span-netbox-importer for my own use, IDK how many other folks manage their home networking & computing infrastructure using NetBox, but just-in-case there are any, I shared it...

There is no (or very little) overlap between that and Home Assistant, AFAICT.
My current work to implement a HASS integration using SPAN API is mentioned in a subsequent post.

[dcj]

SPAN API adopts and implements the Electrification Bus (eBus) framework for Home Energy Infrastructure Device integrations.

Electrification Bus GitHub org provides eBus developer resources, python-sdk may be of interest/help.

@sargonas writes:

However this does mean that all previous undocumented, unsupported SPAN Panel MAIN 32 APIs and local access that we have been relying on up until this point will be deprecated as of December 31, 2026 at the end of year firmware release, so we need to ensure folks are migrated over to the new system by then.

I am actively working on a new HASS integration based on eBus and SPAN API, and hope to publish that ASAP, I decided to take a greenfield approach, and IDK if that will end up being good or not-so-good, we shall see. My integration is currently functional, but seems to have a serious memory leak, which I am attempting to debug, even as I write this post.

[dcj]

Announcing an early alpha release of span-hass, a Home Assistant integration for SPAN smart electrical panels, using SPAN API.

Also announcing hass-atlas a command-line tool for auditing and configuring Home Assistant energy dashboards, area assignments, and device topology. Designed as a companion to span-hass (the span_ebus HA integration for SPAN smart panels), but works with other energy integrations — Tesla Powerwall, Enphase, SolarEdge, and more.

[cayossarian]

Well @dcj you've been busy! Currently this repo is the default HAC's SPAN repo and there is an organization that supports it. Essentially we would have done what you have done so we can take this either one of a few ways generally guided by what is good for the community.

Most user's are not going to want to part with their historical data so alignment of the sensor unique keys, entity id's would be necessary to make that a reality. Unique keys, are of course unique so history is tied to those keys.

Aside from that there are some minor outstanding features that others have, over the years, asked for like syncing panel names, etc that would need to be added to any implementation.

My suggestion is to provide a migration and it would seem the best way to do that is to work as a single team with some structure so there is no churn. If you're amenable we could move the repo into this organization and give you admin rights and work so users do not face disruption.

Once we have something suitable and meet the HA requirements move it into core if that seems like something that is appealing. I can tell you from first hand experience that is not without its own headaches but it's an option. You're tied to their processes, oversight, release schedules, etc.

What do you think?

[dcj]

Most user's are not going to want to part with their historical data so alignment of the sensor unique keys, entity id's would be necessary to make that a reality. Unique keys, are of course unique so history is tied to those keys.

This is an important (critical) requirement/constraint that I didn't consider in my new integration, because I haven't been running SpanPanel/span, years ago I wrote an external daemon that polled the "legacy" (now v1) API, published/bridged to MQTT, and then I configred MQTT "things" (IDK the exact/precise HASS terminology) in HASS to pick them up. I could/should have used MQTT Discovery, but I didn't, I had my daemon spiit out the YAML I needed, which I manually added to my HASS configuration.
And then "something broke" and I never got around to fixing it, so it has been 1-2 years since I had any SPAN panel metering data in my HASS, so there is/was no data/history for me to preserve.

I can easily imagine that supporting the same keys/ids is super important.

I'll need to think about that, and explore/investigate/learn more.
Or, most likely, you folks understand this best/completely, and therefore are best suited to designing this transition.
Whatever works!!!
If none of the code Claude & I generated is of any use, so be it, if any of it is useful, then great!

My goal in coding the new integration was to prove to myself that SPAN API was well-suited to this task, and to solve my own need for a new SPAN integration, it is working well for me so far, but it is "early days"....

[cayossarian]

I'm working on an update for the new SPAN API as the firmware is in my 32 panel. This update will put us in good shape for a non-breaking update when the other panels are supported later in the year. The goal is not to break folks existing dashboards and automations lest we hear a deafening roar from the user base.

[sargonas]

FWIW I just got r202603 as well, so I'm free to start hammering at putting it through it's paces when needed on my secondary testing instance.

[dcj]

on my secondary testing instance

Given the potential need for me to better understand how SpanPanel/span works, the keys/ids it generates, I'm thinking I should probably set up another Pi to run HASS, install & configure SpanPanel/span, and poke around.
Does this "just work", or do I need to do anything special to keep a second HASS instance from interfering with my "production" instance? I'll go Internet search for an answer, hoping/guessing this is documented/explained somewhere, but if not, I'd welcome any advice/tips/pointers about how best to do that.

[sargonas]

I've had no issues with "just doing it". I set it up initially as a duplicate LXC container, but eventually moved to the offical Addon that just lets you run a duplicate core on your existing install. The key thing, and what I did, was that I did not mirror my system, I just setup a second fresh vanilla one, and I did not configure or activate any integrations that I did not absolutely need, and it has no automations. The two integrations I dabble with are the only ones enabled, and as a result I've never had any notable conflicts. I do also, just in case, spin it down whenever I am going long stretches of time not needing it and historical data from it wont be of use to me to collect.

…

On Tue, Feb 24, 2026 at 4:36 PM Don Jackson ***@***.***> wrote: on my secondary testing instance Given the potential need for me to better understand how SpanPanel/span <https://github.com/SpanPanel/span> works, the keys/ids it generates, I'm thinking I should probably set up another Pi to run HASS, install & configure SpanPanel/span, and poke around. Does this "just work", or do I need to do anything special to keep a second HASS instance from interfering with my "production" instance? I'll go Internet search for an answer, hoping/guessing this is documented/explained somewhere, but if not, I'd welcome any advice/tips/pointers about how best to do that. — Reply to this email directly, view it on GitHub <#173 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAALDF7N4BYEOEH7EBX4S6D4NTVCRAVCNFSM6AAAAACV5KLQVOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKOJRG4ZDEMA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[cayossarian]

i pushed a branch for the span-panel-api to cover the e-bus API. This package uses a hybrid HA model since a purely push model might challenge any pi hardware and most of the integrations of any size use a hybrid model for this reason. In fact when we were doing the gRPC stuff the team soon figured out that the CPU usage was untenable and went to the hybrid model. I should have a testable span repo within a day or two.

@dcj i will send an org invite. I did some analysis of the feasibility of a clean cutover but it was more work to reimplement all the features and risk to the user base. There is plenty to do at any rate.

[dcj]

@dcj i will send an org invite.

Thank you, and accepted!

I just posted a self-introduction, which seeks to provide context and transparency about my participation here.

I did some analysis of the feasibility of a clean cutover but it was more work to reimplement all the features and risk to the user base.

I am not surprised that a designed transition/migration might be the best approach. As you dig into this, LMK if/how I might be able to assist.

I would very much appreciate learning & understanding what the full set of features and requirements are, but if provding that would be "real work", which is not a current priority, I completely understand and respect that.

[cayossarian]

No extra work, the full set of features that need to be retained will come out in the upgrade plan, which will be in docs/Dev when I push that branch in the next day or so. Right now a lot of this knowledge is just in code or implicit in the README but the upgrade/migration plan will shed a lot of light on how some of this is newly handled in the rework of the coordinator. I would certainly welcome another set of hands and eyes once the initial standing straw man is out.

As with any software the migration path is some of the hardest to get right and downstream we could definitely work to retire some of this technical debt of migration by forcing folks to upgrade in a precise order, e.g. 1.1.x - 1.2.x - 1.3.x. The first step will strip out a lot the prior migration logic. A lot of folks who would not have upgraded will be forced to upgrade once SPAN retires the old API which for our purposes is gold. Gold because we get a forced diet but also get some new features like native solar sensors, SPAN drive, etc.

[Griswoldlabs]

Great to see official API support rolling out for the MAIN 32. This is a big step forward.

For anyone working on the migration or integration updates — happy to help where needed. I built the Gen3 gRPC integration (PR #171) and have been deep in the span-panel-api library, so I'm familiar with both the old and new transport layers.

On the Gen3 side (MAIN 40 / MLO 48), PR #171 is still open for anyone on pre-7.2.0 firmware. For everyone else, we'll be waiting on the H2 2026 official API rollout for those models. If there's anything I can contribute in the meantime, just tag me.