IoT Simulator 2.0 Release

IoT Simulator 2.0 Release

by | Mar 1, 2019 | Announcement, iot simulator, MQTT Client, MQTT security, MQTT simulation

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

download now

 

MQTT Broker – Manage devices better

MQTT Broker – Manage devices better

by | Oct 16, 2018 | MQTT Broker, MQTT security

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.

Effective use of MQTT Last WILL Messages

Effective use of MQTT Last WILL Messages

by | Mar 14, 2017 | MQTT

Every IoT network is a collaborative working of edge devices. All devices should work in unison to make the environment conducive for the humans. This article helps you make the best use of the MQTT Last WILL Messages.

Last Will is a way of peer to peer monitoring between MQTT clients that operate in a more understanding way. Before we go into the real time use cases, it is better to understand the spec better.

What is the MQTT Last WILL ?

Last Will is a message stored in the MQTT broker specific to particular clients. The Last Will message is a normal MQTT Message that has a will topic, will message , MQTT QoS and retain flag. These messages will be sent to the clients who have subscribed to those WILL topics by the broker when the particular client disconnects ungracefully.

The Last WILL Message should be sent to the broker when the clients connect to the broker via the Connect packet.

A more detailed explanation of how you have to send the connect packet is available here.

When it will be published ?

The WILL Messages will be published by the broker to all the interested subscribers when the particular client gets disconnected from the broker ungracefully. When the client disconnects using a proper disconnect message, the WILL will not be published. The client needs to notify the interesting parties on going down by publishing proper message by itself.

Putting it to use

All mission critical devices needs a back up. Let us take an example of a Database server in an online application. It is one of the core component that needs to run always for the complete service to be useful.

These applications will have masters , slaves and standby servers which needs to be deployed when any of the servers fails. The master server should add a WILL on Connection. The slave will be subscribing to the particular WILL. The WILL should be configured specific to each cluster of the master slave. In this scenario, the broker should be configured to publish the WILL for the graceful as well as ungraceful disconnection of the Master. When the master disconnects, the slave receives the master unavailable message and the necessary scripts can be triggered for the slave to become the master. The standby servers will  become slave and now will subscribe to the WILL of the new master.

This is one scenario of automated take over. Such scenarios exist in all industries like Medical, all kind of Manufacturing industries. We can also use the WILL Message triggers for monitoring the devices and their uptime from a central server.

You can avoid a lot of unwanted monitoring messages to each devices by making the right use of MQTT Last WILL Messages.