ESPHome and ESP32 in Practice: Building Cloud-Free Environmental Sensors
Part 2 of 5 in the series Home Assistant without the cloud

Contents
ESPHome and ESP32 in Practice: Building Cloud-Free Environmental Sensors
Commercially available indoor air quality monitors frequently rely on proprietary cloud ecosystems, introducing latency, security vulnerabilities, and dependency on external servers. Designing custom environmental sensors using ESP32 microcontrollers and ESPHome enables complete local autonomy, sub-second telemetry, and direct integration into Home Assistant. Combining true Non-Dispersive Infrared (NDIR) CO2 sensors like the Sensirion SCD40 or SCD30 with Volatile Organic Compound (VOC) and precision temperature/humidity modules delivers laboratory-grade environmental monitoring entirely confined within an isolated local VLAN.
1. Hardware Architecture and I2C Bus Design
Precision indoor air monitoring requires selecting sensors that measure physical gas concentrations rather than relying on mathematical approximations from cheap heated-metal oxide alternatives. Connecting multiple sensors over a shared I2C bus requires correct pull-up resistor sizing and strict voltage regulation:
- Sensirion SCD40 / SCD30 (CO2): Operating on the NDIR photoacoustic or optical measurement principle, these modules measure true carbon dioxide concentrations between 400 ppm and 5000 ppm with high accuracy and low drift.
- VOC & Thermohygrometer Modules: Integrating secondary sensors such as the Bosch BME680 or Sensirion SGP40 alongside an SHT40 allows measuring Volatile Organic Compound indices and temperature-compensated relative humidity on the same 3.3 V I2C data lines (SDA/SCL).
2. Firmware Implementation via ESPHome YAML
ESPHome compiles clean, highly optimized C++ firmware from structured YAML configuration files. Implementing automatic calibration routines—such as Automatic Self-Calibration (ASC) for NDIR sensors—ensures long-term baseline stability without manual intervention.
# Example: ESPHome configuration for an ESP32 with SCD40 CO2 and environmental sensing
esphome:
name: "env-monitor-office"
platform: ESP32
board: esp32dev
wifi:
ssid: "IoT_VLAN_20"
password: "StrongVLANPasswordHere"
api:
encryption:
key: "32CharacterBase64EncodedKey====="
i2c:
sda: GPIO21
scl: GPIO22
scan: true
frequency: 100kHz
sensor:
- platform: scd4x
co2:
name: "Office CO2"
accuracy_decimals: 0
temperature:
name: "Office Temperature"
accuracy_decimals: 1
humidity:
name: "Office Humidity"
accuracy_decimals: 1
update_interval: 30s
automatic_self_calibration: true
3. Local VLAN Isolation and Native Home Assistant API
For maximum network security, DIY ESP32 sensors should reside within a dedicated IoT Virtual Local Area Network (VLAN) without outbound internet routing permissions. Communication with Home Assistant is handled over the local native ESPHome API (TCP port 6053), which uses Noise Protocol encryption. This architecture prevents external data exfiltration while delivering instantaneous sensor state updates for HVAC automation, mechanical ventilation control, and window-opening notifications.
Summary
Building custom environmental monitors using ESP32 microcontrollers, Sensirion SCD40 NDIR sensors, and ESPHome eliminates cloud dependencies and proprietary data silos. Deploying these sensors within an isolated local VLAN and connecting them via the encrypted native Home Assistant API ensures laboratory-grade telemetry, maximum privacy, and absolute operational reliability.
Sources
Home Assistant without the cloud
- Zigbee2MQTT vs. ZHA: Building a Highly Reliable Mesh Network in Home Assistant
- ESPHome and ESP32 in Practice: Building Cloud-Free Environmental Sensors
- Presence Detection 2.0: mmWave Radars (LD2410/LD2450) in Lighting Automation
- WireGuard & Tailscale DMZ: Secure External Access to Home Assistant and Self-Hosted Servers
- Local Energy Management: Integrating PV Inverters and Battery Storage via Modbus TCP
2 comments
Choosing a genuine infrared sensor over the calculated substitutes is the advice that saves the most disappointment — the cheap modules produce beautiful graphs of something else.
A question about the isolated network at the end: with outbound traffic blocked, how do these devices get firmware updates? Ours are on a VLAN with no route to the internet at all.
From inside the network, which is one of the quieter advantages of this setup: the firmware is compiled locally and served over the air from the same machine that runs the automation. Nothing needs the internet at build time or at flash time — the toolchain does, once, when it downloads the framework, and that happens on the machine doing the compiling rather than on the device.
What the firewall does have to allow is the path from the automation host to the device on the update port, and back. A rule that blocks the sensor VLAN from initiating connections is fine; a rule that also blocks the automation host from reaching into it leaves the devices unreachable for updates and, incidentally, for the encrypted API as well.
Two things worth setting before the first device goes on the wall rather than after: the update password, which is not enabled by default in every configuration, and a stable hostname per device. Retrieving a device that has changed its address and has no working name resolution means a cable and a laptop, which is exactly the situation the wireless update path was meant to avoid.