MQTT is primarily a M2M protocol. It was originally designed for send sensor data from a remote oil field.
As the number of sensors increases the amount of network traffic generated by sensors will increase dramatically and depending on the transport it could prove expensive.
It will be important to understand this sensor traffic and how it can be reduced.
In this tutorial I will be looking at sensor data and sensor types under various conditions and analyze the amount of network data that is generated.
This you may find useful when planning a sensor deployment.
Sensor Basics and Types
Although there will be very many sensors recording lots of different types of data. e.g we could have pressure sensors,temperature sensors, door sensors etc.
Generally they fall into two basic types:
Binary sensors e.g. open, closed or on and off
Multi value type sensors that can have multiple values e.g a temperature sensor.
Sensors will report changes on a predetermined schedule.
For example a temperature sensor could report the temperature every second,every 10 seconds every minute etc. How often the sensor will need to report its data will depend very much on the application.
In addition the sensor data may change or may remain the same. For example:
- if you were measuring the temperature of a room it might not change at all for several hours.
- If you were monitoring a door (open/close) it might remain closed all day. However it might be important that you knew within seconds if the door status had changed.
With this in mind You have two important things to consider.
- The sensor scanning interval
- The need to report all data or just changes
- A security sensor on a door/window etc would have a sensor scanning interval of perhaps every second but only need to report changes.
- A sensor monitoring pressure that is constantly changing would have a sensor scanning interval of perhaps every second and report continuously.
I call these sensors “chatty” or “not chatty”.
Sensor Data Analysis
I’ve created a simple python script that simulates multiple simple on/off type sensors and measured the traffic generated under the following conditions:
- The sensors are chatty
- The sensors are not chatty
- The sensor data is combined on a single topic
Below is a screen shot example of a Python script output showing a simple single sensor sending an on/off message.
In one run I configured the sensor to be chatty, and then in the second run to only send changes.
I’ve configured the script to count the bytes sent on the network.
Notice that the chatty sensor send over 43KBytes of data in 30 minutes whereas the non-chatty sensor only sends 142 bytes.
Combining Sensor Channels
If you have for example several sensors e.g.20 do you publish sensor data for each sensor individually or combine them.
So for example we could publish sensor data for each sensor on their own topic.
sensor1 would publish on topic-base/sensor1 and sensor2 would publish on topic-base/sensor2
do we combine the sensors and publish on a singe topic e.g. topic-base/sensors.
In this case we would need to analyze the data to separate the data for each sensor.
Example publishing a simple on message for five sensors:
The preferred method of combining data would be to use a JSON encoded object. So instead of the data looking like this:
ON,ON,ON,ON,ON it would look more like this:
In which case each data packet would now be increased considerably.
The screenshots below show the results of sending data on multiple sensors. Again we look at chatty and non-chatty.
The screen shot below shows the same tests but with the sensors configured as non-Chatty
- It is much more efficient to only send changes rather than send data at regular intervals.
- Combining sensor data doesn’t reduce network traffic but can slightly increase it. However current IOT/MQTT dashboards take data normally as JSON encoded data, and it is likely to become standard.
Related Tutorials and Resources: