[enhancement proposal]: Implementation of an MQTT-Client

[soester]

Introduction

It would be great if QField would have some sort of interface to receive data from outside your tablet. This could be external sensors or any kind of data available through a network connection. Also to publish data to send commands would in some cases be usefull

A versatile and universally applicable solution to this problem would be the implementation of an MQTT client.

MQTT

(http://mqtt.org)
MQTT is an OASIS standard messaging protocol for the Internet of Things (IoT). It is designed as an extremely lightweight publish/subscribe messaging transport that is ideal for connecting remote devices with a small code footprint and minimal network bandwidth. MQTT today is used in a wide variety of industries, such as automotive, manufacturing, telecommunications, oil and gas, etc.

Proposed implementation

Qfield

Enable Qfield to subscribe and publish to mqtt topics. There are different (opensource libraries available, eg. in java:

• subscribe: make a topic available as a project (or rather mqtt) variable
• publish: publish a user defined expression as specific topic via mqtt (eg. when digitizing a feature)

MQTT-Broker

To publish and subscribe to MQTT access to a mqtt-broker must be available. This can be achieved over network. There are different payed, some free services available. Or you can host your own service. An other option ist to run it locally on your tablet (eg. as an app or via termux + node-red). The choice is dependent on the use case.

Use cases

I think there is an endless number of use cases for this. Some examples:

Use cases subscription:

• Get value from external sensor (connect sensor to local mqtt-broker): This could be anything but really useful for environmental sensors.
• Get value from web service: Why not to log meteorological data while acquiring filed data?
• If you publish sensor data of your mobile device to your local broker it would even be be possible to solve problems like described in: Feature request: geologic compass #1882
• ...

Use cases publication:

• Define an expression which returns information from your dataset combined with your current position and publish it to a specific topic: This could be a solution for problems like described in Enhancement: Add a opportunity to emit a signal to USB-Port to steer a USB-relais as a result of a query #2421
• Make your sensor-data at your position available to other field workers.
• Shortcut for this: https://twitter.com/qgis/status/1441415878348730379?s=20
• ...

We would be glad to fund some parts of required development. Is there anyone else interested in this?

Whats your opinion @m-kuhn?

[m-kuhn]

I like the idea, very nice.
Where would you see the configuration pf connection parameters (host etc) in QField or the project?
Where do you see login credentials fit best?

[soester]

Glad you like it :-)

Where would you see the configuration pf connection parameters (host etc) in QField or the project?
I think there are arguments for both:

• QField: Easy adaption on each Tablet for Tablet specific parameters. A similar approach like connecting to an external gnss reciever could be used.
• Project: Prepare project in QGIS and distribute it to all fieldworkers. I think like this also an implementation in QGIS would be required?

Where do you see login credentials fit best?

I think for use cases restricted to local usage (all run on localhost) anonymus access without credentials would be possible.
But to subscribe to internet based services authentication is a must (either via user/password and TLS or via X.509 Certificate Based Authentication).
I think something like the pg_conf file would be a good option? For the certificate based approach selecting certificates via GUI would be nice!

[soester]

@m-kuhn @nirvn if we are talking about upstream implementation in qgis qgis/QGIS-Enhancement-Proposals#257 might be interesting?
and more specifically this: FraunhoferIOSB/FROST-Server#1297

[nirvn]

@soester , out of curiosity, have you made some tests using the TCP/UDP/serial port sensor support added a while back?

[soester]

@nirvn yes we are using UDP sensor support in production. Our old system (via termux float widget) was no longer reliable on newer Android versions. Since then we have been using a combination of yoctopuce (serial connector), node-red and udp sensor interface in Qfield.
Unfortunately, the generation of measuring devices for which this system works is very old and needs to be replaced. Therefore, despite the cool function, we only use it sporadically.