Sounds easy? Well, it should have been. I’m not talking about a “Hello, World!” (although it is more or less on the same level for me). The goal was to write a set of three MQTT clients that properly talk with each other and interact nicely.
So I had to learn Python and MQTT on the same day. Should not be an issue after 40 years of programming. But it quickly turned out that the Python library/package for MQTT on Ubuntu was heavily outdated (1.6), and did not supply all the functions the documentation and examples (2.0) asked for. Using pip3 didn’t work, as it complained that the package structure was maintained by the OS. In the end, I had to virtualize the python3 system and pip3 the 2.0 package there and run it.
After about three hours, I had the clients working as they should. Yes, I think MQTT is a good base for the next project.
You must log in or register to comment.
I recommended checking out package managers that will simplify using whatever version of a library you want with project level virtual environments.
I haven’t done heavy python dev since 3.7, so I don’t know the full landscape of options these days, but here are some references to dig into.
https://python-poetry.org/ is the one I started using as the first step up from pip.
It looks like there are some new contenders like hatch, rye, and pdm: https://dev.to/adamghill/python-package-manager-comparison-1g98.
There is also pixi referenced from the comments in that article: https://github.com/prefix-dev/pixi
I can recommend arch for programming once you get tired of the Ubuntu outdated thing. Having the latest packages is awesome.
While I have nothing against an arch recommendation, I wouldn’t rely on my distro when there is tooling to get any version of a library directly from pypi.
I think virtualizing the python environment (with
venv) has become quite common, although my only evidence is that the server I’m using to send this was written in Python and uses one.Well done!
The next step will be to implement two of the clients on RPi Pico W boards. The documentation on MQTT on that platform has quite some potential for improvement, to put it mildly.
Having done some MQTT IoT work in the past, dropping a couple resources:
https://github.com/eclipse/mosquitto - CLI interface and C bindings. I’ve only used the CLI interface. Its a nice way to test communication with a remote broker.
RabbitMQ /w MQTT plugin - Message queue based on AMQP. We ran this as the server in a container. There maybe others options like 0MQ (been a few years so don’t know every option). I had my clients post to a wild card topic so that I could consume a single device or all devices. Consumption is not with MQTT though. We’d use AMQP on that side.
I’m running a mosquitto here as the broker, and use MQTT Explorer for debugging.
That just sounds like a normal Linux session to me. I recently barely stumbled my way through using file pointers as the pins for my simple bbb project.
Well, in my professional tasks, I have smoothed out about all trouble spots long ago. So having two new fields at once to work on and deal with their teething problems reminded me of times long ago.
