oneM2M-Enabled AI for Resilient Building Systems

Introduction

Modern infrastructure requires intelligent management systems to balance occupant comfort with energy sustainability. We present a Smart Edge AI system that integrates heterogeneous IoT devices within a multi-room building to provide dynamic, AI-driven service management. By leveraging the oneM2M interoperability standard, specifically the Mobius Common Service Entity (CSE), our solution enables seamless device communication, edge intelligence for anomaly detection, and adaptive service allocation. This project demonstrates how standards-based middleware can decouple hardware from application logic, facilitating scalable smart building solutions.

Motivation and the Problem

Modern buildings are equipped with various IoT devices for environmental monitoring and comfort control. However, significant inefficiencies persist due to three primary issues:

• Siloed Operation: Devices often operate in isolation, leading to redundant sensing and an inability to cross-reference data for accuracy
• Reliability Gaps: Critical services may fail unnoticed if sensors malfunction without backup validation
• Energy-Comfort Conflict: Fluctuating energy availability (e.g., from solar sources) makes it difficult to prioritize services dynamically without compromising user comfort.

The core problem is the lack of a unified, interoperable framework that allows devices to "speak" the same language and act intelligently based on holistic building data.

Our Solution

We developed an integrated system utilizing a multi-agent AI architecture supported by the oneM2M standard. The system aggregates data from Air Quality, Weather, and Actuator nodes (ACs, Fans, Lights) into a central Mobius CSE.

The solution features three distinct layers of intelligence:

• Edge Intelligence: Local anomaly detection at the node level.
• Middleware Layer: oneM2M-based data standardization and access control
• AI Management Layer: A multi-agent system that optimizes operations based on Service Level Objectives (SLOs) defined by the user

How it Works

The system architecture is divided into six logical layers, ensuring modularity and scalability

IoT Nodes Layer: This layer consists of physical sensors (AQI, Weather) and actuators (AC, Fans, Lights). These devices continuously sense environmental conditions and execute commands. Some nodes possess edge capabilities to detect sensor faults locally before transmission.

Communication Layer: To support heterogeneous connectivity and ensure performance efficiency, our deployment uses multiple oneM2M-supported protocols based on device characteristics and operational needs. MQTT is used for continuous sensor reporting and event notifications because it is lightweight and optimized for constrained IoT hardware. CoAP is used for device-level control operations, including actuation and configuration updates, as it provides low-latency message exchange with low network overhead. HTTP remains supported for external system integration, dashboards, debugging, and management tooling.

In addition to IoT protocols, BACnet devices (e.g., HVAC systems) are integrated using a Python-based interworking module that converts BACnet messages to oneM2M-compliant resource structures before publishing them to the CSE. This multi-protocol strategy ensures conformance to oneM2M’s interoperability architecture while optimizing bandwidth usage, latency, and system scalability.

Security and Authentication: Device-to-platform communication is secured using TLS/DTLS, depending on the protocol stack (MQTT-TLS and CoAP-DTLS). Authentication and access management are enforced using oneM2M Access Control Policies (ACPs) that define read, write, and execute rights per resource. Communication between the platform and the dashboard uses token-based authentication, and internal API access is encrypted using platform-level confidential keys. This ensures end-to-end secure communication for sensing, decision making, and actuation workflows.

Interoperability Standard Layer (oneM2M): This is the core of our architecture. We deploy Mobius CSE as the middleware hub. This layer normalizes data streams from different protocols, creates a standard resource tree, and enforces Access Control Policies (ACPs) to secure data access.

Application layer: It bridges raw data with actionable insights. It includes a PostgreSQL database for structured storage and a Decision Maker module. The Decision Maker consumes normalized data from the oneM2M layer and interacts with the AI agents to determine the state of actuators.

AI Agents Layer: We implement a multi-agent approach to handle conflicting objectives:

Emergency Response Agent: This agent holds the highest priority and is responsible for all safety protocols. In a crisis (e.g., fire or gas leak), it overrides all other agents to activate emergency lighting, trigger alarms, and manage building-wide safety procedures.

• Security Agent: With a high priority, this agent manages physical security and surveillance. Its tasks include activating perimeter lighting to support cameras, ensuring security devices are powered, and monitoring access control points.
• Occupancy Agent: This agent optimizes building services based on real-time human presence. It prepares rooms for scheduled meetings, adjusts HVAC and lighting based on detected occupancy, and scales down services in empty zones to conserve resources.
• Comfort Agent: This agent's primary goal is to maintain and optimize occupant comfort. It dynamically adjusts temperature, ambient lighting, and air circulation to match user preferences and activities within a given space.
• Environmental Agent: Focused on occupant health, this agent monitors and manages indoor environmental conditions. It tracks air quality (AQI, CO2), humidity, and ventilation, activating air purifiers or adjusting airflow as needed.
• Energy Efficiency Agent: This agent's objective is to minimize energy consumption. It identifies and deactivates non-essential devices, optimizes HVAC schedules, and balances energy-saving goals against the minimum requirements of the Comfort and Environmental agents.
• SLO Management Layer: This layer provides human-in-the-loop governance. Users define Service Level Objectives (e.g., "Maintain Room 3 Temperature at 24°C"), and the system aligns AI actions to meet these constraints.

Features

• Seamless integration of devices from different manufacturers via oneM2M.
• Automated anomaly detection and service migration during sensor failure.
• Services are activated or deactivated based on energy availability (e.g., solar output) and room priority.
• Users can override AI decisions for critical tasks, ensuring the system remains user-centric.

Hardware Setup

Circuit Diagram and Components

• Raspberry Pi 5 — central controller (runs sensor polling, HTTP server/clients, local logic, and cloud communication).
• Prana PM sensor (particulate matter) — serial / TTL interface (measures PM2.5 / PM10).
• Prana CO₂ sensor — CO₂ ppm sensor (likely UART/serial)
• DHT22 — digital temperature & humidity sensor (single-wire digital/data pin).
• 4-Channel Relay Module — switches mains AC loads (fan, lights, AC compressor, and camera power).
• AC Loads — Fan, Lights, AC, Camera, each powered from building AC, switched via relay contacts.
• Power — 5 V (or Pi-compatible) supply for Pi and sensors; separate mains supply for AC loads. Common ground for the DC side.
• Network — Wi-Fi module (or Pi’s onboard Wi-Fi) provides connectivity to oneM2M (HTTP).

Hardware Setup Block Diagram

• CO₂, PM, and DHT22 sensors send real-time environmental data to the Raspberry Pi 5 inside an IP65 box.
• The Raspberry Pi processes the data and sends it to the oneM2M cloud using HTTP POST.
• The cloud can issue control commands back through subscriptions.
• The Raspberry Pi receives these commands and operates a 4-channel relay module.
• The relay controls key appliances such as the fan, Lights, AC, and Camera
• The system provides environment monitoring + remote automation using oneM2M.

Microcontroller System Architecture for IoT Nodes

This diagram illustrates how a microcontroller manages sensor data and controls devices.

• The Input block reads sensor values through analog/digital interfaces.
• The Communication module connects to the network using the Wi-Fi module.
• An internal HTTP Server handles incoming requests and parses commands.
• The Security module manages hashing, encryption, and secure data handling.
• Based on the received data or commands, the Action Control unit determines the next course of action.
• The output block sends control signals to the Relay Control, which operates external devices.

Software Setup

The system's software is designed as a modular, three-tier architecture to ensure scalability and interoperability. The backend application, developed in Python, contains the core business logic, including the implementation of the multi-agent AI system (Sustainability, Performance, and Hybrid) and hosts the HTTP REST APIs. For data persistence, a PostgreSQL database stores the initial state of rooms and sensors, user-defined Service Level Objectives (SLOs), and a historical log of all AI-driven decisions. The frontend is a single-page web application built using a modern JavaScript runtime. This component functions as the primary "human-in-the-loop" interface, calling the backend APIs to render real-time visualizations of the building's status and allowing users to monitor agent decisions or override system objectives.

A key design choice is the complete decoupling of this application logic from the physical hardware. The backend does not communicate directly with IoT devices. Instead, it interacts exclusively with the Mobius oneM2M CSE (Common Service Entity), which serves as the central interoperability middleware. The backend subscribes to specific data containers within the oneM2M resource tree. When an IoT node publishes new data to Mobius, the middleware automatically notifies the backend application. This event-driven architecture allows the AI agents to react to new data in real-time, eliminating the need for constant device polling and ensuring the system is fully interoperable.

To ensure reliability during the live demonstration and aid reproducibility, the system includes several key features. The repository contains db_init.sql and seed_db.py scripts to pre-populate the database with a predictable environment, such as room layouts and sensor configurations. Furthermore, the system is designed for robustness with an offline fallback logic. While AI agents can be configured with API keys for cloud-based LLMs, they are engineered with deterministic, rule-based logic to fall back on if an external API is unavailable. This ensures the core demo remains fully functional under any network conditions.

oneM2M Usage

To ensure maximum interoperability and security, we utilized advanced features of the oneM2M standard:

• Our system uses oneM2M FlexContainers instead of simple containers to represent complex appliances such as AC units, light controls, and air-quality sensors. FlexContainers allow us to model full device capabilities (such as target temperature, current value, min/max range, state, and unit), while also storing operational data and health parameters in a single structured model. This creates a standardized semantic interface across the entire system, ensuring that any agent or service can understand device behavior without needing custom logic. As a result, the building ecosystem becomes fully interoperable, consistent, and machine-readable.

• To enable real-time intelligence, our system uses oneM2M’s subscription and notification mechanism instead of continuously polling data. Each AI agent subscribes to relevant sensor FlexContainers, and whenever the sensor updates its values—such as temperature, humidity, or CO₂ levels—Mobius automatically pushes the new data to the Decision Maker. This event-driven architecture eliminates the need for constant polling, significantly reduces network load, and ensures immediate responsiveness to environmental changes. This is what enables intelligent, energy-efficient control decisions.
• Each hardware node operates a dedicated Application Entity (AE), and device functionality is structured using multiple FlexContainers under that AE. For example, the HVAC system exposes one AE, but includes FlexContainers such as temperature control, power state, and airflow settings. Multiple IoT nodes participate in the system, but each node maintains one AE hosting multiple capabilities, ensuring modularity and reuse of standard oneM2M semantics.

• Security in the system is enforced using fine-grained oneM2M Access Control Policies (ACPs). We assign precise permissions to each AI agent based on its role: the Sustainability Agent has read-only access to energy meters and limited write access to non-critical actuators, while the Comfort Agent can control AC and fan settings but cannot modify critical or administrative resources. The admin user maintains full access to all resources. This strict, role-based permission model follows the principle of least privilege, ensuring that every agent operates only within its intended scope and making the entire system secure by design.

Resource Configuration Parameters

• Max Instances: Each FlexContainer is configured with a maxNrOfInstances value of 50 to retain recent history while preventing storage overflow
• Expiration Time: Sensor data containers use an expiration value of 1 year to ensure the data is stored, and this data will be overwritten as the data increases, as the maximum number of instances is configured.
• oneM2M SDT Usage: Where applicable, TS-0023 Smart Device Template (SDT) models were referenced to ensure semantic consistency, particularly for environmental sensing models (CO₂, temperature, humidity) and HVAC control.

Control Flow Overview

• Sensor reads environmental metrics and updates its FlexContainer in the MN-CS
• Through subscriptions, the IN-CSE notifies the AI Decision Maker when a new data instance is created.
• The AI layer evaluates current SLOs and environmental conditions.
• If required, actuation commands are generated and written back to the respective AE resources.
• The device receives the command and updates relay outputs or BACnet-controlled actuators.

This cycle creates a closed loop: Sensor → CSE → AI → CSE → Actuator.

Interworking Functionality

BACnet-enabled HVAC systems do not natively support oneM2M formats; therefore, an interworking agent written in Python translates BACnet payloads (e.g., temperature values, fan speeds, system state) into corresponding oneM2M FlexContainer attributes. This enables legacy building automation protocols to participate in the unified interoperability layer.

Dashboard

The dashboard communicates with oneM2M using HTTP REST APIs via subscription pull and on-demand resource queries. Lightweight WebSocket syncing is used to update live building states.

Home Screen: Building Status Summary:

The primary view presents a high-level snapshot of the building’s operational state. It includes:

• Global Satisfaction Index: A composite metric representing how well the system is meeting its defined Service Level Objectives (SLOs). It factors comfort, energy efficiency, environmental safety, and occupancy alignment.
• Active Scenarios and Alerts: Displays current system contexts such as scheduled meetings, detected occupancy, or emergency overrides and highlights anomalies like device failures or missing sensor values.
• AI Decision Feed: A live stream showcasing the actions taken by AI agents across the building (e.g., “AC ON in Room 3, ” “Camera support lighting enabled, ” “Occupancy-based power reduction executed”).

Room-Level Views:

Each room in the building has a dedicated page providing:

• Live IoT Data Panel: Real-time measurements for temperature, humidity, CO₂, occupancy, air quality index, energy usage, noise levels, and other contextual parameters.
• Device State Visualization: A simplified layout showing the status of installed devices such as HVAC units, lights, fans, air purifiers, and cameras. Devices automatically change state based on AI reasoning or SLO policies.
• Decision Trace: A history of actions taken within that room, coupled with the agent responsible for the decision and contextual reasoning. This enables accountability and transparency in autonomous control.

AI Agents Section:

This module displays all available reasoning agents and their operational status. Each agent has a defined role, such as:

• Comfort Agent
• Energy Efficiency Agent
• Occupancy-Aware Agent
• Environmental Health Agent
• Security Agent
• Emergency Response Agent

Users can monitor which agent provided which recommendation and how the system negotiated conflicts e.g., prioritizing emergency response over energy savings.

Service Level Objectives (SLO) Configuration

The SLO management page allows users to express intent, rather than device-level command logic. Rules can be configured globally or per room. Examples include:

• “Security cameras must remain ON at all times.”
• “Prepare Meeting Room 2 fifteen minutes before scheduled use.”
• “Lighting and ventilation must adjust based on occupancy.”

Once configured, SLOs influence the decision-making engine, and agents collaborate to enforce them.

LLM Insights and Reasoning Transparency:

Certain decisions require contextual interpretation or multi-criteria evaluation. LLM integration enables:

• Natural language explanations of why an action was taken
• Semantic analysis of patterns (e.g., “energy usage unusually high for this hour”)
• Recommendation refinement based on user feedback

Analytics and Trends:

Historical data is aggregated to generate patterns and insights, such as:

• Energy consumption trends
• Occupancy flow over time
• Comfort index fluctuations
• Sensor reliability statistics
• Impact of SLO changes on system performance

User and Permission Management:

• The platform supports role-based access control. Admins may assign:
• Building-wide privileges (for full control)
• Operator roles (restricted to specific rooms or actions)
• Viewer roles (read-only monitoring)

Conclusion

Our project successfully demonstrates a resilient and intelligent building management system. By integrating a multi-agent AI framework with a robust interoperability layer, we have shown it is possible to significantly reduce energy consumption and lower carbon footprints without sacrificing occupant comfort. The system's modular architecture not only ensures resilience through its offline fallback logic but also provides a clear path for scalability, from a single building to an entire smart campus. This work moves beyond simple automation, offering a practical blueprint for creating buildings that are smarter, more sustainable, and truly responsive to human needs.