If you’re a Python developer, you probably are already familiar with the simplicity of event handlers. They make it easy for your application to respond to events without manually spinning up a thread to poll for updates. This is even more important for IoT devices that may be resource constrained while still needing to receive information from the cloud at any time. And if you are coding for IoT devices that connect to Azure IoT using Python, then you’ll be happy to learn that our Python SDK makes this easy to achieve!
We recently released a new and improved programming model based on event handlers in the Azure IoT Python Device SDK. Until now, developers had to spin up listener threads to poll for incoming messages to devices—this model required a more complicated API and management of additional resources by the developer.
As a quick example, let's look at a sample for receiving a message from the cloud on a device using event handlers:
# The connection string for a device should never be stored in code. For the sake of simplicity we're using an environment variable here.
conn_str = os.getenv("IOTHUB_DEVICE_CONNECTION_STRING")
# The client object is used to interact with your Azure IoT hub.
device_client = IoTHubDeviceClient.create_from_connection_string(conn_str)
# connect the client.
device_client.connect()
# define behavior for receiving a message
def message_handler(message):
print("the data in the message received was ")
print(message.data)
print("custom properties are")
print(message.custom_properties)
# set the message handler on the client
device_client.on_message_received = message_handler
# finally, disconnect
device_client.disconnect()
In this example, you can see how the code does not create any new threads and receiving a message is as simple as assigning the event handler. The developer does not have to worry about any thread management which makes writing and maintaining code much easier, especially as your IoT projects scale to include more functionality. Event handlers can be used with the Azure IoT Python SDK in all receive message scenarios-- receiving C2D messages, direct methods, device twin patches, etc. To see how you can adapt your code to use handlers, you can explore the samples in our Github repository.
We hope our new event helps simplify your IoT development experience with the Python SDK and optimize your IoT code. As always, please reach out to us on Microsoft Q&A (tag with azure-iot-sdk) or Github with any questions or feedback. Thanks and happy developing!
FAQs
I’ve already written my applications with the listener Python SDK programming model, do I need to update the code to use handlers?
No, the listener API isn’t going away and is still fully supported by the Python SDK. We introduced handlers because we believe they are much easier for developers to work with and, under the covers, they allow the SDK to be a lot more adaptable. We do highly recommend adapting your code to use the new handlers.
What scenarios will benefit from using handlers as opposed to the polling programming model?
All scenarios will benefit from the newer model in terms of ease of use. There are no changes in functionality, we have just introduced a simpler, cleaner, and easier way to use all of the existing receive functionality. However, going forth, any new receive-based patterns that may be introduced will only support the newer handler model. The older, polling-based model remains supported, yet we will not continue to develop on this model and highly recommend using event handlers moving forward.
I see that the Python SDK also supports both a synchronous and asynchronous programming model. What should I consider when deciding between writing sync or async code?
Are you already comfortable with async/await programming models? Do you need to do a high volume of operations simultaneously? If so, our async await pattern may be best for you, as it is optimized to operate asynchronously so your code isn't slowed down by I/O delay.
Otherwise, for users who may not be familiar with this paradigm, and who don't need to optimize performance for a high volume of simultaneous operations, the synchronous model will probably be more familiar and simpler to use.
Does it matter if I’m using Python 2 or Python 3?
No, handlers are supported for both Python 2 and Python 3, and for both synchronous and asynchronous programming. The synchronous client is compatible for both Python 2 and Python 3, whereas the asynchronous client only works with Python 3.
