Building World class IoT Manager Application – Best Practices

Building World class IoT Manager Application – Best Practices

Developing an IoT Application spans across multiple technologies.  It is mandatory to ensure every component involved  is made the best.  So that every one can work together in the best possible way.  Our previous posts  design the Edge,  design the Data  and  designing the IoT agents are a few  articles targeting how you should get your edge device ready for the collaboration. This article covers the best practices for building the IoT manager application.

Technologist always view implementation in their own best known protocol.  Having said that MQTT is the most preferred protocol option of implementing the Edge device communication. . But one of the worst advice give across the web for building manager application is just subscribe to the Broker for all the topics using (#) as another MQTT client and collect data and with that do whatever you want to do.  But we need much more for building manager application. Here are the few requirements for building it.

Need for Complete data

You need the complete data to perfectly design the manager application. People often misinterpret Payload that comes in the messages as a complete data. But beyond that, you need the security keys used, the IP address, the local time of message receipt, the confirmation acknowledgement states, error packets if any, number of connections / connections and a lot more information.

State of Message Delivery

MQTT is best for communication between the Broker and edge device. But the state of delivery of the various QoS levels are limited to the Broker and the client.  The subscribers are not provided with it. This is not only applicable to MQTT, but for any protocol. The IoT manager application should be able to know the state of each message delivery for all the transaction with the edge devices seamlessly.

Security & State of Device

In any IoT Implementation, especially in Industrial ones, the uptime of the edge device is important. So monitoring the edge device for the connectivity and also generate Uptime reports for the connectivity can be done. The manager application needs the complete edge device status data for reporting. Security can be monitored closely when we have the edge device error rate, frequent change in IP or security keys used  and more with the manager.

Behind Gateways

In almost every implementation, there is going to be a gateway behind which there is going to be a lot of sensors / actuators. These edge devices needs to be managed individually by the IoT manager application. We have designed our Platform in such a way that the gateways can send a particular MQTT packet to the platform conveying the individual device details behind it. Such an information will be available only with the Broker and cannot be passed on to some other  edge device.

Mobile won’t work 100% on MQTT

The even worser part is the same advice is provided for the mobile IoT application development as well. All protocol communication except FCM push will be closed by the Mobile OS when the app goes to the background. You can use MQTT to send messages to be broker when it is not avoidable, but never listen to MQTT by keeping it alive at the background. You are going to drain a lot of battery.

How should I build IoT Application

MQTT is a great protocol for edge device communication. But not for the manager / control application. The best way to implement is to closely integrate your application with the data. In our MQTT Broker we store the data into the data store which can be queried directly by any application. We also provide an option to extend the storage, so that the developer can store it anywhere he want and REST API for integration. So choose a MQTT Broker that provides the option for data storage and you can write your application over it. You should be able to directly talk to the MQTT Broker to manage the device (not via MQTT).

If your MQTT Broker does not allow direct integration, allow the broker to store all the data into a Database and build a module that can expose all the data via REST for your further processing. REST provides all the information as available in the data store / big data storage for your processing which is mandate for building a world class IoT manager application.

Feel free to try our products from our downloads page.  Schedule a free consulting now for knowing the best practices for building your IoT Application today.

Best Practices for developing IoT Agents

Best Practices for developing IoT Agents

Every smart device being built today has the software that reads data and communicate with the other devices to create a completely smart environment. It is very important to have a robust and reliable agent for a smart environment. Few best practices to develop simple, light weight agents are,

Don’t build Intelligence into Agents

The  limited life batteries powers IoT devices at the periphery mostly.  Agents should be programmed to run a very few procedures like listen to the event and send the data to the central server, and when the central server sends a command, the agent should trigger the event based on the command. The only code in the agent should be:

If(message_received == “DO THIS” ) {
else If(message_received == “DO THAT” ) {

A little more to this will ruin the battery at a faster rate. Further upgrading the intelligence inside every agent is going to be a very costly deal. The best thing is to create a dump executor agent. If you are doing a MQTT based implementation, just subscribe to only one topic and publish to only one topic and the rest should be taken care by the central broker or the server behind it.

Let the Agents Sleep

Most devices work based on the event that occurs on the devices. In such a scenario, there is no need for the agent to be continuously connected to the Central server. Select a good Protocol standard that allows your agent to sleep for a stipulated time and then come back live. MQTT-SN provides this option. The agent should reconnect within stipulated time to check for messages (if any) for it from the Central server. Have a check on how critical is the data it collects and decide on the sleep duration.

Avoid local storage. Just send it

Time sensitivity of the data is increasing day by day. The sooner the data is received in the Central server, the better decisions will be made by the central big data engine. The Embrace IoT for Perfection will give a more detailed insight into the fast feedback loop

The agent is not for storing data. As soon as you get the event, send it to the central server. Aggregation of data can also lead to intermittent data loss, so Just Send it.

Set Strong Disconnection message

Disconnection of the devices is going to be a more common phenomenon with the explosion of the number of devices and other physical factors affecting the connection. The device can go out of connection due to factors like loss of power, network issue, etc., Make sure the central server or the manager or the relevant devices get notified when devices go out of connection. Set Stronger messages if the particular agent is mission critical. MQTT provides an option of WILL MESSAGES which can inform the other clients and manager if the particular client goes off.

Perfect Restart and Reconnect routine

Anything and Everything can Fail and everything will come back to life. So are the devices. Make sure you hook  agent  well to the start / stop routine of the device for which you program it. The central server in spite of hosted on highly available data center too is no exception to the failure rule. The agent should have a good reconnection algorithm to check the server availability. Very frequent ping to a non available server will drain the power at a faster pace.

At Bevywise Networks, we have built our IoT agents, enterprise broker & simulator for devices and sensors based out of MQTT and MQTT-SN Protocol.