Issue getting _cmd reportLocation working
hastyeagle opened this issue · comments
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!
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.
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.
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.
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)
Same thing
Is allowRemoteLocation enabled (true) in your settings? (Use the configuration editor to check/set)
hmmm, I'm not seeing allowRemoteLocation in the config.
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, ... }
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.
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?
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?
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?
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
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:
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.
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.
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? :)
There's a couple of showstopper bugs and at least one feature still to be sorted, but I'm plugging away at them.
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.
Tentatively closing this as I think the bug's been fixed in the 2.5 beta.
Thanks, @growse. I installed the latest beta and _cmd is now working in non-manual modes. One thing I noticed is that if manual mode is set, Owntracks will refuse to publish the location due to manual mode being set:
LocationProcessor: Not publishing location: message suppressed by monitoring settings: manual
My thinking is that even in manual mode, Owntracks should send the location as requested. Essentially, it's as if I pushed the "Report Location" button (which works even in manual mode) and I'd expect the location to get published as requested.
@hastyeagle I don’t agree: if the owner of the phone decides to stay quiet or send updates only manually, then nobody else from the outside should be able to query the location.
This is the same in iOS.
@hastyeagle I don’t agree: if the owner of the phone decides to stay quiet or send updates only manually, then nobody else from the outside should be able to query the location.
This is the same in iOS.
Works like we designed it. :-)
@ckrey Yea, but there are "manual" and "quiet" modes. I could see not sending an update in quiet mode, but sending the update in manual mode still makes sense to me. I'm fine leaving it the way it is, it's just not how I would have thought it would work.