Using Arduino and Raspberry Pi Together for Smart Home Builds

This post may contain affiliate links. As an Amazon Associate we earn from qualifying purchases. Disclosure.

Arduino and Raspberry Pi solve different problems in a smart home, and the boards work much better together than either alone. Hybrid builds combining Arduino edge sensors with a Pi central brain are the architecture that survives in production. The Arduino is your distributed sensor network -- cheap, low-power, always on. The Pi is the central brain -- running databases, dashboards, voice control, and the automation engine that ties everything together.

I started building hybrid Arduino-plus-Pi setups in 2018 and have refined the architecture across roughly twelve installs since then. The role split below is what survives. Each board handles what it does best; trying to make either do the other's job produces frustration and unreliability.

The Role Split That Actually Works

The fundamental rule: Arduino is the edge, Pi is the centre. Each role has clear properties:

The Arduino edge is cheap (4-15 GBP per board), low-power (often runs from a single USB phone charger), and stays online for years without intervention. Edge devices have narrow responsibilities -- read one or two sensors, report state, accept simple commands. They do not run dashboards, store history, or make decisions.

The Pi centre has the CPU, RAM, and storage to run Home Assistant, Mosquitto MQTT, InfluxDB, Frigate AI, and similar heavyweight services. The Pi makes decisions, stores history, exposes the UI, and handles voice control. The Pi is the brain that thinks while the Arduino edges feel.

The communication path between them is critical. Three options work in 2026: ESPHome native API for direct Arduino-to-Home-Assistant integration, MQTT for general-purpose messaging via Mosquitto, and Zigbee for boards with Zigbee radios via Zigbee2MQTT on the Pi.

A Real Hybrid Architecture I Run

The current architecture in my flat covers 47 device endpoints split as follows:

The centre is a Raspberry Pi 5 with 8 GB RAM, 256 GB NVMe storage via the PCIe HAT, and a Google Coral TPU for camera AI. The Pi runs Home Assistant Operating System with 14 add-ons including Mosquitto, ESPHome, Zigbee2MQTT, Frigate, InfluxDB, and Grafana.

The edge consists of 18 ESP32 and ESP8266 boards running ESPHome, plus 12 Zigbee battery sensors (door, motion, temperature) bridged through Zigbee2MQTT, plus 17 commercial smart devices (Hue lights, Sonos speakers, Aqara cube) bridged through their respective integrations.

The split makes maintenance manageable. Each board does one job; failures are isolated. When the Pi reboots for an update, the edge devices buffer their state. When an edge sensor fails, only that sensor is affected.

When to Use Which Communication Path

The ESPHome native API path is the simplest and what I default to. The Pi runs the ESPHome dashboard add-on; the Arduino board is flashed with an ESPHome YAML config; the device appears in Home Assistant automatically. No broker setup, no message routing, no glue code.

MQTT is the right choice when you need cross-protocol compatibility. Multiple Arduino boards plus a few non-ESPHome devices (Tasmota-flashed smart plugs, custom Python scripts, NodeMCU with custom firmware) all publish to the same Mosquitto broker on the Pi. The broker is a generic bus that anything can read or write to.

Zigbee is the right choice for battery-powered sensors. ESPHome and MQTT work over WiFi; WiFi is a power-hungry protocol that drains batteries quickly. Zigbee uses 100x less power per transmission, so a CR2032 coin cell can run a Zigbee sensor for 1-3 years versus 1-3 weeks for a WiFi equivalent.

In practice my setup uses all three protocols simultaneously. Wired ESPHome devices for sensors I can mains-power. Zigbee for battery sensors. MQTT for legacy devices not yet migrated to ESPHome. The Pi handles all three protocols transparently.

Choosing the Right Arduino Board for Each Role

Three Arduino-class boards cover roughly 95% of smart home use cases. Each one wins for a specific role:

ESP8266 D1 Mini is the cheapest option (about 4 GBP) for projects needing only WiFi. Use it for stationary sensors near a power source -- bedroom temperature, kitchen humidity, soil moisture. Limitations: single-core, limited RAM (80 KB), no Bluetooth.

ESP32 DevKit is the workhorse (about 6 GBP) with WiFi plus Bluetooth, dual-core, and 320 KB RAM. Use it for anything needing Bluetooth (BLE beacon proxy, Govee thermometer relay), anything needing more processing (mmWave radar processing, multi-sensor I2C buses), or anything you want to future-proof.

Arduino UNO R4 WiFi is the learning-friendly board (about 20 GBP) with native USB and an integrated WiFi module. The 5V tolerance makes it easier for beginners working with older sensors. Slower than ESP32 and uses more power, but the documentation and tutorial ecosystem is unmatched.

For battery-powered sensors at the edge, prefer the ESP32 platform reference and deep-sleep YAML configs in ESPHome. Battery life with proper deep sleep stretches from days to months.

A Concrete Multi-Sensor Build

The most useful hybrid project I have built is an air quality monitor combining an ESP32 board, three sensors (CO2 + VOC + PM2.5), and an e-ink display, reporting back to the Pi central. The architecture:

The ESP32 reads three I2C-connected sensors every 30 seconds and updates the e-ink display locally. The same readings stream to Home Assistant via the ESPHome native API every minute. Home Assistant stores the data in InfluxDB for long-term trend analysis.

A Home Assistant automation fires notifications when CO2 crosses 1000 ppm (open a window) or PM2.5 crosses 25 ug/m3 (close one). The notifications use the multi-channel approach -- push notification first, voice announcement second if no acknowledgement within 60 seconds.

Total cost: about 110 GBP for the ESP32 plus sensors plus display plus enclosure. The equivalent commercial product is the Awair Element at 250 GBP. The DIY version produces more data, exposes it openly, and integrates directly with the rest of the smart home.

Why the Pi Should Not Run Sensor Loops Directly

A tempting shortcut for new builders is to attach sensors directly to the Raspberry Pi GPIO pins and skip the Arduino entirely. This works for one or two sensors but breaks down at scale for three reasons:

The first is physical placement. The Pi sits in one room (usually next to the router). Most useful sensors need to be in different rooms. Long GPIO wire runs are unreliable and ugly. WiFi-connected Arduino edges go anywhere with mains power.

The second is reboot resilience. The Pi reboots for OS updates and configuration changes. While the Pi is rebooting, GPIO-attached sensors stop reporting. ESP32 edges keep recording locally and buffer until the Pi comes back online.

The third is single-point failure risk. If the Pi crashes with sensors hard-wired to its GPIO, you lose everything at once. With Arduino edges on a broker bus, a Pi crash means the dashboard is offline but sensors keep publishing. The recovery is faster and the failure surface is smaller.

The hybrid pattern is more work to set up but much more reliable in production. Stick to it from project one rather than learning the lesson by losing data.

The Pi's Other Critical Job: Backups

A smart home with months of automation history, dashboard customisation, and tuned templates has real value. Losing that to a corrupted SD card is unnecessary because the Raspberry Pi 5 specifications support proper backup paths.

Three backup layers I run on every install:

Home Assistant automated snapshots via the official Backup add-on. Daily full snapshots at 4 AM, retained 7 days. Stored to a local NAS via the Google Drive Backup add-on (with the obvious destination swap to a self-hosted NAS for privacy-conscious setups).

InfluxDB exports nightly to the same NAS for long-term sensor data preservation. The HA snapshot captures the live database but not the long-term retention bucket; InfluxDB export captures the full history.

Config-as-code in a Git repository. The HA configuration directory is a git repo synced to GitHub (private) every change. Means any configuration mistake is one git revert away from recovery.

The Arduino edges do not need backup. The firmware is reproducible from the ESPHome YAML configs which live in the Pi's HA config directory, which is in the git repo. Reflash an edge and it is back to known-good state within 30 seconds.

Common Mistakes in Hybrid Architectures

Five errors I have made or seen in other people's hybrid setups:

The first is running everything in production from day one. Build the architecture in a test environment, validate, then migrate. A test Pi sitting next to the production Pi during migration saves the entire household from "the smart home doesn't work" headaches.

The second is mixing protocols within a single room. Sticking to one protocol per zone (WiFi for the bedroom edges, Zigbee for the bedside contact sensors, ESPHome native for the AC controller) keeps debugging tractable.

The third is undersizing the Pi. A Pi 5 4 GB might be 20 GBP cheaper than 8 GB, but the difference between running smoothly versus thrashing on swap files is the difference between maintenance hours per month.

The fourth is treating the Pi as a single device. Modern installs benefit from a primary Pi plus a secondary Pi Zero 2 W as Bluetooth proxy and sensor satellite. The total cost is around 100 GBP versus 85 GBP for a single Pi, and the resilience improvement is meaningful.

The fifth is forgetting time synchronisation. NTP must work on every Arduino edge for timestamps to align with the Pi's clock. Network time drift causes confusing automation behaviour months later -- "the motion sensor fires before the door sensor that triggered it". Set up NTP in every ESPHome config and the timestamps stay correct.

Buy-In and Build Order for First-Time Builders

For someone starting today with no smart home hardware:

• Pi 5 8 GB plus enclosure plus SD card plus PSU as the foundation
• One ESP8266 D1 Mini plus DHT22 as the first custom edge
• Mosquitto and ESPHome add-ons installed and tested first weekend
• One extra ESP device per fortnight thereafter to build coverage

Buy the Pi 5 8 GB plus enclosure plus SD card plus PSU first. Install Home Assistant OS. Spend a weekend exploring the UI and adding any commercial smart devices you already own. Total cost: about 120 GBP, total time: one weekend.

Add one ESP8266 D1 Mini and a DHT22 sensor for the first custom project. Flash with ESPHome, deploy in a living area, observe behaviour for a week. Total addition: 12 GBP plus 2 hours.

Scale up gradually. One additional ESP-based device per fortnight, alternating between sensor types so you build broad coverage rather than depth in one category. After three months the install has roughly 8 ESP devices and a working Pi central. That is more than enough to live with comfortably.

The hybrid architecture rewards patience. Each addition validates against the previous ones. Each protocol gets tested independently. The result is a smart home that works because every layer was proven before the next was stacked on top.