1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
//! Controller templates with defined scheduling, and a variety of input/output configurations.
//!
//! Each controller internally handles scheduling and performs reads and activates/deactivates outputs
//! accordingly. Most controller implementations operate on intervals (e.g.: 1 second intervals), however
//! it is possible to create a controller instance that schedules events in any way. For example, the
//! [`TimedOutput`] controller actuates its output at a certain time every day for a set duration.
//!
//! Each controller defines a [`poll()`](Controller::poll) function, which returns a [`Option<Message>`].
//! When a controller is polled, it evaluates whether an [`Action`](crate::types::Action) should be performed or not.
//! If an [`Action`](crate::types::Action) is performed, a [`Message`] is returned for logging.
//!
//! The controllers are fully documented and contain potential use-cases, examples, and more detailed information.
use ;
pub use Threshold;
pub use BidirectionalThreshold;
pub use TimedOutput;
use crateMessage;
/// A trait that represents a named device that can be polled for events
///
/// There are no restrictions on the inputs or outputs of a controller, but
/// the controller must be able to be polled for events. Each instance of a
/// controller is responsible for responding to the poll request and performing
/// any necessary actions at the appropriate time.
///
/// Instances are not required to be named, however, the name is used for
/// logging purposes and will be contained in the `Message` returned by the
/// `poll` method.