STM32 SCD4x CO2 Sensor Indoor Air Quality Case Study: MQTT and I2C Integration

Overview

This case study documents a small indoor-climate monitoring slice built around an STM32 B-L475E-IOT01A2, an external SCD4x CO2 sensor, MQTT transport, and Combotto Monitor.

The technical goal was straightforward: take a board that already worked for basic room telemetry, add a CO2 sensor over I2C, preserve a modular firmware structure, and make sure the resulting signal stayed useful once it reached the monitoring layer.

The result is not a generic dashboard demo. It is a compact edge-to-monitor path that can be inspected at the device, transport, and alert layers.

Problem context

Temperature and humidity alone can show that a room is drifting, but they do not explain whether the room is becoming unhealthy under occupancy or whether ventilation response is actually needed. For indoor-climate use cases, CO2 changes that interpretation.

The practical problem behind this work was therefore not just “read another sensor.” It was:

• add CO2 without tangling the device code
• keep the telemetry shape usable outside the board
• surface readings and alerts in a way that helps diagnose real room behavior
• distinguish physical drift from stale sensing or weak thresholds

This is where many room-monitoring prototypes stop being useful. They can produce values, but they do not carry enough context across the full path to support operational decisions.

System under test

The system in scope is intentionally small:

• STM32 B-L475E-IOT01A2 room-health device
• SCD4x CO2 sensor connected over I2C
• room-health readings published to MQTT
• Rust-based IoT Gateway carrying the message path
• Combotto Monitor evaluating room state and CO2 alarms configured through application.conf

The value of keeping the slice this small is that each part stays inspectable. It is possible to reason about the sensor integration, the publish path, and the monitor behavior without hiding behind system complexity.

Current room-state view

The main monitor view shows the current room-health state for one device. That matters because room telemetry is only useful when the latest reading, freshness, and recent trend can be seen together.

In this setup, the room-state panel carries:

• current temperature, humidity, and CO2
• freshness status for the latest sample
• one-hour, 24-hour, and 7-day traces for fast inspection
• a health band that tells the operator whether the room is inside the intended range
• room identity preserved from device to monitor

Image description: The updated room-health view shows one STM32 device reporting fresh temperature, humidity, and CO2 data, with short and long traces available in the same operational panel.

For an engineer, the useful part is not that the card says “Healthy.” The useful part is that one panel combines current values with recent history. That makes it easier to tell whether the room is actually stable, whether CO2 is rising under occupancy, or whether the signal quality itself needs investigation.

This is also where the extra sensor dimension matters. Temperature and humidity trends are still visible, but CO2 gives the system a better indoor-air-quality signal than a temperature-only interpretation.

Alert history and failure modes

The alert history is where the setup becomes easier to debug and tune.

The event list carries several different classes of behavior in one place:

• recovered CO2 high alerts with ppm context
• recovered temperature high warnings with Celsius context
• stale-sensor warnings when the freshness story degrades
• time-stamped event evidence that can support incident review or threshold tuning

Image description: The updated alert history shows that the same room-health path can surface CO2, temperature, and freshness events as explicit monitor evidence instead of leaving the operator to infer them from raw values.

That distinction matters because indoor-climate monitoring usually fails in one of four ways:

• a real CO2 rise under occupancy
• a temperature or humidity trend that supports the diagnosis
• a temporary sensor or publish interruption
• or a monitor rule that needs adjustment

The monitor view helps separate those cases without asking the operator to reconstruct the story from raw logs. That is a practical improvement over simpler demos where values are visible but the operational meaning is still ambiguous.

How the STM32 SCD4x integration was done

The device slice is built around the STM32 B-L475E-IOT01A2. The main firmware change was adding an external SCD4x CO2 sensor on the device side while keeping the integration modular. The module shown here is the SCD41, which sits inside the broader SCD4x sensor family.

Image description: The integrated device photo shows the STM32 B-L475E-IOT01A2 board physically wired to the SCD4x CO2 sensor module. It provides the board-level context behind the room-health readings shown in the monitor screenshots.

At a high level, the integration looks like this:

• the SCD4x module is connected to the STM32 over I2C
• a modular sensor abstraction reads the sensor and normalizes the sample into room-health fields
• the device publish layer reuses that normalized sample when it sends CO2, temperature, and humidity to MQTT
• the downstream gateway and monitor can keep working with the same transport and asset model

That split keeps the responsibilities clear:

• firmware owns sensor access and payload formation
• the gateway owns message transport
• the monitor owns threshold logic and alert presentation

The practical benefit is that the device can evolve from onboard humidity sensing into a fuller indoor-air-quality node without rewriting the rest of the telemetry chain.

Sensor and transport notes

The sensor choice matters here because the room-health story is no longer limited to thermal drift. The SCD4x adds a direct air-quality signal and also contributes temperature and humidity readings that are better aligned with the indoor-climate interpretation this case study is trying to support.

At a system level, the data path stays simple:

• STM32 device firmware reads the SCD4x over I2C
• the room-health payload is published over MQTT
• the Rust gateway carries the message path into Combotto Monitor
• indoor-climate alarm thresholds are defined in application.conf

That means threshold tuning stays in the monitoring layer instead of forcing a firmware edit every time the environment changes. For offices, labs, cabinets, or meeting rooms, that is a more practical operating model than hardcoding every room rule into the board image.

Image description: The SCD4x family sensor module adds CO2 sensing plus temperature and humidity support to the STM32 room-health setup through an I2C-connected, modular device integration.

Alarm handling

CO2 alarm policy is not buried in the firmware. The device publishes measurements upstream, then Combotto Monitor evaluates indoor-climate thresholds from application.conf.

That gives the team room to:

• tune indoor-air-quality thresholds for the room or deployment
• add or adjust alarm messaging without changing the sensor driver
• inspect whether the problem is a real room-health event or a telemetry-quality issue
• use the same signal as a clean input for audit findings and hardening work

This is a cleaner operational split than hardcoding every indoor-climate decision into the device.

Practical takeaways

For readers working on similar systems, the most useful parts of this setup are:

• the board-level sensor integration is simple enough to understand and extend
• the telemetry path is still easy to inspect after the sensor change
• the monitor exposes both current room state and event history
• CO2 adds a more useful signal for indoor-health interpretation than temperature and humidity alone
• configuration-driven alarms make the system easier to adapt across environments

In other words, the work adds value at two levels: it improves the device itself, and it improves how the resulting telemetry can actually be used once it reaches operations.

Where this pattern is useful

This pattern is useful when:

• a team needs a believable STM32 to MQTT to monitor slice before rollout
• room, office, lab, or enclosure telemetry is visible but not decision-ready
• indoor-air-quality alarms exist without enough context to trust them
• sensor integration must stay modular instead of being hard-wired through the full stack
• current dashboards show symptoms, but not enough context to decide whether the next move is threshold tuning, firmware refinement, or deeper path review