Polling Overload

Request-Response (REST) style APIs result in constant and frequent polling by each and every API client device.

The Problem

Most HEI device APIs, when they exist at all, are based on a RESTful request-response interaction model. To get data from a device, you must ask for it. If you want to know when data changes, you must keep asking.

This creates a fundamental problem: HEI devices are getting hammered by everyone else asking for the same information!

The Many-to-Many Problem

In a home with multiple HEI devices that need to coordinate, polling creates an explosion of network traffic and CPU load:

flowchart LR
    subgraph devices["HEI Devices"]
        B["Battery"]
        S["Solar"]
        P["Smart Panel"]
        C["EV Charger"]
        H["HEMS"]
    end

    B <-->|"poll"| S
    B <-->|"poll"| P
    B <-->|"poll"| C
    S <-->|"poll"| P
    S <-->|"poll"| C
    P <-->|"poll"| C
    H -->|"poll"| B
    H -->|"poll"| S
    H -->|"poll"| P
    H -->|"poll"| C

REST Polling: Everyone asks everyone for everything.
16+ polling connections, 16+ requests/second - and this is a simple example!

Scaling Problems

With N devices that all want data from each other, you get N×(N-1) polling connections. This scales quadratically:

4 devices: 12 polling connections
6 devices: 30 polling connections
8 devices: 56 polling connections
10 devices: 90 polling connections

Impact on Device Performance

HEI devices are typically embedded systems with limited CPU and memory. Their primary job is controlling power electronics safely and precisely. When they're spending significant resources handling API requests from multiple clients, several problems emerge:

Delayed responses: API latency increases under load
Missed requests: Devices may drop connections or timeout
Reduced reliability: Resources diverted from primary function
Rate limiting: Devices impose request limits, breaking integrations

Wasted Bandwidth and Resources

With polling, the same data is transmitted repeatedly whether it changed or not. A battery's state of charge might only change meaningfully every few minutes, but polling clients receive the same value hundreds of times.

REST Polling (Current)

Client must initiate every request
Data sent whether changed or not
N clients = N requests for same data
Latency = polling interval
Load scales with clients

Publish/Subscribe (eBus)

Device publishes when data changes
Only changed data is transmitted
N clients = 1 publish (broker fans out)
Latency = instant on change
Load independent of client count

Impact on Homeowners

Slow and unreliable device integrations
Devices become unresponsive under load
Integration attempts fail due to rate limiting
Network congestion from constant polling traffic
Higher latency for time-sensitive energy decisions

How eBus Solves This

eBus uses Publish/Subscribe First with MQTT. Each device publishes its status and state to MQTT topics only when values change. The MQTT broker efficiently distributes updates to all subscribers.

With 5 devices and a HEMS, instead of 20+ polling connections, you have 6 connections to the broker. Each device publishes once, and all interested parties receive the update instantly.

flowchart LR
    subgraph devices["HEI Devices"]
        B["Battery"]
        S["Solar"]
        P["Smart Panel"]
        C["EV Charger"]
        H["HEMS"]
    end

    subgraph broker["MQTT Broker"]
        MB[("Broker")]
    end

    B -->|"publish"| MB
    S -->|"publish"| MB
    P -->|"publish"| MB
    C -->|"publish"| MB
    MB <-->|"subscribe"| H
    MB -.->|"fan out"| B
    MB -.->|"fan out"| S
    MB -.->|"fan out"| P
    MB -.->|"fan out"| C

    style MB fill:#ecfdf5,stroke:#10b981,stroke-width:2px

Pub/Sub: Each device publishes once, broker fans out to all subscribers.
5 broker connections, updates only when data changes.

Back to Challenges