arXiv:2609.17954v1 [cs.DC] 16 Sep 2026
Large Language Model based air quality monitoring and localized alert generation Ricardo VIEIRA a,1 , Luis TAVARES a , Kaylane LIMA a , Lucas DE SOUZA a , Arthur POGGY a , João LIMA a , Vitor PINHEIRO a and Markus ENDLER a a Departamento de Informática, Pontifical Catholic University of Rio de Janeiro, Rio de Janeiro, Brazil Abstract. Poor indoor air quality can cause up to five times more direct health problems to occupants than outdoor air. In particular, it may cause headaches, fatigue, eye/throat irritation, and long-time exposure is linked to respiratory and heart as well as some forms of cancer. Despite the importance of indoor health and well-being, most current monitoring devices and systems (usually for offices and workspaces) are passive. The Environmental Quality Monitor (EnQyMo) platform is a generic Internet of Things (IoT) middleware designed to process several sensor data related to air quality in indoor spaces and correlate this data with health exposure risks of users/workplace employees. Using Bluetooth Low Energy (BLE) beacons and a mobile IoT middleware it is able to identify the (smartphone) users exposed to these polluted air or high CO2 (carbon dioxide) levels, and generate location-specific alarms only to the users at the places with the unhealthy air conditions. At the core of EnQyMo is an agency of Large Language Models (LLMs) capable of interpreting regulatory standards and scientific literature to automatically identify critical health exposure levels. Keywords. Indoor Air Quality , Generative AI, Mobile Internet of Things, Environmental Monitoring, Agentic based workflow.
1. Introduction As large fraction of the urban population spends most of its time indoors, the air quality in these spaces critical determinant of the citizen’s health. Poor Indoor Air Quality (IAQ) may be due to fuel-burning combustion appliances, smoking, building materials and furnishings, such as: deteriorated asbestos insulation, newly installed flooring or carpets, central HVAC systems, humidification devices or excess moisture.2 On the other hand, poor IAQ can cause immediate effects like headaches, fatigue, and eye/throat irritation. Long-term exposure is linked to respiratory diseases, heart disease, and, potentially, some forms of cancer. Very often it also causes the exacerbation of chronic respiratory diseases, such as asthma and 1 Corresponding author. Ricardo Bastos Leta Vieira E-mail: [email protected] 2 United States Environmental Protection iaq/introduction-indoor-air-quality#sources
Agency,
www.epa.gov/indoor-air-quality-
COPD. In spite of importance for health and well-being, most current monitoring solutions remain passive. They provide raw data (e.g., parts per million of CO2 or µg/m3 of particulate matter) without translating these values into actionable health insights for the specific individuals at risk. Currently, there is a significant gap in integrated systems that can simultaneously monitor localized indoor environments and provide real-time, context-aware health interventions [1]. To address this, we propose EnQyMo (Environmental Quality Monitoring), an intelligent system designed to bridge the gap between environmental sensing and personalized health protection. Unlike traditional rule-based systems that rely on static, universal thresholds, EnQyMo utilizes an agentic Large Language Model (LLM) framework for its ability to parse and ”reason” over complex, unstructured scientific literature and medical guidelines. By autonomously retrieving and processing technical documents, the system defines dynamic hazard intervals that correlate specific pollutant levels with their impact on chronic respiratory conditions, effectively acting as a digital health expert. The EnQyMo architecture leverages the ContextNet [2] and Mobile Hub (MHub) [3] middleware to solve the challenge of localized alerting. By identifying the precise group of people within a hazardous zone (e.g., a specific office or machine room) and tracking their exposure duration via BLE beacons used for presence tracking, the system delivers targeted notifications. Furthermore, to address the common IoT challenge of data volatility, the system includes a pre-processing layer that filters sensor noise, ensuring that the LLM-driven inference engine receives reliable data for decision-making. While the long-term vision for EnQyMo includes autonomous environmental control, such as the automated triggering of HVAC systems or filtration units, this paper focuses on the foundational pipeline of sensing, intelligent inference, and targeted notification. We also briefly discuss the privacy-by-design considerations inherent in our middleware choice, ensuring that location data is handled securely to protect user confidentiality. The remainder of this paper is organized as follows: Section II discusses related work in IAQ and well-being. Section III reviews the underlying ContextNet and Mobile Hub technologies. Section IV details the EnQyMo hardware and software architecture. Section V explains the INSPIRE engine and its LLMbased agentic workflow, including the specific scientific sources utilized. Section VI presents early experimental results, and Section VII concludes the paper.
2. Related Work Current studies reinforce the importance of a comprehensive vision that unites thermal comfort, air quality, and occupational health, highlighting how the modularity and scalability of monitoring systems are essential for their adaptation to different built contexts [9]. This ecosystem of research, each addressing specific challenges with specialized tools, constitutes a rich and well-established panorama that serves as an essential starting point for the development of even more comprehensive and results-oriented solutions, such as the EnQyMo platform proposed in this work.
Table 1. Synthesis of related works and their connection with EnQyMo. Aspect
Kanagaratnam et al [4]
Renold et al [5]
Arslan et al [6]
Pan et al [7]
Li et al [8]
Main Focus
Robotic mobile IAQ monitoring
Predictive IAQ modeling
Monitoring indoor environmental conditions
LLMenhanced IAQ with contextual data integration
HVAC fault detection & control
LLM / AI
GPT
Deep Learning (LSTM)
LLaMA and Agentic RAG
DeepSeek
EnQyMo (Proposed)
LLM-based IAQ monitoring and localized alert generation Physics-based Specialized LLM LLM Agents (RAG)
IoT sensors (T/ RH/ HVAC/BMS Building sens. CO2 /PM) telemetry + BIM integration via MCP/API (fault data)
IAQ nodes + BLE beacons + phone hub
Mobile robot (PM/CO2 )
Classroom sensor nodes (IAQ+dust)
Hub Device
Mobile Robot
Fixed Sensor Node
Software Platform
Web Service
Analysis Framework
Mobile Smartphone
Implementation Maturity Level
Partial
Complete
Complete
Complete
Complete
Partial
Localized Alerts
No
Yes
No
Yes
No
Yes
Real-Time Alerts
No
No
No
Yes
No
Yes
IoT Application
The application of Artificial Intelligence to Indoor Air Quality (IAQ) encompasses multiple stages of the analytical value chain. A robotic inspection system [4], for instance, employs Large Language Models (LLMs) to optimize data acquisition, automating the spatial mapping of pollutants. This approach primarily focuses on the automated generation of high-resolution environmental diagnostics. EnQyMo, in contrast, positions its contribution in the subsequent stage of semantic interpretation and contextual action. While the robotic system focuses on solving detection and localization problems by establishing the identity and spatial distribution of contaminants, the EnQyMo architecture advances toward health risk inference. Its machine learning core employs LLM agents to correlate multi-spectral pollutant data, collected through a distributed sensor network, with structured biomedical knowledge. This capability enables the system to transcend mere environmental monitoring, translating real-time measurements into personalized health alerts and targeted interventions for effectively exposed individuals, representing a conceptual evolution from diagnostic systems to proactive health protection systems. This health-oriented specialization conceptually distinguishes EnQyMo from other AI-based platforms, such as ThermalComfortBot [6], which implements a Retrieval-Augmented Generation (RAG) architecture to integrate Building Information Models (BIM), sensor streams, and LLMs with a focus on optimizing thermal comfort. EnQyMo, however, significantly broadens the scope of AI applied to IAQ by transcending the domain of environmental comfort. Its machine learning core is specifically designed to identify correlations between complex multimodal pollutant profiles and respiratory health conditions, such as allergies or chronic diseases. Thus, the system’s LLM agents operate as an advanced environmental diagnostic mechanism, generating not only descriptive reports but also proactive occupational alerts grounded in individual and collective exposure profiles.
Within the scope of AI-enhanced IAQ solutions, conversational interfaces have also emerged as a promising direction to make environmental data more accessible to non-expert users. Pan and Nipu [7] (2025) propose an LLM-enhanced air quality monitoring interface that uses the Model Context Protocol (MCP) to integrate real-time IoT sensor data. The system enables natural-language queries and produces contextualized, accurate responses, significantly reducing model hallucinations [7]. While this approach advances accessibility and interpretability, its primary emphasis remains on the interface layer and on communicating information. EnQyMo extends this concept by employing LLM agents not only for interpretation, but as the core of a proactive health-risk inference system. Whereas Pan and Nipu’s solution optimizes human–machine interaction for environmental queries, EnQyMo leverages a similar AI paradigm (tool-using LLM agents via standardized protocols) toward a distinct objective: correlating multimodal pollutant signals with biomedical knowledge and issuing personalized health alerts and contextualized interventions. This represents an evolution from diagnostic systems to proactive, risk-oriented health protection systems. The pursuit of explainable and physically consistent AI models represents another front of advancement in the field, exemplified by the Physics-Informed Large Language Model (PILLM) framework by Subin Lin and Chuanbo Hua (2025), which embeds HVAC thermodynamic and control-theoretic constraints into LLM-driven rule generation for transparent fault detection [8]. EnQyMo aligns with this principle of prioritizing explainability and domain knowledge integration. However, its ML implementation emphasizes a different end goal: coupling contextualized reasoning (via its hub and orchestration modules) to an occupant-aware monitoring paradigm. In this setting, explainability supports not only diagnosing IAQ degradation and its likely physical drivers, but also justifying selective notification actions—i.e., clarifying why a given alert was issued for a specific person, in a specific zone, at a specific time. Finally, in contrast to purely data-driven models that employ deep learning techniques such as hierarchical clustering and LSTM networks to uncover pollutant patterns and predict their concentrations [5], EnQyMo’s AI architecture introduces an additional layer of semantic reasoning. The system complements the detection of purely statistical patterns with an agentive capacity to interpret such patterns in light of established scientific knowledge. Consequently, the platform not only predicts pollutant concentration trajectories but also proactively assesses the health implications of these conditions. Through its low-cost IoT infrastructure, it autonomously operates to mitigate risks in a targeted and contextually relevant manner. The analysis presented in Table 1 shows that EnQyMo, although still under development, offers a uniquely integrative perspective within the intelligent IAQ monitoring landscape. While existing solutions demonstrate maturity in specific domains such as predictive modeling, conversational interfaces, or anomaly diagnostics, our architectural proposal advances by coherently combining capabilities that remain largely disconnected in the current literature. EnQyMo’s distinction lies in integrating a smartphone-based mobile hub, specialized LLM agents for continuous interpretation of scientific knowledge, and a closed-loop mechanism for generating personalized, actionable alerts. Its goal extends beyond environmental
characterization toward proactive, risk-based health protection centered on the individual. The comparison further indicates a natural trade-off between scope and maturity. Systems with a narrower focus tend to achieve higher operational maturity, whereas broader and more integrated proposals, such as EnQyMo, are at earlier stages of realization.
3. Previous Works and Underlying Technologies 3.1. ContextNet Kafka Core The ContextNet Kafka Core (CKC) [2] comprises four backend middleware microservices, that together support scalable IoT communication, sensing and actuation through mobile edge devices (that we named M-Hubs). These CKC services execute on servers or virtual machines in a cloud, and are: (i) the Gateway, that efficiently handles up to thousands of connections with M-Hubs, (ii) the GroupDefiner, which dynamically creates groups of M-Hubs with some context (e.g. their current location), (iii) the PoA Manager, which tries to balance the load of the other CKC services, and (iv) the Mobile Temporary Disconnect (MTD), which is informed of temporary disconnections of some Mobile Hub withholds edge-bound messages until the Mobile Hub device reconnects with the system.
Figure 1. Diagram of CKC architecture. mobile nodes are represented by the element “MN”
In figure 1, mobile nodes connect to CKC through the Gateway via an MR-UDP connection. The Gateway, which is a Kafka Client, communicates via TCP/IP with one of the Kafka servers (Brokers). The Kafka Brokers make up the Kafka Cluster. The Cluster communicates via TCP/IP with the other CKC microservices: PoA Manager, Group Definer, and Mobile Temporary Disconnect, which are Kafka Clients. The applications (“Application 1” and “Application 2”) developed on the middleware are also Kafka Clients and also communicate with the Cluster via TCP/IP. [2]
3.2. Mobile Hub The Mobile Hub (M-Hub) [3] is a general-purpose middleware service (executed on conventional smartphones) that discovers, registers, and enables remote unicast and group-cast communication with several kinds of peripheral beacons or IoT devices, connecting them to the CKC. Hence, the M-Hubs thus ”bridges the gap” between the Internet connection CKC, and the short-range WPAN connections established with the peripheral IoT devices, which may be very simple wearable devices, sensor devices, smart bulbs, door locks, robots with embedded sensors or actuators, none of them with major processing and storage capacity. 3.3. N8N The physical implementation of the AI Platform for Health utilizes N8N, a workflow automation tool, to orchestrate the data processing pipeline. The implementation is structured into three distinct stages: 1. Data Historization: The first step focuses on recording all data received from the sensors into a historical database. This ensures a persistent record of environmental conditions for future training and auditing. 2. Knowledge Base Construction (RAG): This step involves the vectorization of scientific documents to support the AI agents. By ingesting scientific papers and technical standards, the system builds a vector store that allows the agents to perform Retrieval-Augmented Generation (RAG), facilitating accurate correlations between specific pollutants and health risks. 3. Monitoring and Alerting Loop: The system executes a periodic check (configured at specific intervals) of the sensor measurements. It queries the historical metrics and triggers the AI agents for inference. If an anomaly or risk factor is identified, the workflow generates a structured message to be dispatched to ContextNet, ensuring real-time notification.
4. Platform for Air Quality Monitoring and Alert Generation: an Overview The EnQyMo system was developed in cooperation with 3R Brasil, a local company that develops and commercializes high-fidelity sensors for measuring environmental pollution of any kind. This company was the provider of the Air Quality Sensor Device. 4.1. Air Quality Sensor Device The IAQ sensing device (Figure 2) has an ESP32 micro-controller with integrated Wi-Fi and Bluetooth Low Energy connectivity, plus sensors for temperature, pressure, humidity, VOC, particulates 1, 2.5, 4 and 10 microns, and a CO2 sensor. The devices operate at 5V and can thus be powered by a power bank or by small photovoltaic cells. It uses WiFi to periodically transmit all probed sensor data to the INSPIREservice, but also backups all data to a local SD card.
Figure 2. IAQ device used for monitoring the air quality in the rooms.
4.2. Photovoltaic BLE Beacons We developed custom photovoltaic-powered BLE beacons to enable the indoor localization infrastructure. The primary design objective was to create a reliable, autonomous ESP32-based unit capable of operating under a wide range of indoor lighting conditions without requiring external power sources. The power management system consists of a photovoltaic cell connected to a CN3791 solar charge controller, which feeds a 18650 lithium-ion battery. This configuration ensures continuous operation even in low-light environments by buffering energy in the battery, drawing inspiration from the technical foundations of energy-aware IoT gateways [10], which prioritize balancing data transmission with the strict energy constraints of harvested-energy environments. To maximize autonomy, the ESP32 firmware implements an aggressive duty cycle: the device enters deep sleep (consuming approximately 5mA) for 60 seconds, followed by a 1-second wake period (peaking at 280mA) to transmit BLE advertisements. 4.3. EnQyMo Software The EnQyMo system consists of several re-engineered modules, extensions, and additional services of the original ContextNet middleware - both in the mobile edge and the backend/server/cloud components. Together, all these extensions implement the monitoring and alert notification intelligence and the focused notification of only the users directly affected by the unhealthy environmental conditions. In the remainder of this section, we discuss these enhancements and extensions in detail. 4.3.1. Flutter-ready Mobile-Hub components The original M-Hub implementation was initially developed using native Kotlin code and was aimed at Android-based devices. To facilitate the multi-platform de-
(a) Circuit diagram of the BLE Beacon
(b) Prototype of the photovoltaic BLE Beacon and solar cell Figure 3. Photos and circuit diagram used in the first beacon prototype
ployment of the EnQyMo application across both Android and iOS environments from a single codebase, the native component was successfully encapsulated and migrated into a reusable Flutter Plugin. This architectural shift was crucial for leveraging Flutter’s unified user interface capabilities while preserving the high performance and direct, low-level API access of the native M-Hub core, as well as allowing for an easier future integration with an iOS implementation of M-Hub. The conversion process relied entirely on the Flutter Platform Channel mechanism to facilitate asynchronous communication between the Dart (Flutter) layer and the existing Kotlin code of the mhub components. For discrete function calls from Flutter to native, a standard Method Channel
was established. When the Flutter application needs to control the M-Hub, such as initializing its operation, it invokes a method (e.g., ”startMobileHub”) which is intercepted by the Kotlin onMethodCall callback. Arguments like the ipAddress and port are passed through the channel, enabling the Kotlin layer to immediately configure and initialize the native M-Hubservice with integrated communication protocols such as MrudpWLAN, the BLE-based BleWPAN, and the AsperCEP Complex Event Processing component [11]. This request-response pattern ensures core commands like ”stopMobileHub” and the runtime update of mobile context via ”updateContext” are executed precisely in the native environment. To handle continuous streams of incoming sensor data and M-Hub status updates, multiple Event Channels were implemented (onMessageReceivedChannel, onBleDataReceivedChannel, and onScanningStateChangedChannel) in MobileHubPlugin. A key component, the onMessageReceivedHandler, demonstrates this process: it uses a reactive approach, subscribing to native MobileHubEvent. NewMessage events. As soon as a message is processed by the M-Hub, its payload is immediately forwarded to the Flutter application via the EventChannel.EventSink MobileHubPlugin. This architecture guarantees that real-time sensor data, crucial for the system’s function, is instantly propagated from the low-level native logic up to the high-level Dart application layer. 4.3.2. Symbolic Location Map Instead of relying on geo-coordinates or noise-sensitive indoor-positioning techniques, the platform adopts a symbolic zone-based strategy to ensure predictability, resilience, and minimal calibration overhead. While other modern approaches explore decentralized location-based services and geofences on the blockchain [12] to manage spatial boundaries, our symbolic approach focuses on robustness and operational stability in indoor settings by operating as the abstraction layer that converts the physical BLE-beacon infrastructure into a logical zone-based presence model. Each monitored room contains one or more BLE beacons broadcasting periodic advertisements with their unique identifiers (UUID). The continuously running M-Hub on user’s smartphones makes Bluetooth scans and locally records all the visible beacons and their respective signal strengths. This beacon observation set forms a contextual snapshot representing the perceived neighborhood of the smartphone at every moment. The Group Definer consolidates this snapshot through deterministic symbolicmapping rules: the detected beacon set is matched against the reference table of installed beacons, allowing the system to infer the corresponding room. This inference does not aim for absolute coordinates but rather seeks unambiguous identification of the functional zone. The output is a streamlined, actionable statement: “user present in room X.” By operating exclusively on symbolic names of locations, the system eliminates the need for complex localization models, reduces infrastructure dependencies, and ensures operational stability. Through this mapping process, the Group Definer generates user groups aligned with their real-time locations, enabling the automatic generation of tar-
geted alerts only for workers who are effectively exposed to adverse environmental conditions.
5. Intelligent Scientific Publication Information Retrieval Engine (INSPIRE)
Figure 4. Architecture of INSPIRE within the EnQyMo System
At the heart of EnQyMo is an INtelligent Scientific Publication Information Retrieval Engine (INSPIRE). For each possible condition (i.e. air quality, particulates, gases, high-pitched noise and other harmful sounds, degree of vibration, etc.), the system executes INSPIRE service. To identify harmful intensities/concentration values, INSPIRE utilizes an LLM trained on several scientific articles about the corresponding pollutants and their associated health problems and acute/chronic diseases. Through this learning process, a vector-based model is created that triggers corresponding alarms for users located in those unhealthy environments. This use of LLMs has several advantages: it can be easily adjusted for other environmental elements and can be constantly updated with new scientific findings, thereby improving and refining the analysis of sensory data received from environmental sensors. The Retrieval of Information from Technical Academic Sources (INSPIRE) is the core functional module of the Health Quality Platform. It is composed of several specialized microservices and AI agents that work in tandem to transform raw sensor data into actionable health alerts. (Figure 7) The components are detailed below:
IoT Data Acquire This microservice is responsible for receiving data from various sources. It normalizes the incoming data streams and persists them into a database of past and current sensor readings, ensuring a consistent data format for downstream analysis. IA Agent IoT Data Analyzer This agent analyzes a sample of readings performed by various sensors over a configurable time interval (e.g. 2 minutes). It queries the historical database for all information collected within the configured time interval and identifies if any sensor has obtained samples outside the standard acceptable by health and occupational safety regulations. If a pollutant is found to be outside the acceptable range, the agent generates an alert message for the next AI agent, indicating the sensor, the pollutant, and the criticality level. This message is sent to a microservice that routes it to the appropriate specialized agent. Router Message Alert This component is responsible for routing the pollutant alert messages to AI agents specialized in analyzing specific data types. For example, it directs air quality issues to the Air Quality Agent and noise issues to the Sound Quality Agent. IA Data Analyzer (Persistence and Publication) The generated analysis message is persisted in the database to create a knowledge base for quality monitoring, recording all alerts sent to ContextNet. This historical data is crucial for future root cause analysis of diseases and identifying locations or sensors that generate the most health risk alerts. After persistence, the message is published to the AppModel topic within ContextNet for dissemination to Mobile Hubs. IA Agent for Disease Correlation This is an advanced AI agent capable of correlating which diseases may affect a patient or collaborator exposed to the detected pollutant. This agent utilizes a RAG-based knowledge base of scientific research documents to assist in disease correlation. These documents are previously processed into a vector database to aid the AI in accurately retrieving ”Disease × Pollutant” correlations. The agent’s response is formatted as a JSON message, as shown in the following listing. Figure 7 demonstrates the implementation of the agent architecture using N8N as an orchestrator. The solution is divided into 3 parts: • In the yellow rectangle, we have the module responsible for acquiring data from the sensors that sent it to the published endpoint and then persisting it in a relational database. This persisted data will be used by the main workflow, as seen in the figure, in the blue rectangle. • In the pink rectangle, the module is responsible for receives academic documents, technical standards, or any material that is relevant to be used as a knowledge base for the AI agent for analysis that will be performed in the main flow by the agent for correlating alerts and diseases that may be associated. These documents will be stored in a vector database that will be used by the agent as a RAG. • The blue rectangle is the main flow for disease detection and correlation. In general, the workflow follows these steps:
Figure 5. Architecture of INSPIRE within the EnQyMo System - IOT data archive
Figure 6. Architecture of INSPIRE within the EnQyMo System - Vectoring knowledge Base
Step 1) This flow is scheduled from time to time, retrieving the data sent and persisted by the sensors, as described above. Step 2) A first AI agent searches for received alerts that are above a threshold above normal. To do this, it uses a knowledge base containing the enabled technical standards on what is being measured. In this case, pollutants. If there is an indication of alerts above the permitted level, the agent will generate a JSON message indicating the sensor that generated the alert, which pollutant is above the permitted level, and what level above the permitted level it is at.
Figure 7. Architecture of INSPIRE within the EnQyMo System - IA process
[ { "analisys": { "alert_id": "alert_20250813121755894", "timestamp": "2025-08-13T12:17:55.894-03:00", "sensores": [ { "sensor_id": "IAQ_6227821", "poluentes": [ { "poluente": "pm25", "risk_level": "moderate", "affected_diseases": { "disease": [ "asthma", "bronchitis", "respiratory irritation" ] } }, { "poluente": "pm4", "risk_level": "high", "affected_diseases": { "disease": [ "respiratory irritation", "mild systemic inflammation" ] ...} } ] Figure 8. Example of the json sent as an alert
Step 3) If there are measurements that are above the permitted level, the second AI agent is activated with the responsibility of correlating the pollutant that is above the permitted level with diseases that this exposure can cause to a person. For this, it has two tools that will be used as a knowledge base. These are the vector documents included by the process described above and a database with information collected by research and knowledge of experts on the subject. The agent makes these correlations in two steps, the first being to search for the most assertive data from experts and technical standards. The second analysis, in order to verify and refine the information obtained in the first step, uses the vector documents. After these analyses, the agent will generate a message in JSON format (shown in Figure 8) containing the sensor, the altered pollutant, and the possible associated diseases. Step 4) This message generated by the AI agent is then formatted and sent to the contextNet in order to be directed to patients who are in the sensor’s location and who are at risk of the identified diseases. 6. Early Experiments To validate the feasibility and end-to-end functionality of the EnQyMo system, we conducted a proof-of-concept experiment in the lab NITAS (Núcleo de Inovação em Tecnologias e Aplicações para a Saúde) at PUC-Rio. The experimental setup involved a complete deployment of the hardware and software pipeline described in Section 4, specifically designed to demonstrate environmental monitoring, risk inference, and targeted alert delivery. 6.1. Environmental Data Acquisition The environment was monitored using the IAQ 3R-01 device, positioned on a desk of laboratory to capture air quality data. During the experiment, the device successfully streamed real-time sensor data to the INSPIRE , which was visualized on a dashboard displaying critical metrics. As observed in our tests, the sensors captured Carbon Dioxide (CO2 ) levels at 998 ppm, temperature at 24.3◦ C, relative humidity at 66.1%, and concentrations of particulate matter (PM1.0, PM2.5, PM10). 6.2. Workflow Automation and Health Inference The data processing pipeline was orchestrated using N8N workflows. We simulated a scenario where pollutant levels exceeded safety thresholds. The experiment demonstrated the system’s ability to: 1. Receive sensor data at the node executing the INSPIRE; 2. Analyze the data against configured safety thresholds; 3. Trigger the AI analysis agent to identify associated diseases (e.g., asthma, bronchitis, respiratory irritation); 4. Publish a structured alert message to the Kafka queue.
6.3. Targeted Alert Delivery To verify the Groupcast and presence detection capabilities, three smartphones (Android devices) running the Mobile-Hub application were placed in the same room. The devices detected the Bluetooth Low Energy (BLE) beacons, successfully identifying their presence within the lab room.
(a) Smartphone receiving alert
(b) Smartphone detecting BLE beacons Figure 9. Screenshots of the Mobile Hub application executing the alert and detection logic.
Upon processing the high-pollution event, the system broadcasted a targeted message. All three devices simultaneously received the JSON-formatted alert no-
tification containing the pollutant details (PM2.5), the risk level (”moderate”), and the inferred health risks. This confirmed the correct operation of the ContextNet GroupDefiner and the Mobile-Hub’s ability to act as an edge gateway for alerting users in hazardous environments. [3] 6.4. Solar Beacon Autonomy Finally, we validated the hardware design of the photovoltaic BLE beacons. The prototype, utilizing a CN3791 solar charge controller, an ESP32 microcontroller, and an 18650 battery, successfully transmitted advertising packets used for RSSIbased proximity detection. The varying RSSI values were displayed on the mobile application during the test, confirming that the system can distinguish distance and proximity to specific zones even when powered by harvested energy. 6.5. Experimental Limitations While the results described above confirm the functional viability of the EnQyMo architecture, we acknowledge the limitations inherent in this early proofof-concept. The experiments were conducted in a controlled laboratory setting using simulated pollution events to trigger the alert logic, rather than during longitudinal deployment in a complex, densely occupied building. Consequently, this phase did not fully evaluate long-term challenges such as sensor drift, the impact of physical obstructions on BLE signal stability in varying layouts, or the varying efficiency of the photovoltaic beacons under suboptimal lighting conditions over extended periods. Future validation phases will move beyond the laboratory to a multi-room pilot study, focusing on the system’s scalability, the durability of the energy-harvesting hardware, and the practical utility of the notifications in a real-world workflow.
7. Simulation based experiments 7.1. Simulation Environment and Hardware Setup To accurately assess the scalability and responsiveness of the EnQyMo platform under concurrent load, we conducted a series of stress tests using simulated mobile nodes rather than physical smartphone devices. The simulations were executed on a Lenovo Legion 5i Gen 10 equipped with 32 GB of RAM and an NVIDIA RTX 5070 GPU with 8 GB of VRAM and an Intel Core Ultra 7 255HX. Employing Java-based node emulations, rather than the actual physical mobile devices utilized in early experiments, allowed us to isolate the core performance of the ContextNet gateway and the alert distribution mechanism. This approach removes the unpredictable network anomalies, battery throttling, and wireless interference inherent to physical testing environments, providing a clean baseline for evaluating the computational scalability of the platform.
Figure 10. Architecture of the simulation environment
7.2. Stress Test Methodology and Node Mobility The stress test was driven by a custom Java application (StressTestRunner) designed to launch N autonomous mobile nodes against the ContextNet gateway. To ensure accurate simulation of independent clients and to avoid thunderingherd issues on the gateway, the runner dynamically generated a unique UUID for each node, initializing them with a 100-millisecond stagger. While the simulated nodes are capable of operating in a dynamic mode, autonomously hopping between different Bluetooth Low Energy (BLE) beacons to simulate the mobility of the workforce, the metrics for this evaluation were obtained exclusively using the static mode. In static mode, all simulated nodes were pinned to a specific beacon representing a single physical zone. This methodological choice is crucial for accurate measurement. Node mobility does not significantly change the computational cost of context monitoring (group matching) at the gateway, since the context updates regardless of wether the node has moved or not. However, dynamic hopping introduces fluctuating group sizes, which leads to an unpredictable and constantly varying number of expected Acknowledgments (ACKs) for any given alert. By pinning the nodes statically, we eliminated this uncontrolled variable, guaranteeing exactly N nodes per targeted group to reliably measure the precise distribution latency and system overhead. Figure 10 illustrates the simulation architecture. The simulated mobile nodes continuously send each of their updated contexts to the Group Definer, while another separate simulated mobile node, not in the same group, sends a mocked alert to the Processing Node, simulating the alert from INSPIRE. 7.3. Latency Analysis and Results The primary metric evaluated during the stress tests was the Average Round Trip Time (RTT), measured in milliseconds (ms). The RTT encompasses the time required to dispatch localized alerts from the gateway and receive ACKs back
from the target nodes. The stress test recorded alert distribution events scaling from 5 to 100 concurrent target nodes within a single zone.
Figure 11. Time series graph illustrating the Low, High and Average Round Trip Time (RTT) in milliseconds as the number of concurrent target nodes increases
An analysis of the snapshot data reveals that the system scales efficiently while maintaining extremely low latency. As summarized in Table 2, the system consistently achieved average RTTs well below the 100 ms threshold, even at peak capacities. Table 2. Summary of Alert Distribution Round Trip Times (RTT) in Static Mode Target Nodes (ACKs)
Min RTT (ms)
Max RTT (ms)
Mean RTT (ms)
5 10 25 50 75 100
17.00 18.60 24.12 26.98 33.17 39.48
90.20 45.70 49.40 77.98 61.39 84.51
33.34 29.47 34.38 39.24 42.92 51.18
• Low-Density Alerts (5 to 10 nodes): The platform demonstrated nearinstantaneous dissemination, with mean RTTs hovering around 29 to 33 ms. A single outlier at 90.20 ms for a 5-node distribution was observed, likely due to initial JVM warmup overhead. • Medium-Density Alerts (25 to 50 nodes): As the number of target nodes increased, the average RTT remained highly stable, increasing only marginally to a mean of 39.24 ms for 50 simultaneous ACKs. • High-Density Alerts (75 to 100 nodes): At peak tested capacity, disseminating alerts to 100 distinct nodes yielded a mean RTT of 51.18 ms, with the absolute maximum delay recorded at 84.51 ms.
Table 3. Distribution of RTTs (ms) for Box Plot Analysis Target Nodes
Min
Median
p95
Max
5 10
17.00 18.60
24.00 25.70
69.77 43.77
90.20 45.70
25 50 75 100
24.12 26.98 33.17 39.48
29.74 33.82 39.95 46.44
49.24 62.06 55.13 73.67
49.40 77.98 61.39 84.51
Figure 12. Box plot showing the variance and distribution of RTTs across different target node cluster sizes.
The box plot analysis (Table 3 and Figure 12) provides deeper insight into the distribution and variance of the RTTs. The median response times exhibit a stable, modest increase as the node count scales, rising linearly from 24.00 ms (5 nodes) to 46.44 ms (100 nodes). Furthermore, the 95th percentile (p95) values remain consistently low, demonstrating that the vast majority of alert distributions complete predictably without heavy fluctuations. For example, even at peak tested capacity (100 nodes), 95% of the distribution events complete in under 73.67 ms. While there are occasional maximum spikes, such as the aforementioned 90.20 ms outlier at 5 nodes and 84.51 ms at peak load, this tight clustering underscores the reliability of the gateway’s asynchronous processing and the event-driven architecture of the ContextNet middleware. Overall, the EnQyMo platform demonstrated robust scalability. The results confirm that the underlying architecture is highly capable of supporting near realtime, localized alert generation for large populations within monitored indoor spaces without suffering from network or processing bottlenecks.
8. Conclusion The EnQyMo project successfully demonstrated the integration of low-cost IoT hardware, scalable middleware, and Generative AI to address occupational health challenges. By leveraging the ContextNet architecture and the Mobile-Hub concept, we established a robust pipeline that not only monitors environmental variables but also contextualizes them into actionable health insights. The key contribution of this work lies in the development of a general framework that combines AI agency, LLMs and a scalable IoT middleware to shift from passive monitoring to proactive, occupant-aware alerting for occupational health. Unlike traditional systems that merely log environmental data in a cloud a and display statistics on a dashboard, EnQyMo uses agentic AI to interpret environmental sensor readings taking into account knowledge about health parameters and risks that a LLM obtains from scientific and medical literature. This allows the system to deliver localized warning alerts about specific risks—such as respiratory irritation or asthma triggers—directly to the smartphones of employees exposed to those conditions. Furthermore, the implementation of zone-based localization using solarpowered BLE beacons ensures that alerts are spatially accurate without requiring expensive maintenance of the localization infrastructure (i.e., battery replacement) or specific and costly indoor positioning technology, but using only BLE beacons and user smartphones. The successful migration of the Mobile-Hub components to a Flutter plugin also ensures that the solution is ready for crossplatform deployment, enhancing its accessibility for diverse workforce environments. 8.1. Future Work While the current implementation validates the core architecture, several avenues for future development have been identified: • Expanded Environmental Metrics: The current system focuses on air quality (CO2 and Particulate Matter). Future iterations will integrate noise level monitoring and vibration sensors into the risk analysis pipeline, as these are also critical factors in occupational health. • M-Hub-Mediated Data Acquisition: Currently, sensor data is transmitted directly to the backend via WiFi. Future work will leverage the MobileHub’s capability to act as a mobile gateway, as originally designed in the ContextNet architecture. In this model, smartphones will discover local sensors via WPAN (e.g., BLE) and aggregate their data before transmission. This enhances mobility and eliminates the dependence on fixed WiFi infrastructure for the sensor nodes. • Edge-Based Complex Event Processing (CEP): Although the Mobile-Hub implementation currently includes the AsperCEP engine, it is not yet utilized for logic processing. Future developments will activate these CEP capabilities to process sensor streams locally on the smartphone. This will allow for ”Edge AI” filtering, identifying critical anomalies or rapid pollutant spikes in real-time, thereby reducing cloud bandwidth usage and improving system responsiveness.
• Long-term Autonomy Tests: While the solar beacons function correctly in short-term tests, long-term field studies are necessary to validate the energy harvesting efficiency of the CN3791 and solar panel configuration under varying indoor lighting conditions.
9. Acknowledgments Language editing and grammatical corrections were assisted by Google Gemini. The authors reviewed all changes and retain full accountability for the final text.
References [1]
[2] [3]
[4]
[5]
[6]
[7] [8]
[9]
[10]
[11] [12]
Azmeel NA, Roslan H, Sari S. Real-Time IoT-Based Lecture Room Occupancy and Indoor Air Quality Monitoring System. Progress in Engineering Application and Technology. 2025;6(2):249-59. Available from: https://publisher.uthm.edu.my/periodicals/index. php/peat. Endler M, Silva FS. Past, Present and Future of the ContextNet IoMT Middleware. OJIOT. 2018;4(1):7-23. Talavera LE, Endler M, Vasconcelos I, Vasconcelos R, Cunha M, da Silva e Silva FJ. The Mobile Hub concept: Enabling applications for the Internet of Mobile Things. In: PerCom Workshops; 2015. p. 123-8. He L, Kanagaratnam S, Zanandreis LA, Deng M. LLM-Driven Robotic Indoor Air Quality Monitoring: Advances in Natural Language Interaction and Decision-Making; 2025. Conference paper. Available from: https://www.researchgate.net/publication/ 392512616_LLM-Driven_Robotic_Indoor_Air_Quality_Monitoring_Advances_in_ Natural_Language_Interaction_and_Decision-Making. Renold AP, Arockia Abins A, Katiravan J. IoT-Driven classroom air quality management with deep hierarchical cluster analysis. Scientific Reports. 2025;15(1):35595. Available from: https://pubmed.ncbi.nlm.nih.gov/41083460/. Arslan M, Munawar S, Mahdjoubi L, Manu P. Monitoring indoor environmental conditions in office buildings using a sustainable Agentic RAG-LLM system. Energy and Buildings. 2025;347:116276. Available from: https://www.sciencedirect.com/science/ article/pii/S0378778825010060. Pan YE, Nipu AS. LLM-enhanced Air Quality Monitoring Interface via Model Context Protocol; 2025. Lin S, Hua C. Physics-Informed Large Language Models for HVAC Anomaly Detection with Autonomous Rule Generation; 2025. Available from: https://arxiv.org/abs/2510. 17146. El-Leathey LA, Anghelita P, Constantin AI, Circiumaru G, Chihaia RA. System for Indoor Comfort and Health Monitoring Tested in Office Building Environment. Applied Sciences. 2023;13(19):11360. Available from: https://www.mdpi.com/2076-3417/13/19/11360. Talavera LE, Endler M, Colcher S. An Energy-aware IoT Gateway, with Continuous Processing of Sensor Data. In: Proc. of the Brazilian Symposiym for Computer Netwoks and Distributed Systems (SBRC 2016); 2016. p. 1083-96. Luckham DC. The Power of Events: An Introduction to Complex Event Processing in Distributed Enterprise Systems. Addison-Wesley Longman Publishing Co., Inc.; 2001. Victor F, Zickau S. Geofences on the Blockchain: Enabling Decentralized Location-Based Services. ICDMW. 2018:97-104.