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:

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 routin

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 MQTT broker & IoT Simulator for devices and sensors based out of MQTT and MQTT-SN Protocol