Raspberry Pi as an IoT gateway: broker, radios, storage, power and its limits

Yes. A Raspberry Pi 4 or 5 is a capable gateway for a home, a lab, a greenhouse or a small building: it can run an MQTT broker, Node-RED or Home Assistant, and talk to Zigbee, Bluetooth LE and LoRaWAN devices through plug-in radios. What it lacks is the hardening of an industrial product: its default storage is a microSD card, its power input is a consumer USB-C connector, and nothing about it is designed for a hot cabinet or a remote site you cannot visit.

This guide covers the software stack, the radios you can add, the two hardware choices that decide reliability (storage and power) and the point at which an industrial gateway becomes the better buy.

What does an IoT gateway do?

A gateway sits between devices that cannot or should not reach the internet directly and the systems that use their data. In practice it does four things: it translates between radios and IP (Zigbee or LoRa on one side, Ethernet or Wi-Fi on the other), it buffers data when the uplink is down, it runs local logic so that a light still switches when the cloud is unreachable, and it forms a security boundary, so that only the gateway, not every sensor, talks to the outside world. A gateway that also processes data before forwarding it is an edge gateway, the subject of Edge computing explained.

The Raspberry Pi 5 brings to this job a quad-core Arm Cortex-A76 at 2.4 GHz, 1 to 16 GB of RAM, Gigabit Ethernet, dual-band Wi-Fi, Bluetooth 5.0 and a PCIe 2.0 x1 interface, according to its product page. That is far more than a broker and a few flows need.

What software runs on a Pi gateway?

An MQTT broker. Mosquitto is the usual choice and runs comfortably on any recent Pi. Since version 2.0 it binds only to the loopback interface when no listener is configured and requires authentication on every listener unless anonymous access is explicitly allowed, as its changelog records. A broker that “does not accept connections” after installation is usually doing exactly that. Devices such as the ESP32 nodes in ESP32 with MQTT then publish to it over the local network.

A flow engine. Node-RED wires MQTT topics, HTTP calls, databases and dashboards together without much code. Its Raspberry Pi instructions install it as a service with one script and note that the current Node.js line has no 32-bit builds, so use the 64-bit Raspberry Pi OS.

Home Assistant. For a home or small building, Home Assistant can be the whole gateway, as Home Assistant explained describes. Its Raspberry Pi installation guide supports the Pi 4 and Pi 5 with at least 2 GB of RAM and a 32 GB card. Home Assistant OS takes over the whole device and runs extras such as a Mosquitto broker as add-ons; if you want the Pi to do other things too, run the components as containers on Raspberry Pi OS instead.

Which radios can you add?

Zigbee. A USB coordinator stick turns the Pi into a Zigbee hub, driven by Home Assistant’s ZHA integration or by Zigbee2MQTT, which publishes every device to the broker; ZHA vs Zigbee2MQTT compares the two. Placement matters more than the stick. The Zigbee2MQTT stability guide warns that USB 3 ports, HDMI ports and SSDs nearby can ruin reception, and that a 50 cm USB extension cable is often enough to fix it. Pick a Zigbee channel that does not overlap your Wi-Fi. Zigbee explained covers the network itself.

LoRaWAN. A concentrator HAT based on Semtech’s SX1302, a baseband chip for gateways that detects packets on 8 channels, makes the Pi a full multi-channel LoRaWAN gateway. ChirpStack Gateway OS is one ready-made system for this, with configuration options for the most common concentrator shields. The gateway forwards packets to a network server, which can run on the same Pi for a private network; LoRaWAN explained explains the roles. If the site needs an outdoor or carrier-grade unit instead, the LoRaWAN gateway makers shortlist covers the commercial options.

Bluetooth LE. The Pi’s built-in radio can read BLE sensors directly, which covers many temperature, humidity and presence devices without extra hardware.

Where should the data live: SD card, SSD or NVMe?

A gateway writes constantly: broker persistence, logs, and above all the history database. Home Assistant’s recorder commits to its SQLite database every 5 seconds by default, and its documentation warns that on a Raspberry Pi with an SD card this can affect “life expectancy of the storage medium”. It suggests raising commit_interval to around 30 seconds and excluding entities you do not need to keep.

microSD cards wear out under this kind of load. Three ways to reduce the risk, in increasing order of robustness:

Use an Application Class 2 card, as Home Assistant recommends, and cut writes: longer commit intervals, fewer recorded entities, logs in RAM.
Boot from a USB SSD, which the Pi 4 and later support through their USB mass storage boot mode.
On a Pi 5, add an NVMe drive through the M.2 HAT+, which the Raspberry Pi documentation describes as a bootable option.

Whatever the medium, back up the configuration off the device. A gateway that cannot be rebuilt in an hour is a single point of failure.

How should you power it?

Underpowering causes more strange behavior than any software bug. The Raspberry Pi power supply documentation recommends a 3 A USB-C supply for the Pi 4 and the 27 W supply for the Pi 5. On a Pi 5 the supply also sets the budget for USB devices: with a 5 A supply, downstream USB peripherals get 1.6 A; with any other supply they are limited to 600 mA. An SSD plus a Zigbee stick plus a LoRa HAT can exceed that. Every model since the 2014 Raspberry Pi B+, except the Zero range, detects a supply below 4.63 V and logs a warning, and the same page notes that poor supplies can corrupt storage. Check the kernel log when a gateway reboots without reason.

Power over Ethernet removes the separate adapter. The Pi 5 supports PoE+ (IEEE 802.3at) and the Pi 4 supports PoE (802.3af), both through a HAT. For sites with unreliable mains, a small UPS that signals the Pi to shut down cleanly protects the storage from corruption during power cuts.

When should you use an industrial gateway instead?

A Raspberry Pi is the right gateway when the site is accessible, indoors, and a failure costs inconvenience rather than money. Choose an industrial gateway when one or more of these applies:

Environment. Cabinets that run hot or cold, vibration, condensation or dust call for a fanless enclosure rated for an extended temperature range and DIN-rail mounting.
Power. Industrial sites supply 12 or 24 V DC with spikes; industrial gateways accept wide-range DC input with protection, where the Pi expects a clean 5 V.
Interfaces. Isolated RS-485 for Modbus, digital inputs, a cellular modem with a SIM slot or a second Ethernet port for network segmentation come built in.
Certification and support. Regulated sectors need declared conformity, security updates for a defined period and a vendor who answers.
Fleet operations. Tens or hundreds of remote units need remote management, OTA updates and rollback, which you would otherwise have to build yourself.

There is a middle path. The Compute Module 5 puts the Pi 5’s processor on a module with optional eMMC flash (up to 64 GB) instead of an SD card, and third-party industrial controllers are built on it. Raspberry Pi states that both the Pi 5 and the CM5 will remain in production until at least January 2036, which answers the supply question even for long-lived installations.

Where to go next

ESP32 with MQTT covers the device side of a Pi-based broker.
Edge computing explained explains what to process at the gateway and what to send on.
Zigbee explained and LoRaWAN explained cover the two radios most often added to a Pi.

Topics: Raspberry Pi, gateway, MQTT, Home Assistant, hardware