Home

Status

The ModuleInterface library currently transfers:

• Measurements between modules on a subscription basis
• Measurements to database via web server
• Settings from web server to modules
• Locally modified settings from modules to web server (reverse direction)
• Event-triggered immediate measurement(s) between modules in addition to at regular intervals
• Rough clock synchronization from web server to master to modules
• (optional) Bidirectional transfer of online values (inputs and outputs) through MQTT. This allows control of external systems, and allows values from external systems to be easily stored for archival and plotting.
• (optional) Bidirectional synchronization of settings through MQTT, meaning that modules, the web page and an external system connected through MQTT can be kept in sync. Changes in one of these three places will be transferred to the others, allowing external control of ModuleInterface systems while maintaining the full ModuleInterface functionality.

It has a SQL database schema 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.

It also includes 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 dynamic and responsive web page showing live values in plots and tables, letting the user configure the modules in a table. This can be a good starting point for your own setup.

Plans

Some features currently on the drawing board:

• Add MQTT event support to the MQTT connection, to make sure inputs to modules, outputs from modules and settings to and from modules can be flagged as events for more immediate transfer. This can be usable for light switches, motion detectors and so on where fast response is expected, instead of waiting for the next scheduled sync.
• Add support for values coming through MQTT to be archived in the database for use in the ModuleInterface web pages and plots. This will allow composite systems or external systems to be handled in the ModuleInterface web pages.
• Add support for settings in the ModuleInterface database to be sent through MQTT, for allowing external systems to be configured in the ModuleInterface web pages.
• Check that Linux compatibility also covers Raspberry PI (most likely it is covered by the Linux compatibility).
• Create a multi-threaded master for better scalability on multithreaded platforms.
• "Broadcast" events so that modules can subscribe to a topic instead of specific outputs from other modules.
• Add support for InfluxDb (MIT license) as an alternative for storage of historical values (though the current MySQL/MariaDb database schema keeps hundreds of tags for several years stored using little space and giving responsive historical plots over short or long time spans).
• Evaluate dynamic addressing schemes, see if identically flashed modules can be connected and be assigned unique and static ids/names when plugged in. This would help in commercial contexts, to create plug-and-play standard modules.

Recently completed features

• Added MQTT client functionality to the master so that ModuleInterface can be connected to other home automation systems, for mutual benefit. For example, devices like smart switches (Kasa, Shelly, etc) attached to Home Assistant or OpenHAB can be controlled from ModuleInterface modules or web pages. ModuleInterface can send e-mail or mobile phone notifications using plugins to the other systems (for example the PushBullet integration in Home Assistant). Or ModuleInterface modules can be controlled from Home Assistant or any other MQTT connected system. Settings are kept synchronized between modules, web pages and MQTT, so a change in one of these places will change the other two.
• Added presence broadcast to automatically re-establish network routes to allow modules to be moved from one router to another without restarting anything.
• Made the GenericModuleMasterHttp (DUDP) more dynamic by letting it pick up changes to the module list without having to be restarted. This means that after adding a new module physically, it is activated by adding it to the module list setting in the database (can be exposed in the web page as well).
• Added a collection of predefined metrics from master and modules to analyze/verify the data flow.
• Added a list of examples, with descriptions.
• Added a protocol description document.
• Added a ModuleInterface based PJON switch (router / media converter) that reports status and traffic statistics. This includes module response times, making it possible to identify modules that are slow to respond because of inefficient programming or bad connectivity / signal.
• ESP32 support added, examples using the PJON DualUDP strategy over WiFi.
• A generic master for Windows/Linux, using UDP to communicate with groups of devices. All configuration is retrieved from the web server at startup, meaning that the master will not have to be recompiled when adding/removing devices from the setup.
• Support for PJON network mode, having devices on multiple buses with different bus ids.
• Support for Linux and Windows. Master can now be run on the web server computer itself if needed.
• 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.
• WebPage example with instructions, Arduino sketches, database schema, web page files.
• New database schema 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.
• Avoid keeping variable names (settings, inputs, outputs) in RAM, and also support having the contracts in program memory only to save more RAM.