An intelligent lighting and environmental health monitoring system

Abstract

The application discloses an intelligent lighting and environment health monitoring system, and relates to the field of healthy lighting.The system comprises a data collection layer, a message communication layer, a data storage layer, a back-end analysis and API layer and a front-end display layer.The data collection layer collects various sensor data in multiple access modes and converts the data into a unified data structure to be published to the message communication layer.The message communication layer builds a unified data bus based on an MQTT message middleware to decouple the communication between the front end and the back end.The data storage layer stores high-frequency data and low-frequency data in a double-database hierarchical storage architecture.The back-end analysis and API layer provides aggregated analysis and business processing services based on the stored data and builds interfaces corresponding to the services.The front-end display layer performs visual display and interactive analysis of monitoring data by calling the interfaces of the back-end analysis and API layer.The application is compatible with heterogeneous devices, supports multi-dimensional structured analysis, can automatically complete evaluation and report output, and meets the needs of continuous lighting and indoor environment monitoring.

Description

Technical Field

[0001] This invention relates to the field of healthy lighting technology, and more specifically to an intelligent lighting and environmental health monitoring system. Background Technology

[0002] With the gradual promotion of the concept of healthy buildings, various indoor spaces require continuous monitoring of lighting and indoor environmental quality. Quantitatively assessing the impact of the lighting environment on human health and controlling indoor air pollutants provides data support for building operation and maintenance and lighting research, which has significant practical value.

[0003] However, significant shortcomings have long existed in the industry: First, the hardware specifications of various existing sensing devices are inconsistent, lacking a unified access standard. Data from different models of devices are isolated from each other, making centralized and unified management impossible and creating data silos. Second, existing devices can only view raw data locally or provide only basic indicator displays, lacking the ability to aggregate and analyze structured, multi-dimensional data, and providing insufficient support for evaluation systems. Third, the export, processing, and analysis of existing device data rely on manual operation, lacking a complete set of automated evaluation tools, and lacking automation, real-time capabilities, and dynamic scenario correlation capabilities, thus failing to meet the needs of continuous monitoring and the generation of immediate evaluation reports.

[0004] Therefore, how to build a lighting and environmental health monitoring system that is compatible with heterogeneous devices, supports multidimensional structured analysis, and automatically completes assessment and report output is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] In view of this, the present invention provides an intelligent lighting and environmental health monitoring system for indoor lighting health monitoring and building environment quality assessment scenarios. It systematically solves the three core pain points that have long existed in the current industry: heterogeneous equipment that cannot be managed uniformly, unstructured data that cannot be analyzed, and lack of automated tools for lighting health assessment. It is applicable to continuous monitoring of lighting and environment in various places such as office spaces, conference rooms, open work areas, reception spaces, corridor transition areas, educational spaces, and commercial spaces.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: This invention discloses an intelligent lighting and environmental health monitoring system, comprising: a data acquisition layer, a message communication layer, a data storage layer, a backend analysis and API layer, and a frontend display layer; The data acquisition layer uses multiple access modes to collect various types of sensor data and converts it into a unified data structure to publish to the message communication layer. The message communication layer is based on the MQTT message middleware to build a unified data bus, decoupling the communication between the front end and the back end. The data storage layer adopts a dual-database hierarchical storage architecture to store high-frequency data and low-frequency data. The backend analysis and API layer provides aggregation analysis and business processing services based on the stored data, and builds the corresponding interfaces for each service; The front-end presentation layer performs visualization and interactive analysis of monitoring data by calling the interfaces of the back-end analysis and API layer.

[0007] Furthermore, the multiple access modes include: passive broadcast mode, active connection mode, trigger mode, and simulation mode; In the passive broadcast mode, the sensor device continuously sends broadcast packets containing illuminance, color temperature, and EML optical parameters in a passive broadcast manner. The acquisition end passively receives the broadcast through BLE scanning, filters and parses the manufacturer-defined data area according to the device MAC address. In the active connection mode, the acquisition end actively connects to the sensor device, and the sensor device actively pushes data packets according to the sampling frequency. In the triggering mode, after the acquisition end actively sends a trigger command, the sensor device measures and returns the result; In the simulation mode, the general acquisition agent simulates any number of sensor devices of any model in a software manner, generates simulated data that conforms to the data distribution of real devices according to the configured base values ​​and random fluctuations, and publishes it to MQTT at a specified frequency.

[0008] Furthermore, the conversion to a unified data structure specifically involves: the output of all acquisition modes being standardized into a unified JSON structure before being published to MQTT.

[0009] Furthermore, the dual-database hierarchical storage architecture stores high-frequency data and low-frequency data, specifically as follows: The InfluxDB 2.x database is used to process high-frequency time-series metric data. Each record contains a device ID tag, a data type tag, the value of each metric, and a timestamp, supporting nanosecond-level time precision. Manage configuration information and alarm records for infrequent changes via an SQLite database.

[0010] Furthermore, the interfaces for the aggregation analysis include: dashboard summary interface, time trend chart interface, spatial grouping analysis interface, scene task analysis interface, multi-device aggregation interface, and spatial scene comprehensive analysis interface; The interfaces of the business processing service include: a data collection session management interface, an alarm management interface, and a report generation interface.

[0011] Furthermore, the front-end display layer includes: a homepage, an m-EDI time-segmented analysis report page, a multi-device aggregation analysis page, a space and scene analysis page, and an alarm center; The homepage is used to display real-time monitoring data; The m-EDI time-segment analysis report page is used to display the time-segment analysis results of the m-EDI index; The multi-device aggregation analysis page allows users to freely select multiple devices and a single indicator, displaying the statistical envelope of the multiple devices. The space and scene analysis page, through linked filtering, displays a line chart of indicator distribution under a specific space-scene combination; The alarm center displays the number of unread alarms in real time, and lists the alarm devices, exceeded fields, and the comparison between measured values ​​and thresholds.

[0012] As can be seen from the above technical solution, compared with the prior art, the present invention provides an intelligent lighting and environmental health monitoring system, which has the following beneficial effects: (1) Open architecture for the entire lighting industry: The system's MQTT data bus, unified JSON format, and layered decoupling design construct a basic framework for a lighting monitoring platform that can be reused across the industry. Any new lighting sensor brand only needs to implement the corresponding acquisition adaptation layer (reading data from the device and publishing it to MQTT) to access the system's complete analysis, display, and reporting capabilities without having to redevelop the backend, frontend, or reporting logic. This is not only an engineering project but also provides a sustainable evolution system model for the field of lighting health monitoring.

[0013] (2) Complete access verification of real hardware starting from BLE: This system has completed the engineering implementation of two modes, BLE Beacon and BLE Gat, and established a complete digital link from sensor Bluetooth signal to visualization analysis report, providing a clear expansion path for subsequent expansion of various IoT remote sensors and other hardware interface forms.

[0014] (3) From R&D tools to customer-deliverable products: The introduction of fully packaged executable software transforms the system from an R&D tool that requires a professional development environment to run into a plug-and-play software product, greatly reducing the delivery threshold and enabling the same system to be deployed and used directly at different customers' sites without the need for any technical personnel to configure the environment on-site.

[0015] (4) Seamless evolution from simulation to real equipment: The system implementation path design supports a phased mode of verifying software functions first and then connecting to real equipment. After receiving the system, all dashboards and analysis functions can be experienced immediately (using simulated data for testing). When new sensor equipment arrives in the future, the data mode only needs to be switched in the starter, and the front end will automatically switch from the analog identifier to the new sensor protocol interface without affecting the overall system operation.

[0016] (5) Multidimensional analysis enhances the value of data interpretation: The three-dimensional analysis model of time-space-scene enables the system to interpret data. It can not only show how much illuminance there is, but also answer questions such as the meeting time in the conference room, the level of illuminance, and how it compares to the WELL standard. This directly serves WELL assessment, project reporting, and operation and maintenance rectification decisions.

[0017] (6) Scalability of the report output system: Currently, PDF reports and Excel reports are available for export. The report generation layer and the analysis layer are completely decoupled—adding a new report format (such as a good house report or a custom topic report) only requires adding the corresponding Jinja2 template file and adding the corresponding endpoint to the backend route, without modifying any data collection, storage, or analysis logic. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0019] Figure 1 This is a schematic diagram of the overall architecture of the present invention. Detailed Implementation

[0020] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] This invention discloses an intelligent lighting and environmental health monitoring system, such as... Figure 1 As shown, it includes: a data acquisition layer, a message communication layer, a data storage layer, a backend analysis and API layer, and a frontend presentation layer; The data acquisition layer uses multiple access modes to collect data from various sensors and converts it into a unified data structure to publish to the message communication layer. The message communication layer is based on the MQTT message middleware to build a unified data bus and decouple the communication between the front end and the back end. The data storage layer adopts a dual-database hierarchical storage architecture to store high-frequency data and low-frequency data; The backend analytics and API layer provides aggregation analysis and business processing services based on stored data, and builds the corresponding interfaces for each service; The front-end presentation layer uses back-end analytics and API layer interfaces to visualize and interactively analyze monitoring data.

[0022] In one specific embodiment, the data acquisition layer supports multiple access modes, and each mode is completely transparent to the downstream; switching access methods does not affect any other layers. The multiple access modes include: passive broadcast mode, active connection mode, trigger mode, and simulation mode. In passive broadcast mode, the sensor device (Pro device, Pro series—LuxSeeker) continuously sends broadcast packets containing illuminance, color temperature, and EML optical parameters via BLEEeacon passive broadcast. The acquisition end (acquisition script) passively receives the broadcasts via BLE scanning, filters and parses the manufacturer-defined data area according to the device MAC address, extracts standardized parameters, and publishes them to MQTT. This mode does not require establishing a BLE connection, and the device is unaware of the acquisition end's existence, making it suitable for large-scale, multi-device deployment scenarios.

[0023] In active connection mode, the sensor device (Well device, Well series—In.Lichtwell) provides services using the BLEGATT protocol. The acquisition end (acquisition script) actively connects to the sensor device, and after discovering the specified ServiceUUID and CharacteristicUUID, it enables notification. The sensor device actively pushes data packets containing 14 full indicators (optics + air quality + temperature and humidity) according to the sampling frequency. The acquisition script implements an automatic reconnection mechanism after disconnection to ensure long-term stable operation.

[0024] In trigger mode, after the acquisition end actively sends a trigger command, the sensor device (Ultra device, Ultra series—LGT-01) measures and returns the result; the system realizes a complete interactive process of automatic trigger sending → waiting for response → parsing data, and is adapted to the on-demand measurement working mode of the device.

[0025] In simulation mode, the general data acquisition agent (agent.py) supports simulating any number and model of sensor devices in software. It generates simulated data that matches the data distribution of real devices based on configured baseline values ​​and random fluctuations, and publishes it to MQTT at a specified frequency. This is suitable for end-to-end integration testing before system debugging, demonstration, and customer acceptance, and uses the same downstream data link as real devices.

[0026] `agent.py` retains interface implementations for both serial and HTTP reading modes. Sensors providing serial output or HTTP interfaces can be directly configured for connection, and output data enters the system via the standard MQTT link without any downstream modifications. In a specific implementation, the data is converted to a unified data structure: the outputs of all acquisition modes are normalized into a unified JSON structure before being published to MQTT. For example: { "device_id": "WELL-001", "timestamp": "2026-04-15T10:30:00+08:00", "lux": 350.2, "cct": 4850, "m_edi": 182.5, "flicker": 0.02, "svm": 0.12, "eml": 275.3, "co2": 620, "pm2_5": 8.3, "tvoc": 210, Temperature: 23.5 "humidity": 55.0 } Topic Specifications: {Device Type} / device / {Device ID} / metrics ← Time Series Data {Device Type} / device / {Device ID} / status ← Online / Offline Status (LWT Will Mechanism).

[0027] In one specific implementation, the message communication layer uses the Mosquitto MQTT Broker as the message middleware, running in a Docker container on port 1883. MQTT, as the system's data bus, is a key design choice supporting unified access from multiple devices and protocols. Publish-subscribe decoupling: The acquisition end and the subscription end are completely decoupled, and adding or removing devices or connecting new models will not affect the other party.

[0028] Scalability: The message middleware can be replaced with brokers compatible with the MQTT protocol, such as EMQX and HiveMQ, and can also be extended to support MQTT over TLS encrypted transmission for public network deployment scenarios.

[0029] Looking to the future: With the diversification of IoT device forms (NB-IoT, LoRa, Zigbee to MQTT gateway, etc.), any device or gateway that can publish data to MQTT in standard JSON can be plugged into this system without modifying any backend logic.

[0030] In one specific embodiment, the dual-database hierarchical storage architecture stores high-frequency data and low-frequency data, specifically as follows: Using the InfluxDB2.x database, high-frequency time-series metric data is processed, supporting efficient time range querying and aggregation. Each record contains a device ID tag, data type tag, metric values ​​and timestamp, and supports nanosecond-level time precision. Manage infrequently changed configuration information and alarm records using an SQLite database. Configuration information and alarm records are stored in two separate databases: config.db: Space classification configuration (space major category / space subtype), device registration and space association, task scenario definition, and collection session configuration (session_devices table, recording the device-space-scenario combination for each collection). alerts.db: Alarm records (devices exceeding limits, fields, measured values, thresholds), email sending logs (to prevent duplicate sending), and a 24-hour automatic clearing mechanism.

[0031] In one specific embodiment, the interfaces for aggregation analysis include: dashboard summary interface, time trend chart interface, spatial grouping analysis interface, scene task analysis interface, multi-device aggregation interface, and spatial scene comprehensive analysis interface; The business processing service interfaces include: data collection session management interface, alarm management interface, and report generation interface.

[0032] Specifically, the backend analytics and API layer are built on FastAPI, running on port 8000, and provide the following core functional modules: (1) Data query and aggregation analysis interface, as shown in Table 1.

[0033] Table 1 Data Query and Aggregation Analysis Interface

[0034] (2) Collection Session Management Interface (GET / POST / api / session / config): The system launcher synchronizes the user-configured device-space-scene combination to the backend each time collection begins. Based on this, the frontend dynamically filters and displays only the data of the device being collected, realizing the dynamic display logic of "what you see is what you collect".

[0035] (3) Alarm management interface, as shown in Table 2.

[0036] Table 2 Alarm Management Interface

[0037] (4) The report generation interface includes: POST / api / reports / generate: Triggers PDF report generation (InfluxDB data → Aggregate Analysis → Jinja2 template → WeasyPrint → PDF file) GET / api / reports / export-excel: Exports raw collected data within a specified time range to an Excel file, and supports one-click download directly from the interface.

[0038] In one specific embodiment, the front-end display layer includes: a homepage, an m-EDI time-segmented analysis report page, a multi-device aggregated analysis page, a space and scene analysis page, and an alarm center; The homepage is used to display real-time monitoring data; specifically, the homepage includes: Left side indicator card area: the current time window average of the indicator (illuminance, color temperature, temperature and humidity, air quality, etc.), each item is equipped with a color status light (green / yellow / red three levels, based on WELL threshold to judge health status); The right-hand time trend chart is a line chart of time-series data that switches between devices and metrics, and supports page switching to view data for different devices. Data source label: Automatically displays REAL / MOCK, reflecting the current data source; One-click export report button (PDF format); One-click data export button (in Excel format).

[0039] The m-EDI time-segment analysis report page displays the time-segment analysis results of the m-EDI index. Specifically, it showcases the time-segment analysis of the m-EDI index, which is used to assess the impact of lighting on the human circadian rhythm and is a core evaluation criterion of the WELL Lighting Standard. This page provides a dedicated time-series tracking and analysis view for it. The page includes default daytime / nighttime periods (6:00-18:00 / 18:00-6:00) and preset red, yellow, and green thresholds for each period to quickly determine whether the light stimulation level within that period is reasonable. It also supports user-defined time ranges and corresponding red, yellow, and green thresholds for each period. The system automatically generates the corresponding m-EDI aggregate curve based on the settings and displays the difference between the curve and the threshold, as well as the real-time status, allowing users to intuitively analyze the circadian lighting performance under different time periods.

[0040] The multi-device aggregation analysis page allows users to freely select multiple devices and individual indicators to view the statistical envelopes (AVG / MIN / MAX) of the devices, which can be used to compare the differences in indicators between different regions and different models of devices.

[0041] The Space and Scene Analysis page displays line graphs showing the distribution of indicators under specific space-scene combinations through linked filtering. Specifically, the linked filtering process is: Space Category → Space Subtype → Task Scene → Device → Indicator. The options on the Space and Scene Analysis page are limited to the device combinations configured for this data collection session, ensuring precise focus. The Space and Scene Analysis page displays line graphs showing the distribution of indicators under specific space-scene combinations, supporting the analysis of typical monitoring scenarios such as meeting rooms and meeting periods, and open offices and work periods.

[0042] The alarm center features a persistent alarm bell icon in the top navigation bar, displaying a real-time indicator of the number of unread alarms. Clicking on it opens a full-screen alarm center overlay, listing alarm devices, exceeding parameters, and comparisons of measured values ​​with thresholds. Users can input any recipient email address to send a summary email of the current alarms with a single click. Alarm center records are persistently stored in alerts.db, and historical alarms are automatically cleared after 24 hours. The system includes built-in alarms for seven metrics exceeding limits based on the WELL standard, as shown in Table 3.

[0043] Table 3 Explanation of Alarms for Exceeding Indicator Standards

[0044] Once an alarm is triggered, the system automatically sends an email (SMTP) to the default recipient within 5 minutes and displays it in the alarm center. Users can also manually enter any domestic or international email address to send alarm summaries as needed.

[0045] In one specific embodiment, the system uses a GUI to launch the controller. Specifically, launcher.py serves as the user interaction entry point for the entire system. After being packaged into launcher.exe executable software using PyInstaller, the client can run it directly without requiring any additional environment. The main functions are as follows: (1) Pre-collection configuration: Device configuration panel: Users can add the devices used for this data collection. Each device can be configured independently with series (Pro / Well / Ultra), device ID, spatial category, spatial subtype and task scenario. Multiple device combinations can be configured, and the device ID is globally unique. Data acquisition parameter settings: acquisition duration (seconds), analysis window (hours), data mode selection (Mock mode / BLE mode).

[0046] (2) Start-up and control: Start data collection: Start the Docker container detection, backend API service, frontend build and production server, MQTT subscribers for the three types of devices, and data collection agents for each device in sequence, and synchronize the data collection session configuration to the backend; Stop data collection: This only terminates the data collection process (agent and collector), while the backend and frontend continue to run, and the Dashboard data remains accessible. Open the Dashboard: Open the front-end display page in your browser; Shutting down the system: Terminates all backend, frontend, and Launcher processes, exiting completely.

[0047] (3) Adaptive operating environment: Automatically detects whether Docker Desktop is running; if not, it automatically finds the installation path and starts it. Automatically detects the existence of the .next build artifacts, and automatically executes `npm run build` (approximately 40 seconds) on the first run; subsequent runs will directly use `npm start`. All child processes run in a hidden manner, without exposing the console window to the user; The startup log is displayed in real time, fully recording the status of each step.

[0048] The following three specific embodiments illustrate some of the functions of this system.

[0049] Example 1: End-to-end functional verification based on Mock data

[0050] Open the launcher.exe software launcher. The system automatically detects the running status of Docker Desktop and starts the MQTT Broker and InfluxDB containers, starts the FastAPI backend service, executes the frontend production build, and starts the Next.js server. Next, add the data collection device (e.g., Ultra-001, Office Space - Transition Zone) in the launcher interface, select Mock data mode, set the collection duration to 120 seconds, and click Start Collection. The system automatically starts the pro / well / ultra three-way MQTT subscription collector and the agent configured for the device to simulate the collection process, continuously writing simulated data to InfluxDB for 120 seconds. After collection is complete, click Open Dashboard to access the frontend in a browser. The Dashboard displays the time-series trend chart and various indicator cards for the device.

[0051] Example 2: Data Access Based on Real BLE Devices

[0052] Deploy Pro (LuxSeeker), Well (In.Licht well), or Ultra (LGT-01) sensors in the target space. Record the BLE MAC address of each device in `BLE Device Configuration Table.md`. Switch the data mode to BLE in the launcher, fill in the corresponding device MAC address configuration, repackage launcher.exe, and deliver it to the field. The acquisition script discovers devices through BLE scanning. Beacon devices (Pro) passively parse broadcast packets, while GATT devices (Well / Ultra) actively establish connections and subscribe to data notifications. The field mapping layer uniformly converts the manufacturer's field format and publishes it to MQTT. The downstream analysis and display link is exactly the same as in Mock mode, and the front-end data label automatically switches to REAL.

[0053] Example 3: Expanding Access to Add Third-Party Sensor Brands

[0054] If a new lighting sensor from a certain brand that supports an HTTP interface is introduced in the future, simply add the HTTP read mode interface specification to agent.py, register the corresponding device Topic prefix, and add the brand's device in the launcher device configuration for complete integration. The MQTT subscriber, InfluxDB storage, FastAPI analytics API, front-end display, alarm system, and report generation all require no modification. This is precisely the key characteristic pursued in the system architecture design: the cost of expanding to new device types approaches zero.

[0055] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to the method section.

[0056] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. An intelligent lighting and environmental health monitoring system, characterized in that, include: The data acquisition layer, message communication layer, data storage layer, backend analysis and API layer, and frontend presentation layer are all included. The data acquisition layer uses multiple access modes to collect various types of sensor data and converts it into a unified data structure to publish to the message communication layer. The message communication layer is based on the MQTT message middleware to build a unified data bus, decoupling the communication between the front end and the back end. The data storage layer adopts a dual-database hierarchical storage architecture to store high-frequency data and low-frequency data. The backend analysis and API layer provides aggregation analysis and business processing services based on the stored data, and builds the corresponding interfaces for each service; The front-end presentation layer performs visualization and interactive analysis of monitoring data by calling the interfaces of the back-end analysis and API layer.

2. The intelligent lighting and environmental health monitoring system according to claim 1, characterized in that, The various access modes include: passive broadcast mode, active connection mode, trigger mode, and simulation mode; In the passive broadcast mode, the sensor device continuously sends broadcast packets containing illuminance, color temperature, and EML optical parameters in a passive broadcast manner. The acquisition end passively receives the broadcast through BLE scanning, filters and parses the manufacturer-defined data area according to the device MAC address. In the active connection mode, the acquisition end actively connects to the sensor device, and the sensor device actively pushes data packets according to the sampling frequency. In the triggering mode, after the acquisition end actively sends a trigger command, the sensor device measures and returns the result; In the simulation mode, the general acquisition agent simulates any number of sensor devices of any model in a software manner, generates simulated data that conforms to the data distribution of real devices according to the configured base values ​​and random fluctuations, and publishes it to MQTT at a specified frequency.

3. The intelligent lighting and environmental health monitoring system according to claim 1, characterized in that, The conversion to a unified data structure specifically means that the output of all acquisition modes is standardized into a unified JSON structure and then published to MQTT.

4. The intelligent lighting and environmental health monitoring system according to claim 1, characterized in that, The dual-database hierarchical storage architecture stores high-frequency data and low-frequency data, specifically as follows: The InfluxDB 2.x database is used to process high-frequency time-series metric data. Each record contains a device ID tag, a data type tag, the value of each metric, and a timestamp, supporting nanosecond-level time precision. Manage configuration information and alarm records for infrequent changes via an SQLite database.

5. The intelligent lighting and environmental health monitoring system according to claim 1, characterized in that, The interfaces for the aggregation analysis include: dashboard summary interface, time trend chart interface, spatial grouping analysis interface, scene task analysis interface, multi-device aggregation interface, and spatial scene comprehensive analysis interface; The interfaces of the business processing service include: a data collection session management interface, an alarm management interface, and a report generation interface.

6. The intelligent lighting and environmental health monitoring system according to claim 1, characterized in that, The front-end display layer includes: homepage, m-EDI time-segmented analysis report page, multi-device aggregation analysis page, space and scene analysis page, and alarm center; The homepage is used to display real-time monitoring data; The m-EDI time-segment analysis report page is used to display the time-segment analysis results of the m-EDI index; The multi-device aggregation analysis page allows users to freely select multiple devices and a single indicator, displaying the statistical envelope of the multiple devices. The space and scene analysis page, through linked filtering, displays a line chart of indicator distribution under a specific space-scene combination; The alarm center displays the number of unread alarms in real time, and lists the alarm devices, exceeded fields, and the comparison between measured values ​​and thresholds.

Images