eBus / Adapters / Legacy Devices

Legacy Device Adapters

Integrate existing HEI devices into eBus by adapting their proprietary interfaces to the standard eBus/Homie convention.

Overview

Most existing Home Energy Infrastructure (HEI) devices don't natively support eBus. However, many expose some form of API or interface - whether a local REST API, Modbus registers, or even a cloud API. Legacy adapters bridge these interfaces to eBus, making their data and controls available to all eBus riders.

In eBus terminology, devices that don't support eBus are called "pedestrians," while eBus-compatible devices are "riders." A rider that adapts a pedestrian device acts as a proxy, publishing the pedestrian's data to eBus topics.

Key Benefit: Once one rider adapts a pedestrian device, ALL eBus riders benefit. The adapter does the integration work once, and the data becomes available to the entire eBus ecosystem.

Architecture Pattern

flowchart TB
    subgraph legacy["Legacy Devices (Pedestrians)"]
        pw["Tesla Powerwall
REST API"]
        env["Enphase Envoy
REST API"]
        se["SolarEdge Inverter
Modbus TCP"]
    end

    subgraph adapters["eBus Adapter Layer"]
        ta["Tesla Adapter"]
        ea["Enphase Adapter"]
        sa["SolarEdge Adapter"]
    end

    subgraph ebus["eBus Ecosystem"]
        broker[("eBus MQTT Broker
Homie Convention")]
    end

    pw -->|"poll"| ta
    env -->|"poll"| ea
    se -->|"read registers"| sa

    ta -->|"publish"| broker
    ea -->|"publish"| broker
    sa -->|"publish"| broker

Legacy adapters poll or connect to device APIs and publish to eBus MQTT

Adapter Types

REST API Adapters

Many modern devices expose a local REST API for monitoring and control. The adapter periodically polls these endpoints and publishes updates to MQTT topics.

Tesla Powerwall

REST / JSON

Poll the local Gateway API for battery SOC, power flow, and grid status. Publish to Homie topics for ESS devices.

Enphase Envoy

REST / JSON

Read solar production, consumption, and per-panel data from the Envoy local API.

Modbus Adapters

Industrial and solar equipment often uses Modbus RTU (serial) or Modbus TCP for communication. Adapters read registers and translate to MQTT.

SolarEdge Inverter

Modbus TCP

Read SunSpec-compliant registers for AC/DC power, energy totals, and inverter status.

Fronius Inverter

Modbus TCP

Access real-time and historical data from Fronius inverters via Modbus.

Energy Meters

Modbus RTU

Read power, voltage, current, and energy from industrial meters via RS-485.

Cloud API Adapters

Some devices only expose cloud APIs. While not ideal (latency, availability), these can still be adapted to eBus for informational purposes.

Sense Energy Monitor

Cloud API

Access device-level load detection data from Sense's cloud service.

Emporia Vue

Cloud API

Retrieve circuit-level energy data from Emporia's cloud platform.

Implementation Considerations

Polling vs Events

REST APIs require polling, which introduces latency. Poll frequently enough for responsiveness (1-5 seconds for real-time data) but not so often that you overload the device. Once published to MQTT, all subscribers receive updates instantly.

Error Handling

Adapters should handle device unavailability gracefully, updating the Homie $state topic to indicate connection issues and resuming normal operation when the device returns.

Authentication

Many local APIs require authentication. Adapters must securely store credentials and handle token refresh for OAuth-based APIs.

Running Adapters

Adapters need an execution context - somewhere to run the polling/translation code. Options include:

Benefits

Back to Adapters