Expanding the extended data field to contain settings that may be non-optimal for operation about android

[ckrey]

I think on a new topic owntracks/user/device/status. This can be optionally subscribed to by the backend.
.../info is already used for cards and is subscribed by other clients

[growse]

I'm not sure about putting it into configuration - this is meant to be for the configuration of the app, rather than the status of the device. I also agree that the location message type is meant to just contain fields that might conceivably change from one location message to the next.

I think there might be value in getting the device to report its status (in a separate message type), on request from the remote endpoint. Open question as to what extend it's android/ios/whatever specific, rather than genericised.

including a battery icon that changes when charging

Does the icon currently not reflect charging status? That's a bug if so.

[wir3z]

Does the icon currently not reflect charging status? That's a bug if so.

No, did not appear to be so in the 2.4.12 PlayStore version.

[ckrey]

I don't think this more or less "static" data should go into each location message. Rather put it into an extra attribute when the configuration is dumped (or requested by cmd/dump

[ckrey]

The current network status is already in then location message as conn booklet

[jpmens]

I agree that this rather static information should be reported otherwise if at all.

[wir3z]

The current network status is already in then location message as conn booklet

It reports mobile/wifi data source, not if the wifi is disabled which basically breaks significant monitoring mode.

[wir3z]

All of the above settings can be changed by the user and basically render decent presence detection useless. Is there a cmd/dump command (I was looking for that!)? Retrieving it that way would be just as valuable.

[jpmens]

Our Booklet details the supported commands on the JSON page.

[ckrey]

The current network status is already in then location message as conn booklet

It reports mobile/wifi data source, not if the wifi is disabled which basically breaks significant monitoring mode.

It is not supposed to report a "data source" but

conn Internet connectivity status (route to host) when the message is created

[ckrey]

I don't think this more or less "static" data should go into each location message. Rather put it into an extra attribute when the configuration is dumped (or requested by cmd/dump

There are the configuration settings as described in [booklet|(https://owntracks.org/booklet/tech/json/#_typeconfiguration)

You could add an object to this object like:

{
   "_type":"configuration",
   ...
   "local": {
     "wifi": true/false,
     "ps": true/false,
     "bo": true/false,
     "hib": true/false,
     "loc": "app location permissions"
     }
}

[ckrey]

Good idea @growse: How about defining a new "_type":"status" message, which can be retrieved by a {"_type":"cmd", "action":"status"} command. In addition, the app may send this message when requested by the user or when the status changes

[ckrey]

If we do have the "status" message, we can have a genericised part and an iOS/android part like

{
  "_type": "status",

  ... generic attributes (if any)
  
  "android": {
     "wifi": true/false,
     "ps": true/false,
     "bo": true/false,
     "hib": true/false,
     "loc": "app location permissions"
     }
     
... or ...
   
  "iOS": {
    "altimeterAuthorizationStatus": "CMAuthorizationStatusAuthorized",
    "altimeterIsAbsoluteAltitudeAvailable": false,
    "altimeterIsRelativeAltitudeAvailable": true,
    "locationManagerAuthorizationStatus": "kCLAuthorizationStatusAuthorizedAlways",
    "UIBackgroundRefreshStatus": "UIBackgroundRefreshStatusAvailable",
    "version": "17.2.3/de_DE"
  }
}

[growse]

Which topic should status messages live on? /info?

[growse]

Worth sketching out a quick schema with some types for each value?

[wir3z]

https://owntracks.org/booklet/tech/json/#_typeconfiguration

Is cmd/dump applicable for Android? It's listed as iOS only: "dump Triggers the publish of a configuration message (iOS)"

[wir3z]

Would you like a PR for this? I realize that it's in the location message vs status, but you can cherry pick the API's to collect the desired info from Android.

[growse]

Yes please - I suspect at a minimum we'll need:

• New message type for status message
• New enum value for command message action
• handler in the service to process the incoming command, and generate the status message, before sticking it on the outbound queue.
• somewhere between 2 and 385 tests.

I've probably missed something.

Worth also saying that these are incremental - we can introduce a new message type as an atomic change without doing the other bits, so might be easier to break it up.

[wir3z]

Sorry about the late reply -- just tied up on another project. I'll try to get the first bits into a PR this weekend to start chipping away at this.