Was mqtt considered?

I’m reading the doc Simplifying the OpenFlexure microscope software with the web of things which discusses the http interface w/ a Flask back end as well as adherence to w3c WoT spec.

Curious if the team considered using mqtt instead of http/Flask? Trying to learn from the choices the OFM team made.

Thank you.

We thought a bit about MQTT but concluded it’s not quite what we were after. MQTT is very lightweight, and works really well for handling events. The architecture was developed, I think, for simple sensors that needed to communicate without managing who they were talking to, so each sensor would send all its events to a “broker” and anyone interested in the data can “subscribe” to events via that broker.

MQTT isn’t designed to carry a lot of infromation - so images, for example, would not be transmitted by MQTT and instead you’d probably just send a URL and retrieve the image later via HTTP. Also, it’s not point-to-point, so the concept of a “reply” doesn’t really exist: if I want to start a task then monitor its progress, I first need to send an event that says “I want the task to start” then subscribe to events that will inform me what’s happening. However, there’s no guarantee that the task that runs was started by me, because the messages aren’t linked to each other.

It is possible that, at some point in the future, we could look into MQTT again specifically for event handling; currently we don’t really use the concept of “events” and there are several places where we could benefit from this - e.g. if we fire an event whenever the stage moves, it would make it easier for other parts of the software to update themselves whenever this happens. Currently the only way to do this is via polling. However, adding good event support would be quite a significant overhaul, and isn’t one that we’re likely to have capacity to do in the short term.

I think the flexibility and richness of HTTP makes it better suited for a relatively heavyweight IoT device like the microscope; you can send meaningful amounts of data, and it functions much more like a traditional bit of hardware connected over USB or serial, which is helpful to people used to programming for that. MQTT is really useful if you want to have lots of very lightweight devices/services that communicate through an event-based architecture, and it may well be that there’s a role for that in the future of OpenFlexure. There are definitely IoT devices that are already better-suited to MQTT, and I know @B.Diederich has worked with it quite a bit - I have never actually used MQTT.

1 Like

Hi There,

MQTT seems an interesting option - as far as I am concerned - to control motors. The protocol was developed quite a while ago by IBM fellows for communication in shaky network environments (e.g. Earth / Satellites). In that regard the communication is very robust, short and simple. MQTT can guarantee that messages (i.e. command) will be delivered. On the other side it is not intended for two way communication in a sense that you must react immediately to an event (i.e. motors move the stage/… to the allowed limits. And, something I do not know, whether it can also guarantee the sequential order of messages (you don’t want to have one command overtaking, before finalizing the former. In addition big data chunks would NOT be the best to deliver by MQTT, too.

I agree with @r.w.bowman 's the chain of argument. For the purpose described above I think it is worth a 2nd look. However, I know that this might lead into a major rewrite of the software with limited if any benefit.

My 2 pennies of wisdom,


1 Like