paho-mqtt 1.5.1

pip install paho-mqtt Copy PIP instructions

Released: Sep 22, 2020

MQTT version 5.0/3.1.1 client class

Navigation

Project links

Statistics

View statistics for this project via Libraries.io, or by using our public dataset on Google BigQuery

License: OSI Approved (Eclipse Public License v1.0 / Eclipse Distribution License v1.0)

Maintainers

Classifiers

• Development Status
  • 4 — Beta
• Intended Audience
  • Developers
• License
  • OSI Approved
• Natural Language
  • English
• Operating System
  • MacOS :: MacOS X
  • Microsoft :: Windows
  • POSIX
• Programming Language
  • Python
  • Python :: 2
  • Python :: 2.7
  • Python :: 3
  • Python :: 3.5
  • Python :: 3.6
  • Python :: 3.7
  • Python :: 3.8
• Topic
  • Communications
  • Internet

Project description

This document describes the source code for the Eclipse Paho MQTT Python client library, which implements versions 5.0, 3.1.1, and 3.1 of the MQTT protocol.

This code provides a client class which enable applications to connect to an MQTT broker to publish messages, and to subscribe to topics and receive published messages. It also provides some helper functions to make publishing one off messages to an MQTT server very straightforward.

It supports Python 2.7.9+ or 3.5+.

The MQTT protocol is a machine-to-machine (M2M)/”Internet of Things” connectivity protocol. Designed as an extremely lightweight publish/subscribe messaging transport, it is useful for connections with remote locations where a small code footprint is required and/or network bandwidth is at a premium.

Contents

Installation

The latest stable version is available in the Python Package Index (PyPi) and can be installed using

Or with virtualenv:

To obtain the full code, including examples and tests, you can clone the git repository:

Once you have the code, it can be installed from your repository as well:

To perform all test (including MQTT v5 test), you also need to clone paho.mqtt.testing in paho.mqtt.python folder:

Known limitations

The following are the known unimplemented MQTT feature.

When clean_session is False, the session is only stored in memory not persisted. This means that when client is restarted (not just reconnected, the object is recreated usually because the program was restarted) the session is lost. This result in possible message lost.

The following part of client session is lost:

QoS 2 messages which have been received from the Server, but have not been completely acknowledged.

Since the client will blindly acknowledge any PUBCOMP (last message of a QoS 2 transaction), it won’t hang but will lost this QoS 2 message.

QoS 1 and QoS 2 messages which have been sent to the Server, but have not been completely acknowledged.

This means that message passed to publish() may be lost. This could be mitigated by taking care that all message passed to publish() has a corresponding on_publish() call.

It also means that the broker may have the Qos2 message in the session. Since the client start with an empty session it don’t know it and will re-use the mid. This is not yet fixed.

Also when clean_session is True, this library will republish QoS > 0 message accross network reconnection. This means that QoS > 0 message won’t be lost. But the standard say that if we should discard any message for which the publish packet was sent. Our choice means that we are not compliant with the standard and it’s possible for QoS 2 to be received twice. You should you clean_session = False if you need the QoS 2 guarantee of only one delivery.

Usage and API

Detailed API documentation is available through pydoc. Samples are available in the examples directory.

The package provides two modules, a full client and a helper for simple publishing.

Getting Started

Here is a very simple example that subscribes to the broker $SYS topic tree and prints out the resulting messages:

Client

You can use the client class as an instance, within a class or by subclassing. The general usage flow is as follows:

• Create a client instance
• Connect to a broker using one of the connect*() functions
• Call one of the loop*() functions to maintain network traffic flow with the broker
• Use subscribe() to subscribe to a topic and receive messages
• Use publish() to publish messages to the broker
• Use disconnect() to disconnect from the broker

Callbacks will be called to allow the application to process events as necessary. These callbacks are described below.

Constructor / reinitialise

Client()

The Client() constructor takes the following arguments:

client_id the unique client id string used when connecting to the broker. If client_id is zero length or None, then one will be randomly generated. In this case the clean_session parameter must be True. clean_session

a boolean that determines the client type. If True, the broker will remove all information about this client when it disconnects. If False, the client is a durable client and subscription information and queued messages will be retained when the client disconnects.

Note that a client will never discard its own outgoing messages on disconnect. Calling connect() or reconnect() will cause the messages to be resent. Use reinitialise() to reset a client to its original state.

userdata user defined data of any type that is passed as the userdata parameter to callbacks. It may be updated at a later point with the user_data_set() function. protocol the version of the MQTT protocol to use for this client. Can be either MQTTv31 or MQTTv311 transport set to “websockets” to send MQTT over WebSockets. Leave at the default of “tcp” to use raw TCP.

Constructor Example

reinitialise()

The reinitialise() function resets the client to its starting state as if it had just been created. It takes the same arguments as the Client() constructor.

Reinitialise Example

Option functions

These functions represent options that can be set on the client to modify its behaviour. In the majority of cases this must be done before connecting to a broker.

max_inflight_messages_set()

Set the maximum number of messages with QoS>0 that can be part way through their network flow at once.

Defaults to 20. Increasing this value will consume more memory but can increase throughput.

max_queued_messages_set()

Set the maximum number of outgoing messages with QoS>0 that can be pending in the outgoing message queue.

Defaults to 0. 0 means unlimited. When the queue is full, any further outgoing messages would be dropped.

message_retry_set()

Set the time in seconds before a message with QoS>0 is retried, if the broker does not respond.

This is set to 5 seconds by default and should not normally need changing.

ws_set_options()

Set websocket connection options. These options will only be used if transport="websockets" was passed into the Client() constructor.

path The mqtt path to use on the broker. headers Either a dictionary specifying a list of extra headers which should be appended to the standard websocket headers, or a callable that takes the normal websocket headers and returns a new dictionary with a set of headers to connect to the broker.

Must be called before connect*() . An example of how this can be used with the AWS IoT platform is in the examples folder.

tls_set()

Configure network encryption and authentication options. Enables SSL/TLS support.

ca_certs a string path to the Certificate Authority certificate files that are to be treated as trusted by this client. If this is the only option given then the client will operate in a similar manner to a web browser. That is to say it will require the broker to have a certificate signed by the Certificate Authorities in ca_certs and will communicate using TLS v1, but will not attempt any form of authentication. This provides basic network encryption but may not be sufficient depending on how the broker is configured. By default, on Python 2.7.9+ or 3.4+, the default certification authority of the system is used. On older Python version this parameter is mandatory. certfile, keyfile strings pointing to the PEM encoded client certificate and private keys respectively. If these arguments are not None then they will be used as client information for TLS based authentication. Support for this feature is broker dependent. Note that if either of these files in encrypted and needs a password to decrypt it, Python will ask for the password at the command line. It is not currently possible to define a callback to provide the password. cert_reqs defines the certificate requirements that the client imposes on the broker. By default this is ssl.CERT_REQUIRED, which means that the broker must provide a certificate. See the ssl pydoc for more information on this parameter. tls_version specifies the version of the SSL/TLS protocol to be used. By default (if the python version supports it) the highest TLS version is detected. If unavailable, TLS v1 is used. Previous versions (all versions beginning with SSL) are possible but not recommended due to possible security problems. ciphers a string specifying which encryption ciphers are allowable for this connection, or None to use the defaults. See the ssl pydoc for more information.

Must be called before connect*() .

tls_set_context()

Configure network encryption and authentication context. Enables SSL/TLS support.

context an ssl.SSLContext object. By default, this is given by ssl.create_default_context(), if available (added in Python 3.4).

If you’re unsure about using this method, then either use the default context, or use the tls_set method. See the ssl module documentation section about security considerations for more information.

Must be called before connect*() .

tls_insecure_set()

Configure verification of the server hostname in the server certificate.

If value is set to True, it is impossible to guarantee that the host you are connecting to is not impersonating your server. This can be useful in initial server testing, but makes it possible for a malicious third party to impersonate your server through DNS spoofing, for example.

Do not use this function in a real system. Setting value to True means there is no point using encryption.

Must be called before connect*() and after tls_set() or tls_set_context().

enable_logger()

Enable logging using the standard python logging package (See PEP 282). This may be used at the same time as the on_log callback method.

If logger is specified, then that logging.Logger object will be used, otherwise one will be created automatically.

Paho logging levels are converted to standard ones according to the following mapping:

Paho	logging
MQTT_LOG_ERR	logging.ERROR
MQTT_LOG_WARNING	logging.WARNING
MQTT_LOG_NOTICE	logging.INFO (no direct equivalent)
MQTT_LOG_INFO	logging.INFO
MQTT_LOG_DEBUG	logging.DEBUG

disable_logger()

Disable logging using standard python logging package. This has no effect on the on_log callback.

username_pw_set()

Set a username and optionally a password for broker authentication. Must be called before connect*() .

user_data_set()

Set the private user data that will be passed to callbacks when events are generated. Use this for your own purpose to support your application.

will_set()

Set a Will to be sent to the broker. If the client disconnects without calling disconnect(), the broker will publish the message on its behalf.

topic the topic that the will message should be published on. payload the message to send as a will. If not given, or set to None a zero length message will be used as the will. Passing an int or float will result in the payload being converted to a string representing that number. If you wish to send a true int/float, use struct.pack() to create the payload you require. qos the quality of service level to use for the will. retain if set to True, the will message will be set as the “last known good”/retained message for the topic.

Raises a ValueError if qos is not 0, 1 or 2, or if topic is None or has zero string length.

reconnect_delay_set

The client will automatically retry connection. Between each attempt it will wait a number of seconds between min_delay and max_delay.

When the connection is lost, initially the reconnection attempt is delayed of min_delay seconds. It’s doubled between subsequent attempt up to max_delay.

The delay is reset to min_delay when the connection complete (e.g. the CONNACK is received, not just the TCP connection is established).

Connect / reconnect / disconnect

connect()

The connect() function connects the client to a broker. This is a blocking function. It takes the following arguments:

host the hostname or IP address of the remote broker port the network port of the server host to connect to. Defaults to 1883. Note that the default port for MQTT over SSL/TLS is 8883 so if you are using tls_set() or tls_set_context(), the port may need providing manually keepalive maximum period in seconds allowed between communications with the broker. If no other messages are being exchanged, this controls the rate at which the client will send ping messages to the broker bind_address the IP address of a local network interface to bind this client to, assuming multiple interfaces exist

Callback

When the client receives a CONNACK message from the broker in response to the connect it generates an on_connect() callback.

Connect Example

connect_async()

Use in conjunction with loop_start() to connect in a non-blocking manner. The connection will not complete until loop_start() is called.

Callback (connect)

When the client receives a CONNACK message from the broker in response to the connect it generates an on_connect() callback.

connect_srv()

Connect to a broker using an SRV DNS lookup to obtain the broker address. Takes the following arguments:

domain the DNS domain to search for SRV records. If None, try to determine the local domain name.

See connect() for a description of the keepalive and bind_address arguments.

Callback (connect_srv)

When the client receives a CONNACK message from the broker in response to the connect it generates an on_connect() callback.

SRV Connect Example

reconnect()

Reconnect to a broker using the previously provided details. You must have called connect*() before calling this function.

Callback (reconnect)

When the client receives a CONNACK message from the broker in response to the connect it generates an on_connect() callback.

disconnect()

Disconnect from the broker cleanly. Using disconnect() will not result in a will message being sent by the broker.

Disconnect will not wait for all queued message to be sent, to ensure all messages are delivered, wait_for_publish() from MQTTMessageInfo should be used. See publish() for details.

Callback (disconnect)

When the client has sent the disconnect message it generates an on_disconnect() callback.

Network loop

These functions are the driving force behind the client. If they are not called, incoming network data will not be processed and outgoing network data may not be sent in a timely fashion. There are four options for managing the network loop. Three are described here, the fourth in “External event loop support” below. Do not mix the different loop functions.

Call regularly to process network events. This call waits in select() until the network socket is available for reading or writing, if appropriate, then handles the incoming/outgoing data. This function blocks for up to timeout seconds. timeout must not exceed the keepalive value for the client or your client will be regularly disconnected by the broker.

The max_packets argument is obsolete and should be left unset.

Loop Example

loop_start() / loop_stop()

These functions implement a threaded interface to the network loop. Calling loop_start() once, before or after connect*() , runs a thread in the background to call loop() automatically. This frees up the main thread for other work that may be blocking. This call also handles reconnecting to the broker. Call loop_stop() to stop the background thread. The force argument is currently ignored.

Loop Start/Stop Example

loop_forever()

This is a blocking form of the network loop and will not return until the client calls disconnect(). It automatically handles reconnecting.

Except for the first connection attempt when using connect_async, use retry_first_connection=True to make it retry the first connection. Warning: This might lead to situations where the client keeps connecting to an non existing host without failing.

The timeout and max_packets arguments are obsolete and should be left unset.

Publishing

Send a message from the client to the broker.

publish()

This causes a message to be sent to the broker and subsequently from the broker to any clients subscribing to matching topics. It takes the following arguments:

topic the topic that the message should be published on payload the actual message to send. If not given, or set to None a zero length message will be used. Passing an int or float will result in the payload being converted to a string representing that number. If you wish to send a true int/float, use struct.pack() to create the payload you require qos the quality of service level to use retain if set to True, the message will be set as the “last known good”/retained message for the topic.

Returns a MQTTMessageInfo which expose the following attributes and methods:

• rc, the result of the publishing. It could be MQTT_ERR_SUCCESS to indicate success, MQTT_ERR_NO_CONN if the client is not currently connected, or MQTT_ERR_QUEUE_SIZE when max_queued_messages_set is used to indicate that message is neither queued nor sent.
• mid is the message ID for the publish request. The mid value can be used to track the publish request by checking against the mid argument in the on_publish() callback if it is defined. wait_for_publish may be easier depending on your use-case.
• wait_for_publish() will block until the message is published. It will raise ValueError if the message is not queued (rc == MQTT_ERR_QUEUE_SIZE).
• is_published returns True if the message has been published. It will raise ValueError if the message is not queued (rc == MQTT_ERR_QUEUE_SIZE).

A ValueError will be raised if topic is None, has zero length or is invalid (contains a wildcard), if qos is not one of 0, 1 or 2, or if the length of the payload is greater than 268435455 bytes.

Callback (publish)

When the message has been sent to the broker an on_publish() callback will be generated.