How to create simulated IoT Device?

Bevywise IoT Simulator is a Free, highly scalable IoT Device Simulation suite that helps you simulate various scenarios needed for developing , testing and demonstrating realtime devices and managers. The IoT Simulator supports two modes of device configuration. The first one is using the configuration files and the second one is via User Interface.

There are three major requirement under which the IoT Devices M2M communication can be grouped. They are:

  1. Failover & Redundancy
  2. Data Collection
  3. Activate Edge Actions

This article explains how we can simulate IoT Devices using the CSV configuration files and the User Interface will be discussed in the next post. The simulated IoT Devices can be used along with your real devices to act as one of the missing edge devices to have a complete test environment.

IOT Device Failover & Redundancy:

Any redundancy set up needs a master and standby device. The IoT failure of the master need to be propagated to the standby device. In our scenario, the master and the standby device will be connected to the broker and the standby will subscribe to the status of the master device. The broker will notify the standby device when the master goes off for the standby device to take over.

Take an example of the Diesel Generator of a large facility. It has a master and a standby generator. The master should register a WILL Topic and message to the broker and the standby generator should subscribe to the will topic of the master. When the master Diesel generator goes down, the broker will send the message to the interested clients.

Open the willmessage.data inside the data/ folder. The DG master will register the WILL when it connects to the Broker.

# Client name : Will Topic : message : Qos : Retain
DG-Master : /fac/dg_master_status : Down : 0 : 0

The DG-Standby should listen to the master status and do the necessary action. There are two kinds of action required.

  1. — Getting the Standby up and serve the need.
  2. — Sending the status to the Facility manager.

This can be configured in the subscriber.data for receiving the message of the failure.

# Client name : Time : operation : Topic name : Qos
DG-Standby : -1:-1:-1 : subscribe : /facility/dg_master_status : 0

The standby server also need to send a message that it has become active which needs to be configured in the response.data

# Client Name : Request Topic : Message : Response Topic : Message:Qos
DG_Standby :/facility/dg_master_status : Down : /facility/dg_slave_status : Active : 0

Data Collection:

Every decision taken today is powered by the data. The perfect decision making needs a lot of time series data. This mandates the need for collecting data from the edge device for every second or minute based on the device.

IoT Simulator can be configured to send data continuously to the broker and the interested server every second. Health care requires health data to be recorded and sent every second. Let us now simulate a device that records and sends data every second. This needs to be done in the publisher.data

# Client_name : Time : operation : Topic name : Message : Qos : Retain
Heartbeatsensor : *|*|* : publish : /health/HBR : 72 : 0 : 0

Every second is the most possible time interval for sending data. Time can be configured in a very much of a flexible pattern to send every minute or every hour or particular minute of every hour or particular second of every minute and more.

IoT Device Actions:

Sensors mostly work on the data collection. But these data needs to be processed and the necessary action need to be taken. The IoT Platform gives you the flexibility to aggregate and process the data. The inference from this data can trigger messages to the edge devices which can trigger actions at the edge.

For example a water level sensor and a water pump switch can be taken as an example of how we can sense data as well as take actions. In this scenario, the water pump needs to be started when the level is low and needs to be stopped when the water level is high. The water pump will also publish the current status once the the status changes. We can configure this in the response.data

# Client Name : Request Topic : Message : Response Topic : Message : Qos
Water_Pump : /facility/water_level : LOW : /facility/pump_status : STARTED : 0
Water_Pump : /facility/water_level : HIGH : /facility/pump_status : STOPPED : 0

To make this work, the publisher.data can be configured to send the status of water level as LOW and HIGH alternatively.

# Client_name : Time :operation : Topic name : Message : Qos : Retain
Water_Sensor : *|29|* : publish : /facility/water_level : LOW : 0 : 0
Water_Sensor : *|59|* : publish . : /facility/water_level : HIGH : 0 : 0

Hope this article helped you simulate your own IoT Device using the IoT Simulator. Do feel free to write to us if you need any assistance with your device. We do have a few advanced options like Intercepting and customisation of messages and API Control which we will talk in detail in our next article.

Download the IoT Simulator for FREE now to create your own simulated IOT devices.

Do feel free to write to us your feedback and queries using the contact page


Originally published at www.bevywise.com on July 12, 2017.