jpmens / qtripp Goto Github PK

Should we add a UUID to the JSON payloads we publish over MQTT? UUIDs are helpful in tracking unique messages, and in this case, it's just a couple lines of code.

We should probably use a CDB (e.g. TinyCDB) file for device_to_topic() instead of using configuration from the INI file because we'd be able to re-create CDB on changes and have qtripp re-open the CDB -- easier than mucking about with the INI.

data.log has shown buffer with two separate devices in it.

instead of a single data.log we can store a device's data in data-<IMEI>. This simplifies things greatly when we have to replay a device's log or for long-term data storage.

Reconnection logic in qtripp is either missing or buggy.

Add PID to log output in order to easily detect restarts (a.k.a crashes).

GL300(W) devices (battery driven, not car connected) send GTPNA / GTPFA messages when manually switched on or off. As these messages do not contain a position (lat/lon), they are not processed

41 means device is motionless, 42 means device is moving, but ignition is not on.
Should not be interpreted as TOW

mongoose.c:1110:33: error: argument 1 of type 'unsigned char[16]' with mismatched bound [-Werror=array-parameter=] 1110 | void cs_md5_final(unsigned char digest[16], cs_md5_ctx *ctx) { | ~~~~~~~~~~~~~~^~~~~~~~~~ In file included from mongoose.c:1: mongoose.h:1765:34: note: previously declared as 'unsigned char *' 1765 | void cs_md5_final(unsigned char *md, cs_md5_ctx *c); | ~~~~~~~~~~~~~~~^~ cc1: all warnings being treated as errors make: *** [<builtin>: mongoose.o] Error 1

Insert reserved into param 10 and increment everything afterwards.

I'm happy to add support for other GL300 devices however whilst I'm there.

Add a ping command (../*/cmd ping) in order to monitor MQTT subscription. (Inspired by @ckrey)

GTVER is a very useful report for firmware/hardware versions. I added it in #14 but only implemented GL300M devices.

We might also want to add support for more items in devices.h such as:

int device_type;    /* String representation of the device type e.g. gl300m */
int ver_fw;            /* HEX firmware version MAMI for MAjor MInor */
int ver_hw            /* HEX hardware version MAMI for MAjor MInor */

This is something that I could happily undertake and submit a PR when ready.

It looks like qtripp is only able to emit OwnTracks JSON via MQTT.

It would be great if it were also able to emit over HTTP, so that it could be used in a scenario where the Recorder is running in HTTP mode (thus eliminating the need for running a separate MQTT server), or when using alternative backends (i.e. orion-server/orion-web) :)

(or at least more identifiable as being qtripp)
requested by @ckrey