Struct ScheduleCheck

pub struct ScheduleCheck {
    config: ScheduleCheckConfig,
    locks_balling: ScheduleCheckLocks,
    locks_ventilation: ScheduleCheckLocks,
    locks_heating: ScheduleCheckLocks,
    locks_refill: ScheduleCheckLocks,
    lock_error_database_read: bool,
    pub last_ping_instant: Instant,
    pub database_ping_interval: Duration,
}

Contains the configuration and the implementation for the schedule checker. Thread communication is as follows:

graph LR schedule_check[Schedule check] --> ventilation[Ventilation control] ventilation --> schedule_check schedule_check --> heating[Heating control] heating --> schedule_check schedule_check --> refill[Refill control] refill --> schedule_check schedule_check --> balling[Balling dosing control] balling --> schedule_check schedule_check --> signal_handler[Signal handler] signal_handler --> schedule_check

Fields

config: ScheduleCheckConfig

configuration data for schedule checker

locks_balling: ScheduleCheckLocks

inhibition flags for Balling

locks_ventilation: ScheduleCheckLocks

inhibition flags for ventilation

locks_heating: ScheduleCheckLocks

inhibition flags for heating

locks_refill: ScheduleCheckLocks

inhibition flags for refill

lock_error_database_read: bool

inhibition flag to avoid flooding the log file with repeated messages about failure to read from the database

last_ping_instant: Instant

recording when the last database ping happened

database_ping_interval: Duration

database ping interval

Implementations

impl ScheduleCheck

pub fn new( config: ScheduleCheckConfig, database_ping_interval: Duration, ) -> ScheduleCheck

Creates a new ScheduleCheck instance.

This constructor initializes the schedule checking module with its specific configuration and a connection to the SQL database interface responsible for schedule data. It also sets up all internal lock flags to false, which are used to prevent log flooding during operation.

Arguments

• config - Configuration data for the schedule checker, dictating behavior like check intervals and strategies for missing schedules.
• database_ping_interval - A Duration instance, providing the interval to ping the database.

Returns

A new ScheduleCheck struct, ready to monitor and evaluate schedules.

fn check_pending_schedule_request( config: &ScheduleCheckConfig, tx: &mut AquaSender<bool>, rx: &mut AquaReceiver<InternalCommand>, schedule_entry: Option<&ScheduleEntry>, locks: &mut ScheduleCheckLocks, module_name: &str, )

Checks for and processes a pending ScheduleCheck request from another module.

This private helper function is called repeatedly for each control module (Balling, Refill, Ventilation, Heating). It attempts to receive a ScheduleCheck command without blocking. If received, it evaluates whether actuation is currently allowed based on the provided schedule_entry and the configured strategy_if_schedule_not_found. The result (a boolean) is then returned to the calling module.

The function uses several “lock” flags to prevent repetitive logging of the same error/warning.

Arguments

• config - A reference to the ScheduleCheckConfig for general strategy settings.
• tx - The sender channel to send the bool result (actuation allowed/disallowed) back to the requesting module.
• rx - The receiver channel to receive InternalCommand (specifically ScheduleCheck) from the requesting module.
• schedule_entry - An Option containing the ScheduleEntry relevant to the requesting module, or None if no schedule was found for that module.
• lock_error_channel_receive - A mutable reference to a boolean flag that, when true, inhibits repeated error logging for channel receive failures.
• locks - A mutable reference to the struct containing the lock flags.
• module_name - Name of the module for which the schedule shall be checked for logging purposes.

fn find_schedule_check_request( schedule_type: ScheduleType, config: &ScheduleCheckConfig, thread_is_executed: bool, sql_interface_schedule: &SqlInterfaceSchedule, locks: &mut ScheduleCheckLocks, module_name: &str, channel_pair: (&mut AquaSender<bool>, &mut AquaReceiver<InternalCommand>), )

Finds the relevant schedule for a module and processes any pending requests.

This is a helper function designed to reduce repetitive logic in the main execute loop. It encapsulates the full sequence of actions for a single client module (e.g., “ventilation”, “heating”).

The function first checks if the target module’s thread is running. If so, it attempts to find the corresponding schedule entry from the in-memory cache (if config.active is true). It handles any errors during this lookup, using the provided locks to prevent log flooding on repeated failures.

Finally, it delegates the task of channel communication (receiving a request and sending a reply) to the check_pending_schedule_request function.

Arguments

• config - A reference to the main ScheduleCheckConfig.
• thread_is_executed - A boolean indicating if the target client module’s thread is active.
• sql_interface_schedule - The database interface used to find the schedule entry.
• locks - A mutable reference to the log-suppression flags for the specific client module.
• action - The name of the client module (e.g., “ventilation”), used for logging.
• schedule_check_channels - A mutable reference to the struct containing all communication channels.

pub fn execute( &mut self, schedule_check_channels: &mut ScheduleCheckChannels, execution_config: ExecutionConfig, sql_interface_schedule: SqlInterfaceSchedule, )

Executes the main control loop for the schedule checker.

This function runs continuously, managing the validation of various device schedules against the current time. It periodically reads the latest schedule entries from the SQL database and, for each relevant module (Ventilation, Heating, Refill, Balling), it checks if that module is currently allowed to actuate its devices based on its schedule. The result of this check is communicated back to the respective module via channels.

The loop continues until a Quit command is received from the signal handler. Upon receiving Quit, it sends a confirmation back to the signal handler and then waits for a Terminate command to complete its shutdown.

Arguments

• schedule_check_channels - A ScheduleCheckChannels struct containing all necessary mpsc sender and receiver channels for communication with other application modules and the signal handler.
• execution_config - An ExecutionConfig struct containing information about which threads have been started.
• sql_interface_schedule - A SqlInterfaceSchedule instance providing the interface to the SQL database for retrieving schedule entries.

Trait Implementations

impl DatabasePingTrait for ScheduleCheck

fn get_ping_interval(&self) -> Duration

Gets the interval at which the resource should be pinged.

fn get_last_ping_instant(&self) -> Instant

Gets the timestamp of the last successful ping.

fn update_last_ping_instant(&mut self)

Updates the timestamp of the last successful ping.

fn check_timing_and_ping_database( &mut self, database_interface: &mut (impl Pingable + ?Sized), )

Pings the database.

impl ProcessExternalRequestTrait for ScheduleCheck

fn process_external_request( &mut self, rx_from_signal_handler: &mut AquaReceiver<InternalCommand>, _: Option<&mut AquaReceiver<InternalCommand>>, ) -> (bool, bool, bool)

Checks for and processes new commands relevant to the Schedule Check module from external channels.

This is the specialized implementation of ProcessExternalRequestTrait for ScheduleCheck. It delegates directly to process_external_request_without_messaging, indicating that the ScheduleCheck module only processes commands from the signal handler and ignores any input from a messaging channel.

Arguments

• rx_from_signal_handler - A reference to the receiver end of the channel for commands originating from the signal handler.
• _ - This parameter is ignored, as the ScheduleCheck module does not process messages from a messaging channel.

Returns

A tuple (bool, bool, bool) indicating the status of commands received:

• The first bool is true if a Quit command was received; otherwise false.
• The second bool is always false (no “Start” commands processed).
• The third bool is always false (no “Stop” commands processed).