Keep timeouts under software control instead. If software fails, trust in watchdog

note to self

org.eclipse.paho.client.mqttv3.MqttException

• org.eclipse.paho.client.mqttv3.internal.MqttDeliveryTokenImpl.waitForCompletion(), bci=60
• general.MQTTHandler.publish(), bci=68
• general.SocketGPRStask.run(), bci=952

• tcp://host:1883 without TLS works well!
• ssl://host:8883
  OpenSSL Error: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
• ssl://host:8886 (tls_verision tlsv1)
  OpenSSL Error: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol
• ssl://host:8887 (tls_verision tlsv1.1)
  OpenSSL Error: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
• ssl://host:8888 (tls_verision tlsv1.2)
  OpenSSL Error: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number

note to self

I must check content of OwnTracks.properties after next deployment; we've noticed either of user and password went missing / was corrupt.

The default clientID is the IMEI number, but that can be overriden by a user-defined value. $dump reports the IMEI, but that is almost impossible to parse (as well as dumping loads of additional info).

I'd like to request that we publish the device's IMEI number upon startup:

.../hw/imei 1234567890

This is useful for 'inventory' purposes.

$GPGGA,091322.00,xxxx.06561,N,yyyyy.58375,E,1,07,1.13,176.3,M,46.3,M,,*5E

delivers a JSON payload of about

"alt":"1.xx"

I'd like to propose a feature which is easy to implement and would aid in monitoring device status, interesting in particular when we have several devices.

Can we publish to .../status a retained 1 when the device first comes online, coupled with a default retained LWT of 0 when it goes away?

This was necessary in earlier versions of the app because the MQTTHandler could not re-connect at that time.

Should we remove the batt level from the JSON payload for GW devices? It's mostly the same value, and if the battery does die (it happened to my first device) the device probably won't do much anyway ... Saves a few bytes, in particular as the information doesn't seem really valuable.

I published a /cmd gps to the device, whereupon I get

owntracks/GWBUS-ak {"_type":"location","t":"m", ... }
owntracks/GWBUS-ak/cmd/out ACK: command: "gps" {"_type":"location","t":"m", ...}

The first message is expected.
The second isn't. Bug?

operator
closeMode
movState
sleepMin
...

subscribe to .../cmd topic
execute commands:

• set parameters
• report location now
• reboot

Add optionally

• course (heading)
• altitude
• speed
• Distance?
• Battery status

• minDistance minimum distance travelled before next location is published in meters, default 0
• maxInterval maximum time interval before next location is published in seconds, default 0
• retained publish locations with retained flag, 0/1, default 1
• qos publish locations with quality of service 0..2, default 1

I see disconnected on console, and that's it. No way to talk to device over MQTT after that, of course.

2014-08-25 12:38:59 E SSLSocketFactory IOException
2014-08-25 19:56:26 E SSLSocketFactory IOException
2014-08-25 21:25:45 E SSLSocketFactory IOException
2014-08-25 21:42:29 E SSLSocketFactory IOException
2014-08-25 21:43:15 E SSLSocketFactory IOException
2014-08-25 21:44:00 E SSLSocketFactory IOException
2014-08-25 21:44:45 E SSLSocketFactory IOException
2014-08-25 21:45:30 E SSLSocketFactory IOException
2014-08-25 21:46:15 E SSLSocketFactory IOException
2014-08-25 21:47:00 E SSLSocketFactory IOException
2014-08-25 21:47:45 E SSLSocketFactory IOException
2014-08-25 21:48:30 E SSLSocketFactory IOException
2014-08-25 21:49:15 E SSLSocketFactory IOException
2014-08-25 21:50:00 E SSLSocketFactory IOException
2014-08-25 21:50:45 E SSLSocketFactory IOException
2014-08-25 21:51:30 E SSLSocketFactory IOException
2014-08-25 21:52:15 E SSLSocketFactory IOException
2014-08-25 21:53:00 E SSLSocketFactory IOException
2014-08-25 21:53:45 E SSLSocketFactory IOException

2014-08-25 21:54:30 E SSLSocketFactory IOException
2014-08-25 21:54:30 W MQTTHandler connectToBroker: 32103
2014-08-25 21:54:33 W MQTTHandler disconnect: 32101

I think we need a short (!) version number in the payload, maybe not in each and every PUBblish, but upon request? Something that enables an operator to determine whether his devices are up to date.

Ensures last valid position is known.

dist is given in meters since last reboot ("t": = "f").

Positive example:
vehicle ey travels at 97 km/h and reports ~3300 m distance every 120 seconds

ey: {... "tst":"1408524280","vel":"97.830048","dist":"607591"...}
ey: {... "tst":"1408524400","vel":"97.678184","dist":"610864"...}
ey: {... "tst":"1408524520","vel":"97.594844","dist":"614137"...}

Negative example:

vehicle car travels at ~138 km/h and reports ~ 120 m distance every 120 seconds

car: {..."tst":"1408506896","vel":"131.762392","dist":"24140"...}
car: {..."tst":"1408506957","vel":"137.786948","dist":"24267"...}
car: {..."tst":"1408507018","vel":"144.976412","dist":"24390"...}

In town, there are frequent location publishes when stopping at crossings. But the next indication of the direction the vehicle has taken comes maxInterval later.

$state
ACK: NUMSAT:7;BEARER:3;CREG:-1;CGREG:-1;BATT:4.467;EXTV:12.275;gpsQ:0;sending:true;network:true;operator:"Vodafone.de"

OK
;uFW:02.18,02.01,02.16;SW:0.5.89;EG5:Cinterion,EGS5-X,REVISION 02.004;IMEI:356612027383852

should be:

>$state
ACK: NUMSAT:7;BEARER:3;CREG:-1;CGREG:-1;BATT:4.467;EXTV:12.275;gpsQ:0;sending:true;network:true;operator:"Vodafone.de";uFW:02.18,02.01,02.16;SW:0.5.89;EG5:Cinterion,EGS5-X,REVISION 02.004;IMEI:356612027383852

A few seconds ago, at Wed Jul 30 08:47:09 UTC 2014:

"tst":"1406753195"

which translates to Wed Jul 30 22:46:35 2014, which is several hours hence

Current status:

$-commandos - available auf MQTT/cmd, RS232

login
logout
set
reboot
dump
gps

#-commandos - available on RS232

PWD
REBOOT
CFG
CHPWD
SETID
GPRSCFG
POSREP
POSUSR
PUBTOPIC
SETINSENSIBILITAGPS
SIG
SLPTM
TRK
TRKCFG
SETSPEED
TRKTM
LOGREAD
EE_GET_PTR

#-commandos available on Modem-CSD (ATA...ATH)

CLOSE
LOGREAD
LOGQUEUE
OLDLOGREAD
LOGDELETE
PWD
REBOOT
CFG
CHPWD
SETID
GPRSCFG
POSREP
POSUSR
SIG
SLPTM
TRK
TRKCFG
TRKTM
SETINSENSIBILITAGPS
SETSPEED
EE_GET_PTR

SMS commandos - listening on SMS

gps
reboot
state

I'm seeing several of these on the console

't':'p' is also emitted by iOS devices on 'ping'; can we please change this to 'k' (parK) or something?

Reasoning: In order to suppress 'p'ings from iOS, m2s queries the value of 't' (there's no other way I can check for pings), and this would suppress park messages from greenwich devices.

For error tracking

The JSON payload of vel is fine as it is, but for the gps SMS, I'd suggest rounding velocity/speed to a single decimal point. The potentially long decimal is overkill and potentially causes truncation of the following text.

GPS fix is ok (red light and $state)
Network is available (yellow light blinking twice and $state)

MQTTconnect returns 32103=Unable to connect to server

Can only be solved by HW reset

a) find reason for problem
hint: at+cgatt=1 returns ERROR

b) add timeout for 32103 and use GPIO Watchdog to reset device

I'm seeing dist as a fractional number with about a million decimal places in the SMS (but not in the JSON payload). This is unnecessary (they are meters) and it consumes valuable space in the gps SMS.

(I warned you I'd think up evil stuff during your vacation!)

In view of limiting data (M2M etc.) I'm thinking whether we could add some intelligence to the number of MQTT publishes that occur. For example:

• Quiet time (a.k.a. parked hours). Configurable time frame (22:30 - 06:45) during which the Greenwich should not publish at all, or maybe once an hour only.
• Dynamic speed. We currently have minDist and minSpeed, but supposing we have minDist=100 and we're driving at 100 km/h, this will cause lots of publishes. If we can detect we're going over a certain speed, we could dynamically increase the minDist, thereby lowering number of publishes but still having dynamic maps update rather frequently.

Something we should consider as enhancement, I'd say.

settings: user and password, can be null

JavaME limitations, still to be done

App sometimes starts in airplane mode

Using maxInterval and minDist, in my test setup the gw does sent every 3 minutes one publish.
It issues the PINGs every keepAlive (default 60) seconds. But now looses the connection.

Will try with keepAlive = 30.

Is there any timeout parameter on the GPRS connection?

Currently voltage is reported when changes > 0.1V happen. Better use 0.5V or make this configurable. As internal battery is more stable, 0.1V seems to be a good reporting level.

that has changed in version <= .89