Module schedule_check

Schedule checker centralizes all communication to the database in regard to permission to run. The implementation polls the database and answers requests from the threads with the information retrieved from the database. Implements the central, schedule-based permission controller for the application.

This module provides the ScheduleCheck struct, which runs as a dedicated, long-running thread. Its primary responsibility is to act as a centralized “permission oracle” for modules Ventilation, Heating, Refill, and Balling. It determines whether these modules are allowed to perform their actions (e.g., turn on a pump or heater) based on time-based schedules stored in the database.

Key Components

• ScheduleCheck Struct: The core state machine for the thread. It holds the configuration and a set of ScheduleCheckLocks for each client module. These locks are a crucial part of its design, used to prevent the same recurring error or warning from flooding the log files.

• execute() Method: The main thread loop. It operates in two modes simultaneously:

  1. Proactive Caching: It periodically re-reads all schedules from the database, caching the results in memory. This reduces database load, as it avoids querying on every single request.
  2. Reactive Service: In each loop iteration, it polls the channels from each client module (Heating, Refill, etc.), checking for incoming requests.

• check_pending_schedule_request() Method: The workhorse function that handles a single request. It performs a non-blocking try_recv on a client’s channel. If a ScheduleCheck command is found, it consults the cached schedule. Based on the schedule entry (or a configured fallback strategy if none is found), it sends a simple true (allowed) or false (disallowed) reply to the client.

Design and Architecture

This module is a cornerstone of the application’s concurrent design, promoting decoupling and robustness.

• Centralized Permission Logic: By centralizing all schedule-based checks, this module simplifies the logic in all other hardware-controlling modules. A module like Heating doesn’t need to know anything about database queries or time calculations; it only needs to ask ScheduleCheck for permission.

• Robust Error Handling (Log Flood Prevention): The extensive use of ScheduleCheckLocks is a deliberate design choice for a resilient, long-running service. If a recurring problem occurs (e.g., a missing schedule in the database), the error is logged once. The lock is then engaged to suppress identical log messages until the underlying condition is resolved. This prevents a single, persistent issue from filling up disk space with repetitive logs.

• Decoupled Request/Reply Pattern: The communication is based on a simple and effective request/reply pattern. A client sends a request and waits for a boolean response. This decouples the client modules from the implementation details of the permission logic.

Structs

ScheduleCheck

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

ScheduleCheckLocks

Contains all inhibition flags for a specific schedule communication