iot development Archives - Bevywise Networks

How IOT can Save Money?

by Ranjith Kumar DSM | May 24, 2017 | General

Cutting cost is one of the major goal for any production line. This blog gives a heads up on how can IOT save money for you.

Human race is running very fast to beat the time. In this race, we often fix problems at surface level and did not go into root cause of the problem. Hence this results in repeated occurrence of the problem creating a bigger damage. But the reason for most of the quick fixes is we don’t have enough data to understand real problem.

If we set a target to reduce the power consumed in a manufacturing, our agenda would be to switch off all unwanted visibly running equipment without understanding who is the real culprit. The real saving will come when we really understand who is consuming the excess power than the prescribed rating.

Aristotle says, “The whole is greater than the sum of its parts.”

IoT is the saviour which can help you collect a lot of information from various points of interest. And it will help you analyse it with a time perspective and take proactive decisions. You can deploy the sensors in your production line to understand the flow of materials, machine efficiency and make decision on the maintenance schedules.

With real time data, we will be able to make the best decision in manufacturing, shipping, health care , fitness , automotive, home etc.

“By looking at close to 600 variables in 16 stations in the assembly line and looking at data over a period of time we have been able to bring down scrap by 67%—that’s massive in terms of material usage. If you put a cost to the material, you are saving close to 2.4 million euros annually.” , claims

Bosch

or provide details

for a free consultation on how you can improve your efficiency with IoT.

Benefits of MQTT-SN over MQTT

by Ranjith Kumar DSM | May 23, 2017 | General, MQTT Client

MQTT SN is exclusively designed for sensor networks and the specification for the same (MQTT SN specification) is available at MQTT.org. MQTT protocol & MQTT SN (MQTT for sensor networks) are both IoT Protocol used most widely for developing IoT devices. This blog is for developers to understand when to use MQTT-SN (SN MQTT for sensor) and the advantages of the same over MQTT.

MQTT SN Auto Discovery

In the MQTT set up, agents need to be informed where the broker runs. This increases the configuration overhead at the end user. But for MQTT-SN protocol, the sensors and the gateway can propagate messages which is understood by its counterpart and can establish connection to communicate with each other. This makes it much simpler to configure.

Reduced Bandwidth

The size of the every packet that is transferred in the MQTT-SN has been redesigned. For example in the CONNECT, only the required parameter is sent. The WILL and WILL Message has been split into separate packets and sent only when required. The overall data transferred over the network is reduced to a greater extent to reduce the bandwidth used. Moreover MQTT SN supports four types of MQTT QoS (Quality of service) QoS 0,1,2,-1 or 3.

Predefined Topic IDs & Topics Names

The topic names can be predefined in the MQTT SN Gateway with a pre defined topic IDs. The client can directly send packets using the ID and no need to use the topic names. The topic IDs occupies a max of two bytes. The short topic names less than 2 bytes can also be used without topic IDs. If the client wants to use a new topic, then can send a register command for the new topic.

Lower Processing Power

The packet size reduction highly reduces the amount of power required to create and communicate data. Further there are provisions like Sleep of the clients which will stop the gateway from further sending or publishing messages to this client . The client can send a resume message to get all the packets received during the sleep period. This make this publish subscribe messaging protocol highly suitable for battery powered sensors.

Connectionless

MQTT is over TCP/IP Protocol. TCP has a lot of connection over head which is not required in the MQTT-SN which is over UDP. And it does not depend on TCP/IP networks. This again reduces the amount of data transfer and the power required.

Medium Independence

It can be propagated over Zigbee, Z-Wave , bluetooth in addition to the wired and wireless sensor networks. MQTT SN is mainly targeted at embedded devices, on non TCP/IP networks such as zigbee.

You can have a look at the detailed document on how to develop MQTT-SN Clients and how to develop MQTT Clients.

Best Practices for developing IoT Agents

by Ranjith Kumar DSM | Jan 17, 2017 | General

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” ) {
DO_THIS()
}
else If(message_received == “DO THAT” ) {
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 MQTT broker & IoT Simulator for devices and sensors based out of MQTT and MQTT-SN Protocol.