kurtcms.org

Thinking. Writing. Philosophising.

Email Github LinkedIn

From Monitoring to Control: Building an Indoor Air Quality Automation Stack with Home Assistant, Matter and SCD41

Posted on May 25, 2026 — 8 Minutes Read

As compute and networking continue their transition away from monolithic and hardware-centric infrastructure towards modular, software-defined and distributed systems, observability and automation are no longer limited to servers, routers and applications alone. Increasingly, the same architectural principles that power scalable cloud-native infrastructure are finding their way into the physical environment itself, where temperature, humidity, air quality, occupancy and energy usage become telemetry streams that may be monitored, automated and acted upon in real time.

What was once constrained to proprietary building automation systems and vertically integrated smart-home platforms may now instead be implemented with commodity hardware, open protocols and containerised applications that are modular, portable and reproducible. Whether it is MQTT acting as a lightweight event bus for distributed sensor nodes, Home Assistant orchestrating automation and visualisation, Matter providing a vendor-neutral interoperability layer, or low-power microcontrollers exposing environmental telemetry over Wi-Fi, the broader direction remains the same: decoupling sensing, transport, processing, decision-making and control into composable layers that may evolve independently over time.

Tapping into the modularity and simplicity of containers and open protocols, what follows is a lightweight indoor air quality monitoring and automation stack built around a Raspberry Pi, Home Assistant, Eclipse Mosquitto, the Home Assistant Matter Server and an Adafruit SCD41 carbon dioxide sensor. The stack is orchestrated with Docker Compose and designed for long-term operational simplicity, low maintenance overhead and extensibility, and is shared on Github for reference and further development.

The Problem

Following the birth of our daughter, concerns around indoor air quality and ventilation motivated a closer examination of the bedroom environment.

Environmental conditions are often assumed rather than measured.

Temperature may be perceived directly, but many other variables that influence comfort, health and building performance remain effectively invisible without instrumentation. Carbon dioxide concentration, humidity, air quality and ventilation effectiveness are all examples of environmental characteristics that are difficult to assess reliably through intuition alone.

This asymmetry between perception and reality mirrors a familiar problem in modern computing. Distributed systems, networks and applications frequently behave differently from what operators expect. As a result, observability emerged as a foundational discipline within software engineering, providing mechanisms to measure, understand and reason about system behaviour through telemetry rather than assumption.

The same principle applies to the physical environment.

To better understand the environment, an Adafruit SCD41 sensor was deployed in the bedroom and measurements were collected over an extended period.

Without instrumentation, the environment appeared entirely normal.

However, once carbon dioxide concentration was measured directly, a different picture emerged. Overnight CO2 concentration regularly exceeded 1,500 ppm and occasionally approached 2,000 ppm despite the partially opened window.

The room did not feel stuffy, nor was there any obvious indication that ventilation was inadequate. Yet the measurements suggested otherwise.

The experience reinforced a broader observation: environmental conditions are often poorly correlated with perception, and meaningful optimisation begins only once measurement becomes available. The question then becomes how such environmental telemetry may be collected, analysed and acted upon in a reliable and extensible manner.

Architecture

The system architecture is intentionally simple.

Adafruit SCD41
        │ I2C
Python Collector
        │ MQTT
Eclipse Mosquitto
Home Assistant
        ├── Recorder
        ├── Historical Graphs
        ├── Notifications
        ├── Automations
        └── Matter
        Matter Devices
        (Fans, HRVs, Air Purifiers,
         Smart Plugs and Switches)

An Adafruit SCD41 sensor connected to a Raspberry Pi collects carbon dioxide concentration, temperature and relative humidity measurements over I2C.

A lightweight Python collector publishes measurements to MQTT through Eclipse Mosquitto. Home Assistant automatically discovers the sensor entities via MQTT Discovery and stores historical measurements through its built-in recorder integration.

The stack intentionally remains lightweight. Home Assistant’s built-in recorder and visualisation capabilities proved sufficient for the problem at hand, eliminating the need for additional telemetry infrastructure while reducing operational complexity and maintenance overhead.

Observability and Automation

Modern infrastructure systems increasingly operate as closed-loop systems.

Metrics are collected, analysed and used to trigger automated actions. Autoscaling, self-healing infrastructure, automated remediation and policy enforcement are all examples of this pattern. Observability is no longer an end in itself; rather, it serves as an input into decision-making systems that continuously adapt infrastructure in response to changing conditions.

In this sense, observability increasingly functions as the foundation upon which automation is built rather than merely a mechanism for visibility.

Conceptually, the pattern is straightforward:

Observe
Store
Decide
Act

The same architectural model may be applied to the physical environment.

Environmental telemetry becomes the observation layer. Historical storage provides context and trend analysis. Automation becomes the decision layer. Matter-compatible devices become actuators capable of modifying the environment in response to measured conditions.

Viewed through this lens, indoor air quality monitoring is not fundamentally different from monitoring a distributed software system. Both involve collecting telemetry, reasoning about system state and executing corrective actions when predefined conditions are met.

Introducing Matter

The addition of the Home Assistant Matter Server fundamentally changed the nature of the project.

Rather than merely observing environmental conditions, Home Assistant may now respond directly to them through Matter-compatible devices.

For example:

  • Enable a ventilation fan when CO2 exceeds 1,000 ppm
  • Activate an air purifier during poor indoor air quality conditions
  • Control smart plugs connected to ventilation equipment
  • Disable ventilation once acceptable conditions have been restored
  • Integrate environmental telemetry into broader home automation workflows

A simple Home Assistant automation may now implement a closed-loop ventilation system:

Measure
Detect
Actuate
Recover

At this point, the system ceases to be merely a monitoring platform and instead becomes a software-defined environmental control system.

From Monitoring to Control

Monitoring alone is often insufficient.

While visibility into indoor air quality provides useful insight into environmental conditions, it does not by itself improve those conditions. By incorporating the Home Assistant Matter Server into the stack, environmental telemetry may be used to drive real-world actions through Matter-compatible devices.

For example, ventilation systems, air purifiers and smart fans may be activated automatically when indoor CO2 concentration exceeds predefined thresholds and subsequently disabled once acceptable conditions have been restored.

In this sense, the stack evolves from a passive monitoring solution into a closed-loop environmental control system.

The distinction is subtle but important.

A monitoring system informs humans of environmental conditions.

A control system actively modifies the environment in response to those conditions.

The latter represents a fundamentally different class of system.

The Role of ESP32 Sensor Nodes

While the Raspberry Pi currently performs both sensing and orchestration duties, the architecture naturally extends toward distributed sensor nodes.

Low-cost ESP32 microcontrollers running ESPHome may be deployed throughout the home:

ESP32 + SCD41 Bedroom
ESP32 + SCD41 Basement
ESP32 + Leak Sensor Utility Room
        │ Wi-Fi
Raspberry Pi
(Home Assistant + Matter)

This approach reduces dependence on long I2C cable runs, allows sensors to be placed where measurements are most meaningful and improves scalability as additional monitoring requirements emerge.

In many ways, the resulting architecture resembles a miniature distributed system.

Sensor nodes become data producers.

MQTT acts as the messaging fabric.

Home Assistant becomes the orchestration layer.

Matter devices become actuators.

Environmental telemetry becomes another form of operational telemetry.

Lessons Learned

Several lessons emerged from building the system.

First, measurement frequently challenges intuition. Environmental conditions that appear acceptable may differ substantially from reality. In this case, a bedroom that appeared well ventilated regularly exceeded 1,500 ppm CO2 overnight despite a partially opened window.

Second, simplicity matters. Home Assistant’s built-in recorder and automation capabilities proved more than sufficient for the problem at hand, eliminating the need for additional databases and visualisation platforms.

Third, observability is most valuable when it serves as an input into decision-making. Metrics, by themselves, rarely improve a system. The ability to act upon those metrics is where meaningful improvements begin to occur.

Fourth, automation often delivers more value than monitoring alone. Visibility is useful, but the ability to respond automatically transforms a monitoring platform into a control system.

Fifth, modern open protocols such as MQTT and Matter make it possible to build sophisticated environmental monitoring and control systems without becoming locked into proprietary ecosystems.

Finally, operational simplicity extends beyond the application stack itself. Remote administration is performed through Tailscale, eliminating the need for port forwarding while providing secure access to Home Assistant and supporting services from outside the home network. As with the rest of the stack, the goal is not merely functionality, but functionality achieved with minimal operational overhead.

Conclusion

Environmental telemetry, once opaque and inaccessible, may now be measured, transported, stored, automated and acted upon using the same modular principles that underpin modern distributed systems.

The addition of Matter extends the stack beyond observability and into control. Sensors become inputs, automation becomes decision logic and physical devices become actuators. The modern home itself increasingly resembles a distributed cyber-physical system where environmental conditions may be continuously monitored and adjusted through software-defined infrastructure.

While the implementation described here focuses on indoor air quality, the broader pattern extends far beyond carbon dioxide monitoring. Water leaks, occupancy, energy usage, temperature regulation, ventilation and security systems may all participate in the same feedback loop.

The same software-defined principles that transformed compute, storage and networking are beginning to extend into the physical environment itself. Environmental conditions become telemetry. Automation becomes policy. Matter devices become actuators. The distinction between information systems and physical systems gradually erodes, giving rise to a new class of infrastructure that is increasingly observable, programmable and autonomous.

What emerges is not simply an air quality monitor, but a small example of how the boundaries between software systems and physical environments continue to converge.