This section describes the existing architecture and the proposed feature updates for the project.
An additional database for real-time analysis called InfluxDB (a Time-Series Database) will be integrated to improve performance and reliability for high-velocity sensor data.
| Feature | Description | Rationale |
|---|---|---|
| InfluxDB Integration | Implementation of a second database instance, separate from the primary application database, to specifically handle time-stamped sensor data. | Optimized for Time-Series: InfluxDB is engineered for fast write and query speeds on time-series data, which is essential for sensor readings. This will prevent the primary relational database (e.g., PostgreSQL) from becoming a bottleneck for analytics. |
| Dual Database Architecture | The existing relational database will be retained for user, device, and configuration metadata (Structured Data), while InfluxDB will handle the stream of sensor readings (Time-Series Data). | Separation of Concerns: Ensures the core application remains reliable and allows each database to operate on the data type it is best suited for. |
A robust and lightweight communication protocol will be implemented to simulate the data stream from remote sensor agents.
| Feature | Description | Rationale |
|---|---|---|
| MQTT Broker Setup | Deploying an MQTT Broker (e.g., Mosquitto, EMQX) to act as the central message hub for all sensor agents. | Lightweight Protocol: MQTT is ideal for IoT applications due to its minimal data overhead, low power consumption, and suitability for constrained devices and unreliable networks. |
| Data Ingestion Pipeline | Implementing a service (e.g., a custom microservice or a tool like Telegraf) to subscribe to the MQTT topics, process the sensor messages, and write the time-series data into InfluxDB. | Real-Time Stream: Creates a direct, non-blocking path from the sensor data (via MQTT) to the high-performance analytics database (InfluxDB). |
| Sensor Agent Simulation | Developing a small script or application to simulate multiple MQTT clients (sensor agents) publishing data to specific topics on the broker. | Functional Testing: Allows for realistic testing of the entire data pipeline, from data transmission to persistence, before a physical hardware deployment. |
An AI agent will be introduced to move beyond simple aggregation and provide valuable, actionable insights from the sensor data through synthesis and natural language.
| Feature | Description | Rationale |
|---|---|---|
| LLM-Powered Data Summarization | Integration of a Large Language Model (LLM) API (e.g., Gemini API) to synthesize the day's sensor data (from InfluxDB) into concise, natural-language reports. | Clarity & Value: Translates complex numerical data into simple, human-readable summaries, providing immediate, non-technical value to the end-user. |
| End-of-Day Batch Processing | The summarization task will be executed once per day on a schedule (e.g., midnight) to process the full 24-hour dataset. | Cost-Effectiveness & Feasibility: A batch approach simplifies the AI Agent logic, minimizes API calls to the free tier, and avoids the complexity and high latency requirements of real-time analysis. |
| AI Insights API & Persistence | The AI Agent will use a dedicated service to query InfluxDB, generate the LLM summary, and save the resulting text report to the application's primary database (PostgreSQL). | Intelligent User Experience: Ensures that the final, most valuable output of the system is easily accessible by the frontend application for display in daily reports or dashboards. |
The remodel shifts the architecture from a single-tier CRUD to a multi-tier, event-driven IoT system.