Control application - Revision history

Uwe: /* Threads */

2026-01-30T18:17:16Z

Threads

← Older revision		Revision as of 20:17, 30 January 2026
Line 138:		Line 138:
	\| publish_pid \|\| Writing PID to lock file		\| publish_pid \|\| Writing PID to lock file
	\|-		\|-
	\| temperature_gradient \|\| [[Temperature ~~Gradient Calculation~~]]		\| temperature_gradient \|\| [[Temperature gradient calculation]]

	\|}		\|}

Uwe: /* Threads */

2026-01-30T18:16:39Z

Threads

← Older revision		Revision as of 20:16, 30 January 2026
Line 137:		Line 137:
	\|-		\|-
	\| publish_pid \|\| Writing PID to lock file		\| publish_pid \|\| Writing PID to lock file
			\|-
			\| temperature_gradient \|\| [[Temperature Gradient Calculation]]

	\|}		\|}

Uwe: /* Phase 5: Component Initialization */

2026-01-30T18:15:54Z

Phase 5: Component Initialization

← Older revision		Revision as of 20:15, 30 January 2026
Line 79:		Line 79:
	* watchdog		* watchdog
	* schedule checker		* schedule checker
			* temperature gradient calculation
	* IPC messaging system		* IPC messaging system

Uwe at 18:09, 30 January 2026

2026-01-30T18:09:27Z

← Older revision		Revision as of 20:09, 30 January 2026
Line 22:		Line 22:
	* Schedule checks to limit the hour of day of operating certain actuators		* Schedule checks to limit the hour of day of operating certain actuators
	* [[Communication with HW Watchdog]]		* [[Communication with HW Watchdog]]
			* [[Temperature gradient calculation]]
	The application is written in Rust and is [[automatic start by using systemd\| automatically started using systemd]].		The application is written in Rust and is [[automatic start by using systemd\| automatically started using systemd]].

Uwe: /* Commissioning */

2026-01-11T13:34:36Z

Commissioning

← Older revision		Revision as of 15:34, 11 January 2026
Line 188:		Line 188:

	= Commissioning =		= Commissioning =
	For the [[commissioning of the aquarium control~~\|commissioning software~~]], there is a separate binary which resides in <code>src/bin/commissioning.rs</code>.		For the [[commissioning software\|commissioning of the aquarium control]], there is a separate binary which resides in <code>src/bin/commissioning.rs</code>.

Uwe: /* Commissioning */

2026-01-11T13:34:16Z

Commissioning

← Older revision		Revision as of 15:34, 11 January 2026
Line 188:		Line 188:

	= Commissioning =		= Commissioning =
	For the [commissioning of the aquarium control\|commissioning software], there is a separate binary which resides in <code>src/bin/commissioning.rs</code>.		For the [[commissioning of the aquarium control\|commissioning software]], there is a separate binary which resides in <code>src/bin/commissioning.rs</code>.

Uwe: /* Commissioning */

2026-01-11T13:34:02Z

Commissioning

← Older revision		Revision as of 15:34, 11 January 2026
Line 188:		Line 188:

	= Commissioning =		= Commissioning =
	For the commissioning of the aquarium control, there is a separate binary which resides in <code>src/bin/commissioning.rs</code>.		For the [commissioning of the aquarium control\|commissioning software], there is a separate binary which resides in <code>src/bin/commissioning.rs</code>.

Uwe at 13:32, 11 January 2026

2026-01-11T13:32:27Z

Uwe: /* Measurement using Atlas Scientific circuits */

2026-01-08T18:31:57Z

Measurement using Atlas Scientific circuits

← Older revision		Revision as of 20:31, 8 January 2026
Line 139:		Line 139:

	== Measurement using Atlas Scientific circuits ==		== Measurement using Atlas Scientific circuits ==
	~~1. Core~~ Abstraction (`AtlasScientificDriver` Trait)		The core Abstraction (<code>AtlasScientificDriver</code> Trait) is defined in <code>src/sensors/atlas_scientific_driver.rs</code>, this trait serves as the common interface for all sensor types. It enforces three key behaviors:
	~~Defined~~ in src/sensors/atlas_scientific_driver.rs, this trait serves as the common interface for all sensor types. It enforces three key behaviors:		* <code>send_request_to_i2c_interface</code>: Encapsulates how to trigger a measurement (e.g., constructing specific I2C commands).
	* send_request_to_i2c_interface: Encapsulates how to trigger a measurement (e.g., constructing specific I2C commands).		* <code>receive_response_from_i2c_interface</code>: Handles parsing the raw byte response from the I2C bus into a normalized floating-point value.
	* receive_response_from_i2c_interface: Handles parsing the raw byte response from the I2C bus into a normalized floating-point value.		* <code>device_init</code>: Performs hardware-specific setup (crucial for OEM type sensor circuit).
	* device_init: Performs hardware-specific setup (crucial for OEM ~~sensors~~).

	2. ~~Specific Implementations~~ (~~The Strategies~~)		Circuit-type-specific implementations
			* OEM Driver (<code>AtlasScientificOem</code>):
			** Protocol: Uses a binary, register-based protocol.
			** Initialization: Requires an explicit "Wake Up" command (writing to <code>REG_WAKEUP</code>) and verifies the hardware by reading the <code>REG_DEVICE_TYPE</code>.
			** Read Cycle: Writes a register address (e.g., <code>REG_DATA_MSB_PH</code>), waits for a short processing time, and reads 4 bytes.
			** Parsing: Decodes the 4-byte response as a Big Endian unsigned integer and divides it by a specific scale factor (e.g., 1000.0) to get the float value.
			* EZO Driver (<code>AtlasScientificEzo</code>):
			** Protocol: Uses a text-based (ASCII) command protocol.
			** Initialization: Minimal or no-op (these devices are typically always ready or auto-on).
			** Read Cycle: Sends the ASCII character 'R', waits for a longer processing time, and reads a fixed 8-byte response.
			** Parsing: Validates "magic" start/end bytes (1 and 0), converts the inner ASCII string (e.g., "23.50") to a float.

	* OEM Driver (~~`AtlasScientificOem`~~):		Context and factory (<code>AtlasScientific</code> struct)
	* ~~Protocol: Uses~~ a ~~binary~~, ~~register-based protocol~~.		* The main <code>AtlasScientific</code> struct acts as the context. It holds a <code>HashMap<AquariumSignal</code>, <code>Box<dyn AtlasScientificDriver>></code>.
	* ~~Initialization~~: ~~Requires an explicit~~ "~~Wake Up~~" ~~command (writing to REG_WAKEUP~~) and ~~verifies~~ the ~~hardware by reading the REG_DEVICE_TYPE~~.		* Factory Logic: The <code>create_drivers</code> method functions as a factory. It reads the <code>aquarium_control.toml</code> configuration (specifically fields like <code>sensor_type_ph = "oem"</code> or <code>"ezo"</code>) and
	* ~~Read Cycle~~: ~~Writes a register address (e~~.g.~~, REG_DATA_MSB_PH), waits for a short processing time,~~ and ~~reads 4 bytes~~.		instantiates the correct driver implementation for each sensor (temperature, pH, conductivity).
	* Parsing: Decodes the 4-byte response as a Big Endian unsigned integer and divides it by a specific scale factor (e.g.~~, 1000~~.~~0) to get~~ the ~~float value~~.		* Execution: The main thread loop calls <code>driver.send_request...</code> and <code>driver.receive_response...</code> on the active driver, unaware of whether it is communicating via binary registers or ASCII commands.

	* EZO Driver (`AtlasScientificEzo`):		Communication Flow
	* Protocol: Uses a text-based (ASCII) command protocol.
	* Initialization: Minimal or no-op (these devices are typically always ready or auto-on).
	* Read Cycle: Sends the ASCII character 'R', waits for a longer processing time, and reads a fixed 8-byte response.
	* Parsing: Validates "magic" start/end bytes (1 and 0), converts the inner ASCII string (e.g., "23.50") to a float.

	~~3. Context & Factory~~ (~~`AtlasScientific` Struct~~)		The architecture decouples protocol logic from bus I/O:
	* The main AtlasScientific ~~struct acts as~~ the ~~"Context"~~. ~~It holds a HashMap~~<~~AquariumSignal, Box~~<~~dyn AtlasScientificDriver>~~>.		# Driver creates an abstraction-specific <code>I2cRequest</code> (containing address, write buffer, read length, delay).
	* Factory Logic: The create_drivers method functions as a factory. It reads the ~~aquarium_control.toml configuration (specifically fields like sensor_type_ph = "oem" or "ezo")~~ and		# <code>AtlasScientific</code> thread sends this request via a channel to the <code>I2cInterface</code> thread.
	~~instantiates~~ the ~~correct~~ driver ~~implementation~~ for ~~each sensor (Temperature, pH, Conductivity)~~.		# <code>I2cInterface</code> thread performs the physical I2C transaction.
	* Execution: The main thread loop simply calls driver.send_request... and driver.receive_response... on the active driver, ~~unaware of whether it is communicating via binary registers~~		# <code>AtlasScientific</code> thread receives the raw bytes and passes them back to the driver for parsing.
	~~or ASCII commands~~.		# Additionally, <code>AtlasScientific</code> performs measurement value checks informing deviations to <code>Monitors</code>.

	~~Communication Flow~~		This design enables the system to mix and match sensor types (e.g., an OEM type pH sensor circuit with an EZO type temperature sensor circuit) purely through configuration changes.

	~~The architecture completely decouples protocol logic from bus I/O:~~
	~~1. Driver creates an abstraction-specific I2cRequest (containing address, write buffer, read length, delay).~~
	~~2. AtlasScientific Thread sends this request via a channel to the I2cInterface Thread.~~
	~~3. I2cInterface Thread performs the physical I2C transaction.~~
	~~4. AtlasScientific Thread receives the raw bytes and passes them back to the Driver for parsing.~~

	This design enables the system to mix and match sensor types (e.g., an OEM pH sensor with an EZO temperature sensor) purely through configuration changes.

	== Monitors ==		== Monitors ==

Uwe: /* Architecture */

2026-01-08T18:21:21Z

Architecture

← Older revision		Revision as of 20:21, 8 January 2026
Line 137:		Line 137:

	\|}		\|}

			== Measurement using Atlas Scientific circuits ==
			1. Core Abstraction (`AtlasScientificDriver` Trait)
			Defined in src/sensors/atlas_scientific_driver.rs, this trait serves as the common interface for all sensor types. It enforces three key behaviors:
			* send_request_to_i2c_interface: Encapsulates how to trigger a measurement (e.g., constructing specific I2C commands).
			* receive_response_from_i2c_interface: Handles parsing the raw byte response from the I2C bus into a normalized floating-point value.
			* device_init: Performs hardware-specific setup (crucial for OEM sensors).

			2. Specific Implementations (The Strategies)

			* OEM Driver (`AtlasScientificOem`):
			* Protocol: Uses a binary, register-based protocol.
			* Initialization: Requires an explicit "Wake Up" command (writing to REG_WAKEUP) and verifies the hardware by reading the REG_DEVICE_TYPE.
			* Read Cycle: Writes a register address (e.g., REG_DATA_MSB_PH), waits for a short processing time, and reads 4 bytes.
			* Parsing: Decodes the 4-byte response as a Big Endian unsigned integer and divides it by a specific scale factor (e.g., 1000.0) to get the float value.

			* EZO Driver (`AtlasScientificEzo`):
			* Protocol: Uses a text-based (ASCII) command protocol.
			* Initialization: Minimal or no-op (these devices are typically always ready or auto-on).
			* Read Cycle: Sends the ASCII character 'R', waits for a longer processing time, and reads a fixed 8-byte response.
			* Parsing: Validates "magic" start/end bytes (1 and 0), converts the inner ASCII string (e.g., "23.50") to a float.

			3. Context & Factory (`AtlasScientific` Struct)
			* The main AtlasScientific struct acts as the "Context". It holds a HashMap<AquariumSignal, Box<dyn AtlasScientificDriver>>.
			* Factory Logic: The create_drivers method functions as a factory. It reads the aquarium_control.toml configuration (specifically fields like sensor_type_ph = "oem" or "ezo") and
			instantiates the correct driver implementation for each sensor (Temperature, pH, Conductivity).
			* Execution: The main thread loop simply calls driver.send_request... and driver.receive_response... on the active driver, unaware of whether it is communicating via binary registers
			or ASCII commands.

			Communication Flow

			The architecture completely decouples protocol logic from bus I/O:
			1. Driver creates an abstraction-specific I2cRequest (containing address, write buffer, read length, delay).
			2. AtlasScientific Thread sends this request via a channel to the I2cInterface Thread.
			3. I2cInterface Thread performs the physical I2C transaction.
			4. AtlasScientific Thread receives the raw bytes and passes them back to the Driver for parsing.

			This design enables the system to mix and match sensor types (e.g., an OEM pH sensor with an EZO temperature sensor) purely through configuration changes.

	== Monitors ==		== Monitors ==

← Older revision		Revision as of 15:32, 11 January 2026
Line 30:		Line 30:
	There is a [[Release procedure\|release procedure]] which is highly recommended to be followed also by anyone developing the SW further.		There is a [[Release procedure\|release procedure]] which is highly recommended to be followed also by anyone developing the SW further.

	== Architecture ==		= Architecture =
	=== Startup of the application ===		== Startup of the application ==
	The startup uses a two-layer approach:		The startup uses a two-layer approach:
	# main() - Simple error handler wrapper that calls run() and exits with code 1 on errors		# main() - Simple error handler wrapper that calls run() and exits with code 1 on errors
	# run() - The actual initialization orchestrator that performs the major steps		# run() - The actual initialization orchestrator that performs the major steps

	==== Phase 1: Command Line & Configuration ====		=== Phase 1: Command Line & Configuration ===
	* Parses command line arguments ("help", "version", config file)		* Parses command line arguments ("help", "version", config file)
	* Sets the default config file: <code>/etc/aquarium_control/aquarium_control.toml</code>		* Sets the default config file: <code>/etc/aquarium_control/aquarium_control.toml</code>
	* Loads configuration and creates <code>ExecutionConfig</code> (boolean flags determining which modules to run)		* Loads configuration and creates <code>ExecutionConfig</code> (boolean flags determining which modules to run)

	==== Phase 2: System Setup ====		=== Phase 2: System Setup ===
	* Initializes the logging system		* Initializes the logging system
	* Logs version information and executable hash		* Logs version information and executable hash
Line 47:		Line 47:
	* Publishes process ID to file for client communication		* Publishes process ID to file for client communication

	==== Phase 3: Database & Hardware ====		=== Phase 3: Database & Hardware ===
	* Connects to database (MariaDB)		* Connects to database (MariaDB)
	* Creates component-specific SQL interfaces (<code>Schedule</code>, <code>Balling</code>, <code>Refill</code>, <code>Heating</code>, <code>Feed</code>, <code>Data</code>)		* Creates component-specific SQL interfaces (<code>Schedule</code>, <code>Balling</code>, <code>Refill</code>, <code>Heating</code>, <code>Feed</code>, <code>Data</code>)
Line 60:		Line 60:
	** Relay actuator (Controllino)		** Relay actuator (Controllino)

	==== Phase 4: Communication Channels ====		=== Phase 4: Communication Channels ===
	* Creates the <code>Channels</code> struct containing ~30+ inter-thread communication channels		* Creates the <code>Channels</code> struct containing ~30+ inter-thread communication channels
	* Uses custom <code>AquaSender</code>/<code>AquaReceiver</code> wrappers for MPSC channels		* Uses custom <code>AquaSender</code>/<code>AquaReceiver</code> wrappers for MPSC channels
	* Establishes bidirectional and unidirectional message paths between all modules		* Establishes bidirectional and unidirectional message paths between all modules

	==== Phase 5: Component Initialization ====		=== Phase 5: Component Initialization ===
	Instantiates all high-level control components:		Instantiates all high-level control components:
	* data logger		* data logger
Line 80:		Line 80:
	* IPC messaging system		* IPC messaging system

	==== Phase 6: Thread Spawning ====		=== Phase 6: Thread Spawning ===
	* Uses <code>std::thread::scope</code> for guaranteed cleanup		* Uses <code>std::thread::scope</code> for guaranteed cleanup
	* Spawns threads conditionally based on <code>ExecutionConfig</code> flags		* Spawns threads conditionally based on <code>ExecutionConfig</code> flags
	* Critical: A 3-second startup delay allows sensors to acquire first data before control loops activate		* Critical: A 3-second startup delay allows sensors to acquire first data before control loops activate

	==== Architecture of thread configuration ====		=== Architecture of thread configuration ===
	* The <code>Channels</code> module (<code>src/launch/channels.rs</code>) acts as a central wiring diagram, with the Signal Handler serving as the main event coordinator.		* The <code>Channels</code> module (<code>src/launch/channels.rs</code>) acts as a central wiring diagram, with the Signal Handler serving as the main event coordinator.
	* The <code>ExecutionConfig</code> decouples configuration from execution - threads only receive flags about which modules are active, not the full config - this also avoids ownership issues.		* The <code>ExecutionConfig</code> decouples configuration from execution - threads only receive flags about which modules are active, not the full config - this also avoids ownership issues.

	=== Threads ===		== Threads ==
	The application spawns the following threads:		The application spawns the following threads:
	{\| class="wikitable" style="margin:auto"		{\| class="wikitable" style="margin:auto"
Line 138:		Line 138:
	\|}		\|}

	== Measurement using Atlas Scientific circuits ==		= Measurement using Atlas Scientific circuits =
	The core Abstraction (<code>AtlasScientificDriver</code> Trait) is defined in <code>src/sensors/atlas_scientific_driver.rs</code>, this trait serves as the common interface for all sensor types. It enforces three key behaviors:		The core Abstraction (<code>AtlasScientificDriver</code> Trait) is defined in <code>src/sensors/atlas_scientific_driver.rs</code>, this trait serves as the common interface for all sensor types. It enforces three key behaviors:
	* <code>send_request_to_i2c_interface</code>: Encapsulates how to trigger a measurement (e.g., constructing specific I2C commands).		* <code>send_request_to_i2c_interface</code>: Encapsulates how to trigger a measurement (e.g., constructing specific I2C commands).
Line 173:		Line 173:
	This design enables the system to mix and match sensor types (e.g., an OEM type pH sensor circuit with an EZO type temperature sensor circuit) purely through configuration changes.		This design enables the system to mix and match sensor types (e.g., an OEM type pH sensor circuit with an EZO type temperature sensor circuit) purely through configuration changes.

	== Monitors ==		= Monitors =
	The Monitors module (<code>src/watchmen/monitors.rs</code>) is a dedicated thread that aggregates and stores historical system state information.		The Monitors module (<code>src/watchmen/monitors.rs</code>) is a dedicated thread that aggregates and stores historical system state information.
	It interacts with the following modules:		It interacts with the following modules:
Line 186:		Line 186:

	The number of samples is also limited (rolling window), to avoid overflow.		The number of samples is also limited (rolling window), to avoid overflow.

			= Commissioning =
			For the commissioning of the aquarium control, there is a separate binary which resides in <code>src/bin/commissioning.rs</code>.