Getting started IoT — part 2
In the first part of “Getting started IoT”, we focused on hardware, now it’s time to communicate! (see part 1 if you lost it!)
Communicate to external world it’s the big difference from a smart device only and an IoT device.
The device can communicate with other devices (m2m), with a server or directly to a client, and the most adopted protocol is MQTT.
MQTT:
According to Wikipedia:
MQTT (MQ Telemetry Transport or Message Queue Telemetry Transport) is an ISO standard publish-subscribe-based “lightweight” messaging protocol for use on top of the TCP/IP protocol. It is designed for connections with remote locations where a “small code footprint” is required or the network bandwidth is limited. The publish-subscribe messaging pattern requires a message broker. The broker is responsible for distributing messages to interested clients based on the topic of a message. Andy Stanford-Clark and Arlen Nipper of Cirrus Link Solutions authored the first version of the protocol in 1999.
The most interesting advantage of using a publish-subscribe pattern is the possibility to exchange messages only when it’s needed (and use less bandwidth). Devices don’t need to receive a request before send a message, it’s like when you receive a notification on your phone without open an app.
Every element of your system could subscribe to a topic, which is a representative string that group messages of the same context, and after that they listen for every published message in this channel.
Anyone sending a message to a topic, send it to all listeners:
The advantage of this method is that the publisher doesn’t need to know every client address, and sends only one message to everyone who need it.
Recap:
- Publisher create a topic, where it send messages ( like stringified json)
- Devices subscribe to topics, and everyone can read published messages.
- Topics have various levels divided by slash ‘/’. It’s also possible to use wildcards: ‘+’ for single level, ‘#’ for multi level.
Sample of subscriptions:
Given following topics:
home/kitchen/lights
home/bathroom/lights
home/bedroom/lights
home/bedroom/ceilingfan
Valid subscriptions to ‘home/+/lights’
OK:
home/kitchen/lights
home/bathroom/lights
home/bedroom/lights
NO:
home/bedroom/ceilingfan
Valid subscriptions to ‘home/bedroom/#’
OK:
home/bedroom/lights
home/bedroom/ceilingfan
NO:
home/kitchen/lights
home/bathroom/lights
Broker:
All messages need a dispatcher server, called broker.
Is’t possible to use third part software and servers:
Free servers (warning: unprotected data and tasked server down):
http://test.mosquitto.org
http://broker.mqttdashboard.com
Free software (also works on local machine)
http://mosquitto.org
https://github.com/mcollina/mosca [NodeJS]
Opensource framework:
http://www.lelylan.com/
Quality of Service (QoS):
Brokers, can support 3 different strategies of message delivery:
- At most once (0)
- At least once (1)
- Exactly once (2)
Depending on your needs, and server support you can set this levels:
- QoS 0: basic support, broker delivers the message at most once time. use only when send non necessary data (like temperature update)
- QoS 1: Broker check that the message is delivered at least once, but you can receive multiple copies of it (server should manage it)
- QoS 2: Not supported for every broker, and is also bandwidth wasteful. It’s guaranteed the delivery of message.
Mastering MQTT:
As usual, I suggest to check some link to mastering into argument:
