From 09c0b1c23199ae0982cdc86c7668ccbd0970f0f3 Mon Sep 17 00:00:00 2001 From: Brent Date: Wed, 13 Jul 2016 20:48:05 -0500 Subject: [PATCH] Added dynamic entity tracking documentation (#641) * Change ordering * Added dynamic entity tracking documentation --- .../sensor.google_travel_time.markdown | 35 +++++++++++++++++++ source/developers/releasing.markdown | 7 ++-- 2 files changed, 39 insertions(+), 3 deletions(-) diff --git a/source/_components/sensor.google_travel_time.markdown b/source/_components/sensor.google_travel_time.markdown index 1667c1551a3..01a1643484d 100644 --- a/source/_components/sensor.google_travel_time.markdown +++ b/source/_components/sensor.google_travel_time.markdown @@ -40,3 +40,38 @@ Configuration variables: - **options** (*Optional*): A dictionary containing parameters to add to all requests to the Distance Matrix API. A full listing of available options can be found [here](https://developers.google.com/maps/documentation/distance-matrix/intro#RequestParameters). - **departure_time** (*Optional*): Can be `now`, a Unix timestamp, or a 24 hour time string like `08:00:00`. If you provide a time string, it will be combined with the current date to get travel time for that moment. - **arrival_time** (*Optional*): See notes above for `departure_time`. `arrival_time` can not be `now`, only a Unix timestamp or time string. You can not provide both `departure_time` and `arrival_time`. If you do provide both, `arrival_time` will be removed from the request. + + + +###Dynamic Configuration +Tracking can be setup to track entities of type device_tracker, zone, and sensor. If an entity is placed in the origin or destination then every 5 minutes when the component updates it will use the latest location of that entity. + +```yaml +# Example entry for configuration.yaml +sensor: + # Tracking entity to entity + - platform: google_travel_time + name: Phone To Home + api_key: XXXX_XXXXX_XXXXX + origin: device_tracker.mobile_phone + destination: zone.home + + # Tracking entity to zone friendly name + - platform: google_travel_time + name: Home To Eddie's House + api_key: XXXX_XXXXX_XXXXX + origin: zone.home + destination: Eddies House # Friendly name of a zone +``` + +####Entity Tracking +- **device_tracker** + - If state is a zone then the zone location will be used + - If state is not a zone it will look for the longitude and latitude attributes +- **zone** + - Uses the longitude and latitude attributes + - Can also be referenced by just the zone's friendly name found in the attributes. +- **sensor** + - If state is a zone or zone friendly name then will use the zone location + - All other states will be passed directly into the google API + - This includes all valid locations listed in the *Configuration Variables* diff --git a/source/developers/releasing.markdown b/source/developers/releasing.markdown index 93e0f47fa40..5c0fec8b407 100644 --- a/source/developers/releasing.markdown +++ b/source/developers/releasing.markdown @@ -22,9 +22,10 @@ This page describes the steps for publishing a new Home Assistant release. 1. Create a blog post and base it on the PR text. Add images, additional text, links, etc. if it adds value. Tag each platform/component in message to documentation. 2. Create missing documentation as stumbs. -3. Update the link on the frontpage (`source/index.html`) to link to the new release blog post and version number. -4. Merge blog post and updated frontpage to `master` (`git merge next`). -5. Change to `next` and merge with `master` (`git checkout next && git merge master`) to keep in sync. +3. Create a pull request from `next` to `master` with the upcoming release number as title. +4. Merge `master` into `next` (`git checkout next && git merge master`) to make the PR mergable. +5. Update the link on the frontpage (`source/index.html`) to link to the new release blog post and version number. +6. Merge blog post and updated frontpage to `master` (`git merge next`). ### {% linkable_title Python Package Index %}