How Does AirObserver Use W5500 and PoE to Build a Reliable Indoor Air Quality Sensor Node?

Overview

AirObserver is a PoE-powered indoor air quality sensor node project developed by Tuomo Björk.

The project aims to create a reliable, low-maintenance, compact, and quick-to-deploy sensor node for indoor air quality monitoring.

The core idea is to use a single RJ45 connector for both power and data transmission. By using Power over Ethernet and WIZnet W5500, the sensor node can be integrated into existing network infrastructure while providing stable wired connectivity.

The project focuses on monitoring indoor air quality values such as CO2, volatile compounds, particulate matter, and other environmental indicators.

The selected hardware direction includes:

• nRF5340 as the main MCU
• WIZnet W5500 for wired Ethernet
• Power over Ethernet for power delivery
• USB-C as a backup and development interface
• Sensirion SCD41 for CO2 sensing
• Bosch Sensortec BME690 for volatile compound sensing
• Bosch Sensortec BMV080 for particulate matter sensing
• Optional flexible interface for a carbon monoxide sensor module
• eInk display for local information output
• Zephyr RTOS as the firmware platform
• Home Assistant as the primary backend target

This makes AirObserver a strong example of a PoE-powered environmental sensor node where W5500 provides the wired Ethernet foundation.

What Problem Does AirObserver Solve?

Indoor air quality directly affects comfort, productivity, concentration, and health.

CO2 levels are especially important because poor ventilation can reduce cognitive performance and energy levels. Since people spend a large amount of time indoors, it is important to understand whether rooms are properly ventilated and supplied with fresh air.

AirObserver is designed to solve this problem by creating a distributed indoor air quality monitoring node.

The goal is not just to measure a single value. The goal is to provide a reliable air quality profile that can support data-driven environmental optimization.

A system like this can help answer questions such as:

• Is the room properly ventilated?
• Are CO2 levels too high?
• Is air quality changing during occupancy?
• Are volatile compounds present?
• Is particulate matter increasing?
• Can ventilation be improved while reducing energy waste?
• Can air quality data be integrated into existing smart building systems?

By collecting indoor air quality data over the network, AirObserver can help improve air quality where and when it matters.

How Is the System Structured?

AirObserver is designed as a network-connected sensor node.

The system combines air quality sensors, a microcontroller, Ethernet communication, PoE power delivery, and backend integration.

The basic structure can be described as follows:

Indoor Air
        |
        | CO2 / VOC / Particulate Measurement
        |
AirObserver Sensor Node
        |
        | nRF5340 Main MCU
        |
WIZnet W5500 Ethernet
        |
        | RJ45
        | Power over Ethernet
        |
Existing Network Infrastructure
        |
Home Assistant / Custom Backend / Monitoring System

The sensor node measures indoor environmental conditions.

The nRF5340 handles the main embedded application.

The W5500 provides wired Ethernet communication.

PoE allows the device to receive power and network connectivity through the same RJ45 cable.

This architecture makes the device suitable for wide indoor deployment because it can be installed wherever Ethernet cabling is available.

What Does W5500 Add to AirObserver?

The W5500 provides the Ethernet interface for AirObserver.

In this project, wired Ethernet is selected as the main networking approach because the sensor node is intended to be reliable, low-maintenance, and easy to integrate into existing infrastructure.

Reliable Wired Connectivity

Indoor air quality nodes are expected to operate continuously.

For fixed installations, wired Ethernet is often more reliable than Wi-Fi because it avoids wireless coverage problems, interference, and reconnection issues.

W5500 gives AirObserver a stable wired network interface.

Zephyr RTOS Driver Support

The project specifically selected W5500 partly because of its driver support in Zephyr RTOS.

This is important because firmware development becomes easier when the Ethernet controller is already supported by the selected RTOS.

With Zephyr support, developers can focus more on sensor integration, data handling, backend communication, and device behavior instead of writing a low-level Ethernet driver from scratch.

Accessible Development Path

The project also considered the availability of breakout boards and application designs.

W5500 has accessible development hardware, including breakout boards, which makes early prototyping easier.

This helps reduce development risk during the early design stage.

Practical Embedded Ethernet Choice

Although some newer Ethernet options may offer different power characteristics, W5500 was selected because its overall balance was good for the project.

The important factors were reliable driver support, availability, existing application designs, favourable package format, and accessible breakout hardware.

This makes W5500 a practical Ethernet choice for a compact PoE-powered sensor node.

Why Is PoE Important?

PoE is one of the key design choices in AirObserver.

The project aims to use a single RJ45 connector for both power and data.

This provides several practical advantages.

Single-Cable Deployment

With PoE, the device only needs one cable.

That cable provides both Ethernet communication and power.

This simplifies installation and reduces wiring complexity.

Better Fit for Building Infrastructure

Many offices, classrooms, labs, and commercial buildings already have Ethernet infrastructure.

A PoE-powered sensor node can be added to the existing network more easily than a device that requires separate power wiring.

Reliable Long-Term Operation

Indoor air quality monitoring should run continuously.

PoE allows the device to receive stable power from a central PoE switch or injector.

This makes it easier to manage multiple sensor nodes across a building.

Cleaner Installation

A PoE sensor node can be installed on a wall, ceiling, desk, or equipment area without a separate power adapter.

This is useful for distributed sensing systems that need wide coverage.

Why Was nRF5340 Selected?

The project selected nRF5340 as the MCU.

The nRF5340 is suitable because it supports Zephyr RTOS and provides the required hardware features for the project.

The project also notes that it uses an ARM architecture, which was familiar to the group members.

The nRF5340 is also a recommended pairing for Nordic’s nRF7002 Wi-Fi module, which leaves room for future wireless networking options.

In AirObserver, the nRF5340 can handle:

• Sensor communication
• Ethernet communication through W5500
• Zephyr RTOS application logic
• Local interface control
• Backend communication
• Device status handling
• Future wireless expansion possibilities

This makes it a practical controller choice for a modern environmental sensor node.

What Sensors Are Used?

AirObserver is designed to build a more complete indoor air quality profile.

Instead of measuring only one value, the project considers several air quality categories.

CO2 Sensor

CO2 is treated as the most important value in the air quality profile.

The selected CO2 sensor is Sensirion SCD41.

CO2 monitoring is useful because it gives a practical indication of ventilation quality and room occupancy impact.

Volatile Compound Sensor

For volatile compounds, the project selected Bosch Sensortec BME690.

This sensor category helps provide a broader view of air freshness and indoor air composition.

Particulate Matter Sensor

Fine particulate matter is another important factor in air quality.

The project selected Bosch Sensortec BMV080 for particulate sensing.

Particulate matter can include dust, pollen, and particles generated by burning reactions or other indoor activities.

Carbon Monoxide Consideration

Carbon monoxide sensing was considered as an additional possible function.

The project notes that CO sensors can be more complex because they may have a limited lifespan and may need to be replaceable.

The idea was to add a flexible interface for a CO module with options such as I2C, UART, ADC, and ground connections.

This makes the design more adaptable while acknowledging the practical and regulatory concerns around CO sensing.

How Does the Device Connect to a Backend?

The project targets Home Assistant as the primary backend solution.

Home Assistant is a practical target because it is widely used for smart home and building monitoring applications.

The device is also expected to support pushing air quality metrics to an arbitrary URL.

This gives the system flexibility.

Possible backend paths include:

• Home Assistant integration
• Custom HTTP endpoint
• Local monitoring server
• Building dashboard
• Environmental data platform
• Automation system

This makes AirObserver useful not only as a standalone sensor node, but also as part of a wider building monitoring system.

What Local Interface Does the Sensor Node Include?

The project also considers a local user interface.

The local interface includes buttons, LEDs, and an eInk display.

Buttons can be used for navigating the interface and resetting the device.

LEDs can indicate power status, network status, CO2 level, and general air quality level.

The eInk display provides a local information output. This is useful because users can check the device or room condition without opening a dashboard.

The selected display is based on SSD1680 and was chosen because Zephyr-ready drivers were available and the display module had convenient mounting holes for prototyping.

How Does Zephyr RTOS Fit Into the Project?

AirObserver is built around Zephyr RTOS.

Zephyr is useful in this project because it supports embedded networking, sensor integration, driver-based hardware abstraction, and structured firmware development.

The selection of W5500 was influenced by Zephyr driver support.

The selection of the eInk display was also influenced by available Zephyr drivers.

This shows that the project is not only a hardware design, but also a firmware-driven embedded system where RTOS support strongly affects component selection.

How Was Development Organized?

The project uses development kits to divide work between developers.

The kits were prepared with MCUs, peripherals, breadboards, jumpers, and buttons so that each developer could work on a specific firmware task.

The development kits included:

• nRF52840 XIAO with eInk display over SPI
• nRF52840 Dongle with SCD41 and BME690 over I2C
• nRF52840 Dongle with W5500 over SPI and SCD41 over I2C

This development approach helps test each subsystem before combining everything into the final sensor node.

The project repository is organized into categories for electronics, firmware, mechanical design, and software.

This structure makes the project easier to manage as a complete product-style development effort.

System Architecture

The complete system can be divided into several layers.

Sensor Layer
---------------------------------
Sensirion SCD41 for CO2
Bosch BME690 for volatile compounds
Bosch BMV080 for particulate matter
Optional CO sensor module interface

Control Layer
---------------------------------
nRF5340 main MCU
Zephyr RTOS
Sensor data processing
Local interface control

Network Layer
---------------------------------
WIZnet W5500 Ethernet
RJ45 connector
Power over Ethernet
USB-C backup and development interface

Backend Layer
---------------------------------
Home Assistant
Custom URL endpoint
Environmental dashboard
Building monitoring system

This layered structure shows how AirObserver combines sensing, control, networking, and backend integration.

The sensors collect the air quality profile.

The MCU processes data and manages firmware behavior.

The W5500 provides wired network connectivity.

PoE powers the device through the same infrastructure used for data.

The backend receives air quality information for monitoring and automation.

What Applications Can Use This Design?

AirObserver can be used in many indoor environmental monitoring applications.

Possible applications include:

• Office air quality monitoring
• Classroom ventilation monitoring
• Meeting room CO2 monitoring
• Laboratory air quality monitoring
• Smart building sensing
• Home Assistant environmental monitoring
• Facility management systems
• HVAC optimization
• Occupancy-related air quality analysis
• Indoor environmental data logging
• PoE-powered sensor networks

The same design approach can also be adapted for other PoE-powered environmental sensor nodes.

Why Is This a Good W5500 Use Case?

AirObserver is a good W5500 use case because Ethernet is not added as an extra feature.

Ethernet is central to the deployment model.

The project wants a sensor node that is reliable, low-maintenance, compact, quick to deploy, and able to use a single RJ45 connector for both power and data.

W5500 helps the project achieve that goal by providing a practical Ethernet interface with Zephyr RTOS support.

In this design, W5500 helps the system:

• Use wired Ethernet for reliable indoor deployment
• Integrate with existing network infrastructure
• Support PoE-based installation
• Work with Zephyr RTOS
• Reduce Ethernet development risk
• Provide a practical path from prototype to custom PCB
• Enable backend integration with Home Assistant or custom endpoints

This makes W5500 an important part of the AirObserver architecture.

Conclusion

AirObserver is a PoE-powered indoor air quality sensor node designed for reliable and low-maintenance environmental monitoring.

The project combines nRF5340, WIZnet W5500, PoE, Zephyr RTOS, Home Assistant integration, and multiple air quality sensors to create a compact network-connected sensing platform.

W5500 provides the wired Ethernet interface, while PoE allows power and data to share a single RJ45 connection.

The selected sensors provide a broader indoor air quality profile, including CO2, volatile compounds, particulat