Configuration system

[scalablecory]

Aether requires a configuration system. It must be able to save to a file to survive reboots.

This would describe things like:

• What sensors are enabled.
  • I²C/etc. addresses.
  • Dependencies.
• What displays are enabled.
  • SPI/etc. addresses.
  • Which theme to use, and what measurements/sensors to use in the theme.

[AkwasiAkosah]

Configuration. Happy to learn

[scalablecory]

So the basic goal here is to store all the things needed to instantiate the app.

The instantiation itself might be handled by the glue layer, but needs to inform the design of the config.

1. Open each configured device as an I2cDevice.
2. Open each sensor against its I2cDevice.
   • Note sensors can depend on each-other, e.g. the SCD4x takes a dependency on barometric pressure to calibrate itself. So, sensors must be initialized in order of dependency and config must track these dependencies.
3. Open display devices (e-Ink screen, RGB strips, Zigbee, etc.)
4. Bind sensors to display devices.

[AkwasiAkosah]

Are there any suggestions on how to start? Or any documentation you think might be helpful.
Sorry if I am asking too many questions

[scalablecory]

From a high level, I think the in-memory config could look something like this:

class RootConfig
{
    List<SensorConfig> Sensors;
    List<Theme> Themes;
}

class SensorConfig
{
    // used to lookup a sensor factory.
    string SensorName;

    GpioAddress Address;

    // used by e.g. the SCD40 that has a dependency on barometric pressure.
    List<Measure> Dependencies;
}

class GpioAddress
{
    int? I2cBus;
    int? I2cAddress;

    // I2C is well defined right now, but others aren't. We can add on later.
    // int? SpiAddress;
    // List<int> GpioPins;
}

class ThemeConfig
{
    // used to lookup a theme factory similar to SensorInfo factories; not made yet.
    string ThemeName;

    // a theme can have more than one spot to draw a measurement; this fills in the spots.
    List<Measure> ThemeMeasures;

    // the display to run the theme on.
    DisplayConfig Display;
}

class DisplayConfig
{
    // used to lookup a display factory similar to SensorInfo factories; not made yet.
    string DisplayName;
    GpioAddress Address;
}

And then we'll need some sort of load/save mechanism that the glue layer can call:

RootConfig config = await RootConfig.LoadAsync("path/to/config.txt");
await RootConfig.SaveAsync("path/to/config.txt", config);

In existing code, you can see an I2C sensor factory being looked up by name and instantiated, by user-provided "config" (command line inputs) here:

aether/src/Aether/Program.cs

Lines 36 to 45 in 6df481e

	testi2cSensorCommand.Handler = CommandHandler.Create((string name, uint bus, uint address) => RunAndPrintSensorAsync(() =>
	{
	SensorInfo? sensorInfo = SensorInfo.Sensors.FirstOrDefault(x => x is I2cSensorInfo && string.Equals(x.Name, name, StringComparison.OrdinalIgnoreCase));
	return sensorInfo switch
	{
	I2cSensorInfo i2c => i2c.OpenDevice((int)bus, (int)address, Observable.Empty<Measurement>()),
	_ => throw new Exception("An I2C sensor by that name was not found.")
	};
	}));

And binding a theme to a display and (as a Subject) sensor output:

aether/src/Aether/Program.cs

Lines 65 to 69 in 6df481e

	var lines = new[] { Measure.CO2, Measure.Humidity, Measure.BarometricPressure, Measure.Temperature };
	using var driver = new SimulatedDisplayDriver("out", 296, 128, 112.399461802960f, 111.917383820998f);
	using var sub = new Subject<Measurement>();
	using IDisposable theme = MultiLineTheme.CreateTheme(driver, lines, sub);

[AkwasiAkosah]

I am assuming all these properties for the various classes should allow for getting and setting the values

[AkwasiAkosah]

In the process of initializing a giving sensor, is it safe to assume that the user knows information about the address of the device, name and other properties needed to establish the communication? Are we using any pre-made methods?

[scalablecory]

In the process of initializing a giving sensor, is it safe to assume that the user knows information about the address of the device, name and other properties needed to establish the communication? Are we using any pre-made methods?

If they are editing the file directly, yes.

If they use UI, some additional help is available: the SensorInfo class contains metadata for sensors like default address. SensorInfo.Sensors contains all supported sensors. Many users will be able to select their sensors from a list and use the defaults. Metadata for themes and displays will exist for the same usage.

[scalablecory]

aether/src/Aether/Devices/Sensors/Metadata/SensorInfo.cs

Lines 11 to 19 in 6df481e

	/// <summary>
	/// A collection of all sensors supported by Aether.
	/// </summary>
	public static IReadOnlyList<SensorInfo> Sensors { get; } = new List<SensorInfo>
	{
	new ConcreteI2CSensorInfo<ObservableScd4x>(),
	new ConcreteI2CSensorInfo<ObservableSht4x>(),
	new SimulatedI2cSensorInfo<ObservableMs5637>()
	};

aether/src/Aether/Devices/Sensors/Metadata/SensorInfo.cs

Lines 21 to 26 in 6df481e

	public abstract string Manufacturer { get; }
	public abstract string Name { get; }
	public abstract string Uri { get; }
	public abstract IEnumerable<MeasureInfo> Measures { get; }
	public abstract IEnumerable<SensorDependency> Dependencies { get; }
	public abstract IEnumerable<SensorCommand> Commands { get; }

aether/src/Aether/Devices/Sensors/Metadata/I2cSensorInfo.cs

Lines 5 to 8 in 6df481e

	internal abstract class I2cSensorInfo : SensorInfo
	{
	public abstract int DefaultAddress { get; }
	public abstract ObservableSensor OpenSensor(I2cDevice device, IObservable<Measurement> dependencies);