Easier than MQTT? MQTT / UDP
I wanted to write a detailed article on this topic, but, obviously, my hands do not reach. Therefore a brief message. I developed and implemented in several languages in the form of a prototype code version of the MQTT protocol under the working name MQTT / UDP. For the impatient and those who are already clear and obvious, the code on Gitkhab
What for
I live in an apartment that is almost completely controlled by my own smart home system for several years. Control of light, climate, sensors, easy automation, that's all.
')
During this time, I found out (yes, by the way, I understood it before) that the main feature of UD systems is reliability.
All systems with a central site are by definition unreliable. Hence, the desire to get an interconnect system component (and there are a lot of them in a real smart home) without using any central hub.
At the same time, we proceed from the assumption that, in general, the traffic of UD systems is small - the sensors rarely need an update more than once a minute, the rest of the data are eventual (they turn on the light), and the traffic is completely unimportant. Even every second update of all data in the system is not only a disaster, but even a significant problem.
The logical conclusion - UDP Broadcast is the perfect tool.
(Yes, I assume that the internal network of the apartment is closed by a firewall.)
What are the advantages:
Incredibly simple implementation. A minimal microcontroller with tiny memory will be able to send a UDP packet. For the sensor, even UDP reception is not needed.
Extremely low latency. There is no forward in the central hub, the UDP packet delivery time is practically the minimum time quantum in the modern system.
There is no central point of failure in the hub / broker. Consider a simple circuit: two temperature sensors, a heated floor controller, and a heating controller. With the use of MQTT / UDP, the failure of any part of such a system does not lead to the failure of the system as a whole.
Low network traffic. Below is nowhere. TCP and confirmations only add traffic, but do not add reliability. Failed sensor will not work from receiving TCP ACK. A failure, and so we reveal the absence of updates.
The unreliability of the UDP protocol itself is insignificant - the sensors still update the data regularly, and the loss of counting is completely unnoticed, and the disappearance of a command from, for example, a switch, is visually confirmed by a failure of the target system. What does a man do? Clicks again. However, this is the main limit to the applicability of the protocol. Ideal for repetitive surveys.
No system configuration required. No one needs to register the address of the broker, hub, etc. However, the sensor configuration is still needed - you need to register the sensor identifier. But when transferring other parts of the system to other servers, reconfiguration of the response components is not required.
Separately, it is interesting that this data exchange model fits well with natural broadband media, such as a radio channel or RS / 485. I have not experimented with this, and the protocol in such environments needs to be controlled. It makes sense here to apply CRC16 from modbus, by the way.
The disadvantages are also obvious: the reliability of delivery is determined only by the hardware and the traffic on the network, well, and if an enemy has snuck into the network, the protocol is immediately defeated. True, let's be frank, hacking other typical protocols of the smart home is a matter of seconds, so this is a controversial drawback of MQTT / UDP. Another unobvious negative is a maximum of one receiver per IP address.
What has been done and is in the source repository:
What would I do if I had more time:
Thank you for this, welcome to the repository.
PS: A similar approach, but with multicast, is described in this article.
What for
I live in an apartment that is almost completely controlled by my own smart home system for several years. Control of light, climate, sensors, easy automation, that's all.
')
During this time, I found out (yes, by the way, I understood it before) that the main feature of UD systems is reliability.
All systems with a central site are by definition unreliable. Hence, the desire to get an interconnect system component (and there are a lot of them in a real smart home) without using any central hub.
At the same time, we proceed from the assumption that, in general, the traffic of UD systems is small - the sensors rarely need an update more than once a minute, the rest of the data are eventual (they turn on the light), and the traffic is completely unimportant. Even every second update of all data in the system is not only a disaster, but even a significant problem.
The logical conclusion - UDP Broadcast is the perfect tool.
(Yes, I assume that the internal network of the apartment is closed by a firewall.)
What are the advantages:
Incredibly simple implementation. A minimal microcontroller with tiny memory will be able to send a UDP packet. For the sensor, even UDP reception is not needed.
Extremely low latency. There is no forward in the central hub, the UDP packet delivery time is practically the minimum time quantum in the modern system.
There is no central point of failure in the hub / broker. Consider a simple circuit: two temperature sensors, a heated floor controller, and a heating controller. With the use of MQTT / UDP, the failure of any part of such a system does not lead to the failure of the system as a whole.
Low network traffic. Below is nowhere. TCP and confirmations only add traffic, but do not add reliability. Failed sensor will not work from receiving TCP ACK. A failure, and so we reveal the absence of updates.
The unreliability of the UDP protocol itself is insignificant - the sensors still update the data regularly, and the loss of counting is completely unnoticed, and the disappearance of a command from, for example, a switch, is visually confirmed by a failure of the target system. What does a man do? Clicks again. However, this is the main limit to the applicability of the protocol. Ideal for repetitive surveys.
No system configuration required. No one needs to register the address of the broker, hub, etc. However, the sensor configuration is still needed - you need to register the sensor identifier. But when transferring other parts of the system to other servers, reconfiguration of the response components is not required.
Separately, it is interesting that this data exchange model fits well with natural broadband media, such as a radio channel or RS / 485. I have not experimented with this, and the protocol in such environments needs to be controlled. It makes sense here to apply CRC16 from modbus, by the way.
The disadvantages are also obvious: the reliability of delivery is determined only by the hardware and the traffic on the network, well, and if an enemy has snuck into the network, the protocol is immediately defeated. True, let's be frank, hacking other typical protocols of the smart home is a matter of seconds, so this is a controversial drawback of MQTT / UDP. Another unobvious negative is a maximum of one receiver per IP address.
What has been done and is in the source repository:
- Client / server implementations in multiple languages. There are C, Python and Java. I didn’t master Lua (couldn’t put everything you need, how do you live in it?) And Codesys (couldn’t put together a package, who invented this language?).
- Minimum Gate to Traditional Python MQTT
- Primitive tool for displaying MQTT / UDP traffic on the network
What would I do if I had more time:
- Would write a module for openHUB.
- Would make a protocol variant on JSON on another port and a converter into the main format and port. Or gate in both directions.
- Would make a sales pig for the main platforms. For Arduino, I made an approach to weight and really tested the code, but did not design everything properly. For Raspberry test examples are suitable for Python.
- Would make a digital signature and encryption, but it is unclear how.
- Multicast
Thank you for this, welcome to the repository.
PS: A similar approach, but with multicast, is described in this article.
Source: https://habr.com/ru/post/429714/
All Articles