MQTT Support

[engineererr]

We tried to use the paho MQTT client library for arduino but the GSM module is not the same and some other dependencies make life hard..

Do you have any plans to implement the MQTT protocol on the opentracker?

If yes: Do you know roughly when we can use it?
If no: Do you have any advice on how we can achieve MQTT communication by ourselves?

Thank you very much

[m4rkw]

Hi @kurky91 just curious what it is you want to achieve by using MQTT with the opentracker? The run loop in the codebase for opentracker is fairly long, around 16 seconds or so I think, so you'd likely see fairly high latency trying to use this.

[engineererr]

Hello @m4rkw
MQTT is a good bet to connect little devices because of the very small overhead and quality of service features. But the real reason is that we want to connect to a plattform that only supports MQTT at the moment.

We don't go for speed. Maybe there is no real need for MQTT since we have enough power in the car.

But I guess this question is still eligible: Why using HTTP when there is MQTT?

[m4rkw]

Hi @kurky91, I didn't write the original software so I can't say why it was originally designed to use HTTP rather than MQTT but if I had to guess I'd say because HTTP is simpler and more common. The way trackers traditionally work is simply by reporting their position (and other data) at an interval and pushing it via HTTP is more than sufficient for this. Also given the availability of a GSM connection which can be used to parse sms commands, having the commands sent via MQTT would seem to introduce unnecessary complexity (most people have a phone, not everyone has something that can talk MQTT and even if they did sms often works in areas where data coverage does not).

I don't think I really understand your use case with regards to MQTT, but if the aim is just to have the opentracker spitting out MQTT messages then you could solve this by putting a translation layer on the MQTT server that receives the HTTP (or raw) data from the tracker and translates it into MQTT messages.

[Daniel-dk]

MQTT would make it a bit simpler to parse tracker information when rolling your own tracking server or getting data into other systems ( setting up a MQTT server is easier for some than creating a REST service ) - like NodeRED and mosquitto combined

Implementation of MQTT ( using working existing libraries like pubsub ) would need some rework of the underlying GSM interface in opentracker to use Arduino's Stream and Client interfaces like Ethernet and Wifi libs do ( essentially a rewrite of the GSM interface of openTracker ).

One could use the Arduino GSM as a starting point - M10 ( Arduino GSM shield ) and M95 ( opentracker ) have identical commands regarding the TCP/IP stack, the big issue is the hard coded and custom software serial communication for AVR in the Arduino library - it is the reason for incompatibility with the Arduino DUE and Zero.
The devs seemed to weave the SS communication and buffers into the rest of the library in such a way that it is difficult to replace it with a "standard"/ hardware Serial interface ( .read(), .peak() , .print() , .available() ).

• https://github.com/arduino/Arduino/tree/master/libraries/GSM

One could use the SIM900 /800 based libraries- they are simpler to follow than the Arduino GSM lib, but the modems are not that similar so a lot of datasheet surfing is needed and one can only use them as a "wireframe" and rewrite the modem AT commands and the state machine to fit the M95

• https://github.com/r-map/rmap/tree/master/arduino/sketchbook/libraries/sim800

whichever way one goes, its a big chunk of work...

[Daniel-dk]

it looks like the Arduino.org group have edited their GSM library to work on the Zero ( samd arch )
they are still using SoftwareSerial and seemt o have changed the pin handling methods to work with the Arduino Zero
so Due / OpenTracker port should be simpler with that as a starting point but still not the ideal case using a real UART/USART and some datasheet surfing would still be required.