2017-05-05, 03:47 AM
https://wiki.fhem.de/wiki/MQTT_Einf%C3%BChrung
Needs to be adaptet for the documentation also its gnu lizense! https://mosquitto.org/ is a good broker
Shure the Dokumentation is in german and there are 3 parts
MQTT Introduction
Table of Contents
1 MQTT
1.1 What is it?
1.2 Basic structure
1.3 This is how MQTT ticks
1.4 Order in the chaos
1.5 What can you do with it now?
1.6 Ah, yes. And what is great about it?
1.7 Still, why is it so great?
1.8 Cool, what do you need?
1.9 Disadvantages
1.9.1 Single Point of Failure
1.9.2 Security
1.9.2.1 Username / Password
1.9.2.2 TLS
1.9.3 Changing the topic hierarchy
1.9.4 Network Traffic
1.10 outlook
1.10.1 QoS
1.10.2 Retained Messages
1.11 Links
MQTT
Message Queue Telemetry Transport
What's this?
It is a protocol to transfer data among different devices. MQTT works eg via a TCP / IP connection. (For those who want to post something verbal: one calls the M2M, Machine to Machine, otherwise MQTT is a transport protocol.)
Basic structure
The heart of the MQTT network is a broker. The devices connected to the broker are called clients for simplicity. (Not quite right, but later we get to know more)
So ticks MQTT
We simply write / send a message to the broker. If you pick up and read the message, you will not be interested at all. This is one of the great advantages.
Order in the chaos
What is the advantage? And how can someone read a message? This is where MQTT's refined concept starts: We do not simply provide data to the broker. We also organize them ourselves. The magic word for this is called "Topic". You can imagine something like a directory tree under Windows, or like a file on a web server. Another picture for a "topic" would be a kind of bulletin board.
A topic could be this: at home / 1OG / kitchen / light / state
This topic would make it possible to re-write the state of the kitchen light on the first floor.
Our small smart light switch could always record the current state of the light in this topic. In "MQTT-Speaking" one would say our client is a publisher. He publishes information.
Let us take a sensor: at home / 1OG / kitchen / fridge / temperature / state
That would be a nice topic for a temperature sensor in the refrigerator. Here, too, we would be dealing with a publisher.
It is important that we do not have to worry about the technology. We also have a lot of free hands in organizing the topics.
What can you do with it now?
Now let's see the refrigerator temperature on a display. Maybe we store sensitive medicines in the refrigerator and have children who like to leave the refrigerator door open?
So we take a display and pinch it to our broker. But now we do not want to publish the temperature, that is the sensor. We want to read them. So we report to the broker with the display and "subscriben" the topic. We inform the broker that this information is of interest to us.
So our display subscribes to the temperature. In future, the broker will always try to communicate the temperature to our display.
Ah yes. And what is great about it?
Well, as we programmed the thermometer, we did not know anything about the display. We do not have to change anything on the thermometer either. This remains the way it is.
If we now want to have another display, we are just building a second display and subscriben the topic also with the broker. In the future, he will send the information to both displays.
If we want a graphical evaluation of the temperature profile, then we could subscribe the topic to the broker with FHEM. Temperature get, write in logfile, plot, finished.
Still, why is it so great?
Well, when designing MQTT, it is important to be able to manage without great resources. This means that for many "Bastelhardware" (Arduino etc.) there are ready libraries. I'll show you later. Also, anyone who likes to javascript, java, Perl, Python, finds well functioning libraries. For the "ambitious hobbyist" this means: We can build and program devices that communicate with each other independently. A button that turns on the light on a remote actuator is not a problem. Without burdening FHEM or even needing it. So we can very quickly read and evaluate our refrigerator temperature with various programming languages on a myriad of devices.
Cool, what do you need?
An MQTT broker; Eg Mosquitto. For the microcontroller of your own choice a suitable library. For Arduino, the PubSubClient would offer Ggfs. An analysis tool such as MQTT.fx
disadvantage
Single Point of Failure
Where light is, as is known shadows. For us, as we use FHEM to house control, the first question is, why one does not simply connect its devices directly to FHEM, but first sets up an MQTT broker (ultimately a piece of software) in front of it. Possible reason: MQTT is better than any self-knit protocol. It is even ISO standard. There are many tools and aids for this; Own intelligence to teach the devices is also quite simple.
safety
In principle, MQTT is just as secure as a postcard. As long as you do not extra secure, anyone who is in his own LAN (and the address of the broker knows) can read all the topics. My house / hall / doorstep: open / close Is not really smart! Remedy:
Username / Password
First you can assign a Username / Password. Since it is synonymous for a long time not sure, but at least it increases the effort already times. Now you have to sniff at least once packets and understand, unauthorized to read or even to publish.
TLS
!!!!!!!!!!!!!!!!!!!!!!!!To be really safe, no way leads to TLS. Unfortunately, for example, an Arduino simply can no longer. Somewhere the memory and the computing power then noticeable.
Change the topic hierarchy
!!!!!!!!!!!!!!!!!!!!!!!!!!Yes that is a problem. If you want to change the hierarchy of the topics, you will rarely get around to adjust your program code (Arduino ..,), re-compile it and upload it again. The same applies if, for example, the IP address of the broker changes.
Network Traffic
Another question you can ask yourself is a basic one: What is the purpose of having to network your network (especially WLAN) with such things as sensor data. This is not completely unjustified.
!!!!!!!!!!!!!!!!!!!MySensors is probably a much better choice for many small battery-powered sensors. Integrating sensors with batteries into a WLAN is technically a real challenge. The great advantage, however, is that one can easily expand its WLAN in the case of the Reichsendende. WLAN repeater, thing good.
outlook
Here ends only the short overview. If you are curious, you can look forward to many more exciting topics:
QoS
Another feature is the QoS Level of MQTT.
* QoS Level 0: is a kind of fire and forget. Whether the data arrive is not checked further
* QoS Level 1: guarantees the delivery of the message; But it can also happen that a message is sent and received more frequently
* QoS Level 3: This ensures that every message arrives at the recipient's exact address
Retained Messages
Also a funny thing, we get to know later. But one example I would like to describe already: We later tinker the above-mentioned temperature sensor and the associated display. This is expanded by a flashing LED when a certain temperature is exceeded. Quizquery: from where does the display know the desired threshold? Of course you could put it in the program code. But then it is hard-wired. If we just would publish it normally, the display would only know him if the threshold value was popped after the display was connected to the broker ... Here are retained messages. These are also sent when connecting a subscriber, although there was no change.
Left
Official homepage of MQTT, English
http://mqtt.org/
Very good introduction, English, are 5 readable parts
http://www.hivemq.com/blog/mqtt-essentia...ucing-mqtt
An excerpt from Heise with examples, deusch, very readable
https://www.heise.de/developer/artikel/M...68152.html
MQTT FX - a very useful analytical tool
http://www.mqttfx.org/
Discussion forum in the forum
Part 2 of the MQTT introduction, heavier food
https://translate.googleusercontent.com/...k2hL4WBo4Q
Needs to be adaptet for the documentation also its gnu lizense! https://mosquitto.org/ is a good broker
Shure the Dokumentation is in german and there are 3 parts
MQTT Introduction
Table of Contents
1 MQTT
1.1 What is it?
1.2 Basic structure
1.3 This is how MQTT ticks
1.4 Order in the chaos
1.5 What can you do with it now?
1.6 Ah, yes. And what is great about it?
1.7 Still, why is it so great?
1.8 Cool, what do you need?
1.9 Disadvantages
1.9.1 Single Point of Failure
1.9.2 Security
1.9.2.1 Username / Password
1.9.2.2 TLS
1.9.3 Changing the topic hierarchy
1.9.4 Network Traffic
1.10 outlook
1.10.1 QoS
1.10.2 Retained Messages
1.11 Links
MQTT
Message Queue Telemetry Transport
What's this?
It is a protocol to transfer data among different devices. MQTT works eg via a TCP / IP connection. (For those who want to post something verbal: one calls the M2M, Machine to Machine, otherwise MQTT is a transport protocol.)
Basic structure
The heart of the MQTT network is a broker. The devices connected to the broker are called clients for simplicity. (Not quite right, but later we get to know more)
So ticks MQTT
We simply write / send a message to the broker. If you pick up and read the message, you will not be interested at all. This is one of the great advantages.
Order in the chaos
What is the advantage? And how can someone read a message? This is where MQTT's refined concept starts: We do not simply provide data to the broker. We also organize them ourselves. The magic word for this is called "Topic". You can imagine something like a directory tree under Windows, or like a file on a web server. Another picture for a "topic" would be a kind of bulletin board.
A topic could be this: at home / 1OG / kitchen / light / state
This topic would make it possible to re-write the state of the kitchen light on the first floor.
Our small smart light switch could always record the current state of the light in this topic. In "MQTT-Speaking" one would say our client is a publisher. He publishes information.
Let us take a sensor: at home / 1OG / kitchen / fridge / temperature / state
That would be a nice topic for a temperature sensor in the refrigerator. Here, too, we would be dealing with a publisher.
It is important that we do not have to worry about the technology. We also have a lot of free hands in organizing the topics.
What can you do with it now?
Now let's see the refrigerator temperature on a display. Maybe we store sensitive medicines in the refrigerator and have children who like to leave the refrigerator door open?
So we take a display and pinch it to our broker. But now we do not want to publish the temperature, that is the sensor. We want to read them. So we report to the broker with the display and "subscriben" the topic. We inform the broker that this information is of interest to us.
So our display subscribes to the temperature. In future, the broker will always try to communicate the temperature to our display.
Ah yes. And what is great about it?
Well, as we programmed the thermometer, we did not know anything about the display. We do not have to change anything on the thermometer either. This remains the way it is.
If we now want to have another display, we are just building a second display and subscriben the topic also with the broker. In the future, he will send the information to both displays.
If we want a graphical evaluation of the temperature profile, then we could subscribe the topic to the broker with FHEM. Temperature get, write in logfile, plot, finished.
Still, why is it so great?
Well, when designing MQTT, it is important to be able to manage without great resources. This means that for many "Bastelhardware" (Arduino etc.) there are ready libraries. I'll show you later. Also, anyone who likes to javascript, java, Perl, Python, finds well functioning libraries. For the "ambitious hobbyist" this means: We can build and program devices that communicate with each other independently. A button that turns on the light on a remote actuator is not a problem. Without burdening FHEM or even needing it. So we can very quickly read and evaluate our refrigerator temperature with various programming languages on a myriad of devices.
Cool, what do you need?
An MQTT broker; Eg Mosquitto. For the microcontroller of your own choice a suitable library. For Arduino, the PubSubClient would offer Ggfs. An analysis tool such as MQTT.fx
disadvantage
Single Point of Failure
Where light is, as is known shadows. For us, as we use FHEM to house control, the first question is, why one does not simply connect its devices directly to FHEM, but first sets up an MQTT broker (ultimately a piece of software) in front of it. Possible reason: MQTT is better than any self-knit protocol. It is even ISO standard. There are many tools and aids for this; Own intelligence to teach the devices is also quite simple.
safety
In principle, MQTT is just as secure as a postcard. As long as you do not extra secure, anyone who is in his own LAN (and the address of the broker knows) can read all the topics. My house / hall / doorstep: open / close Is not really smart! Remedy:
Username / Password
First you can assign a Username / Password. Since it is synonymous for a long time not sure, but at least it increases the effort already times. Now you have to sniff at least once packets and understand, unauthorized to read or even to publish.
TLS
!!!!!!!!!!!!!!!!!!!!!!!!To be really safe, no way leads to TLS. Unfortunately, for example, an Arduino simply can no longer. Somewhere the memory and the computing power then noticeable.
Change the topic hierarchy
!!!!!!!!!!!!!!!!!!!!!!!!!!Yes that is a problem. If you want to change the hierarchy of the topics, you will rarely get around to adjust your program code (Arduino ..,), re-compile it and upload it again. The same applies if, for example, the IP address of the broker changes.
Network Traffic
Another question you can ask yourself is a basic one: What is the purpose of having to network your network (especially WLAN) with such things as sensor data. This is not completely unjustified.
!!!!!!!!!!!!!!!!!!!MySensors is probably a much better choice for many small battery-powered sensors. Integrating sensors with batteries into a WLAN is technically a real challenge. The great advantage, however, is that one can easily expand its WLAN in the case of the Reichsendende. WLAN repeater, thing good.
outlook
Here ends only the short overview. If you are curious, you can look forward to many more exciting topics:
QoS
Another feature is the QoS Level of MQTT.
* QoS Level 0: is a kind of fire and forget. Whether the data arrive is not checked further
* QoS Level 1: guarantees the delivery of the message; But it can also happen that a message is sent and received more frequently
* QoS Level 3: This ensures that every message arrives at the recipient's exact address
Retained Messages
Also a funny thing, we get to know later. But one example I would like to describe already: We later tinker the above-mentioned temperature sensor and the associated display. This is expanded by a flashing LED when a certain temperature is exceeded. Quizquery: from where does the display know the desired threshold? Of course you could put it in the program code. But then it is hard-wired. If we just would publish it normally, the display would only know him if the threshold value was popped after the display was connected to the broker ... Here are retained messages. These are also sent when connecting a subscriber, although there was no change.
Left
Official homepage of MQTT, English
http://mqtt.org/
Very good introduction, English, are 5 readable parts
http://www.hivemq.com/blog/mqtt-essentia...ucing-mqtt
An excerpt from Heise with examples, deusch, very readable
https://www.heise.de/developer/artikel/M...68152.html
MQTT FX - a very useful analytical tool
http://www.mqttfx.org/
Discussion forum in the forum
Part 2 of the MQTT introduction, heavier food
https://translate.googleusercontent.com/...k2hL4WBo4Q