The benefits of standardization
Hi Habr! I am engaged in the development of electronics (good skills cover most of this interesting hobby). And I somehow ordered the development of a GSM-logger for utilities.
In addition to having the required inputs / outputs (including 4-20 ma) and a 5-30 volt power supply for sensors, the main condition was to minimize the consumption in order to be able to be powered from batteries. After working through the circuit design and the printed circuit board in its entirety, the question arose protocol. I wanted something simple and standard.
MQTT. But MQTT is TCP with all the advantages and disadvantages. And I have a battery and work life of 3 months. For tests, a primitive protocol was written over UDP. But since I do not consider myself to be a pioneer, I’m piously convinced that they’ll write something digestible in just 2 days — I continued to search for something generally accepted.
I don’t remember how - I came across the mention of MQTT-SN. A protocol that inherits the semantics of MQTT, but is adapted for transmission over UDP and battery-powered clients. It turned out there is one developed in the depths of IBM and subsequently open to the community. After reading the description, it became clear that here it is, happiness, next.
')
But you need a broker (as the server is called in MQTT), the usual Mosquitto (according to Jan Krags from 2013) will ever be able to in MQTT-SN, but not now. But there is RSMB, and even in the source code on the Git-hub.
Source codes are good, it is necessary to collect. The assembly is made by CygWin-ohm in Visual Studio (which I saw last time 5 years ago). We put the free version, create a project and - no way. For 5-10 times (in general, in my life, chance and stubbornness play a big role) I registered the project correctly - and oh, a miracle, it did collect a broker. I note that under Linux this action was much easier.
Solemnly run. It's a shame but does not work. Maybe your own protocol is the way out? Imagining the amount of work on writing and debugging the server and clients - I decided not, my choice is MQTT-SN. Everything turned out to be simple - it was necessary to register the configuration and point it to the broker.
The minimum looks like this:
And after that the broker earned. Briefly distinguish MQTT-SN from classic MQTT.
The eclipsa git-e contains the MQTT-SN client sources with examples. Actually it is necessary to prescribe the functions of working with the transport_xx channel to fit your needs. Otherwise, there are no big problems (I found a couple of errors, I need to test it).
Unfortunately support for sleeping clients is not implemented. Stand stubs. Who can throw in the authors of the protocol stone - source code is available, help is welcome.
What I wanted to say in the end. Having spent some (short time) I received a ready infrastructure for the further development of the project. The protocol allows the use of STM32 at 4 MHz. I can use a lot of clients on different platforms (which it was unrealistic to do it alone when writing my protocol). Moreover, being able to build a broker for Linux, I placed it on the Amazon instance and my customer got the solution without having to keep and maintain the server. Standard solutions (not always, but in the overwhelming number of cases) speed up the execution of the task.
References:
MQTTSN client - Eclipse
RSMB - github
In addition to having the required inputs / outputs (including 4-20 ma) and a 5-30 volt power supply for sensors, the main condition was to minimize the consumption in order to be able to be powered from batteries. After working through the circuit design and the printed circuit board in its entirety, the question arose protocol. I wanted something simple and standard.
MQTT. But MQTT is TCP with all the advantages and disadvantages. And I have a battery and work life of 3 months. For tests, a primitive protocol was written over UDP. But since I do not consider myself to be a pioneer, I’m piously convinced that they’ll write something digestible in just 2 days — I continued to search for something generally accepted.
I don’t remember how - I came across the mention of MQTT-SN. A protocol that inherits the semantics of MQTT, but is adapted for transmission over UDP and battery-powered clients. It turned out there is one developed in the depths of IBM and subsequently open to the community. After reading the description, it became clear that here it is, happiness, next.
')
But you need a broker (as the server is called in MQTT), the usual Mosquitto (according to Jan Krags from 2013) will ever be able to in MQTT-SN, but not now. But there is RSMB, and even in the source code on the Git-hub.
Source codes are good, it is necessary to collect. The assembly is made by CygWin-ohm in Visual Studio (which I saw last time 5 years ago). We put the free version, create a project and - no way. For 5-10 times (in general, in my life, chance and stubbornness play a big role) I registered the project correctly - and oh, a miracle, it did collect a broker. I note that under Linux this action was much easier.
Solemnly run. It's a shame but does not work. Maybe your own protocol is the way out? Imagining the amount of work on writing and debugging the server and clients - I decided not, my choice is MQTT-SN. Everything turned out to be simple - it was necessary to register the configuration and point it to the broker.
The minimum looks like this:
trace_output off # , listener 1883 INADDR_ANY # MQTT listener 1883 INADDR_ANY mqtts # MQTT-SN And after that the broker earned. Briefly distinguish MQTT-SN from classic MQTT.
- The MQTT-SN protocol works over UDP, not TCP as usual. This shifts the responsibility for controlling the delivery of messages to the programmer. But it allows the device to spend less energy (which is important for me) to maintain the communication channel via GSM.
- A new level of QoS (Quality of Service, quality of service) -1 has been introduced. Significant lack of delivery control. The device wakes up, does the necessary work, sends the results and then falls asleep without waiting for confirmation.
- There are gateways that allow you to aggregate data from multiple devices and send them to the broker.
The eclipsa git-e contains the MQTT-SN client sources with examples. Actually it is necessary to prescribe the functions of working with the transport_xx channel to fit your needs. Otherwise, there are no big problems (I found a couple of errors, I need to test it).
Unfortunately support for sleeping clients is not implemented. Stand stubs. Who can throw in the authors of the protocol stone - source code is available, help is welcome.
What I wanted to say in the end. Having spent some (short time) I received a ready infrastructure for the further development of the project. The protocol allows the use of STM32 at 4 MHz. I can use a lot of clients on different platforms (which it was unrealistic to do it alone when writing my protocol). Moreover, being able to build a broker for Linux, I placed it on the Amazon instance and my customer got the solution without having to keep and maintain the server. Standard solutions (not always, but in the overwhelming number of cases) speed up the execution of the task.
References:
MQTTSN client - Eclipse
RSMB - github
Source: https://habr.com/ru/post/309060/
All Articles