Introducing Google’s Protocol buffers in Bevywise IoT Simulator

Introducing Google’s Protocol buffers in Bevywise IoT Simulator

The first release update of the year is here..we have something new for our IoT simulator customers..We could see a considerable interest among people in using protocol buffers. This simple language-neutral has a well-justified reputation amongst all programming developers as a convincing perspective in relieving painful growth by taking out concerns from large applications. Bevywise IoT simulator version 3.0 now offers the possibility to use Google’s protocol buffers, the best way of encoding structured data in productive yet extendible pattern / scheme. With this new update, users can customize their payload in the way they need before sending it.

What and Why you need Google Protobuf

Protocol buffers are google’s structured format to arrange serially and encode your data being the best choice over JSON. You can specify how your data should be in a structured format to make such structured data easy to read & write using the language you prefer. This signifies that one spec is critically enough to transmit data between complexes irrespective of the implementation / execution language. That is you can exchange information between processes or even across different servers with different architectures. With flexible, easy to understand & convenient structure and compiler with support for multiple languages, google protobuf furnishes a format that can be stored & retrieved by both sides.

Google protocol buffers binary encoding pattern which permits you to define a schematic model for your data using a specification language, like so:

message Payload {

 optional string contrast_ratio = 1;

 optional string viewing_tech = 2;

 optional string color_depth = 3;

 optional string touch_type = 4;

 optional int32 ntsc = 5;

 optional int32 temperature = 6;

 optional int32 backlight_longevity = 7;

 optional int32 luminance = 8;

}

The above schema is an example to define payload in IoT simulator. Here we use a structure that represents contrast_ratio, temperature & more, where it has every fields as a optional attributes.

By providing just a schema, you can now consequently acquire a class that can be used to encode and decode messages into protocol buffer pattern. As of now we had a glimpse of a bit overview of a protobuf, let’s dive in to the use of protobuf in IoT simulator specifics a bit more.

Adding protobuf support to Simulator

For all IoT implementations, JSON has become a default data format because of its light weightness and scalability which makes it easy to get & load the requested data quickly. In that case, you can simulate any level of JSON with IoT simulator to help you test your manager application. But the Protobuf is revamped to be faster than JSON by getting rid of many commitments conventionally done by data formats and making it focus only on the ability to serialize and deserialize data as quickly as possible. With the support of protobuf in IoT simulator you can make your payloads smaller and simpler. Also, if your client doesn’t support binary messages, there are capabilities to protobuf to serialize binary data to string.

Getting started with protobuf in IoT simulator is as simple as that. Just start defining your requirement as schema in .proto file and generate code in your preferred language using protoc compiler. You can start creating your devices and add event that corresponds to the one you have written in .proto file from the simulator UI itself.

The simple extension to have a glimpse and get on with protobuf in IoT Simulator is given here

Get started with protocol buffers by downloading IoT Simulator of FREE.

Testing HiveMQ & EMQX Implementation with Bevywise IOT Simulator

Testing HiveMQ & EMQX Implementation with Bevywise IOT Simulator

Bevywise IoT simulator is a comprehensive simulating tool to develop, test & demo real time IoT applications and IoT devices in a quick and easy way. It is a simple & powerful tool with all the flexibility to develop & test MQTT Broker / application without real devices/networks. In that case, Bevywise IoT simulator supports testing your IoT application built on any MQTT Broker available. This article provides you an ultimate step by step guide on integrating HiveMQ & EMQX with Bevywise IoT Simulator.

HiveMQ testing with IoT Simulator

Before we start the integration procedure to test MQTT Broker, let us complete the installation process of HiveMQ & Bevywise IoT Simulator.

HiveMQ Installation

First, check the pre-installation requirements of HiveMQ with the help of this user guide.

If all the requirements are satisfied, download Hive MQ package from the below-mentioned link.

https://www.hivemq.com/downloads/hivemq/

For Linux/MacOS

You can use the terminal to unzip & run the package

cd <hivemq_install_directory>

unzip hivemq-<version>.zip

Now go to bin foder & set your permissions

cd <hivemq_install_directory>/bin

chmod 755 run.sh

Use the below command to run HiveMQ (Root user)

 ./run.sh

For windows

Use your file browser to extract the ZIP archive to the directory of your choice.

To start the batch file, open the bin folder and double-click run.bat.

Once the installation is done, you can move to the browser at  http://localhost:8080

Enter the login details & get started with HiveMQ

  • User – admin
  • Password – hivemq

Bevywise IoT Simulator Installation

As the installation process is simple and easy, you don’t need to spend much time setting up the simulating environment.

Let us start by downloading the package. Download Bevywise IoT Simulator for free & you can use the FREE version without restrictions for 30 days.

For Linux/Mac

Unzip the downloaded “Bevywise_IoTSimulator__Linux.zip.zip”

or

“Bevywise_IoTSimulator_Mac.zip” file

Open the terminal & move to the bin folder

cd < Installation path >/Bevywise/Iotsimulator/bin

Now run the simulator with the below command

sh runsimulator.sh

For windows

Double click the downloaded “Bevywise_IoTSimulator_Win_64.exe” file

Provide the installation path in the installation window & start installation.

Open command prompt and go to the “bin” folder

< Installation path>/Bevywise/Iotsimulator/bin

Now start the simulator with runsimulator.bat command.

Connecting IoT Simulator with HiveMQ

You can either connect with TLS/SSL enabled or without TLS/SSL.

MQTT Broker Configuration

Enable/disable the TLS/SSL in MQTT Broker as per your need and check port number.

By default simulator runs in port 1883 if TLS is disabled & 8883 if TLS is disabled

Simulator Configuration

Start the Simulator in your environment and it will lead you to an IoT simulator user interface. Next, create a new network and the Simulator Setting windows will appear.

In the Simulator settings, choose as follows:

  • Manager Application – Others
  • Broker IP Address – IP address of PC or server where you run the MQTT Broker i.e (localhost)
  • TLS/SSL – Enable (if enabled)
  • Port – By default 8883(if TLS enabled), if your MQTT broker runs in a different port, specify here. Use 1883, if TLS is disabled
  • Root certificate – Upload the root.crt file which you have created or downloaded before.[ Don’t forget to click upload]
  • Once you’re done, save the configuration.
  • Next, create devices virtually with simulator and events with published messages.
  • There is no authentication option in HiveMQ side to connect devices. So you can directly connect your created devices without enabling authentication in simulator side.
  • Start the network by clicking the start button and if the connection is successful, then you can see the published messages in the simulator Network log or device log.

If your integration is successful, you can view the list of connected devices in HiveMQ UI. Now, get started with your application testing by simulating your real devices with IoT simulator.

mqtt-broker-connection-with-simulator
Simulator-dashboard

EMQX integration with IoT Simulator

Before we start the integration procedure to test MQTT Broker, let us complete the installation process of EMQX & Bevywise IoT Simulator.

EMQX Installation

Operating systems currently supported by EMQX Broker:

  • CentOS 6,7,8   
  • OpenSUSE tumbleweed
  • Debian 8,9,10
  • Ubuntu 14.04, 16.04, 18.04, 20.04
  • macOS 10.13, 10.14, 10.15
  • Windows Server 2019

Installation can be done in multiple ways. You can check your preferred method here.

https://www.emqx.io/docs/en/v3.0/install.html

Let us see the installation in Linux servers

One-click installation of shell script (Linux)

curl https://repos.emqx.io/install_emqx.sh | bash

Installation via zip package

Use this link to download your preferred package

https://docs.emqx.io/en/broker/v3.0/install.html#emq-x-package-download

 or

https://docs.emqx.io/en/broker/v4.3/getting-started/install.html#zip-linux%E3%80%81maxos%E3%80%81windows

Once done, unzip the downloaded package

unzip emqx-ubuntu18.04-v3.1.0.zip

Then start EMQX

<installation path>./bin/emqx start

<installation path>./bin/emqx_ctl status

 OR

Installation using snap store

sudo snap install emqx

To Quick Start with EMQX

sudo emqx start

To check Status

sudo emqx.ctl status

To Stop EMQX

 sudo emqx stop

To view the dashboard after running, use your browser to open: http://localhost:18083

You will get access to the EMQX dashboard by default when the broker starts. The default user name is admin and the password is public. 

To get a Free Trial License:

https://docs.emqx.io/en/broker/v4.3/getting-started/start.html#request-a-trial-license

Bevywise IoT Simulator Installation

First, download the Simulator package for FREE.

For Linux/Mac

 Unzip the downloaded “Bevywise_IoTSimulator__Linux.zip.zip

or

Bevywise_IoTSimulator_Mac.zip” file

Open the terminal & move to the bin folder

cd < Installation path >/Bevywise/Iotsimulator/bin

Now run the simulator with the below command

sh runsimulator.sh

For windows

Double click the downloaded “Bevywise_IoTSimulator_Win_64.exe” file

Provide the installation path in the installation window & start installation.

Open command prompt and go to the “bin” folder

< Installation path>/Bevywise/Iotsimulator/bin

Now start the simulator with runsimulator.bat command

Connecting IoT Simulator with EMQ X

You can either connect with TLS/SSL enabled or without TLS/SSL.

MQTT Broker Configuration

Enable/disable the TLS/SSL in MQTT Broker as per your need and check port number.

By default simulator runs in port 1883 if TLS is disabled & 8883 if TLS is disabled. 

Simulator Configuration

Start the Simulator in your environment and it will lead you to an IoT simulator user interface.

Next, create a new network and the Simulator Setting windows will appear.

In the Simulator settings, choose as follows:

  • Manager Application – Others
  • Broker IP Address – IP address of PC or server where you run the MQTT Broker i.e (localhost)
  • TLS/SSL – Enable (if enabled)
  • Port – By default 8883(if TLS enabled), if your MQTT broker runs in a different port, specify here. Use 1883, if TLS is disabled
  • Root certificate – Upload the root.crt file which you have created or downloaded before[ Don’t forget to click upload]
  • Once you’re done, save the configuration.
  • Next, create devices and events with published messages.
  • There is no authentication option in EMQX side to connect devices. So you directly connect your created devices without enabling authentication in simulator side.
  • Start the network by clicking the start button and if the connection is successful, then you can see the published message in the simulator Network log or device log.

If your integration is successful, you can view the list of connected devices in EMQX UI. 

 

EMQX-dashboard
emqx-connection-with-simulator

Hope this article provides you a detailed view on how to test MQTT Broker (HiveMQ & EMQX) with Bevywise IoT Simulator. Try connecting with any MQTT Broker & test your application faster. You can also connect FOREVER FREE version of Bevywise MQTT Broker with IoT simulator for reliable testing.

Download IoT Simulator now for FREE to get started with your application testing.

IoT Simulator 2.2 Release

IoT Simulator 2.2 Release

Simulating various scenarios is essential for testing & developing real-time devices & managers. We believe that event configuration should be much easier & simple so that we can spend more time on validation & analysing the final data. We at Bevywise always strive hard to make our solutions easier & faster for our customers. Hence, we enable CSV Import option in IoT simulator to configure the IoT events to publish time-based messages. With a new update you can save your time by submitting your pre-defined data in csv file.

Assign a bulk publishing event

Sending events with different variable data at different times that is creating a time-based message publishing will make the simulator event generation more versatile & robust. CSV importer will allow you to assign a bulk publishing event during a specific time interval. You can configure the IoT events by uploading your pre-defined data set as csv file. This allows you to add or update events at one time, avoiding the need for updating multiple times.

CSV import option will simplify & saves time on the IoT event configuration. With the new update you will be able to replace the time-consuming methods & get your events to be published in an effortless, simple & faster way.

Supports JSON array

For all IoT implementations, JSON has become a default data format because of its light weightness and scalability which makes it easy to get & load the requested data quickly. JSON is preferred for all IoT applications since it can self-describe. JSON is a way to store information in an organized & easy-to-access manner. The previous version already provides support to simulate more complex nested MQTT JSON data.

Most devices use the JSON array to transfer data in a simple & efficient way. To enable testing in a more efficient way, we have made a simulator to publish messages with multiple data and information. With the new update, IoT simulator provides support to simulate JSON array data which help you check the efficiency of your devices more accurately. By this functionality, you can now simulate any level of JSON to help you test your manager application.

Keep an eye out for further updates and upgrades. Try the latest version of Bevywise IoT Simulator now.

 

Developing IoT virtual network using IoT simulator

Developing IoT virtual network using IoT simulator

Every IoT project needs testing. IoT simulator eases the life of developers and testers by providing complete functional and load testing.  IoT device simulation helps you simulate various scenarios needed for developing, testing and demonstrating real-time devices and managers.  In addition, you can create your own virtual IoT device with much ease. You will be able to develop, test and demo your IoT servers, managers, MQTT clients, MQTT sensors, and MQTT Devices. IoT simulator supports MQTT protocol that it creates publish events, subscriptions and more.

Creating Publish events

Above all, IoT simulator allows you to create templates for your devices and topic names to create dynamic networks. You can send messages within a range or from random set or values based on time and client. It can send multiple values in a single message like the real world IoT devices. The publisher will send data to the broker for every second or minute based on the device. For example, the temperature of the room can be send to the broker based on time.

Connecting to IoT platform

You can connect IoT simulator to Azure IoT hub, AWS IoT core, any IoT platform like Bevywise IoT platform and any other MQTT Application or Broker. IoT simulator supports all Qos levels, WILL & Retain messages, MQTT authentication & clean session as MQTT specifications. Broker collects data from the publisher for every second or minute based on the device. Besides that you can easily hook the data stored to send it to any data visualization tool for powerful analysis and decision-making.

Creating Subscriptions

The broker will collect data from the publisher and store the data in any data base, but the data will not be sent to the receiver side until you subscribe to the existing topic. For instance, The Air conditioner needs to be switched off if the temperature reaches 25’C.  The publisher will send a message to the broker and the broker will send a message to the clients who subscribe to this topic.

Configuring Device response

The automatic response which will respond to the subscriber based on the received message and topics can be done by behaviour simulator. As a result, behaviour simulation helps transforming incoming messages and publish different message and as different client. Besides that you can add alerts by using behaviour simulator.

Download IoT simulator now to create your own virtual IoT device.

IoT Simulator 2.0 Release

IoT Simulator 2.0 Release

Security is one of the major concerns of the IoT Manager applications. Keeping this in mind, we built the manager applications with different level of security. IoT Network Simulator is enhanced to support all manager applications based on their security practices. Similar to the previous version, the simulator supports all its options from the user interface itself.

IoT Network simulator for AWS IoT core / Azure IoT hub

The User interface will provide options based on the IoT applications. For example Azure IoT hub supports SAS Token and Certificate based authentication. Users will be able to create a specific network for the Azure IoT core and able to create devices that handshakes with the IoT hub based on the details specified when configuring the device. Similarly, this is possible for the AWS IOT as well.

Simulating IoT Network for Other Manager applications

For all other manager applications like Bevywise IoT Platform, Losant , and others, you will be able to specify a single certificate at the common settings page and get your devices connected to the manager application.

Device-level SSL Security

Azure IoT / AWS IoT manages every device to have a unique certificate. In addition, the IoT Network simulator supports the configuration of the root Certificate in the settings window and ensures that you specify each and every client certificate in the device configuration screen. The WILL, QoS, retain event messages and command messages configuration is the same as before.

Individual Device IP Address

The simulator runs on a single machine and simulates all its devices. But, The manager will be seeing all the devices from one Host (IP Address). This contradicts the real-time Simulation. In order to overcome this, the 2.0 version has added support for using Virtual IP Addresses. By this functionality, each simulated device will connect to the manager application from a different host Address.

Try the new IoT Simulator 2.0 now.

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 protocol 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 MQTT Broker 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.

Feel free to write to support for any questions.