Skip to main content

span-panel-api-schema-1

The parent/child schema parser for span-panel-api: the multi-device Homie tree published by SPAN firmware r202633+, which reports data-model-version 1.x.

Why this is a separate distribution

span-panel-api is a transport and a dispatcher. It knows how to connect to a panel's MQTT broker, route messages, and choose a parser — but it contains no parsing code. Each wire format ships as its own distribution and registers itself under the span_panel_api.schema_adapters entry-point group, so the bootstrap never imports this package until a panel asks for it by name.

The split matters more here than anywhere else in the workspace: this parser depends on the eBus SDK to turn the tree back into devices, and that dependency is this distribution's alone. A flat-panel install never pulls it in.

Installation

pip install "span-panel-api[schema-1]"

Installing this package is what makes parent/child panels work. span-panel-api on its own will connect and then raise SpanPanelAdapterMissingError naming the adapter it could not find.

A consumer that wants to support panels on either schema installs both adapters, and dispatch happens at runtime, per panel, from the data-model-version the panel reports:

pip install "span-panel-api[schema-0,schema-1]"

What it parses

SchemaOneAdapter maps the device tree onto the same SpanPanelSnapshot the flat adapter produces — circuits, both lugs devices, the BESS, PV and EVSE — plus the surface that only exists under the parent/child model:

  • The MID (SpanPanelSnapshot.mid). The enclosure model puts the grid capability on a Microgrid Interconnect Device rather than on the enclosure, so islanding state, grid state and the grid-forming entity live there.
  • Adopted devices (SpanPanelSnapshot.adopted_devices). A device type this parser models nothing for is reported whole — identity and readings — rather than dropped. The schema is explicitly vendor-extensible, so an unmodelled device is an expected arrival rather than a hypothetical one.
  • Extension properties (SpanPanelSnapshot.extension_properties). A vendor property on a device this parser does model, carried with its value and the snapshot subject it hangs off.

Devices are sorted by declared device type, never by device id. Field metadata comes from each device's own $description rather than from a schema document, because the same capability exposes different properties on different device classes — meter is voltage on the panel, power and energy on a circuit, and both currents on the lugs.

ControllerRoutes is how the eBus SDK reaches the panel without opening its own connection: it is an ebus_sdk.MqttControllerTransport that records Controller's subscriptions instead of making them, so a single wildcard subscription owned by span-panel-api's transport covers the whole tree and each message is routed to whichever SDK callback asked for it.

Conformance

spec_lock.json ships with the package and records what this parser targets: the firmware range, the eBus specification commit its vocabulary was read from, and the version of every capability, device and registry it implements. The capability catalogs it addresses are byte-copied under spec/.

Those copies exist to be checked against, never parsed in production — units and datatypes come from each device's $description, since a catalog is the superset across all hardware rather than a statement about the panel in front of you. The suite asks the consumer's question rather than the publisher's: is every name this adapter reads one the specification defines? A consumer addressing a name that no longer exists does not fail loudly, it goes quiet — the property never arrives, metadata lookup returns None, and an entity disappears.

Reference payloads

A retained-topic capture of a full 40-space parent/child panel, and the replay that turns it back into devices, are fixtures of the repository's test suite at tests/reference_payloads/.

span_panel_api_schema_1.reference_payloads no longer exists. It was package data until 1.1.0 — carried in this wheel because it sat inside the package directory, though no runtime path read it. A consumer that was importing it should vendor the bytes it needs and record the release it took them from, asserting that against importlib.metadata.version("span-panel-api-schema-1") so a moved pin that outruns the copy fails loudly instead of testing against a tree no panel publishes.

Release files for span-panel-api-schema-1 1.1.1

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for span-panel-api-schema-1 1.1.1
File Size Uploaded
span_panel_api_schema_1-1.1.1.tar.gz 100.6 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for span-panel-api-schema-1 1.1.1
File Interpreter ABI Platform
span_panel_api_schema_1-1.1.1-py3-none-any.whl Python 3 none any Details

Total release size: 178.0 kB

Release files / span_panel_api_schema_1-1.1.1.tar.gz

Download URL span_panel_api_schema_1-1.1.1.tar.gz
Size 100.6 kB
Tags Source
SHA-256 checksum
How to use checksums
50dd407f36f8a0cf685274a47db374b85f27a475cfb11ea8e24b2d116450e9cb
BLAKE2b-256 checksum
How to use checksums
b85729f9f593ed3011287c1c539127380d86aa9607f23a72832b755a98bb766b
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Aug 27, 2026.

Transparency log

Release files / span_panel_api_schema_1-1.1.1-py3-none-any.whl

Download URL span_panel_api_schema_1-1.1.1-py3-none-any.whl
Size 77.4 kB
Tags Python 3
SHA-256 checksum
How to use checksums
c1426af72108f5c9d1d54d5fef586e930ef0a53962eb0d658419d8807be2a0fc
BLAKE2b-256 checksum
How to use checksums
d419dee150de07fbc43db599d494a0ba618da22b99da0689f66ed4a14a778010
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Aug 27, 2026.

Transparency log
Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page