Sending remote config 'monitoring': 2 generates too many updates

[waldner]

• App build number: 2.1.3 (21302)
• Android version: 10 QKQ1.190828.002
• Device: Xiaomi Mi 8

I'm running owntracks android client in HTTP mode with remote commands enabled, since I want all devices to use 'monitoring': 2, I thought it could be a good idea to have the HTTP server send back just that option to clients to always ensure consistent configuration, so I put the following lines in the server PHP code:

$response = array();

$response['_type'] = "cmd";
$response['action'] = 'setConfiguration';
$response['configuration'] = array();
$response['configuration']['_type'] = 'configuration';
$response['configuration']['monitoring'] = 2;
print json_encode($response);

This does indeed set the desired client monitoring mode, however if I leave that enabled, clients start sending lots of updates (up to 2-3 per second). As soon as I comment the last line above, clients go back to regular ~15-30 seconds updates. Is this expected? My intention with the above code was to fix the client config if it's not correct, and do nothing on clients that are already configured correctly.

[growse]

I suspect that what's happening here is that you have a feedback loop. Every message causes you to write a config value, in this case setting the monitoring mode to 2 (the highest accuracy setting). Updating the mode to the same value that it's currently at shouldn't do anything, but if there was a bug causing it to re-initialize the location, then that might see the behaviour you're seeing.

I'll see if I can replicate.

[waldner]

Thanks. Sometimes it takes some time before the feedback loop starts, like 1 minute or so, but it always happens eventually. Contact me privately if you want to test directly against my server.

[waldner]

Hi, any news on this one?

[growse]

Working on it.

[growse]

Ok, I think I narrowed this down to an event that fires indiacting that the monitoring changed whenever the preference setter was called. Obviously, this got called regardless of what the current value was, and that event triggered a few things, including setting up a new Location listener. In turn, this could then turn into a feedback loop.

Should now only trigger that event if the monitoring mode actually changes. Will be in 2.2.1.

[boogymantoo]

Hello (again),

I have used version 21302 intensively. Since a few months I am using version 22061. In both cases, I configure the app by importing a (generated) otrc file.

Besides the identification data, the imported config contains the following: "auth": true, "ignoreInaccurateLocations": 0, "ignoreStaleLocations": 3, "locatorDisplacement": 0, "locatorInterval": 10, "moveModeLocatorInterval": 10, [this was added since version 22061] "mode": 3, "monitoring": 1, "locatorPriority": 3, "pubExtendedData": true, "remoteConfiguration": true,

Since the new owntracks version, this (unchanged) configuration causes location updates to be sent (almost) exactly twice as frequent as before. That is: now every 5 seconds, before every 10 seconds.

Question: would that be caused by the same bug -- and therefore fixed in 2.2?

Many thanks, Chris.

[growse]

Good question.

I think it's unlikely - updates to the configuration where a mode is supplied but does not actually change it from the current mode should be a no-op.

My gut feeling is that the various updates on dependent libraries between 21xxx and 22xxx have caused a behavioural change in how the Google location service provides locations to the app. One thing that's really not very obvious is that the config values for locationInterval/moveModeLocatorInterval are more requests for updates at least this frequency, rather than specifically at that frequency. Updates may be provided more frequently than the interval requested, and in move mode the app will post every new location it gets from the device to the network, no matter how often it gets them.

I'll try and set this up again with this config and see if I can replicate this difference.

[boogymantoo]

I'll try and set this up again with this config and see if I can replicate this difference.

Much appreciated!

In order to have some more factual data, I added a function in the db where the owntracks locations are stored (in their unprocessed form). The function calculates the average period between owntracks updates for a given device ID and in a given timespan, based on the timestamps received in the location messages.

I ran that function on a number of device IDs, all of them Android based, selecting samples in August 2020 (using v21302 at that time) and samples in November 2020 (using v22061). For completeness: only two of the sampled device IDs represent the same physical device in August and now (we use owntracks to monitor people's movements during events, so the people and devices change over time - except for the event staff).

The results show this:

• with v21302, the period varied between 10.3 and 11.8 seconds (based on 5 different devices)
• with v22061, the period varies between 2.6 (*) and 5.6 seconds (based on 3 different devices, 2 of which are also sampled with v21302)

(*) 2.6 seconds on one device, as it happens that's the only device where the osmand app is also running

Best regards, Chris.

[axelpip]

Hi, I got the same behaviour with Android Version 2.4.3(243002) when using remote config via MQTT and set the 'monitoring':2 parameter. Once done there are very frequent location updates (4-9 sec, most close to 5 sec). Setting the mode manually will not cause the issue. It happens on 2 different devices (Huawei Mate 20pro and Huawei P20). If the app is stopped and cache is flushed things go back to normal. Switching to "significant change" Mode manually in the app will not trigger this behaviour, unless the mode had been changed remotely before. Pleas let me know if you need any additional info.

Best regards, Axel

[growse]

I'm having real trouble replicating this.

With locator interval at 60 and move mode locator interval at 10. In significant mode I get updates every 30 seconds, which fits the pattern seen on recent Android versions and FusedLocationClient settings. It's at least every 60 seconds. If I switch to move mode in app, I get updates every 5 seconds.

I see the same behaviour if I switch using a cmd message of '{"_type":"cmd", "action":"setConfiguration", "configuration": {"_type": "configuration", "monitoring": 2}}'

Are you expecting to receive location updates no more frequently than locatorInterval / moveModeLocatorInterval? Is the problem that updates are faster than specified?