m2ag.labs iot framework block diagram

m2ag.labs IoT framework

The m2ag.labs IoT framework is a collection of techniques for running very capable IoT devices completely disconnected from any specific cloud provider. The framework, currently in pre-alpha, is an moderately opinionated implementation that seeks to cover the basics of communication, security and configuration of most IoT devices needs. The implementor will have a consistent framework with which to start projects with and only need to focus on the IoT functionality to be implemented.

The framework itself is intended to be used inside a controlled firewall with no access to the internet. Because of this the self signed X509 certificates are used to provide SSL and MQTTS connectivity for the device.

The framework consists of several distinct parts:

  • API
  • UI
  • Action Engine
  • Logger
  • Device
  • COMM module
  • Device manager
  • Hardware interface
  • Multiple component modules to implement functionality

Installer:

A basic install script will ensure required elements are installed and put in a basic configuration. Initially there will be some configuration that is manually completed but as the framework matures a more complex installation and configuration system will be implemented.

API:

A REST API to allow access to logs database and configuration pages for the device. In general configuration is set through this API.

The API includes the device database which serves as the persistent memory for the device as well as configuration registers.

UI:

HTML5 based app to provide default access to both the config API and the Device. If device is a HUB, will coordinate a fleet of devices.

Initially just basic connectivity will be implemented. As the framework matures preconfigured modules will be used to allow basic UI of common components to displayed.

Device:

A device is the implementation of the IoT functionality. As the python app service is concerned – it manages MQTT comm, configuration changes and general live activities the specific application requires. Monitor a temperature or pressure and send an alarm. Did a position sensor change — send a message. Basic IoT stuff. Other aspects of the device implementation – the support services – are basic Linux/Raspberry PI configurations. The non-python functions of the device will require separate setup steps. These steps will be documented in the installer.

The device coordinates:

COMM module:

Is a generic interface to allow MQTT access. MQTTs is the mechanism for interacting with the IoT functionality.

Each device may be its own MQTT server, or it may connect to a central MQTT server so that events can be aggregated.  The architecture supports connecting to cloud services in a on your own terms manner. The implementor has complete control of what data gets sent to the cloud, if any.

Device manager:

The device manager coordinates activity between the COMM, API and Hardware. Events are monitored and generated here (TBD a better location — probably on the logger service)

Hardware manager:

Handles command processing amongst the python monitored modules. This module contains a list of submodules that comprise the actual implementation of functionality. An object representing the exposed functionality of a module can be addressed in a simple yet expressive manner that can cause any state change that may be required for the implementation.

Component Modules:

 Generally the object will wrap an hardware item – like a bmp280. The framework will generally wrap an Adafruit Circuit Python library for the module with helpers to facilitate standardized data transfer over the mqtt interface.

Component modules may aggregate components to abstract an more complicated component. The comm framework strives to be agnostic to message traffic.

In general — gpizero will be wrapped to implement desired functionality. One of the framework goals is to be as simple as possible to allow easy adoption of the framework with a minimum of technical ability. You won’t need to necessarily be a software engineer to be able to make use of the framework.

Action Engine:

A separate process that monitors MQTT topics for programmed events. Can collect data and trigger actions. This process also logs the MQTT traffic. Each device in a fleet can run it’s own action engine, or they can defer to a central point.

Logger:

A  logger task monitors MQTT traffic to gather telemetry about the IoT system. Will aggregate traffic and log to a SQLite database of the hub.  This is a separate python app that is running as a service on the hub device (a solo device is its own hub).

The idea is to provide a standardized implementation of the common aspects of getting a system running. Control and monitoring, combining components and events can be coordinated in a easy to implement pattern. 

An installer process will do the preliminary install. This will get the api, logger and device services installed as and enabled as well as getting mosquitto mqtt, circuit python, etc.

Some critical tasks — like generating and staging X509 certificates need to take place before install. The frame work strives to be reasonably secure without too much effort.

Alpha versions of the framework will be available in the upcoming weeks.

If you find this work helpful perhaps you would consider supporting m2ag.labs open source efforts by buying us coffee. Any amount would be appreciated. Please use this link to do so:

Small Donate Button

Thanks for stopping by.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.