Raspberry Pi Gateway

The Pi's job

A Raspberry Pi makes a natural gateway: it has real networking, a real OS, and drivers for buses an ESP32 would struggle with. Point it at your local sensors — BLE, I²C, Modbus, serial — poll them on whatever schedule makes sense, and forward the results upstream as one gateway message per cycle.

Shape of the loop

The implementation is small. In pseudocode, a polling cycle reads every downstream sensor, wraps the results in the gateway envelope, and publishes once:

# 1. read every downstream sensor into the per-device shape
readings = {
    "sensor_01": { "numb": { "temperature": { "temp": read_ble_temp() } } },
    "sensor_02": { "numb": { "temperature": { "temp": read_i2c_temp() } },
                   "status": { "battery": read_battery() } },
}

# 2. wrap them in the gateway envelope
payload = { "gateway": readings }

# 3. publish once, then sleep and repeat
publish("larry/gateway", json.dumps(payload))

The nested shape under each sensor is exactly what that sensor would have sent on its own — type / graphName / fieldName. The gateway wrapper is the only thing that marks this as a bundle.

MQTT or HTTP

An always-on Pi is a good fit for a persistent MQTT connection — connect once with paho-mqtt and publish each cycle. If you'd rather stay stateless, POST the identical payload to the Ingest API instead. Same bundle, same result on the dashboard; pick whichever fits how the Pi already runs.

What you see

The platform unpacks the bundle and renders a device card and graphs for each nested sensor — sensor_01, sensor_02 — never for the Pi itself. The Pi is plumbing; your sensors are the devices.