Home / Docs / What EEBUS is

What EEBUS is

EEBUS explained from the ground up: the actors, the four-layer stack of SHIP and SPINE, and why §14a EnWG made the grid use cases certifiable in 2026.

EEBUS is the open standard by which appliances in a building — a heat pump, a wallbox, a battery, a photovoltaic inverter — talk to an energy manager, and by which that energy manager talks to the distribution grid operator. It is maintained by the EEBus Initiative e.V., and it is the interface a growing amount of European energy regulation now assumes exists.

Why it became mandatory reading

Two German rules did most of the work.

§14a EnWG obliges the operator of a congested low-voltage grid to be able to reduce the draw of a controllable consumption device — a heat pump, a wallbox, a storage heater — rather than disconnect the street. Since 2024 every new such device must accept a limit, and the fallback is not a suggestion: 4.2 kW is the floor an installation must keep available.

§9 EEG is the mirror image on the production side: a photovoltaic plant must be able to have its feed-in curtailed.

A limit means nothing without evidence that it was honoured, so the acknowledgement an appliance sends back is a regulatory artefact, not a protocol nicety. That single fact shapes more of this crate's API than any other.

Since July 2026 four use cases are formally certifiable: limitation of power consumption and production, and monitoring of power consumption and of the grid connection point. Certification means a laboratory runs a published test suite against your device.

The actors

EEBUS describes participants by the role they play, not by what they are:

Role	Who plays it	What it does
Controllable System	heat pump, wallbox, battery	accepts limits and reports what it did
Energy Guard	grid operator's control box, or an energy manager acting for one	sends limits, and is answerable for them
Monitoring Appliance	energy manager, display, gateway	reads measurements and their meaning
Monitored Unit	anything with a meter	publishes measurements

A single physical box is usually several roles at once: a home energy manager is an Energy Guard toward the heat pump and a Controllable System toward the grid operator.

The layers

EEBUS is not one protocol but a stack of four documents, and this crate implements the whole of it.

flowchart TB
  uc["<b>Use cases</b> — what the device is <i>for</i><br><small>LPC · LPP · MPC · MGCP · e-mobility · inverters and batteries</small>"]
  spine["<b>SPINE</b> — what the device <i>says</i><br><small>device model · discovery · bindings · subscriptions · partial reads and writes</small>"]
  ship["<b>SHIP</b> — how the bytes <i>travel</i><br><small>mDNS-SD · TLS 1.2 · WebSocket · five-phase handshake · trust by SKI</small>"]
  tcp["<b>Transport</b><br><small>TCP/IP over the building's LAN</small>"]

  uc --- spine --- ship --- tcp

  classDef layer fill:#e6f5ef,stroke:#0b8f63,color:#101620,text-align:left;
  classDef base fill:transparent,stroke:#7b8595,color:#55606f;
  class uc,spine,ship layer
  class tcp base

SHIP — Smart Home IP — is the transport. It finds peers with mDNS-SD, connects over TLS 1.2 with mutual authentication, upgrades to a WebSocket, and runs a five-phase handshake that establishes trust and agrees on a message format. Identity is the certificate: a peer is its Subject Key Identifier, a 20-byte hash of its public key. There are no usernames and no central authority.

SPINE — Smart Premises Interoperable Neutral-message Exchange — is everything above that. It defines an information model (devices contain entities, entities contain features, features hold functions) and a protocol for reading, writing, subscribing to and discovering that model.

Use cases are the application layer: named bundles of scenarios that say which features a device must have and which messages it must exchange to claim it plays a role.

The vocabulary you will keep meeting

SKI — Subject Key Identifier. Twenty bytes, hex-encoded, taken from a node's certificate. It is the node's name and the whole basis of trust: two devices are paired when each has recorded the other's SKI.

Feature address — where in the model a thing lives: device / entity / feature. Written as d:_i:46925_HeatPump-1 with an entity path like [1] and a feature id.

Function — a named piece of data on a feature, such as loadControlLimitListData. What you actually read, write and subscribe to.

Binding vs subscription — a binding grants the right to write; a subscription asks to be notified. LPC requires both, in that order.

Scenario — one numbered exchange within a use case. LPC has four: the limit, the failsafe values, the heartbeat, and the constraints.

Prior art

EEBUS has implementations in several languages, and this crate was written after reading them.

Project	Language	What it is
`enbility/ship-go`, `spine-go`, `eebus-go`	Go	The de-facto reference, used by evcc and by several vendors.
`openmuc/jEEBus`	Java	An XSD-generated model with fluent builders — the generated-model idea is the one worth copying.
`NIBEGroup/openeebus`	C	The grid four, one remote connection at a time: the constrained-device niche.
`ULudo/eebus-sdk`	Python	An async SDK and CLI for LPC/LPP and smart-meter-gateway interoperability testing, with JSONL trace fixtures.
`DerAndereAndi/eebus-rust`	Rust	An early experiment — the client handshake only.
`enbility/devices`	data	Captured discovery responses from real devices.

Where this crate fits

It differs less in what it covers — the whole stack, both sides of every use case — than in how it is built: a protocol core with no sockets and no clock, a model generated from the specifications' own XML Schemas, and a test suite that carries the certification's test identifiers. Where it reaches a different answer from the reference implementations, the sentence of the specification driving the difference is named under Conformance.

What it does not set out to do is worth reading before you commit to it: Scope and non-goals.