Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mobile App: report location should only allow location + battery #21761

Closed
balloob opened this issue Mar 7, 2019 · 9 comments · Fixed by #21849
Closed

Mobile App: report location should only allow location + battery #21761

balloob opened this issue Mar 7, 2019 · 9 comments · Fixed by #21849

Comments

@balloob
Copy link
Member

balloob commented Mar 7, 2019

The current report location is just a wrapper around device_tracker.see. We should only allow sending in gps, gps_accuracy and battery. All other data should be filled in on the server side with details from the registration.

See API docs for how it should be: https://developers.home-assistant.io/docs/en/app_integration_sending_data.html#update-device-location

@robbiet480
Copy link
Member

robbiet480 commented Mar 8, 2019

At a minimum the iOS app would also need to be able to still send source_type, location_name and consider_home which are all accepted values in the standard device_tracker.see payload.

There are a number of location related attributes that the iOS app sends which users have found valuable that are outside of the standard device_tracker.see payload. These include:

  • speed
  • altitude
  • course
  • trigger (e.g. Geographic Region Entered/Exited, iBeacon Region Entered/Exited, Manual, Significant Location Update, Background Fetch, Push Notification and a few other possible values)
  • floor

Do you have any thoughts on allowing these to still be sent? If I had to choose only one to keep, it would be trigger.

Everything else we currently send as part of device_tracker.see can be split into sensors.

@robbiet480
Copy link
Member

Okay, so thinking more about those extra attributes, I'll leave them out for now and expose them all via sensors (#21782) instead.

Limited schema work at robbiet480@2b0658a

@robbiet480
Copy link
Member

@balloob So when we call device_tracker.see, it still wants a device ID or MAC address. What should be provided?

@balloob
Copy link
Member Author

balloob commented Mar 9, 2019

we should generate a registration iD for the device ID.

I'm fine with including speed, altitutde etc. Those can be useful.

Source type should always be GPS, as that's what mobile devices use.

Location name, shouldn't we resolve that using zones?

Consider home, isn't that done by mapping GPS to the home zone at backend?

@robbiet480
Copy link
Member

Source type can be bluetooth_le for iBeacon.

Location name is set by the app for situations in which a iBeacon doesn't have defined coordinates like its in a car.

We set Consider Home to 180 seconds for iBeacon exits to resolve some issues people have had with the iOS app jumping in and out of the zone.

@balloob
Copy link
Member Author

balloob commented Mar 9, 2019

I think that iBeacon sightings might have to be processed via the iOS extension

@robbiet480
Copy link
Member

iBeacon exists on Android though too...

@balloob
Copy link
Member Author

balloob commented Mar 9, 2019

Wwe should not premature standardize, let's first see what things are in demand.

@balloob
Copy link
Member Author

balloob commented Mar 9, 2019

It's a non-breaking change to move something from ios to mobile_app if the API stays the same

@ghost ghost removed the in progress label Mar 13, 2019
@robbiet480 robbiet480 modified the milestone: mobile_app Mar 14, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants