Home

Status

The ModuleInterface library currently transfers:

• Measurements between modules on a subscription basis at regular intervals
• Measurements to database via web server at regular intervals
• Settings from web server to modules at regular intervals
• Event-triggered immediate measurement(s) between modules in addition to at regular intervals

And it has a proposed database scheme and php scripts to transfer values between database and modules and between database and a web page that uses JavaScript. All lined up to let a user create hardware modules and web pages for configuring and inspecting them.

Plans

Some features currently on the drawing board:

• Support for two-way synchronization of settings for modules that have a local user interface like a LCD display and buttons, joystick or rotary encoder. In this way, configuration changes performed on a physical module will show up in the web pages and vica versa.
• (Done) New database scheme with a current-value table and transfer from this to the time-series table. This will allow only a subset of measurements to be logged versus time, while the current value for all will always be available in the first table. It will also make it smoother with larger setups where multiple ModuleInterface masters use the same database.
• (Done) Avoid keeping variable names (settings, inputs, outputs) in RAM, and also support having the contracts in program memory only to save more RAM
• "Broadcast" events so that modules can subscribe to a topic instead of outputs from multiple modules
• Test InfluxDb (MIT license) as an alternative for storage of historical values for large setups.

It is also intended to include a whole working setup as an example:

• A couple of basic modules with settings, inputs and outputs
• A master transferring values between the modules and talking to a web server
• A MariaDb/MySQL database
• An Apache web server
• A simple web page showing live values in plots and tables, and letting the user configure the modules in a table