I see, thanks for chiming in and explaining.
Makes having a device_tracker as source/destination somewhat inconvenient.
would you happen to know is this is the same for google travel time?
Iāve been following this thread and finally got around to getting my waze time sensor working again. Looks like the origin/destination name to gps mapping has changed a little. Specifying GPS co-ords sorts that.
My problem is that I was forcing a specific route via use of incl_filter and ex_filter - So that waze wouldnāt re-route around traffic on my usual route, and HA would send me a message warning me about an issue on my normal route when i left the house.
My current problem is now that whenever I use incl_filter and ex_filter I get the following error in logs:
Traceback (most recent call last):
File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 57, in run
result = self.fn(*self.args, **self.kwargs)
File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/components/waze_travel_time/sensor.py", line 92, in <lambda>
hass.bus.listen_once(EVENT_HOMEASSISTANT_START, lambda _: sensor.update())
File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/components/waze_travel_time/sensor.py", line 222, in update
self._waze_data.update()
File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/components/waze_travel_time/sensor.py", line 289, in update
route = sorted(routes, key=(lambda key: routes[key][0]))[0]
IndexError: list index out of range
Anyone have any advice on this?
whats your configuration
Sorry for slow responseā¦ If I comment out the last two lines, I get a result back - But without them, waze might be using some crazy route (Iām currently setting start point very specifically to try and encourage it to use my desired route!!
- platform: waze_travel_time
origin: 53.768413, -1.749178
destination: Merrion Way Leeds, UK
region: 'EU'
name: Work Commute
incl_filter: M62
excl_filter: Stanningley
Waze API can return up to 3 results. The filter removes items from those 3 results and returns the remaining first result. If all 3 results contain your excluded result, all results will be excluded and youāll get this error. There is no way around this, we cannot pre-filter with the api. By that I mean, you cannot provide the api with exclusions and requests routes without said exlusion. You can only request routes then filter out.
So with that being said, try each filter independently. Otherwise you may get this error if all routes contain Stanningley or no routes include M62.
Iāll put a PR to remove the error, but it still wonāt get you a result based on my explanation above.
Thanks, understood.
Iām seeing odd behaviour, is it possible Waze API is only returning a single result?
Is there a way to confirm what is being returned, and what my filters are operating on?
Cheers
The order can change. The order is based off estimated duration.
Itās possible. It really depends on the conditions. The api is very limited because itās not a real api. We are basically sending url requests with different attributes and parsing json back. Instead of using an address, try using lat and lon for both origin and destination. It may return different results.
lat+lng has meade things much more reliable! Thanks 
Yah, iāve noticed that the waze address -> lat / long is not very good. Itās very apparent that they do not use the same method that google map uses.
not sure if this is the correct thread, but please let me ask this:
for quite a few automations, I need the dir of travel of the device being tracked. Reviewing my code because I noticed unwanted (lack of) responseā¦ I realized Waze doesnāt set a dir_of_travel attribute at all, and thats why I had to build the sensor, based on proximity sensors using another device_trackerā¦
like:
trigger:
platform: numeric_state
entity_id: sensor.waze_marijn_home
below: 15
above: 1
condition:
- condition: template
value_template: >
{{ state_attr('proximity.marijn_home', 'dir_of_travel') == 'towards' and
states('device_tracker.marijn') != 'home' }}
this used to work quite alright before, somehow lately I dont get an action. Which makes me wonder if the waze integration couldnāt be āimprovedā using the same import as the Proximity integration uses, and set the attribute dir_of_travel
could this be done at all?
secondly, I would love to experiment a bit with the dynamic route selection in the docās which does this:
sensor:
- platform: template
sensors:
dest_address:
value_template: >-
{%- if is_state("input_select.destination", "Home") -%}
725 5th Ave, New York, NY 10022, USA
{%- elif is_state("input_select.destination", "Work") -%}
767 5th Ave, New York, NY 10153, USA
{%- elif is_state("input_select.destination", "Parents") -%}
178 Broadway, Brooklyn, NY 11211, USA
{%- else -%}
Unknown
{%- endif %}
a bit like:
dest_address:
value_template: >-
{%- if is_state("input_select.destination", "Home") -%}
zone.home
{%- elif is_state("input_select.destination", "Work") -%}
zone.work
{%- elif is_state("input_select.destination", "Parents") -%}
zone.parents
{%- else -%}
Unknown
{%- endif %}
which would be even nicer as:
dest_address:
value_template: >-
zone.{{states('input_select.destination')}}
could we have the sensor read a configured Zone, (considering these zones have gps attributes and could be set verbosely?
thanks for having a look!
The waze sensor returns information from an api. You give it an origin and a destination and it will tell you how to get there and how long it will take.
The proximity sensor can āwatchā a device tracker and by watching the history of GPS-coordinate changes it will calculate a direction of travel.
Waze is a single request/response and it doesnāt know about your device trackers.
To your other question:
Both of your implementations will work if you configure the waze sensor as follows:
- platform: waze_travel_time
name: "Me to destination"
origin: <YOUR_ORIGIN>
destination: sensor.dest_address
region: 'US'
waze has been able to use sensors for about a year and a half. I added it may 2018 I think. Some recent changes went through but they arenāt related to proximity and I didnāt add them. As for the proximity changes, just use the proximity sensor. No point to combine them when there already is a solution.
thanks @petro @eifinger
will use both for their specific strengths then 
sensor:
- platform: template
sensors:
destination_address:
friendly_name: Destination
value_template: >
{{states('input_select.waze_destination')}}
icon_template: mdi:map-marker-path
origin_address:
friendly_name: Origin
value_template: >
{{states('input_select.waze_origin')}}
icon_template: mdi:map-marker
- platform: waze_travel_time
name: 'Select Origin Destination'
origin: sensor.origin_address
destination: sensor.destination_address
region: 'EU'
makes for a fine card in Lovelace:
- type: entities
title: Dynamic Waze travels
show_header_toggle: false
entities:
- input_select.waze_origin
- input_select.waze_destination
- sensor.origin_address
- sensor.destination_address
- type: custom:waze-card
title: Travel time
entities:
- entity: sensor.select_origin_destination
above setup is utterly useless, and Waze returns the most awkward results. Many times it reproduces the exact same impossible route (often via a route in Budapest)ā¦
It cant find the coordinates of the life360 device_trackers, even though they are perfectly populated with all attributes.
About the only thing it does show correctly is when I choose 2 same zones for origin and destination, it shows 0 for distance. But I must go over Budapestā¦ and that would take me 4 minutes
Change your sensor to output the lat,lon, not the name of the entityā¦
yes, Ive thought about that but this is what the docs say:
Enter the starting address or the GPS coordinates of the location (GPS coordinates has to be separated by a comma). You can also enter an entity id which provides this information in its state, an entity id with latitude and longitude attributes, or zone friendly name.
wouldnāt the current sensor then be exactly what the docs prescribe?
No. You can provide an entity_id and it will look at that entity_id. It does not say it will look at an entity_id then assume that this entity is providing other entity_idās. It does the following:
Does this entity_id contain lat and lon attributes?
Yes -> use them.
No - > Is this a sensor?
ā¦ Yes -> Provide the sensor string to the api. The sensor api requires a comma separated lat and lon or an address.
ā¦ No -> Error out.
This is the third time now that a user of the travel_time components thinks that they work this way.
I implemented the desired functionality in this PR, still WIP thoughā¦
Ah yeah, it doesnāt seem like it would be a bad change. I didnāt realize you tagged me in itā¦ github really needs to work on that. Iāll take a look at it.