The key features of the configuration system are that it must be easy to:
- update changes, e.g. switch x has to control appliance z instead of appliance y,
- integrate new functionality, e.g. when a new type of appliance is put into action,
- upgrade the operating system of the local controllers so no physical action is needed in the field, e.g. bug fixes.


The configuration system is based on an array linking input variables over modules to output variables. As an examle of such a module, let us take a switch with a delayed off function. The symbolic array entries would be:

x.status >> switch-delay with id=y, input1 >> y.status
constant >> switch-delay with id=y, input2 >> y.delay-setting


On each microcontroller, a second array maps the hardware pins, it looks like this:

some hardware pin on this controller >> switch with id=x, input1 >> x.status
y.status >> relais with id=z, input1 >> some hardware pin on this controller

Note that the hardware mapping must reside on the microcontroller where the actual hardware is to be found. The switch-delay module entries can be anywhere in the network. This implies that the variables should be broadcasted over the network. However to limit traffic, a flag is added to all variables to know if they are needed elsewhere.


The only way that the delay setting of the module can be seen over the network is by resetting it, not very handy. Furthermore, it would be nice to get the complete configuration: one more input is added to the module:

c.configuration-request >> switch-delay with id=y, input0 >> y.configuration


Likewise we can add an input to the actuator modules to know if the appliance is on:

c.status-request >> relais with id=z, input0 >> y.status


This plan is still to be seen as a draft, please feel free to post comments on the forum.