Skip to content

Commit d70abbe

Browse files
committed
umqtt.simple: Add README.
1 parent c8a08bc commit d70abbe

File tree

1 file changed

+87
-0
lines changed

1 file changed

+87
-0
lines changed

umqtt.simple/README.rst

Lines changed: 87 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,87 @@
1+
umqtt.simple
2+
============
3+
4+
umqtt is a simple MQTT client for MicroPython. (Note that it uses some
5+
MicroPython shortcuts and doesn't work with CPython).
6+
7+
Design requirements
8+
-------------------
9+
10+
* Memory efficiency.
11+
* Avoid infamous design anti-patterns like "callback hell".
12+
* Support for both publishing and subscription via a single client
13+
object (another alternative would be to have separate client classes
14+
for publishing and subscription).
15+
16+
API design
17+
----------
18+
19+
Based on the requirements above, there are following API traits:
20+
21+
* All data related to MQTT messages is encoded as bytes. This includes
22+
both message content AND topic names (even though MQTT spec states
23+
that topic name is UTF-8 encoded). The reason for this is simple:
24+
what is received over network socket is binary data (bytes) and
25+
it would require extra step to convert that to a string, spending
26+
memory on that. Note that this applies only to topic names (because
27+
they can be both sent and received). Other parameters specified by
28+
MQTT as UTF-8 encoded (e.g. ClientID) are accepted as strings.
29+
* Subscribed messages are delivered via a callback. This is to avoid
30+
using a queue for subscribed messages, as otherwise they may be
31+
received at any time (including when client expects other type
32+
of server response, so there're 2 choices: either deliver them
33+
immediately via a callback or queue up until an "expected" response
34+
arrives). Note that lack of need for a queue is delusive: the
35+
runtime call stack forms an implicit queue in this case. And unlike
36+
explicit queue, it's much harder to control. This design was chosen
37+
because in a common case of processing subscribed messages it's
38+
the most efficient. However, if in subscription callback, new
39+
messages of QoS>0 are published, this may lead to deep, or
40+
infinite recursion (the latter means an application will terminate
41+
with ``RuntimeException``).
42+
43+
API reference
44+
-------------
45+
46+
Taking into account API traits described above, umqtt pretty closely
47+
follows MQTT control operations, and maps them to class methods:
48+
49+
* ``connect()`` - Connect to a server.
50+
* ``disconnect()`` - Disconnect from a server, release resources.
51+
* ``ping()`` - Ping server (response is processed automatically by wait_msg()).
52+
* ``publish()`` - Publish a message.
53+
* ``subscribe()`` - Subscribe to a topic.
54+
* ``set_callback()`` - Set callback for received subscription messages.
55+
* ``wait_msg()`` - Wait for a server message. A subscription message will be
56+
delivered to a callback set with set_callback(), any other messages
57+
will be processed internally.
58+
* ``check_msg()`` - Check if there's pending message from server. If yes,
59+
process the same way as wait_msg(), if not, return immediately.
60+
61+
``wait_msg()`` and ``check_msg()`` are "main loop iteration" methods, blocking
62+
and non-blocking version. They should be called periodically in a loop,
63+
``wait_msg()`` if you don't have any other foreground tasks to perform
64+
(i.e. your app just reacts to subscribed MQTT messages), ``check_msg()``
65+
if you process other foreground tasks too.
66+
67+
Note that you don't need to call ``wait_msg()``/``check_msg()`` if you only
68+
publish messages, never subscribe to them.
69+
70+
For more detailed information about API please see the source code
71+
(which is quite short and easy to review) and provided examples.
72+
73+
74+
Supported MQTT features
75+
-----------------------
76+
77+
QoS 0 and 1 are supported for both publish and subscribe. QoS2 isn't
78+
supported to keep code size small. Besides ClientID, only "clean
79+
session" parameter is supported for connect as of now.
80+
81+
82+
MQTT client with automatic reconnect
83+
------------------------------------
84+
85+
There's a separate `umqtt.robust` module which builds on `umqtt.simple`
86+
and adds automatic reconnect support in case of network errors.
87+
Please see its documentation for further details.

0 commit comments

Comments
 (0)
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy