Category Archives: Python

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


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.


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.


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.


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.


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.

Embedded audio alerts with gpizero and simple circuit

For the devices I tend to make the Raspberry PI is intended to be a controller or sensor of some sort that does not usually have a visual interface attached. It is nice to have the device setup so that all critical functions are easily accessible, and the device be able to give indications of type. Certainly LEDS are easy to implement on the PI. A simple transistor allows us to interface a wide assortment of devices. In this case I want to interface a piezo buzzer to provide audible alerts for device activity.

Now granted, I could attach a plain speaker to the appropriate port and play audio files. There is a lot of overhead to doing that and it would be way overkill for what I am trying to accomplish. Generally I am looking for a beep at power up, maybe a tone when the network is down, an alarm for a sensor – you know.

A simple circuit is all you need –

A few pennies worth of discrete components implements the buzzer

6.8 K worked for me, but you should match R1 to the transistor you are using. This makes for an audible tone that is not too loud. If you need a reference to calculate R1 this is a good source:

Python code to implement tones could not be simpler. Using gpiozero‘s buzzer can give basic beep or tonal buzzer can be used to create compelling tones. Pwmled can also be used to give an attention getting alert.

from gpiozero import PWMLED
import time

buzzer = PWMLED(13)
buzzer.pulse(fade_in_time=0.5, fade_out_time=0.2, n=10, background=True)

Vary the fade_in_time and fade_out_time to experiment with tones. I’ll be using some variation of this implementation in the upcoming m2ag.labs IoT framework for general device side alerting. As I develop tones I will add them the the m2ag.labs example repo. I’d be happy to include your tones of you create a pull request.

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.

Control an Arduino from Python with PyCmdMessenger

March 6, 2020

There are many methods that can be used to provide communication with a host computer and an Arduino device. ArduinoCmdMessenger is a stable and relatively easy to use choice. It enables simple messages to be sent to the Arduino to control actions and return data.

Command Messenger itself can be installed via the Arduino Library Manager. The latest is version 4.0. It comes with examples in both C# and Visual Basic. My requirement is Python, so the PyCmdMessenger will be used. PyCmdMessenger can be installed via pip3. 

Both the projects have not had many updates in the recent years, but I find in combination they address the needs of my projects.

The problem:

I want to use Raspberry PI for IoT work. I want to use an Arduino to run some sensors that the PI will poll and publish.

True, the PI can handle most sensors and do the work for me. But in this particular case I have one of Adafruit’s CCS811  air quality sensors. The only way to get the sensor to work directly on the Raspberry PI is to slow the i2c bus speed down as described here -> .

I don’t really want to slow the i2c bus down on the PI as I have it busy with some other sensors. Plus — the implementation I have in mind is the CCS811 and a BME280 comprise an add on module for other projects. Using an Arduino Leonardo clone, the DF Robot Beetle, I can treat the implementation as a plug and play add on for other projects such as our up coming Raspberry Alarm Clock.

There are other options like Firmata. But I was not looking to couple the Arduino code so closely. I could roll my own implementation, but I’d rather use something that is already available. I  just want to be able to reliably pass commands and data back and forth asyhronously.  PyCmdMessenger provides a solution for this.

An example project can be found in the m2ag.labs examples repo. The code is documented and can be modified to use alternate sensors.

Prototype Sensor module.
Prototype Beetle sensor module. There is plenty of unused capacity on the Beetle that could be put to use.