System Architecture - kobeylake/ares-red GitHub Wiki

System Overview

The following section provides a high-level overview of the system architecture, showing how different embedded nodes interact to ensure smooth operation of the intelligent greenhouse monitoring and control system. The system uses a combination of Bluetooth and serial communication to collect, fuse, and visualize environmental data.

See the following diagram for an overview of the system architecture: image

System Nodes

Base Node

Platform: nRF52840dk

Function: The base node acts as the central control unit of the system. It collects data from both mobile and local sensors and performs data fusion and decision-making algorithms to determine actuator control signals. It also interfaces with the PC for data logging and visualization.

Mobile node

Platform: Thingy52

Function: The mobile node serves as a remote environmental sensing unit. It collects key environmental parameters and transmits them periodically to the base node via BLE.

Responsibilities Include:

  • Temperature
  • Humidity
  • eC02
  • BLE transmission

Actuating node

Platform: nRF52840dk and CRIKIT for power supply

Function: The actuator node physically manipulates greenhouse elements based on decisions made by the base node. It uses servo motors powered via the CRICKIT and receives control signals over GPIO.

Responsibilities Include:

  • Drive servo motors to open/close greenhouse vents
  • Receive actuator commands from the base node
  • Maintain Bluetooth connectivity for status updates

Viewer Node

Platform: M5 Core2

Function: The viewer node acts as a mobile display unit, showing real-time alerts and system statuses based on Bluetooth messages received from the base or actuator nodes.

Responsibilities Include:

  • Visual display of warnings, alerts, or recommended actions
  • Displays basic sensor data
  • Receives data via Bluetooth from PC

Dashboard

Platform: PC using Grafana and InfluxDB

Function: This node serves as the main interface for system monitoring. It provides visual dashboards of all collected and fused sensor data, letting users observe trends over time.

Responsibilities Include:

  • Real-time graphing of all sensor values
  • Historical data logging via InfluxDB
  • Communication with the base node over USB UART using JSON packets

DIKW Pyramid Abstraction

The DIKW (Data–Information–Knowledge–Wisdom) pyramid helps structure the greenhouse system’s operation from raw sensor inputs to intelligent control decisions. This abstraction is critical to explain how the system transforms low-level readings into meaningful environmental actions.

Data

Raw readings collected from various sensors:

  • Temperature in °C (from Thingy:52)
  • CO₂ concentration in ppm (from Thingy:52)
  • Humidity in %RH (from Thingy:52)
  • Soil moisture as a voltage or % (from base node)
  • Ultrasonic distance in cm (to detect if the door is open or closed)

These values are sampled periodically (e.g., every second) and transmitted over BLE.

Information

Raw data is processed into structured, contextualised values:

  • Temperature CategoryLow / Normal / High
  • CO₂ LevelSafe / Elevated / Hazardous
  • Door StateOpen / Closed (based on ultrasonic threshold)
  • Soil Moisture LevelDry / Optimal / Wet

This layer turns raw sensor outputs into human-readable, categorised states using thresholds and lookup rules.

Knowledge

The system fuses sensor states using decision logic and a Kalman filter to make informed control decisions:

  • When temperature is high, CO₂ is elevated, and the door is closed, trigger ventilation.
  • If soil moisture is low, raise a watering alert on the M5 Core2.
  • Apply data smoothing to reduce noise and prevent erratic actuator toggling.

At this level, the system combines and interprets multiple pieces of information to decide when to act and how.

Wisdom

The system behaves intelligently based on long-term and high-confidence patterns:

  • Avoid opening vents unnecessarily when the door is already open (ineffective airflow).
  • Delay vent closing until CO₂ levels have stabilised after ventilation.
  • Allow the user to monitor trends via Grafana to make manual interventions (e.g., watering, vent overrides).
  • Learn from environmental responses and avoid redundant commands through adaptive thresholding (future expansion potential).

This layer reflects the governing principles and refined judgement built into the control strategy, enabling sustainable, efficient greenhouse management.