Tinker's thoughts~

About Blog GitHub

23 Sep 2014
Python based Device Agent for Internet of Things

Once we have all the backend infrastructure ready with Event Collection, Device Management etc etc - we need a Device Agent to connect the actual device with the aforementioned infastructure. I have embedded the RA diagram below to refresh our thoughts.

Reference Architecture for IoT

After thinking for a while - I got a feeling that there are 2 types of things that the agent does.

  • Device Management Agent
  • Activity Agent

Device Management Agent

DM Agent is a generic component set that provide Device Management and utilities. For an example, DM Agent provides -

  • Communication adaptors for MQTT, HTTP
  • Device Enrollment
  • Token Management
  • Management for platform type

Activity Agent

​Activity Agent is a framework that allows developers to plugin custom Publishers and APIs. The framework can load the Publishers periodically and publish data using communication wrappers (provided from the framework). In a real world example - this is a temperature sensor publishing data to an API.

The framework can expose custom API classes using MQTT / HTTP API wrapper. This allows external invocation of Hardware APIs via the wrapper. A Buzzer connected to a Raspberry Pi exposed as an API is the ideal example.

The White Paper by WSO2 on the Reference Architecture for the Internet of Things explains all the components in IoT and give details on implementation of different components. The RA diagram was taken from it.

Architecture of the Agent

It would help to see the components of the Device Agent stacked together to better understand the agent architecture.

Architecture of the Python Agent

Before - I took an example of a Temperature sensor and a Buzzer actuator. Let’s connect those to a RaspberryPi and see what the architecture looks like.

Architecture of the Python Agent in Raspberry Pi


Now comes the exciting part. I have started work on this at our RA for IoT Github repo. Currently I have added support to RaspberryPi and BeagleBone Black. Lot of you might ask - why we chose Java instead of Python to write the base agent. This is mainly because of the out of the box support provided by most hardware to run python (RaspberryPi, BeagleBone, Arduino Yun).

Currently I manage to obtain below data from both platforms -

'hardware': {
'node': 'beaglebone',
'system': 'Linux',
'machine': 'armv7l',
'version': '#1SMPFriApr1101: 36: 09UTC2014',
'release': '3.8.13-bone47',
'processor': ''
'platform': {
'terse': 'Linux-3.8.13-bone47-armv7l-with-glibc2.7',
'alias': 'Linux-3.8.13-bone47-armv7l-with-debian-7.4',
'normal': 'Linux-3.8.13-bone47-armv7l-with-debian-7.4'
'python_info': {
'version_tuple': ('2',
'version': '2.7.3',
'build': ('default',
'Mar14201417: 55: 54'),
'compiler': 'GCC4.6.3'
'os': {
'name': ('Linux',
'#1SMPFriApr1101: 36: 09UTC2014',

WSO2 Device Manager

After the device enrollment and provisioning -the user can view the device on the Device Manager. All the Device Info is shown as key value pairs on the page. The plan is to show the APIs as operations on the Device Manager.

Device Management view of BeagleBone

As for the enrollment part - I thought of writing a separate post on it. There are multiple enrollment mechanisms for IoT devices and the option we see is to support all of them. Right now - the implementation supports token based enrollment. This approach assumes that the agent knows a token that is already registered to a user on the device manager.

Till next time mate,
Dulitha at 05:32

About Blog GitHub