Gateway Publishing

One edge device, many sensors. Bundle readings from a whole cluster of devices into a single message and let the platform fan it back out.

The gateway pattern lets a single publisher — a Raspberry Pi, an ESP32 hub — report data on behalf of many devices at once. The platform unpacks the bundle and treats each nested device as if it had published on its own.

Why publish as a gateway

Not every sensor speaks WiFi and MQTT. BLE tags, I²C and Modbus sensors, serial peripherals, 433 MHz nodes — these reach the internet through an edge device that already has to be there. Rather than have that edge device fake a separate connection per downstream sensor, it collects their readings and sends one message describing all of them.

The gateway payload

Publish to a gateway topic with a payload nested by device. Each nested device carries the same type/graph/field structure it would have used on its own:

topic:   larry/gateway
payload: {
    "gateway": {
        "sensor_01": {
            "numb": {
                "temperature": { "temp": 72.5 }
            }
        },
        "sensor_02": {
            "numb": {
                "temperature": { "temp": 68.1 }
            },
            "status": {
                "battery": "82%"
            }
        }
    }
}

On the dashboard you get device cards for sensor_01 and sensor_02 — not for the gateway device itself. As far as your graphs and twins are concerned, those two sensors published independently.

It skips the aggregator

A gateway payload is forwarded straight to storage and the dashboard rather than going through the per-device aggregation pipeline. That's deliberate: if you're already batching and summarizing at the edge, you don't want the platform to aggregate your aggregates. You send the numbers you want plotted, and those are the numbers that get plotted.

This is the structural cousin of the most compact form in Topic Flexibility — the difference is the extra gateway wrapper that names the devices inside the bundle.

How to send it

A gateway message is just a publish, so any path works. From a connected MQTT client (the natural choice for an always-on Pi), publish the payload above to your gateway topic. From something that only speaks HTTP, POST the same payload through the Ingest API.

For a complete, runnable edge-device example — reading non-MQTT sensors, batching them, and publishing the bundle — see Raspberry Pi Gateway.

When to use it — and when not to

Reach for the gateway pattern when readings genuinely originate on devices that can't talk to the platform themselves, or when one edge box is already the aggregation point for a cluster. Don't reach for it just to save messages from a single device that's perfectly capable of publishing on its own — for that, the compact multi-type payload in Topic Flexibility is simpler and keeps each device as its own publisher.