Bevywise Networks | IoT Platform & IoT Solutions - IoT Solutions & Artificial Intelligence to make a better tomorrow.
  • MQTT Simulator enhanced

MQTT Simulator 1.5 – Everything you need to know

By Ranjith Kumar Diraviyam




  • MQTT Simulator enhanced

MQTT Simulator 1.5 – Everything you need to know

By |April 24th, 2018|


We are happy to announce the new updated MQTT Simulator which can help you do simulate a more complex nested MQTT JSON data simulation and much more. Here is the list of additional values the simulator can provide to your test environment.

Complex MQTT Data Simulation

Most devices today send data as nested JSON. As more than one meaningful value is packed into a message, the real world has moved on to the JSON as a default data format on all the IoT Implementations. To enable testing of such environment, we have made the simulator to publish messages that has the same kind of JSON format. You can simulate any level of nested JSON to help you test any manager application.

complex nested mqtt data simulation

Emulate Real world Device Uptime

In the Real world situation, the devices connectivity cannot be uniform due to various reasons like power , network and other device failure related circumstances. In order to replicate the same real time scenarios, we have added the Randomized start / stop of devices based on your configuration. You can specify the lowest possible uptime you would like to simulate in the networks. We will make sure the devices have an uptime that ranges from the specified value up till 100%.

For example, if you specify the minimum uptime as 91% in the MQTT Simulator, then the devices will have a uptime between 91% & 100%. The devices will be automatically stop and restart multiple times to maintain an uptime of the specified range. Different devices will have a different stoppage time based on the random data. We are working on generating a report for the uptime so that it can be compared with your manager applications report. The reports will be available in the next version of the simulator.

Flexible IoT Events

90% of the world is going to be with Sensors which are going to just publish events. These sensors sends events with different variable data and variable times. The simulator can now send events On StartOn Disconnect , For a specified time duration & For the whole day with a specified time interval , at a specified time and by a manual trigger. You can add multiple events for these each criteria and each event can have unique complete JSON with a variable data of System defined variable, RANDOM , RANGE and LINEAR data variance. These features make the simulator event generation more versatile and robust.

Flexible IoT Simulator Events

Refreshing MQTT Simulator UI

The MQTT simulator UI now provides a easy to view events that are published from the device and the commands received from the manager / broker application on the user interface to make the testing much easier. The User interface also has been made more cleaner for easier overall device simulation.

The Settings of the simulator like Broker Address and Port , TLS / SSL enable , Python Interceptor and Uptime simulation has been moved to the User interface for the ease of use.

MQTT Simulator UI

Try the latest version of the Bevywise MQTT Simulator now.

Download IoT Simulator

We are working on integrating the simulation with the other automation tools to provide a complete test automation.

For more reference Please refer our Help document and watch our YouTube videos. 

  • Advantages of MQTT

MQTT vs REST from IoT Implementation perspective

By |April 11th, 2018|


Most of the IoT Implementations today uses REST over HTTP based connectivity from the client to the Server. REST has its own limitation that pops in while your solutions scales up to the larger number of devices and more number of translations per second. MQTT, the light weight protocol designed exclusively for IoT has its advantage over REST in all dimensions. This blog compares MQTT vs REST to help you finalize your communication protocol.

Instant Response – Need of the hour

REST is a one way connection. The connection to the server is intermittent. The client connects to the server when needed to push data from the client and pulls the data down to the client. The server needs to wait for the clients to connect to send the data that is intended for the client. This makes the user intended action to wait for the client connection. Most solution providers allow their edge server or their gateways to connect every 1 minute or higher so that the server is not loaded.

Take an example of a activating a light from a mobile app. The message from the mobile will hit the server instantly. But the message from the server to the client needs to wait for the time client to connect.

MQTT allows the client to be connected always providing a two way communication between the client and the server. This allows server to push the message to the edge device making the device respond to your command instantly as expected by Customers.

Lower Power consumption

When directly compared for the same data transfer using REST and MQTT, MQTT consumes 20% lesser power. In the case of the REST, most energy is lost on the resources used on connecting and disconnection and resource cleanup on both the server and the client. So when you build a battery operated remote device, MQTT helps you with a longer battery life than REST.

Highly Secure IoT Device Deployments

Most of devices today are deployed behind the firewall for the security reasons. One of the limitation of the REST is that the server can no way communicate from the server to the client on demand. Even if we put a REST Server on the client devices and try to make connections form the server, it will fail when devices are installed behind the firewall. MQTT inherently solves this problem of two way communication with the persistent connections.

MQTT vs REST Performance

MQTT is an always connected against the intermittent REST Calls. Due to the permanent connection, the need to connect and disconnect for every data transfer is not required. The keep alive ping has a much lesser overhead compared to the reconnection connection calls the REST makes. As per the analysis and test reports, MQTT data transfer can transfer data at a rate 20 to 25 times faster than REST Calls.

The number of message transaction highly depends on the number of connections the server can accept in the stipulated time. The number of concurrent connections that the fastest available web server today will be in the order of 1000s per second. This restricts the data transfer in sequence. MQTTRoute can process upto 40,000 messages per second on a commodity server. The number of parallel connections the broker can hold can again be tweaked based on the hardware. A simple commodity server can hold upto 50,000 connections in parallel.

In a clear advantage, MQTT wins the MQTT vs REST choice for the IoT Implementation.  Try MQTTRoute the fastest MQTT Broker available today.

Download FREE MQTT Broker

Do write back your queries to Bevywise support.

  • Iot Implementation - Design the data

IoT Implementation Series – Design the Data

By |March 21st, 2018|


As part of the IoT Implementation series, this topic covers the best practices in designing the data communication between the edge device and the Central Platform.

IoT Device to Cloud response

Humans always expects a response for every action. The response can be emotional, physical, visual or in any human understandable form. The same is the norm when we interact our intensions via an ioT device. Developers often miss the point that the edge device too need them for a completion of the response back to the humans. The acknowledgement user need is different from what the protocol provides. The protocol level ack message only confirms the receipt of the data at the edge or the server. But the action happens after the protocol ack is sent back. So you need to make sure you send back a message from the device or the server once the intended action is complete. The response should be a success or a fail message based on the outcome. Check the outcome before the message is triggered.

Design the right message handle

All IoT Protocols have an identifier for the event and command messages between device and manager application. MQTT calls it by the name Topic. It is very important to define good and clear topics for the communication. The topics should be very relevant as it should be understandable by the Humans too. It is advisable to have a mandatory device identifiers on the subscriptions, as we will be able to know where the command is going. For the events, it is the implementors choice to use the topic.

Send relevant Data to MQTT Cloud

An half baked data is equivalent to having no data. So make sure you put all the data available into the cloud from the edge. For example, when we collect a machine status from the edge device, the core information is about the health of the machine like temperature, coolant flow, vibration level. But we often loose sight of the time relevance at the edge. It is better to get the time from the edge device than use the time on the server. Add the device identifier also as part of the data which can help a lot during the data analysis. There will some more core information which may not be of interest today. But it is better to have them for future analysis.

Identify & Group the Devices

Different IoT Cloud application has different kind of device identification process. Most of them get this done when they add the device. But this process increases the human effort to add these devices. Bevywise Iot Platform allows any device to connect if they have the right auth keys. The device can send additional data later. Most of the IoT Protocols today does not allow you to send more information while connecting to the server. So identify the register command and the list of data requested by the IoT Platform and send it as a separate message based on the protocol. On the platform side, you will be able to create device specific user interface for your operators based on their roles. The IoT Platform mostly need to know the type of the device, manufacturer, location, etc. But you can always customise it to have more information as needed for your IoT Device management and inventory.

Mobile integration

One of biggest deceiving point in the IoT Implementation is that the developers tend to use the same protocol to connect your mobile applications. But that is not the right IoT implementation of the mobile application. The mobile application should be built over the REST API of the IoT Platform and should be integrated with messaging system like Firebase Cloud messaging for the notification. As an option, developers can use the protocol based communication when the app is open for instant messages to the server, but should not depend on it end to end.

Bevywise Networks is an end to end solution provider for IoT Implementation for any vertical from Edge devices to IoT Cloud Platform. We would be happy to help you get your solution tailored by us.

Free IoT Consulting

 

Related Post:

Designing the Edge

  • Integrate MQTT Broker as a component into your Server

Integrate MQTT Broker into any Application

By |March 5th, 2018|


MQTT Broker is the central server that  manages all the communication between the edge devices, collect data from them and ensures the Quality of Service in message delivery.  Any IoT Management application needs the MQTT Broker as one of the communication component.   We have been providing MQTT Broker in two different flavours.

IoT Platform

The IoT Platform is a SaaS based highly scalable architecture which can be used to connect millions of devices. The IoT Platform also supports multi tenancy by which you can provide solutions to any number of devices. The Platform provides an individual customer access to manage their devices and create rules for automation between their devices. The platform in turn provides a powerful API interface which can be used to build web and mobile applications over the platform.

Standalone MQTT Broker

The MQTTRoute is a standalone MQTT broker which supports all operating system. The MQTTBroker can be extended by connecting to any big data engine or your application over python connectors – MongoDB Connector & ElasticSearch Connector.

Something is missing ??

YES…  Even though the above components can be integrated into any of the manager application, these application needs a standalone monitoring and server management.  The existing Device manager and IoT Applications vendors will be more than happy if they can integrate these applications into their application.

When used as a separate component.

  • – Multiple set up process.
  • – API Control for every operation.
  • – Separate Data Storage.
  • – No control over the MQTT Broker process.

MQTT Broker as an integral Component

Keeping this in mind, we today announce a variant of MQTT Broker where can be added as one of the components into your application.   You will be able to do the following.

  • – Start / Stop the MQTT Broker from your core application.
  • – Know about the client connects and disconnections, the clients IP address, passwords used and the will details.
  • – Know about the messages published from the edge devices.
  • – Know about the subscription details of each device
  • – Know about the message propagation to individual edge devices
  • – The acknowledgement status for each message sent to each device.
  • – Send message to each device individually or as a group.
  • – Control over the authentication tokens.

This MQTT Broker component can be integrated into any of your application and can be made to work irrespective of the programming language in which your product or server is built on. The component can provide more functional communication between the component and your application based on the need. 

You can download and try our standalone MQTTRoute.

Download FREE MQTT Broker

Looking for getting your application MQTT enabled, drop a message to support.

  • IoT & IIoT Implementation - Designing edge device

IoT & IIoT Implementation Series – Designing the Edge

By |February 13th, 2018|


Edge device is one of the core component of the overall IoT & IIoT implementation.  Edge devices is the key source of data for the IIoT Implementation. The first important thing to be kept in mind is that nothing is reliable. The nothing mainly constitutes the Power and the Internet.

Power Saving:

There are two kinds of devices with respect to power. First one is connected to the electricity and the later is without any continuous power source. The second ones runs on batter. In the former case, there is no need to worry about the usage of the power.

When you create a device that runs on power, you need to make sure, the number of cycles you run per second determines the power consumption.  In one of the implementation, we enabled the communication of the remote device with the central server only when there is a change in the data. But the device will monitor the condition every few seconds. This will increase the battery life and at the same time save a lot of network traffic.

Internet Failure:

The device cannot take the Internet connectivity for granted. The device should be optimised for reconnections.  So the reconnection should be made smoother with longer intervals, so that there is not surge in the drain of battery.

The device should be connected with  MQTT WILL Messages so that the interested parties or the device manager will notify every one with the device disconnections once it happens.

Heat Generation:

Heat dissipation is one of the most important aspect to be considered for the device development. Even a very small heat generated in the micro controller should be properly let out. If not done properly may lead to Fire hazard. It becomes more important when you develop devices that works on the high voltage lines.

IIoT Implementation –  Software:

Most MQTT servers supports two forms of connecting to the Central broker.

  1. TCP Connections
  2. Web Socket

The remote devices should implement the tcp form of connections. The web browser based clients or communication when the applcaition is open can use the Web socket. But for mobile offline messaging, developers should strictly use the other tools like Firebase Cloud messaging.

MQTT Connection Security:

Most MQTT Server can be run in Non TLS or TLS mode. We recommend you to run the platform enabling the TLS mode in the configuration. The TLS enabled broker will listen at port 8883. You can refer to our previous article on creating SSL Certificate for MQTT Communication for generating and using TLS Certificates. The above article also provides steps to add the client certificate in your client folder and connect it to the central Server.

client = MQTTClient(“Secure_Client” , 1883 , “40” , “broker.bevywise.com” , 0)

PS:- Even though the MQTT Platforms support TLS modes, we run them as NON TLS mode on our server for ease of development.

MQTT Device Authentication:

TLS data transfer provides the option to transfer the data securely. But the MQTT Authentication will provide an additional level of security. The Authentication also provides a level of access Prineville on who can publish and who can receive data from the MQTT Broker. The access restrictions will be defined at the MQTT Broker level and the clients can use the device authentication as needed for the implementation.

client = MQTTClient(“Secure_Client” , 1883 , “40” , “broker.bevywise.com” , 0 , “authentication_key”, “authentication_value”)

Setting WILL Details on Connection:

Setting the WILL messages will help other devices / applications in the network know the status of the device that sends the WILL details to the Broker. The WILL message will be triggered when the device disconnects with a notice to the broker. To connect the client to the broker, you can connect using the following method.

client = MQTTClient(“Secure_Client” , 1883 , “40” , “broker.bevywise.com” , 0 , “auth_key”, “auth_value” , True , 0 , 0 , “/will/device/” , “Device down”)

You can use the following prebuilt clients on Python to connect to any standard MQTT Broker via TCP.

 Macintosh         

 Linux                   

 Windows 32-bit

 Windows 64-bit

 ESPClient           

You can have the following import and then write the above code.

import py_mqtt_client

 For the Websocket based client, you can use the following client.

 Eclipse Paho Client for Web socket

Bevywise Networks is an end to end solution provider for IoT & IIoT Implementation for any vertical from Edge devices to IoT Cloud Platform. We would be happy to help you get your solution tailored by us.

Free IoT Consulting

  • IOT Device Manager Update

IOT Device Manager – Security & Device Management Update

By |January 24th, 2018|


IOT Device Manager application has been enhanced with more security and Device management functionality. This update is supported in the On-demand version and the self hosted platform.

Instant Command:

 Most IOT Devices that connect to the IOT Device Manager will send events and at the same time listen to specific commands for receiving instructions from the manager application. The manager at anytime send commands to device to active some tasks or manage them.  The new update has been added with an option to send commands to specific device or a group of device which listen to a command.

Authentication & Access Privilege:

The new update allows you to create multiple Authentication keys for a particular set of IOT devices and also allow users to set access rights like Read/Write, Read Only and Write Only.

 The Sensors which just sends data to the IOT Device Manager can be allowed to use the Write only keys while an actuator valve which turns on and off flow of liquids can be used with a Read Only key. The new functionality allows right keys to be used as required for enhanced security.

The Device manager also provides an option to disable a particular authentication key inactive in case of emergency or suspicious connections and re enable once the alarms are cleared.

Enhanced User Interface:

The User Interface has been enhanced with a better dashboard and a cleaner look and Feel.

Powerful API for Integration:

We have added a few apis that will help build the Mobile application or integrate any application to the IOT Platform. You can download the PDF which contains the API Specification here. These API will also work on the custom hosted servers and you need to use your domain instead of https://devicemanager.bevywise.com in the API URL.

With an objective to allow users to easily SignUp and manage their devices, we have set up the Device manager in the Non SSL mode for the TCP and the Web socket Communication.

Create Account in Bevywise Device Manavger

The Device manager can be customised and hosted in your Brand on your servers. Request a Quote if you are looking fora platform for privately managing your customers devices.

 Feel free to contact us via support for any assistance or feedback.