LW IT Solutions
« Blog Overview /Smart Home / ESPHome and ESP32 in Practice: Building Cloud-Free...
This post in other languages:

ESPHome and ESP32 in Practice: Building Cloud-Free Environmental Sensors

Part 2 of 5 in the series Home Assistant without the cloud

ESPHome and ESP32 in Practice: Building Cloud-Free Environmental Sensors
Contents
  1. ESPHome and ESP32 in Practice: Building Cloud-Free Environmental Sensors
  2. 1. Hardware Architecture and I2C Bus Design
  3. 2. Firmware Implementation via ESPHome YAML
  4. 3. Local VLAN Isolation and Native Home Assistant API
  5. Summary
  6. Sources

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).
Wiring sketch: ESP32 connected over I2C to an SCD40 sensor, whose three readings go to Home Assistant over an encrypted local link
The whole device is two wires and a config file. What it measures goes straight into the local instance over an encrypted link — nothing takes a detour past a manufacturer.

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.

Home Assistant without the cloud

  1. Zigbee2MQTT vs. ZHA: Building a Highly Reliable Mesh Network in Home Assistant
  2. ESPHome and ESP32 in Practice: Building Cloud-Free Environmental Sensors
  3. Presence Detection 2.0: mmWave Radars (LD2410/LD2450) in Lighting Automation
  4. WireGuard & Tailscale DMZ: Secure External Access to Home Assistant and Self-Hosted Servers
  5. Local Energy Management: Integrating PV Inverters and Battery Storage via Modbus TCP
Lukas Wojcik

Lukas Wojcik

Systems architect and technology enthusiast specializing in scalable tracking solutions, GMP Stack (GA4 & GTM), and robust backend architectures. Advocate for clean code and privacy-first design.

Get in Touch

Briefly describe your project or inquiry for a tailored response. This site is protected by reCAPTCHA.

2 comments

  1. Josefine Aalto

    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.

    1. Lukas Wojcik Author

      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.

Write a comment

The email address is not published. Required fields are marked with an asterisk.

ALL ARTICLES & CATEGORIES

CCTV

Follow this category by RSS

Cloud & AI

Follow this category by RSS

Data Privacy

All 11 articles in this category Follow this category by RSS

Digital Analytics

All 44 articles in this category Follow this category by RSS

Digital Marketing

All 25 articles in this category Follow this category by RSS

IT & Networks

All 15 articles in this category Follow this category by RSS

Raspberry PI

Follow this category by RSS

Smart Home

All 11 articles in this category Follow this category by RSS

Web Development

Follow this category by RSS

WordPress Plugins & Tricks

Follow this category by RSS