NAME App::Device::Chip::sensor - Base class to build Device::Chip::Sensor-based applications on SYNOPSIS #!/usr/bin/perl use v5.26; use Object::Pad; use Future::AsyncAwait; class App extends App::Device::Chip::sensor { method output_readings ( $now, $sensors, $values ) { print "At time $now, we have some sensor values...\n"; } } await App->new->parse_argv->run; DESCRIPTION This module provides a base class to assist in writing applications that process data periodically from one or more Device::Chip-based sensors, via the Device::Chip::Sensor interface. A typical program using this module would derive a subclass from it, provide the remaining methods as necessary, and eventually call the "run" method to start the application. COMMANDLINE OPTIONS The following commandline options are recognised by the base class and may be used in addition to any defined by the actual application logic. * --blib, -b Uses the blib module to add additional paths into @INC to search for more Perl modules. May be useful when testing chip drivers under development without needing to install them. * --interval, -i TIME Specifies the time, in seconds, between every round of collecting sensor readings and invoking the "output_readings" method. Defaults to 10 seconds. * --adapter, -A STR Adapter configuration string to pass to "new_from_description" in Device::Chip::Adapter to construct the chip adapter used for communication with the actual chip hardware. * --filter, -F STR Specifies the kind of filtering to apply to gauge values. See "FILTERING" for more detail. * --mid3, -m Enable "middle-of-3" filtering of gauge values, to reduce sensor noise from unreliable sensors. This is equivalent to setting -F mid3. * --best-effort, -B Enables best-effort mode, which causes failures of sensor readings to be ignored, reporting undef instead. In this mode, the on_sensor_fail method may be invoked for failures; it can further refine what the behaviour should be. PROVIDED METHODS The following methods are provided on the base class, intended for subclasses or applications to invoke. parse_argv $app->parse_argv(); $app->parse_argv( \@argv ); Provides a list of commandline arguments for parsing, either from a given array reference or defaulting to the process @ARGV if not supplied. This uses "OPTSPEC" to collect the defined arguments, whose references should handle the results. add_chip $app->add_chip( %config ); Since version 0.05. Adds a new chip to the stored configuration, as if it had been given as a commandline argument. Takes the following named arguments: type => STR Required string that gives the name of the chip class. adapter => Device::Chip::Adapter Required Device::Chip::Adapter instance. mountopts => HASH Optional HASH reference containing extra mount parameters. config => HASH Optional HASH reference containing extra chip configuration to set up using the configure method once mounted. chips @chips = await $app->chips; An asynchronous memoized lazy accessor for the list of Device::Chip instances, whose class names are taken from the remaining commandline arguments after the options are parsed. sensors @sensors = await $app->sensors; An asynchronous memoized lazy accessor for the list of Device::Chip::Sensor instances of each of the configured chips (from the "chips" method). run await $app->run; An asynchronous method which performs the actual run loop of the sensor application. This implements the main application logic, of regular collection of values from all of the sensor instances and reporting them to the "output_readings" method. In normal circumstances the Future instance returned by this method would remain pending for the lifetime of the program, and not complete. For an application that has nothing else to perform concurrently it can simply await this future to run the logic. If it has other logic to perform as well it could combine this with other futures using a Future->needs_all or similar techniques. print_readings $app->print_readings( $sensors, $values ); Prints the sensor names and current readings in a human-readable format to the currently-selected output handle (usually STDOUT). REQUIRED METHODS This base class itself is incomplete, requiring the following methods to be provided by an implementing subclass to contain the actual application logic. output_readings $app->output_readings( $now, $sensors, $values ); This method is invoked regularly by the "run" method, to provide the application with the latest round of sensor readings. It is passed the current UNIX epoch timestamp as $now, an array reference containing the individual Device::Chip::Sensor instances as $sensors, and a congruent array reference containing the most recent readings taken from them, as plain numbers. The application should put the bulk of its processing logic in here, for example writing the values to some sort of file or database, displaying them in some form, or whatever else the application is supposed to do. OVERRIDABLE METHODS The base class provides the following methods, but it is expected that applications may wish to override them to customise the logic contained in them. If using Object::Pad to do so, don't forget to provide the :override method attribute. OPTSPEC %optspec = $app->OPTSPEC; This method is invoked by the "parse_argv" method to construct a definition of the commandline options understood by the program. These are returned in a key/value list to be processed by Getopt::Long. If the application wishes to parse additional arguments it should override this method, call the superclass version, and append any extra argument specifications it requires. As this is invoked as a regular instance method, a convenient way to store the parsed values is to pass references to instance slot variables created by the Object::Pad field keyword: field $_title; field $_bgcol = "#cccccc"; method OPTSPEC :override { return ( $self->SUPER::OPTSPEC, 'title=s' => \$_title, 'background-color=s' => \$_bgcol, ); } after_sensors await $app->after_sensors( @sensors ); This method is invoked once on startup by the "run" method, after it has configured the chip adapter and chips and obtained their individual sensor instances. The application may wish to perform one-time startup tasks in here, such as creating database files with knowledge of the specific sensor data types, or other such behaviours. on_sensor_ok $app->on_sensor_ok( $sensor ); This method is invoked in --best-effort mode after a successful reading from sensor; typically this is used to clear a failure state. The default implementation does nothing. on_sensor_fail $app->on_sensor_fail( $sensor, $failure ); This method is invoked in --best-effort mode after a failure of the given sensor. The caught exception is passed as $failure. The default implementation prints this as a warning using the core warn() function. FILTERING The --filter setting accepts the following filter names null No filtering is applied. Each sensor reading is reported as it stands. midn The most recent n values are sorted, and the middle of these is reported. To be well-behaved, n should be an odd number. (mid3, mid5, mid7, etc...) ravgn Recursive average with weighting of 2 ** -n. AUTHOR Paul Evans <leonerd@leonerd.org.uk>