Issue getting _cmd reportLocation working

[hastyeagle]

App build number: 2.4.12
Android version: 14
Device: Google Pixel 7a, 6a
Installation source: Github/APK

Hi! I'm trying to get the _cmd: reportLocation working. I can publish a message to the owntracks/<user>/<device>/cmd topic, and I see it when I subscribe to the topic:

2023-11-09T18:11:18Z cmd {"_type":"cmd","cmd":"reportLocation"} 00

On the device in the Owntracks logs page I'm seeing E MessageProcessorEndpointMqtt: message failed validation. Remote commands are enabled. The command I'm running to publish the message is:

echo '{"_type":"cmd","cmd":"reportLocation"}' | mosquitto_pub --cafile ca.crt --cert owntrack_client.crt --key owntrack_client.key -h <MQTTIP> -p <PORT> -t 'owntracks/<USER>/<DEVICE>/cmd' -u <USERNAME> -P "<PASSWORD>" -q 1 -s

I'm not sure what the 00 is at the end in the message log (it's not in the command I published). Any ideas where I screwed up?

Thanks!

[jpmens]

There’s something wrong with your mosquitto_pub command, IMO. First you’re missing a value for -h and for -p and second I’d use -l (read line) instead of -s (send file from stdin).

Other than that the command looks ok to me.

[hastyeagle]

Sorry -- I forgot to escape the host and port on the post. I changed to -l and now the 00 is not appearing when I publish the message, but the app is still throwing the message failed validation error.

[jpmens]

mosquitto_pub … -s is adding an additional newline (\n) to the payload, whereas -l doesn’t. I’m assuming that’s the reason Android doesn’t recognized the cmd.

[jpmens]

Could you please humor me and try

printf '{"_type":"cmd","cmd":"reportLocation"}' | mosquitto_pub ... -l

(use printf i/o echo to completely avoid the newline)

[hastyeagle]

Same thing

[jpmens]

Is allowRemoteLocation enabled (true) in your settings? (Use the configuration editor to check/set)

[hastyeagle]

hmmm, I'm not seeing allowRemoteLocation in the config.

[jpmens]

Forgive me for leading you up the garden path: the message needs an action and not a cmd in it:

mosquitto_pub -t owntracks/jpm/s8/cmd -m "$(jo _type=cmd action=reportLocation)" -q 1

This should provoke a location publish with t: r in it:

{"_type":"location","t":"r","tid":"s8","tst":1699562723, ... }

[hastyeagle]

OK, we're getting farther now! Now when the app receives the message it says "[...] Received incoming message: MessageCmd on [...]. It's not pushing a location, though. Could it be related to the allowRemoteLocation config option not being present? I tried adding it, but it said it wasn't a valid key.

[jpmens]

That configuration option (allowRemoteLocation) doesn’t exist on android; I’ve amended the documentation. Please ensure the device is connected to MQTT; that could be a reason for the missing publish.

[hastyeagle]

Gotcha on allowRemoteLocation only being on iOS.

The app is definitely connected to MQTT. It's seeing the MessageCmd come through, and I see it has an updated location. It's just not publishing the location back to MQTT.

I'm guessing it disregards the Minimal location displacement and Location interval when it gets the reportLocation command?

[jpmens]

It ought to just report the last obtained location, but I think we need expert help here now.

@growse management summary: cmd with action: reportLocation is coming in, but @snakedoctr's device isn't publishing a location (my S8 does). What are we doing wrong?

[growse]

Do you have debug logging enabled? If so, do you see a On demand location request debug log entry shortly after the Received incoming message message?

[hastyeagle]

I do:

2023-11-10 10:38:05.049 I MessageProcessor: Received incoming message: MessageCmd on owntracks/user/device
2023-11-10 10:38:05.051 D BackgroundService: On demand location request
2023-11-10 10:38:05.052 D GMSLocationProviderClient: Removing location updates clientcallback=201885842
2023-11-10 10:38:05.052 D GMSLocationProviderClient: Requesting location updates priority=0, interval=null clientCallback=201885842
2023-11-10 10:38:05.053 D GMSLocationProviderClient: transformed location request is Request[PRIORITY_HIGH_ACCURACY requested=3600000ms fastest=600000ms expireIn=60000ms num=1]
2023-11-10 10:38:05.082 D ConnectionPool: BackgroundService On-demand location result received: LocationResult(lastLocation=Location[fused <LAT>,<LON> hAcc=48.0 et=+0d13h18m30s28ms alt=120.0 vAcc=04.0 vel=0.0 sAcc=2.859375 {Bundle[{satellites=0, maxCn0=0, meanCn0=0}]}])
2023-11-10 10:38:05.155 D GMSLocationProviderClient: GMS Background location update request completed: Success=true Cancelled=false

[growse]

Huh. So it's asking for, and receiving a location. The only thing that would prevent a location being published at that point is this conditional:

android/project/app/src/main/java/org/owntracks/android/services/BackgroundService.java

Lines 513 to 525 in 47ffad4

	void onLocationChanged(@Nullable Location location, @Nullable String reportType) {
	if (location == null) {
	Timber.e("no location provided");
	return;
	}
	Timber.v("location update received: tst:%s, acc:%s, lat:%s, lon:%s type:%s", location.getTime(), location.getAccuracy(), location.getLatitude(), location.getLongitude(), reportType);
	if (location.getTime() > locationRepo.getCurrentLocationTime()) {
	locationProcessor.onLocationChanged(location, reportType);
	} else {
	Timber.v("Not re-sending message with same timestamp as last");
	}
	}

So it looks like the device is giving OT a location that's already been published. Now, this is definitely a bug, because the fact that it's an on-demand location request should override this check - that's been fixed in 2.5.0.

android/project/app/src/main/java/org/owntracks/android/services/BackgroundService.kt

Lines 571 to 580 in e99e322

	fun onLocationChanged(location: Location, reportType: MessageLocation.ReportType) {
	Timber.v("location update received: $location, report type $reportType")
	if (location.time > locationRepo.currentLocationTime || reportType != MessageLocation.ReportType.DEFAULT) {
	lifecycleScope.launch {
	locationProcessor.onLocationChanged(location, reportType)
	}
	} else {
	Timber.v("Not re-sending message with same timestamp as last")
	}
	}

It's only going to get triggered when the device doesn't go and get a fresh location, which is what it should really do with a PRIORITY_HIGH_ACCURACY location request.

[hastyeagle]

Thanks @growse for fixing this! Looking forward to v2.5.0.

Thanks @jpmens for the help as well!

[wir3z]

Excited to try this as well. Any ETA on v2.5.0? Or Beta version that we can sign up for and exercise for you? :)

[growse]

There's a couple of showstopper bugs and at least one feature still to be sorted, but I'm plugging away at them.

[wir3z]

In 2.4.12, the on-demand location lookup for HTTP would fail (wasn't implemented for HTTP?). This is now working on 2.5.0 since this SHA 074d4ec when you added it for ping/manual locations.