Aquarium-Control - Recent changes [en]

Control application

Uwe — Sat, 01 Aug 2026 09:42:44 GMT

Using llvm-cov

Event-based deletion of old database entries

Uwe — Fri, 24 Jul 2026 05:58:36 GMT

User privileges

← Older revision		Revision as of 07:58, 24 July 2026
(3 intermediate revisions by the same user not shown)
Line 43:		Line 43:

	== Configuration of MariaDb ==		== Configuration of MariaDb ==
	Activate the event scheduler by adding the two last lines of below example to MariaDb configuration file (usually <code>/etc/mysql/my.cnf</code>).		Activate the event scheduler by adding the two last lines of below example to MariaDb configuration file (usually <code>/etc/mysql/my.cnf</code> or <code>/etc/mysql/mariadb.conf.d/50-server.cnf</code>).

	<pre>		<pre>
Line 86:		Line 86:

	== User privileges ==		== User privileges ==
	Check if your database user account has sufficient privileges by running <code>~~show grants for~~ user@localhost;</code>.		Check if your database user account has sufficient privileges by running <code>SHOW GRANTS FOR user@localhost;</code>.

	You can assign specific privilege for executing events by running ~~<code>GRANT ALL PRIVILEGES ON `your_database_name`.* TO 'your_username'@'localhost';</code>.~~		You can assign specific privilege for executing events by running:

	~~Alternatively, you can assign all privileges to your database user account by running~~ <code>GRANT ~~ALL PRIVILEGES~~ ON `your_database_name`.* TO 'your_username'@'localhost';</code>.		<code>GRANT EVENT ON `your_database_name`.* TO 'your_username'@'localhost';</code>

	~~In both cases, run additionally~~ <code>FLUSH PRIVILEGES;</code>.		and

			<code>GRANT EXECUTE ON `your_database_name`.* TO 'your_username'@'localhost';</code>

			and

			<code>GRANT SUPER ON . TO 'your_username'@'localhost';</code>

			and

			<code>FLUSH PRIVILEGES;</code>.

	== Restart of MariaDb ==		== Restart of MariaDb ==
Line 132:		Line 142:

	== Adding events ==		== Adding events ==
	The repository of the database contains a script <code>~~database_cleanup_setup~~.sh</code>.		The repository of the database contains a script <code>aquariumcontrol_database_cleanup_setup.sh</code>.
	The script will set up the cleanup for the following tables:		The script will set up the cleanup for the following tables:
	{\| class="wikitable"		{\| class="wikitable"

SQL database

Uwe — Sat, 18 Jul 2026 17:08:31 GMT

Configuration of connection timeout

← Older revision		Revision as of 19:08, 18 July 2026
(2 intermediate revisions by the same user not shown)
Line 116:		Line 116:
	\| heating \|\| 0:00 \|\| 23:59 \|\| 0		\| heating \|\| 0:00 \|\| 23:59 \|\| 0
	\|}		\|}

			=== Configuration of connection timeout ===
			Edit the file <code>/etc/mysql/mariadb.conf.d/50-server.cnf</code> and add <code>wait_timeout = 10000</code> at the bottom of the <code>[mysqld]</code> block.

			Restart the database afterwards with <code>sudo systemctl restart mariadb</code>.

			This avoids connection timeouts. The application checks this configuration during startup.

			You can verify the change with the SQL command <code>SHOW VARIABLES LIKE '%timeout%';</code>.

Use of an asynchronous runtime for the main application

Uwe — Sun, 12 Jul 2026 09:16:03 GMT

Overview

← Older revision		Revision as of 11:16, 12 July 2026
(7 intermediate revisions by the same user not shown)
Line 1:		Line 1:
	= Overview =		= Overview =
	The Aquarium Control application uses a hybrid execution model to balance responsiveness, low latency, and hardware constraints. It uses the Tokio asynchronous runtime for coordinating sensor logging, network communication, safety interlocks, and scheduling. Concurrently, it spawns dedicated native operating system threads for operations requiring strict timing or blocking I/O (such as direct GPIO sensor reading).		The Aquarium Control application uses a hybrid execution model to balance responsiveness, low latency, and hardware constraints. It uses the Tokio asynchronous runtime for coordinating sensor logging, network communication, safety interlocks, and scheduling. Concurrently, it spawns dedicated native operating system threads for operations requiring strict timing or blocking I/O (such as direct GPIO sensor reading).

	== Task and Thread Inventory ==		== Task and Thread Inventory ==
Line 132:		Line 132:
	=== Developer Diagnostics with Tokio Console ===		=== Developer Diagnostics with Tokio Console ===

	For runtime inspection, task profiling, and detecting deadlocks or starvation, you can run the application with Tokio Console integration.		For runtime inspection, task profiling, and detecting deadlocks or starvation, you can run the application with Tokio Console integration.

	==== Prerequisites & Compilation ====		==== Prerequisites & Compilation ====
Line 144:		Line 144:

	==== Running and Reading ====		==== Running and Reading ====
	1. Launch the compiled application:		# Launch the compiled application:
	2. Open a separate terminal window and run <code>tokio-console</code>.		# Open a separate terminal window and run <code>tokio-console</code>.
	This presents a live dashboard of running tasks, showing busy poll times, total lifetime, and idle periods.		This presents a live dashboard of running tasks, showing busy poll times, total lifetime, and idle periods.

			[[File:tokio-console.png \| center \| 800px \| Screenshot of tokio-console during execution of the main application.]]

	=== Interpreting Task Size Warnings ===		=== Interpreting Task Size Warnings ===

File:Tokio-console.png

Uwe — Sat, 11 Jul 2026 11:43:37 GMT

Uwe uploaded File:Tokio-console.png Screenshot of tokio-console during execution of main application

New page

== Summary ==
Screenshot of tokio-console during execution of main application

Use of an asynchronous runtime for the main application

Uwe — Sat, 11 Jul 2026 11:42:15 GMT

Overview

← Older revision		Revision as of 13:42, 11 July 2026
(10 intermediate revisions by the same user not shown)
Line 1:		Line 1:
	= Overview =		= Overview =
	The Aquarium Control application uses a hybrid execution model to balance responsiveness, low latency, and hardware constraints. It uses the Tokio asynchronous runtime for coordinating sensor logging, network communication, safety interlocks, and scheduling. Concurrently, it spawns dedicated native operating system threads for operations requiring strict timing or blocking I/O (such as direct GPIO sensor reading).		The Aquarium Control application uses a hybrid execution model to balance responsiveness, low latency, and hardware constraints. It uses the Tokio asynchronous runtime for coordinating sensor logging, network communication, safety interlocks, and scheduling. Concurrently, it spawns dedicated native operating system threads for operations requiring strict timing or blocking I/O (such as direct GPIO sensor reading).

	~~---~~

	== Task and Thread Inventory ==		== Task and Thread Inventory ==
Line 125:		Line 123:
	The Tokio runtime is explicitly built at startup with a constrained configuration:		The Tokio runtime is explicitly built at startup with a constrained configuration:

	<~~syntaxhighlight lang="rust" line~~>		<code>
			let rt = tokio::runtime::Builder::new_multi_thread().worker_threads(1).max_blocking_threads(4).enable_all().build()
	let rt = tokio::runtime::Builder::new_multi_thread()		</code>
	.worker_threads(1)
	.max_blocking_threads(4)
	.enable_all()
	.build()
	<~~syntaxhighlight~~>

	=== Why this configuration is chosen ===		=== Why this configuration is chosen ===
	~~1. `~~worker_threads(1)`: The application runs on Raspberry Pi. Limiting the event loop scheduler to one worker thread minimizes CPU context-switching overhead and prevents resource exhaustion.		# <code>worker_threads(1)</code>: The application runs on Raspberry Pi. Limiting the event loop scheduler to one worker thread minimizes CPU context-switching overhead and prevents resource exhaustion.
	~~2. `~~max_blocking_threads(4)`: Restricting the blocking thread pool prevents the runtime from spawning too many concurrent threads when database pings, file operations, or synchronous calculations are invoked (such as via `tokio::task::spawn_blocking` or `block_in_place`).		# <code>max_blocking_threads(4)</code>: Restricting the blocking thread pool prevents the runtime from spawning too many concurrent threads when database pings, file operations, or synchronous calculations are invoked (such as via <code>tokio::task::spawn_blocking</code> or <code>block_in_place</code>).

	=== Developer Diagnostics with Tokio Console ===		=== Developer Diagnostics with Tokio Console ===
Line 144:		Line 136:
	==== Prerequisites & Compilation ====		==== Prerequisites & Compilation ====
	Tokio Console requires unstable instrumentation.		Tokio Console requires unstable instrumentation.
	1. Use the `debug_tokio` feature flag, which initializes the `console-subscriber` in `run.rs`:		# Use the <code>debug_tokio</code> feature flag, which initializes the <code>console-subscriber</code> in <code>run.rs</code>: <code>RUSTFLAGS="--cfg tokio_unstable" cargo build --features "debug_tokio"</code>
	~~```bash~~		# The <code>tokio_unstable</code> compiler flag ensures that Tokio exposes internal tracing endpoints (like the task builder names).
	RUSTFLAGS="--cfg tokio_unstable" cargo build --features "debug_tokio"
	~~```~~
	2. The `tokio_unstable` compiler flag ensures that Tokio exposes internal tracing endpoints (like the task builder names).

	==== Installing the Terminal Console ====		==== Installing the Terminal Console ====
	Install the client CLI on your development machine (macOS/Linux) via Cargo:		Install the client CLI on your development machine (macOS/Linux) via Cargo:
	~~```bash~~		<code>cargo install --locked tokio-console</code>
	cargo install --locked tokio-console
	~~```~~

	==== Running and Reading ====		==== Running and Reading ====
	1. Launch the compiled application:		1. Launch the compiled application:
	2. Open a separate terminal window and run:		2. Open a separate terminal window and run <code>tokio-console</code>.
	~~```bash~~
	tokio-console
	~~```~~
	This presents a live dashboard of running tasks, showing busy poll times, total lifetime, and idle periods.		This presents a live dashboard of running tasks, showing busy poll times, total lifetime, and idle periods.

	=== Interpreting Task Size Warnings ===		=== Interpreting Task Size Warnings ===
	When checking with `tokio-console`, you see warnings that tasks like `signal_handler`, `relay_manager`, `data_logger`, or `heating` are 1024 bytes or larger.		When checking with <code>tokio-console</code>, you see warnings that tasks like <code>signal_handler</code>, <code>relay_manager</code>, <code>data_logger</code>, or <code>heating</code> are 1024 bytes or larger.
	~~* ~~These warnings can be safely ignored.**		* These warnings can be safely ignored.
	* The size refers to the stack footprint of the compiler-generated `Future` state machine. In debug builds, these are larger due to lack of optimization.		* The size refers to the stack footprint of the compiler-generated <code>Future</code> state machine. In debug builds, these are larger due to lack of optimization.
	* Because these tasks are long-lived workers spawned once at startup and run until shutdown, they are allocated on the heap only once. A 1–2 KiB heap footprint has zero impact on application performance, fragmentation, or memory leaks.		* Because these tasks are long-lived workers spawned once at startup and run until shutdown, they are allocated on the heap only once. A 1–2 KiB heap footprint has zero impact on application performance, fragmentation, or memory leaks.