Modbus IoT Data integration with MQTT Broker

Modbus IoT Data integration with MQTT Broker

Industrial automation is not new. But it is time to create a better modbus iot integration for a deeper understanding of your data and also manage your devices in a efficient way. 

In the Industry 3.0, devices are managed in an isolated fashion. From late 1960s to early 19790 PLCs , DCS and few more ways to automate the simple process came into existence. In addition, With the introduction of Modbus, programmers were able to mange them and automate a few of the process in a localised fashion.

But these machines are still managed in the same isolated way in many industrial sectors. However It is time to integrate them for a more productive outcome.  Over the last weekend, we tried writing some code to integrate data received from Modbus/TCP into MQTT Broker.   The integration was very simple and straight. But  One of the major challenge is the association of the data we read from the Modbus Server to the actual spec as provided by the Manufacturer.

MQTTClient

We have used Bevywise MQTT Client for creating the gateway to push the Modbus data and the MQTT Broker. This MQTT client will work with all the MQTT 3.1 & 3.1.1 supported Server. You can download the MQTT client  for your operating system from the Broker help page.

 

Modbus Client

We used the pymodbusTCP python implementation of the Modbus iot gateway. This will querying the data from the Modbus TCP Server. Using the pymodbusTCP implementation, you will be able to read and write data into the the memory registers & Coils of your equipment.

Modbus IoT Integration

We have written a sample PoC python script which will read a particular set of holding register data. And also it pushes it to the MQTT Broker every 5 seconds. You can download the script here and also can update your Equipment IP and port on the script.

You can either run the MQTT Broker on your local machine or point the script to send data to the Device Manager.  For running in your local machine Download the MQTT Broker now.

download now

You can download the complete working version of the Modbus IoT Integration scripts from here. We are working a full fledged script which can make the Modbus IoT Integration much simple.  We will be happy to collaborate with you to provide best possible solution for your IIoT problems.

Bengaluru Traffic Problem & Suggestions

Bengaluru Traffic Problem & Suggestions

Excuse for late arrival has become a norm as everyone has one reason for their delay – Bengaluru traffic problem. I felt really bad for the first couple of times when I was new to Bengaluru arriving late for meetings.  I get use to it slowly. But let me raise up before I get accustomed to it. Here are few of my thoughts how we can increase the efficiency of the overall transport.

The false belief – The tables turned

People started using personal cars as it highly saved the time for people. But we don’t have that luxury anymore. Going by a personal car or by a public transport does not make a big difference. Most of the workforce in Bengaluru does cognitive work. At least when you don’t drive, you have to give your mind a more time to think. At least take a nap to be productive later. With an availability of a lot of Air conditioned busses, I believe given the right infrastructure around the transport, people will be ready to adopt.

Shared Rides are good But not 4 passengers

Shared rides in Ola / Uber really saves a lot of space on the road. But when the ride goes a merry go around trip, it again uses more road space then what is needed. It is time that the algorithm used by Ola / Uber should get more streamlined so that the required commute / actual commute comes down drastically. I hate Share as it loads (not boards) three person at the back seat of car making it really tough to commute and making me shift back to solo hires.It will be good if they reduce it to 3 passengers for a peaceful ride.

Dynamic Speed Limit

The speed limit currently set at 40 is good and I believe that has reduced a lot of accidents in Bengaluru. But when the roads are open after the peak hours, the speed limit should be increased. It is better to adopt a dynamic speed limit in at least wide roads like ORR. Having said that it is not to set a limit from hour to hour basis which will fail during unprecedented traffic.

Google today has a lot of information about how traffic in every city operates. Google can accurately saw how much time it will take to reach from one place to another considering all the forthcoming confession into its algorithm.Create the Speed limits dynamically using Artifactual intelligence and display it for cars to follow.In a sense this will make the pre peak traffic flow faster giving lot of room for the peak traffic.

Make it walkable

People often use cars as they feel a longer walk or unsafe to walk from their home to the nearby terminal of public transport. A few places in Bengaluru especially west around IISC has a lot of trees and I believe even when you walk a few Kms, you won’t find yourself exhausted. But when you walk in-between concrete jungles, you will be. People will start walking when there are enough pavements and sun shades (trees). There should be the better markings in the road signs and the pedestrian crossings  to make it more safer.

Car Pool Lane

There is no car pool Lane even in the broad roads. Given the number of cars on the road, it is even better to allocate two lanes for the car pool to increase car pooling and reduce the number of single person occupied cars.

Autos rickshaw saves a lot

Auto rickshaw is one of the major transport system. If the pollution levels are brought down, people will use more autos than cars. Autos on the overall will use a lower space on the road then cars. Shared Auto rides with 7 seater autos are common in Chennai. But I don’t see them in Bengaluru. Not sure whether it is a government decision to keep them off.

Empty Busses Off the Road:

I always see a few A/C Busses that come for the same destination and a very few passengers in each bus. This happens at the peak traffic as well.It is better to keep these busses off the road and ply it on demand. We may sometime need to lower the efficiency of the professionals for the overall efficiency of the Transport corporation. By keeping these buses out of road, we will be able to increase the person to bus ratio to a better extent.

Cost – a Major Factor

Cost is always a concern for every Indian citizen. The good news is that the A/C busses price cut a few months back has increased adoption of the busses. But I believe it is still on a higher side for people to ride. Government should also think about working closely with the Shared ride providers like Ola / Uber to bring down the cost to increase people to move away from single occupant cars. For overall Bengaluru to be efficient, few of the services may need to loose some more money on the A/C bus tariff to increase adoption.

Due to the Bengaluru traffic problem, it takes more than 5 to 6 minutes for a kilometre of ride during peak hours. Not everyone will have the luxury to use a non peak hour drive to office.People who have to be on time to office waste most of their time on the road. A survey in 2015 states that 60 crore man hours are wasted in traffic per year in Bengaluru alone.This is a very serious number and translates to thousands of crores of money in value. Time to rethink transport for a better living.

With the advent of the IoT we will be able to get more and more data about every aspect of the traffic and the road. If we can put these data into right use and with all the above mentioned possible options, the Bengaluru traffic problem and the mental stress can be brought down to a liveable extent.

Sparkplug B MQTT Simulation

Sparkplug B MQTT Simulation

Sparkplug provides an open and freely available specification for how Edge of Network (EoN) gateways or native MQTT enabled end devices and MQTT Applications communicate bi-directionally within an MQTT Infrastructure. One of the unique aspects of MQTT is that it was originally designed for real time SCADA systems to help reduce data latency over bandwidth limited and often unreliable network infrastructure.  Similarly the intent of the Sparkplug specification is to take full advantage of MQTT’s native Continuous Session Awareness capability as it applies to real time SCADA/IIoT solutions.

Specifications of Sparkplug

 

Currently there are two Sparkplug defined encoding schemes that this specification supports.

  • Firstly the Sparkplug A encoding scheme based on the very popular Kura open source Google Protocol Buffer definition.
  • Secondly the Sparkplug B encoding scheme that provides a richer data model developed with the feedback of many system integrators and end user customers using MQTT.

Sparkplug MQTT Topics and Messages

 

This blog guide you to simulate the Sparkplug B encoding in Bevywise IoT Simulator. Before simulating you must know about the Sparkplug Topic Namespace Elements and Sparkplug MQTT Message Types. 

Sparkplug Topic Namespace Elements:

All Clients which use the Sparkplug spec will use this default UTF-8 Format Topic namespace.

namespace/group_id/message_type/edge_node_id/[device_id]

  • namespace: It is the root element that will define both the structure of the remaining namespace elements as well as the encoding used for the associated payload data. Format for namespace is UTF-8 string constant should be used. Similarly  the current Sparkplug specification defines two namespaces:
  • Sparkplug payload definition A
  • namespace element should be “spAv1.0”
  • Sparkplug payload definition B
  • namespace element should be “spBv1.0”
  • group_id: This provides unique logical group ID of MQTT EoN nodes. For group_id the format should be  UTF-8 alphanumeric string, except for the reserved characters of ‘+’ (plus), ‘/’ (forward slash), and ‘#’ (number sign). Examples of where the [group_id] might be used include Cement industry where MQTT EoN nodes on different department have the different [group_id].
  • message_type Element: It provide the indication as to, how to handle the MQTT payload of the message. The following message_type elements are defined for the Sparkplug Topic Namespace:
  • NBIRTH – Birth certificate for MQTT EoN nodes.
  • NDEATH – Death certificate for MQTT EoN nodes.
  • DBIRTH – Birth certificate for Devices.
  • DDEATH  – Death certificate for Devices.
  • NDATA    – Node data message.
  • DDATA     – Device data message.
  • NCMD – Node command message.
  • DCMD      – Device command message.
  • STATE – Critical application state message.
  • edge_node_id: Unquie identification for the MQTT EoN nodes within the infrastructure. For edge_node_id the format should be UTF-8 alphanumeric string, except for the reserved characters of ‘+’ (plus), ‘/’ (forward slash), and ‘#’ (number sign). The edge_node_id travels with every message published, so it should be as short as possible
  • device_id: Unquie ID which used to identify the device attached to the MQTT EoN node. device_id is an optional element since some messages will be either originating or destined to the edge_node_id, in that place device_id would not be required. The format of the device_id is a valid UTF-8 alphanumeric String except for the reserved characters of ‘+’ (plus), ‘/’ (forward slash), and ‘#’ (number sign). The device_id travels with every message published, so it should be as short as possible.

Simulate Sparkplug MQTT Device & Network

  • Bevywise IoT Simulator is a simulation tool which help users to test and develop the MQTT/IoT Applications. For installation and setup of Bevywise IoT Simulator, please refer our help doc and video tutorial.
  • After starting the Simulator, create a new network.
  • In new network, create three MQTTEoN nodes by via device creation : spBv1.0, Node2, Node3.

Sparkplug MQTT Message Types

 

Sparkplug defines the Topic Namespace for set of MQTT messages that are used to manage connection state as well as bidirectional metric information exchange that would apply to many typical real-time SCADA/IIoT, monitoring, and data collection system use cases. The defined message types include:

  • NBIRTH – Birth certificate for MQTT EoN nodes.
  • NDEATH – Death certificate for MQTT EoN nodes.
  • DBIRTH – Birth certificate for Devices.
  • DDEATH  – Death certificate for Devices.
  • NDATA    – Node data message.
  • DDATA     – Device data message.
  • NCMD – Node command message.
  • DCMD      – Device command message.
  • STATE – Critical application state message.

Advantage of using these defined messages:

Using these defined messages the SCADA/IIOT Application can:

  • Initially Discover all metadata and monitor state of any EoN/Device connected to the MQTT infrastructure.
  • Then Discover all metrics which include all diagnostics, properties, metadata, and current state values.
  • Issue write/command messages to any EoN/Device metric.

Creating Sparkplug MQTT Message types in IoT Simulator

 

MQTT EoN NBIRTH and NDeath Certificate: The first MQTT message that an EoN node MUST publish upon the successful establishment of an MQTT Session is an EoN BIRTH Certificate.

Creating NBIRTH: [namespace/group_id/NBIRTH/edge_node_id]

  • Click spBv1.0 and
  • Create a event with “Whole day” configuration with every 5 sec time interval.
  • In that give the topic namespace as

spBv1.0/kiln/NBIRTH/1

  • Select QoS as 1 and retain as 1
  • Give message as “NBIRTH” and save it

Creating NDEATH: [namespace/group_id/NDEATH/edge_node_id]

  • Click spBv1.0 and
  • Create a event with “On Disconnect” configuration.
  • In that give the topic as

spBv1.0/kiln/NDEATH/1

  • Select QoS as 1 and retain as 1
  • Give message as “NDEATH” and save it.

MQTT EoN Node Data (NDATA)

  • Once an MQTT EoN node is online with a proper NBIRTH, the NDATA will published.
  • This enables the advantages of the native Continuous Session Awareness of MQTT to monitor the STATE of all connected MQTT EoN node and to rely on Report by Exception (RBE) messages for metric state changes over the MQTT session connection.
  • The payload of NDATA messages will contain any RBE or time based metric EoN node values that need to be reported to any subscribing MQTT clients.

Creating NDATA:[namespace/group_id/NDATA/edge_node_id]

  • Click spBv1.0 and
  • Click the + icon and select Behaviour
  • In that, give command topic as “NBIRTH topic namespace” and command “NBIRTH”.
  • Next give the NDATA topic namespace in Event and give Event Data as current time and click save.

spBv1.0/Kiln/NDATA/1

  • Now NDATA will published to subscriber once they subscribe the NDATA topic namespace.

Device Birth Certificate[DBRITH]

  • The MQTT EoN node is responsible for the management of all attached physical and/or logical devices. Once the EoN node has published its NBIRTH, the customers application ensure that EoN Node is ONLINE
  • But each physical and/or logical device connected to this node will still need to provide this DBIRTH before consumer applications create/update the metric structure (if this is the first time this device has been seen) and set any associated metrics in the application to a “GOOD” state.

Creating the DBRITH:[namespace/group_id/DBIRTH/edge_node_id]

  • Click spBv1.0 and
  • Click the + icon and select Behaviour
  • In that, give command topic as “NBIRTH topic namespace” and command “NBIRTH”.
  • Next give the DBIRTH topic namespace in Event and give Event Data as DBIRTH and click save.

spBv1.0/Kiln/DBIRTH/1

  • Now DBIRTH will published to subscriber once they subscribe the DBIRTH topic namespace.

Device Data Messages (DDATA):

  • Once an MQTT EoN node and associated devices are all online with proper Birth Certificates it is in a mode of quiescent Report by Exception (RBE) reporting of any metric that changes.
  • It take advantage to monitor the STATE of all connected devices and can rely on Report by Exception (RBE) messages for any metric value change over the MQTT session connection.
  • Creating DDATA: [namespace/group_id/DDATA/edge_node_id/device_id]
  • Click spBv1.0 and
  • Click event with “Specific Duration” for 20 min duration with 10 sec interval.
  • In that give the topic as

spBv1.0/kiln/DDATA/1/LSM213

  • Select QoS as 1 and retain as 1
  • Give Random message as “ON|OFF” and click save.

Device Death Certificate[DDEATH]

  • If the device becomes unavailable for any reason (no response, CRC error, etc.) it is the responsibility of the EoN node to publish a DDEATH on behalf of the end device.
  • Once the DDEATH certificate published, any MQTT client subscribed to this device should set the data quality of all metrics to “STALE”.

Creating DDEATH:

 [namespace/group_id/DDEATH/edge_node_id/device_id]

  • Click spBv1.0 and
  • Click the + icon and select Behaviour
  • In that, give command topic as “DDATA topic namespace” and command “OFF”.
  • Next give the DBIRTH topic namespace in Event and give Event Data as DDEATH and click save.

spBv1.0/Kiln/DDEATH/1

  • Now DDEATH will published to subscriber once they subscribe the DBIRTH topic namespace based on the DDATA.

SCADA/IIoT Host Birth and Death Certificates

  • The SCADA/IIoT Host Node is any MQTT Client application that subscribes to and publishes messages.
  • In an infrastructure, mulitple MQTT Servers provide redundancy and scalability, for that MQTT EoN nodes need to be aware of the “state” of the primary SCADA/IIoT Host application(s).
  • The “state” can be acheived by the unique set of Birth/Death Certificates that the SCADA/IIoT Host MQTT Client MUST publish when a new MQTT session is established.
  • Topic namespace for SCADA/IIOT Host : STATE/scada_host_id
  • It uses an aspect of the MQTT transport called a “RETAINED” publish to maintain the current state of the Primary Host MQTT Client session state to all available MQTT Servers.
  • The format of the scada_host_id can be valid String with the exception of the reserved characters of ‘+’ (plus), ‘/’ (forward slash), and ‘#’ (number sign).

Creating SCADA/IIoT Birth Certificate Payload (STATE):

  • Click the SCADA/IIOT and
  • Create events with “On Connect” configuration.
  • In that give topic as SCADA/IIOT Host topic namespace[STATE/scada_host_id]: STATE/SCADABIRTH
  • Set WILL Retain flag as “1” and QoS as “1”
  • Select message type as “Text” and variant as “Constant”.
  • Give Payload or message as “ONLINE“.

SCADA/IIoT Host Death Certificate Payload (STATE):

  • When the SCADA/IIoT Host MQTT client establishes an MQTT session to the MQTT Server(s), the Death Certificate will be part of the Will Topic and Will Payload registered in the MQTT CONNECT transaction.
  • The Will Topic should be: STATE/scada_host_id

Creating SCADA/IIoT DEATHCertificate Payload (STATE):

  • Click the SCADA/IIOT and
  • Click the switch button straight to WILL
  • In that give topic as : STATE/SCADADEATH
  • Give message or payload as “OFFLINE”
  • Set WILL Retain flag as “1” and QoS as “1”

MQTT EoN Node Command (NCMD) 

  • The NCMD command topic provides the Topic Namespace used to send commands to any connected EoN nodes.
  • This means sending an updated metric value to an associated metric included in the NBIRTH metric list.
  • Topic namespace: namespace/group_id/NCMD/edge_node_id

Creating MQTT EoN Node Command (NCMD)

  • Click spBv1.0 and
  • Create event withInstant command
  • In that give topic as

spBv1.0/Kiln/NCMD/1

  • Set QoS to “1” and Retain to “1”
  • Select message type as JSON and click + button.
  • In that add NBIRTH metric like:
  • ONLINE_STATE and ONLINE TIME.
  • Give the Key as ONLINE_STATE, select “constant”, give value as TRUE and click ADD
  • Next click + button and
  • Give Key as ONLINE_TIME, select “System variable” and select “$Current_time from list
  • next click ADD and save the JSON.
  • Once the NBIRTH occurred, publish the NCMD by clicking the action icon
  • on the left side, now the NCMD will send commands to connected EoN nodes.
  • Next the subscribe the NCMD topic in SCADA/IIOT to get the Update metric from spBv1.0.

Device Command (DCMD)

  • The DCMD topic provides the Topic Namespace used to publish metrics to any connected device.
  • This means sending a new metric value to an associated metric included in the DBIRTH metric list.
  • Topic namespace: namespace/group_id/DCMD/edge_node_id/device_id

Creating Device Command (DCMD)

  • Click spBv1.0 and
  • Create event with “Instant command
  • In that give topic as

spBv1.0/Kiln/DCMD/1/LSM213

  • Set QoS to “1” and Retain to “1”
  • Select message type as JSON and click + button.
  • In that add NBIRTH metric like:
  • ONLINE_STATE and ONLINE TIME.
  • Give the Key as ONLINE_STATE, select “constant”, give value as TRUE and click ADD
  • Next click + button and
  • Give Key as ONLINE_TIME, select “System variable” and select “$Current_time from list
  • next click ADD and save the JSON.
  • Once the DBIRTH occurred, publish the DCMD by clicking the action icon
  • on the left side, now the NCMD will send commands to connected EoN nodes.
  • Next the subscribe the DCMD topic in SCADA/IIOT to get the Update metric from spBv1.0.
  • These are the Sparkplug set of MQTT Message Types that are used to manage connection state. Next connect the Bevywise IoT Simulator to built-in MQTTBroker or connect to any other MQTTBroker to start the Spatkplug Simulation. Likewise create Sparkplug message type for other Nodes.

You can get started by downloading the IoT Simulator now.

download now

Feel free to write to support for any questions.

MQTT Broker – Manage devices better

MQTT Broker – Manage devices better

Today we are happy to announce an enhanced version of the MQTT Broker.The newly updated version will help you identify MQTT connection error, Manage devices better & also provides Dynamic MQTT Authentication.

MQTT Broker manage devices better

You will be able to initiate a command to any particular device from the User Interface of the MQTT Broker. This has been previously supported via REST API built over the broker. The REST APIs were used by customers to initiate a command from their application.

When you do a real time project, IP Address of the edge device helps you get more information & exact location of the device. The new update shows your the client IP Address on the UI. Going forward we will be adding alerts based on the changes in the client IPs to inform suspicious activity.

MQTT Connection Error Monitoring

There is no ideal system in the world. You may face some MQTT connection error while connecting your devices. But it is very important to know the issues and mitigate them. All Edge devices will not behave perfectly as per the Protocol. Any Edge device can be disconnected from the MQTT Broker for various reasons. In a similar way, any packet that is not as per the standard can be dropped as well. We have added support to highlight the actual cause for MQTT connection error. It helps you identify and clear the alarm easily. The following scenarios will show you a warning on the User Interface :

  1. Reuse of the Client identifier.
  2. Usage of wrong MQTT credentials.
  3. Inconsistency in connectivity & Timeout issues.
  4. Usage of invalid Certificates for SSL / TLS connections.
  5. Not supported characters in Client Identifier.
  6. Missing of required Client Details.
  7. Atypical disconnection.
  8. Error in the MQTT Packet formation.
  9. Server not able to handle new request.

Dynamic MQTT Authentication

You can now configure your MQTT Broker parameters from the User Interface. When the authentication is enabled, you will be able to add new MQTT Username and password and also delete authentication keys dynamically. This helps you in take actions swiftly when you find some wrong usage of authentication keys.

Further You will be able to enable / disable TLS and authentication from the User Interface. Also enable Custom Store option from the UI. But these setting changes need a restart of the broker from the terminal. We working on making these changes dynamic as possible.

The new version of the MQTT Broker can be hosted on AWS Securely. We would always recommend you to use Monit to run the MQTT Broker as a service and control over the web also.

Download the MQTT Broker now.

download now

We would be happy to answer your question and hear your feedback. Feel free to write your queries to support.

Free IoT Products for your Non Commercial Projects

Free IoT Products for your Non Commercial Projects

During  College / research time, everyone cannot afford premium products for non commercial projects.  Free IoT Products will help students, researchers, professors today help do research to innovate new  things. It also helps them better to challenge the future world.  IoT , AI , ML  & Edge Computing are few of the fast growing technologies in the world today.
We at Bevywise Networks would like to take this opportunity to encourage the students, teachers and researchers community with a free complimentary license.  These products can help them do their research much easier and in a cost effective way.  We provide edge clients for the various operating System , MQTT Broker , IoT Simulator tools and an IoT Platform. The hosted IoT Platform (Bevywise Device Manager ) is always free and can be used for your testing.  How can you utilise these tools for your projects.

Building Edge Devices with Free IoT Products

MQTT is one of most widely adopted protocols for industrial and general purpose IoT Implementation. If you are building any edge device as part of your project, then you can utilise the MQTT Broker as your Message broker for your implementation. This will help you collect messages (events) from your edge devices, send commands to your edge devices as well using APIs.

Building Application for a Vertical

MQTT Broker is a perfect middleware which can collect the information from your edge device and then hand it over to your backend application or data store as required. You will be able to build an application for a Small and medium business use case with the MQTT Broker. We already have some integration done for MongoDB , ElasticSearch, Redis, etc.

With custom storage option

  • Do data analysis over these big data engines
  • Connect to your Big Data Engine
  • Integrate it with any IoT Application

If you are looking for a large scale project which needs an IoT Platform kind of framework, we can also work out a model to make it available for researchers and students.  Our simulation tool can help you test your application using different variations of data.

To start with you can always download all our products for a FREE evaluation.

If you feel our tool would help us achieve your goal, feel free to contact us.