aiomqttc - Asynchronous MQTT Client #17309
Replies: 3 comments 12 replies
-
|
That could be very nice. I do mqtt stuff for both my raspberry pi and also on various mp boards such as the Pico and ESP32, though as my amateur programming efforts are rather spaced out time-wise I usually have to look back at some previous code efforts to remind myself of the difference between the mosquito and the async mp for mqtt, so a similar async for both may be right up my garden path. Thanks for sharing the library and I will be having a test with something I'm working on for my rpi5 shortly. |
Beta Was this translation helpful? Give feedback.
-
|
I haven't had time to review this in detail, but I think there is a bug if a I'm also doubtful about the limited use of the Does the code perform retransmissions if a Have you tested this under conditions where WiFi connectivity is unreliable? One minor point: the |
Beta Was this translation helpful? Give feedback.
-
|
These are valid concerns and I'll review it. Thank you. |
Beta Was this translation helpful? Give feedback.
-
|
To add some general comments. An asynchronous MQTT client portable between CPython and MicroPython, and between wired and wireless connection, is a worthwhile task. mqtt_as is unlikely to support these objectives: MicroPython WiFi handling is deeply "baked in". MQTT is designed to provide reliable connection over an unreliable link: one where messages may be lost, but if a message is received it will be correct with no message corruption. WiFi on a microcontroller provides such a link. The entire purpose of When the broker is expected to send an ack, the client should wait for a period, then assume its outgoing message was lost, and retransmit. Note that if the link is down the retransmit should be postponed until the outage is over. Retransmissions may occur more than once. Bear in mind that acks may themselves be lost. If the client sends an ack to a With an asynchronous client it is necessary to consider unexpected application behaviour, and unexpected behaviour by other clients. An application may send a set of |
Beta Was this translation helpful? Give feedback.
-
If you are aiming for resilience you need to test with a signal which drops to the point where nothing is received, and then increases again. We did this by gradually moving the device under test out of range, then back again. Also test abrupt loss and regain of connectivity (e.g. disabling the AP). One trick for testing is to use a microwave oven as a Faraday cage - the point being that you can see the behaviour of LEDs through the translucent door grille. I notice that the code which supports qos==1 publications is commented out. With the code as published |
Beta Was this translation helpful? Give feedback.
-
|
@peterhinch You make some statements that are not true in my opinion. I take as a reference the MQTT 3.1.1 specs.
Chapter 4.2 of the MQTT 3.1.1. specs say: The MQTT protocol requires an underlying transport that provides an ordered, lossless, stream of bytes TCP/IP is such a transport.
That is not true. The broker will only retransmit on reconnect (and off coerce clean_session=0), just as the link that I showed you before. I have tested this with a few online brokers They all will not resent qos==1 messages (at least not after waiting for one hour) if b.t.w To my surprise test.mosquitto.org did not even respect 4.4 Message delivery retry of the MQTT 3.1.1 specs. How is that possible?
Why is this a bug? If a resource constrained device is switched on after a week downtime, you should better connect with clean_session=1, then disconnect immediately and then reconnect with clean_session=0. |
Beta Was this translation helpful? Give feedback.
-
This means that if a message is sent, the receiver must receive it in complete form without loss or corruption. It doesn't imply a guarantee that the message is received. The existence of This confusion has been a bone of contention since the official library was published. The author assumed perfect TCP/IP connectivity. The reality of WiFi meant that a link rarely stayed up for longer than 30 minutes. I can't explain your broker results but the whole purpose of the PID/ack protocol is to enable the In industrial applications links are often via a point to point radio. The transport layer uses CRC to ensure that received packets are only passed on to the MQTT client if they are correct. The
This isn't always easy in the field with firmware in ROM. However, that is what my |
Beta Was this translation helpful? Give feedback.
-
They all do support It bothers me too that nowhere in the specs is explained how lost transmissions/acknowledgments in the same session are handled. |
Beta Was this translation helpful? Give feedback.
-
|
QOS=1 is supported since we get back the PUBACK. What is comments out is the retransmission part (will be done soon). Retransmission at the MQTT protocol is one place to handle this very particular protocol delivering mechanisms. But in real world (as of my experience and use cases) the critical data that MUST be delivered is handled in other application layers. I'm pretty happy with the actual results. Knowing that I don't have any WDT in place, so far this code behave very well. |
Beta Was this translation helpful? Give feedback.
-
Welcome to aiomqttc 🚀
This is my first time sharing a public Python library, and I’m excited to contribute to the community!
aiomqttc is a lightweight, fully asynchronous MQTT client designed for both standard Python and MicroPython, with a special focus on ESP32 platforms.
Whether you’re building IoT solutions, home automation systems, or experimenting with MQTT on constrained devices, I hope this project helps speed up your development and simplifies your MQTT integration.
Feedback, suggestions, and contributions are very welcome!
👉 Check out the repo here
Beta Was this translation helpful? Give feedback.
All reactions