As explained in card dedicated to the component, MQTT it is a simple but effective network service designed to quickly exchange messages to and from home automation / IoT components and devices. This service allows you to "control" the changes in status of the components and collect the answers, the telemetry and, generally, information from them products.
- A quick explanation
- MQTT in personal domotics
The functionnameis simple: in the typical scenario of a home automation network based on LAN /Wi-Fi there is a broker MQTT, which acts as sorter of messages, and then of MQTT clients, which send e receive such messages.
Examples of MQTT client I'm:
- components / devices enabled to use MQTT (eg a component Sonoff equipped with firmware Tasmota, or one Shelly);
- any personale HUB (Home Assistant, Homebridge, openHAB etc.);
- un computer, a smartphone, a tablet that use any MQTT client.
The mechanism it's very simple: each client can "register" to broker be like Publisher (publisher) that how Subscriber (Subscriber).
The role of publisher provides for the publication at the MQTT message broker, while the one from subscriber provide the reception by the broker of all the messages received from it containing a given signature / signatures to which the subject is, appanointed, "registered". The "signature" is defined in the "topic", which is a string containing a series of information relating to the device and the type of message (which is for example telemetry or command).
The MQTT messages are formed by a topic and a payload ("Payload"), or a certain set of information which will be useful to one or more recipients listening to the broker.
If for example we had a temperature sensor configured to automatically publish (every tot) an MQTT message containing the telemetry of the temperature detected by it and two subscriber record listening on that data topical at broker, such subscriber would receive (every tot) the temperature through an MQTT message from the broker containing the temperature contained in the payload.
An example of topic "telemetry" it could be:
stat /Sensorecamera / sensor
with relative payload (in notation JSON)
(as you can see, it contains the temperature as well as other information relating to date, time, type of sensor, etc.).
By subscribing to that topic, for each publication all subscriber they will receive the content.
Similarly, command messages (eg switching on / off an intelligent MQTT switch) are formed by a topical (containing the "name" of the recipient) and a payload (containing the action to be performed). Any MQTT client that has signed up to that topical will be hired to perform an action against the publication at the broker of a message destined, appanointed, at that topical.
An example di topical "Command" it could be:
cmnd / Artemis / power
with relative payload (in notation JSON)
This example is relative at the ignition command of a device called "Artemide" with firmware Sonoff-Tasmota.
Who subscribes to the borker that topical it is usually the device itself, while who publishes the command messages in this case is theHUB personal.
Obviously, as explained, i subscriber listening on a given topical they can be multiple; in addition, i publisher they can limitlessly publish on the broker how many and which messages they want. There is no control over the message source: the broker it merely receives them and then to turn them over to anyone who subscribes to that data topical.
Usually it appears in personal domotics a rather typical scenario, with the presence of:
- one or more MQTT components / devices;
- one or more HUB personal;
- an MQTT broker.
The MQTT broker it is usually unique, As acts as a collector for exchange of all MQTT messages related to home automation and usually resides on a specific computer Windows, its macOS or is it a Raspberry Pi with Raspbian operating system or other solutions.
Let's assume we have a scenario in which un personale HUB has an entity in configuration rappsents an MQTT switch to which, if activated / deactivated, send the relative command message MQTT and from which to receive, in response, its new status (activated / deactivated).
The sequence will be as follows:
- the user activate the switch at thepersonal HUB(from web interface, app mobile, voice command - what it is);
- 'spersonale HUB format and send an MQTT command message intended for the intelligent switch based on the configuration assigned to it:
- with topical containing relevant information the type of command and the recipient;
- with payload containing the action to be performed
- the broker receives the MQTT message;
- the broker checks if and which client MQTT has signed the topical contained in the message (in this case, the device to be controlled);
- the broker turns to the client MQTT (the component / device) the message MQTT;
- the device, which knows what to do when a message is received from it topical and from that payload, perform the action;
- the device formats and sends a MQTT telemetry message broadly conceived as follows:
- containing a topic which identifies the message as a telemetry device and the fact that it is prolearned from him (he does not have a "recipient", it is simply a "raise his hand to communicate something");
- containing a payload containing the response to the action appena performed;
- the broker receives the MQTT message;
- the broker checks if and which client MQTT has signed the topical contained in the message (in this case, thepersonale HUB, which will have in the switch configuration appena commanded not only the command topic, but also the telemetric topic to be signed to obtain the answers);
- the broker turns to the MQTT client (thepersonale HUB) the MQTT message;
- 'spersonale HUB takes the answer based on the content of payload and its interpretation (eg "ON" will indicate, trivially, that the switch has been turned on).
The whole in a fraction of a second.
First It is important to clarify one thing: it is necessary that the broker MQTT possess a static IP, invariable, within the profirst network. This is because ALL MQTT clients (of any type) will be "pointed" at him and must always be able to contact him without it changing. When the broker's IP changes, all the configurations of the various components / devices will go down the drain.
The IP of the client MQTT (of any type) can instead be eveningsnameMarketplace to vary. This is because each client that presents itself to the broker, authenticates itself and then subscribes (and / or publishes) one or more topics, is automatically recalled from the broker itself, so changing the IP has no negative effect.
The broker can take any IP, provided that once set, that is and that remains; can also use simple authentication (username/ password) and / or encryption certificates. All this is related to the specific configuration of the broker in use.
COMPONENTS (Sonoff, Shelly and the like)
All MQTT components / devices in home automation must "aim" to the broker IP which, as we have said, must be immutable.
The IP to be configured under "host"Or"server"Or"broker”In the MQTT section will therefore be that of the broker. Obviously if the broker will provide a username/ password, then you will also need to indicate this information in the configuration. The port usually used by the broker is the 1883. So far as has been configured differently, also report this change in the MQTT configuration of the component / device.
The field "client", Instead, rappwill resent the "name”Of the device contained within the topical of various messages.
If for example the component was an intelligent MQTT switch appapplied to a lamp, maybe we will set this field trivially to "Lamp" so we can easily remember the name.
Nb. The names to be used in MQTT are case-sensitive. "Lamp"Will therefore be different from"lamp"
Once the configuration is complete communication with the broker must be verified: the devices they use Sonoff-Tasmota have the "console" available, which clearly states:
MQT: Attempting connection ...
which confirms the successful connection to the broker.
A "Connect failed”Obviously indicates the inability to connect to the broker.
- that the broker is actually running;
- that the IP and port indicated are correct;
- that username/ password are correct;
- that on macchina where the broker is running there is no firewall that prevents communication on the 1883 port.
In the presence of one or more personal HUBscenarios are two:
- 'sHUB It is running on the same computer where the MQTT broker is running;
- 'sHUB It is running on a different computer from the one where the MQTT broker is running.
In the first case the configuration of the MQTT clients of thepersonale HUB will have to "focus" on the IP of loopback, or 127.0.0.1; otherwise, it will have to be indicated broker IP.
For the rest (credentials, door etc.) the same speeches made for the components / devices apply.
How to carry out tests
At this point just connect to the broker and from there "pretend" one or more of the subjects present on the net. For example, if you want to verify that thepersonale HUB is actually sending MQTT command messages to a given other subject, will suffice join the topical that you expect to be using to verify that it is actually forwarded to the broker; vice versa, it will be possible to publish commands and or MQTT telemeters to see if the recipients actually receive the command or not.
To this we will dedicate an ad hoc focus later.
|ATTENZIONE: remember the existence of our community FORUM for any doubt, question, information on the specific merit of the contents of this page and much more.|