Article for advanced users

Information on this page is intended for users with advanced technical knowledge.

Treon Gateway - Tutorials

Apr 14, 2022 · 5 minutes to read

This chapter describes the main modules and interfaces of the Treon IoTGW application and explains how to add new functionality to it.

Architecture

The application consists of three main layers:

  • Cloud adapter
  • Data processor
  • Local connectivity adapter

Each layer handles its dedicated functionality: the cloud adapter handles the cloud connectivity and cloud specific data formatting, the data processor parses the binary data from sensors as well as transforms messages from the cloud to the sensor format, and the local connectivity adapter handles, for example, the mesh network specific functionality.

Interfaces

The layers exchange messages over the two main interfaces. The system also has external interfaces to the cloud and mesh network, but those interfaces are out of scope for this document.

Implementation

The layers are implemented as separate Linux processes. The initial Treon implementation is done with Python but the architecture does not impose or limit the choice of development language. The Treon implementation of the layer functionality is subject to change.

The interfaces are implemented as message queues using sockets. The ZeroMQ (http://zeromq.org/) queuing library is used. The used messaging pattern is publish/subscribe. The producer of the data publishes the data to the socket and theconsumer of the data subscribes to the data it is willing to process. There can be several publishers and consumers connected to the interface. The pub/sub pattern does not provide flow control. The subscriber must receive the messages as they arrive and potentially queue them internally for processing.

Interface Structure

The detailed implementation of interfaces A and B (shown in the picture above) is presented in the picture below. An additional Forwarder component ‘binds’ to sockets, so the users of the sockets make ‘connect’. The benefit of this approach is that there can be multiple components publishing or subscribing to messages.

The sockets are normal localhost (127.0.0.1) sockets. The sockets are defined in */opt/iotgw/gw.conf from where all components read the configuration.

Used sockets

The current configuration is as follows:

From cloud adapter: tcp://127.0.0.1:5500

To cloud adapter: tcp://127.0.0.1:5501

From local connectivity adapter (mesh adapter): tcp://127.0.0.1:6001

To local connectivity adapter (mesh adapter): tcp://127.0.0.1:6000

If a new handler for the cloud adapter is developed, it must connect to the localhost ports 5500 and 5501.

Message Format

Zero MQ multipart messages are used to move data in interfaces A and B. The message parts are strings.

Interface A

Message coming from cloud adapter to data processor:

<topic> <message data>

<topic> :== string, used for message subscription

<message data> :== string, JSON

The message data JSON is specific to the implementation. This data could contain e.g. commands or settings to the sensor nodes.

Message from data processor to cloud adapter:

<topic><message data>

<topic> :== string, used for message subscription

<message data> :== string, JSON

In the Treon implementation, the JSON of this message data contains sensor information that is sent to the cloud.

Interface B

Message from data processor to local network adapter (mesh adapter):

<topic><destination><message data>

<topic> :== string, used for message subscription

<destination> :== string, sensor node address (Treon SensorId)

<message data>:==string, base64 encoded message data e.g. Treon Sensor TLV message

The local connectivity adapter (mesh adapter) implemented by Treon implements ‘BROADCAST’ destination access in addition to using in individual sensor addresses.

Message from local network adapter (mesh adapter) to data processor:

<topic><wirepas source><message data>
<topic><destination>
<topic> :== string, used for message subscription
<destination> :== string, sensor node wirepas address
<message data>:==string, base64 encoded message data e.g. Treon Sensor TLV message

The local network adapter (mesh adapter) cannot return SensorId as it is contained in Treon Sensor TLV message and local network adapter (mesh adapter) is not handling the message payload. Only the Wirepas network address is returned.

Python snippet examples

The socket connection in cloud adapter. It subscribes to topic ‘azureloT’ send by data Processor.

 

import zmq

ctx = zmq.Context.instance()

cloud_outbox = ctx.socket(zmq.SUB)

cloud_outbox.connect(' tcp://127.0.0.1:5501')

cloud_outbox.setsockopt(zmq.SUBSCRIBE, ' azureIoT')

The data is received by:

while True:
topic,message = cloud_outbox.recv_multipart()
print message

Wirepas address calculation

Treon sensor node serial number (SensorId) is full 32-bit number whereas wirepas network address is 24-bit. Wirepas address is calculated from SensorId. SensorId string presents serial number in hexadecimal little-endian format.

WIREPAS_ADDR_COUNT = 0xFFFFFDL
  temp = serial * WIREPAS_ADDR_COUNT
node_addr = (temp » 32) & 0xFFFFFFFFL
node_addr +=

Create your own data plugin/parser

The data plugin should be implemented as a process that listens to the sockets from local network adapter and cloud plugin.

Create your own cloud plugin

The plugin should be implemented as a process that listens to the socket from data plugin. It also implements connection to cloud as well as any cloud specific formatting of data (JSON).

Develop an edge application

You can develop different edge applications for the gateway. Our example: value tracker written in Python. An application could be developed to track the changes in a specific value recorded by sensor nodes.

As described in ‘Implementation’, the edge application just needs to subscribe to the data it needs or alternatively publish the data aimed for the data parser or mesh adapter

 


Was this article helpful? Let us know.
Next
Previous