Add support for diff friends array

[binarybucks]

As discussed: Maintain a mapping of returned locations for each friend and only include it, if it changed if POST request contains X-DIFF header.

[jpmens]

This is going to be very invasive.

Would it suffice if Recorder made note of a CRC of the whole friends[] array it returns to a particular client? On the next HTTP POST to the recorder, if the CRC isn't the same as the previously transmitted friends array, you would get the whole array.

[binarybucks]

wouldn't the CRC/hash always be different when the client itself is included?

[jpmens]

You are going to have to remind me what this was intended for, as I've forgotten the exact use-case.

[travisghansen]

Not that it helps directly in the project but I'm handling this very idea pretty easily in Node-RED I take incoming mqtt messages from my primary broker (filter them first to ensure acc is sane, would be nice if ios/android apps allowed handling this on their end too) send the 'good' messages on to recorder's internal mqtt instance for storage there. After that I shove the Node-RED msg through some geofence nodes and then cache the result in redis. The next message that comes through for a particular device/user then retrieves the cache and does a diff. I then can send notification/etc logic from there.

The whole setup allows for easy server-side geofencing logic pretty easily. If you care for more details I can elaborate.

[binarybucks]

do you mean that there should be an option to not send messages if acc is > x?

Am 24.09.2016 um 07:20 schrieb Travis Glenn Hansen <notifications@github.com

:

Not that it helps directly in the project but I'm handling this very idea pretty easily in Node-RED I take incoming mqtt messages from my primary broker (filter them first to ensure acc is sane, would be nice if ios/android apps allowed handling this on their end too) send the 'good' messages on to recorder's internal mqtt instance for storage there. After that I shove the Node-RED msg through some geofence nodes and then cache the result in redis. The next message that comes through for a particular device/user then retrieves the cache and does a diff. I then can send notification/etc logic from there.

The whole setup allows for easy server-side geofencing logic pretty easily. If you care for more details I can elaborate.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/owntracks/recorder/issues/127#issuecomment-249346192, or mute the thread https://github.com/notifications/unsubscribe-auth/AAvwFC3HT9wEckChpZgjBS7BpblrJqx5ks5qtLMdgaJpZM4JU_mF .

[travisghansen]

@binarybucks absolutely. I've seen similar filters built-in to home assistant (and I know there's a ticket for the feature in openhab if it's not already there) for server-side handling to ignore messages in exactly this fashion.

Basically the phone goes into power-save mode but still publishes messages with an accuracy in the thousands in my case. An iOS device for example regularly sends through messages with acc of 3000 to 4000 (basically it picks the middle of the city). In my situation now that I handle geofences server-side it's not a big deal but when I attempted to use owntrack's built-in regions in conjunction with the built-in notifications it made a mess of things. After moving the logic server-side with filtering et al the experience is much cleaner. Android seems better but is not immune to the issue.

On a related note, I also had to add a special case for acc == 0 as iOS would send that at times but clearly the accuracy was way off for those messages.

Thanks!

[jpmens]

This has been implemented in the apps as configuration ignoreInaccurateLocations