Close

Python MicroService Bus for IoT Messaging

mark-traverseMark Traverse wrote 11/19/2016 at 16:13 • 3 min read • Like

Python Peer to Peer MicroService Bus for IoT Messaging Framework

Latest work:

I am currently well along a personal project to build a simplified data-driven MicroService Bus in Python to integrate RPI HAN nodes, ESP IoT wifi devices., communicating freely with the world of telemetry and cloud messaging service capabilities (think ESB for the PI).

Why?

Well, I started integrating everything I could on Raspberry PI. Sensors, i2c, 1-wire, GPIO, SPI, USB X10, API's, webscrape etc etc. Then started to think about how to federate within a Home Area Network. I didn't want everything going back to a central computer in the home, more wanted to be able to have satellite control points with say a PI in the kitchen dealing with communications for appliances, another dealing with living room,a nano for weather, satellite arduino mediators and of course small IoT devices on ESP etc. MQTT was the obvious answer for M2M communications because of the lightweight nature of the clients BUT you end up with a jungle of hard-wired scripts to maintain on each node. Every setup needs the tinkering with GPIO for sensors and displays, the 1-wire bus setup, the I2C setup, - and of course all the setup of pub/sub topics. So the idea was to create a metadata-driven wrapper around it all, harvesting environment setup by interogating the OS and adding data to allow it all to be consistently addressed through an abstrated driver layer. As this data is organised it is used for automated setup of publishing (sensors, inputs, web data) and subscription for controls (displays, connected devices, home automation controls)

Again, I know there are many available products for this that may get near to where I need (such as openHAB) but I really wanted total flexibility for extensibility. The world is moving fast and I need to be able to plug into iot services quickly (and sometimes those that wouldnt be supported in a product). So this will remain strictly HOMEGROWN with a healthy re-use of Open Hardware and Open Software.

The main components (per HAN node):

  1. ENVIRONMENT DATA SCHEMES: Metadata & agent wraps over sub-systems
  2. BULLET PUBLISHERio: Data-driven, resilient, bullet-proof configurable Scheme Publisher for MQTT (configurable thru topic controls)
  3. DRIVERPACKi: returning 'readings' from multitude of Sensor types, API's, and all Input-bound interactions
  4. AGENT MEDIATORio: Configurable Subscriber / Mediator responding to topic controls and orchestrating actions with sub-systems for all connected devices inc displays (OLED / LCD), I2C output devices, GPIO drivers
  5. DRIVERPACKo: for data-driven actions on all connected devices, O/S commands, API's
  6. RULESio: Lightweight configurable M2M rules engine for simple orchestrations (major orchestrations handled in NODE-RED)
  7. STATEio: a lightweight persistent state store for short-term persistence
  8. BRIDGEio: for handling M2M & Broker bridging between HAN MQTT and external / cloud iot services. (Adafruit.io, Arduino.io, Artik, PubNub, ThingSpeak, IBM Watson)
  9. API G/W: Currently supporting Weather Underground, Google Docs, Twitter, Email.


Like

Discussions