The Configuration Concept

See also:: Registry: The Object Register

Solarpowerlog uses libconfig as configuration backend.

On startup it loads a file and extracts the configuration for the individual components.

The settings are structured to the indivdual sections, like general settings, settings for inverters, settings for the loggers.

The program parses the basic layout of configuration.

Out of the infos stored in configuration, the program generates a number of objects.

The generated object will be told its own configuration path (in libconfig notation) to allow it to extract its own configuration. (This makes us the the live easier, as we do not need to care which configuration items a object requires: It knows best.)

Registry: The Object Register

See also:: Registry

The class Registry also maintains a list of all objects it has created during startup. At the moment these are Inverters and Loggers.

This allows other components to search for other components by its name.

Solarpowerlog will make sure, that no objects will exist with identical name.

The Work Scheduler

See also:: CWorkScheduler

The Registry also maintains one CWorkScheduler object which is can be used by all objects.

Note:: By sharing one scheduler for all objects, the objects does not need to care about concurrency, as all the work is done sequencially. This is also true for timed work.

See also:: CWorkScheduler, ICommand, ICommandTarget

Default Scheduler example code

This example code shows how to schedule work using the main scheduler:

          // Schedule the initialization and subscriptions later...
          ICommand *cmd = new ICommand(CMD_INIT, this, 0);
          Registry::GetMainScheduler()->ScheduleWork(cmd);

This example shows the usage with Timed Work. (1 second)

          timespec ts = { 1, 0 };
          ICommand *cmd = new ICommand(CMD_INIT, this, 0);
          Registry::GetMainScheduler()->ScheduleWork(cmd, ts);