Create time_travel component for google and waze

[ljmerza]

we currently have google_travel_time and waze_travel_time sensors. I was thinking to create a travel_time component for these two platforms. Then we can create a travel time lovelace card.

state: time to get there

attributes:

• origin name
• destination name
• unit of measurement
• time units

_get_location_from_entity on TimeTravel component would get from TRACKABLE_DOMAINS = ['device_tracker', 'sensor', 'zone', 'person']

[balloob]

Does each platform always know the orig/destination lat/long ?

We should make sure the platform standardizes the origin/destination config. So you either have origin_entity or origin_name in your config.

[balloob]

What is measurement units?

Also, for state, if we want this to be graphable, we should have the state be the number of minutes and a unit of measurement should be 'minutes'.

How will this/can this work with Lyft/Uber or othe ride hailing services. If so, what would need to be added to support this?

[arsaboo]

1. In addition to device_trackers, they should also use person component as inputs.
2. We also should to be able to control how/when it updates to avoid hitting the limits. For example, during the morning, it would make sense to update the sensor to office more frequently and vice versa in the evening (right now, I am doing it using automation that only updates when needed).

[ljmerza]

Does each platform always know the orig/destination lat/long ?

Doesn't look like the latest version of waze library needs it anymore. Now that I think about it we don't really need coordinates for time_travel attr.

We should make sure the platform standardizes the origin/destination config. So you either have origin_entity or origin_name in your config.

I do want to have some way to get the name for the origin/destination so the lovelace card could be a table. then you can click on a row to open your gps app. this is how my waze card works

to	from	time	route?
home	work	25 min	I40 East

What is measurement units?

sorry i meant unit of measurement couldnt think of the word

[ljmerza]

1. In addition to device_trackers, they should also use person component as inputs.
2. We also should to be able to control how/when it updates to avoid hitting the limits. For example, during the morning, it would make sense to update the sensor to office more frequently and vice versa in the evening (right now, I am doing it using automation that only updates when needed).

For some people using my waze card, they travel as part of their job so the regular 9-5 doesn't apply here. The google sensor is already rate limited to 5 min. i dont think the waze sensor needs to be but it uses an unofficial api ;/

[arsaboo]

The problem with a blanket 5 min scan_interval is that most of the calls are wasted during the day. Instead, we can update the sensors more frequently when they are in use and not update them during the rest of the day (that is what I am doing with an automation). Maybe it is out of scope for this issue, but now that we have homeassistant.update_entity, we should think about such dynamic updates.

[ljmerza]

looked into this homeassistant.update_entity and that would be great for google map limits. My vote is for out of scope though. I'd love to get this through to work on a proper lovelace card.

[Petro31]

The problem with a blanket 5 min scan_interval is that most of the calls are wasted during the day. Instead, we can update the sensors more frequently when they are in use and not update them during the rest of the day (that is what I am doing with an automation). Maybe it is out of scope for this issue, but now that we have homeassistant.update_entity, we should think about such dynamic updates.

The Waze API isn't reliable in my opinion. The main loop for getting information checks 3 servers which routinely reply with an "Internal Error" or No response. People have been complaining about this for a while now. I don't think a PR to the WazeRouteCalculator will fix the issues either because the Internal Errors are coming directly from Waze. I don't know if this is because this is an unofficial API or if the Waze servers are just that bad.

[Petro31]

Also as a side note. If this new travel time component is going to replace the existing one, we may want to investigate adding functionality to notify the user based on a time. Possibly an event of some sort. Something people always attempt to do is create a notification telling them when to leave based on a 'work arrival time' and the duration of the 'travel time'. Maybe change the sensor to a boolean (or add a new boolean sensor) with a 'arrival time', 'origin', 'destination', etc.

[ljmerza]

If this new travel time component is going to replace the existing one

there is no existing time_travel component. the google_travel_time and waze_travel_time will be converted to platforms. PR to refactor waze_travel_time home-assistant/core#21632 for reference

[Petro31]

there is no existing time_travel component. the google_travel_time and waze_travel_time will be converted to platforms.

We are saying the same thing. I was referring to this 'new' component this thread is referring to. When/if it gets implemented we should consider the following: Create a binary sensor that users can use to trigger automations based on an arrival time and the duration of travel.

[ljmerza]

I think that can be handled through templating. You'll already have the duration in the state. My hope was to get this up as simple as possible so the lovelace card can be created. Most attributes for waze and google match up, I just want it formally standardized.

[Petro31]

Ah, you must not help people with templates much. Time and templating is a thing people do not understand.

[ljmerza]

Yeah, I'll agree templating is a little advanced. As far as the basic TimeTravel component I was thinking this:

class TimeTravel():
	def name:
	def device_state_attributes:
		return origin, destination, units of measurement, time units
	def state
		return time

The waze/google platforms will inherit this and use update() and some kind of normalize method to adhere to attr structure

attr: {
	origin: string,
	destination: string,
	unit_of_measurement: string,
	unit_of_time: string
        distance: number
}

state: number

Then consts as well like SCAN_INTERVAL, UNITS, etc. Very basic stuff just to get this in. As far as binary sensors or anything else I think can be added in another PR.

[Petro31]

We'd need to add in distance. I've tried removing that in the past and people were not happy. At a minimum, we should keep what is currently in waze otherwise they will all complain. I'd argue the same for google's as well. It looks like google has a large set of attributes though.

Also, are you okay with having origin and destination being lat, long when outside a zone, or without an address?

[ljmerza]

We'd need to add in distance

ah yeah distance as well, thats what unit_of_measurement is for. updated.

are you okay with having origin and destination being lat, long when outside a zone,

I think address if given else lat,long string.

[Petro31]

We are just talking about base attributes right? Ones that will be common among both platforms? The google platform seems to do so much more. I'd hate to lose that functionality for the sake of 'making things common'.

I also like @arsaboo's Idea of having defined times where polling rates are higher. Personally, after dealing with the poor waze API, I want to switch to google.

[ljmerza]

google platform seems to do so much more

Yes, I think this would only be common attributes. device_state_attributes() can be implemented on each sensor

[ljmerza]

side note, google_travel_time doesn't support person entities

[phil-scott-78]

One thing that would be absolutely fantastic is if this component could take multiple origins and destinations rather than a single one. For example my wife works at 10 different locations and I have a couple myself. Under the current architecture this requires 12 sensors. The current component is using the distance matrix and even says it supports multiple origins and destinations but it just discards them and takes the first one. This would allow a single call to google maps when possible and drastically reduce the amount of calls needed which is super important with the new quotas in place on the APIs.

In an ideal world it would be a list with their own name, origin, and destination.

[Petro31]

One thing that would be absolutely fantastic is if this component could take multiple origins and destinations rather than a single one. For example my wife works at 10 different locations and I have a couple myself. Under the current architecture this requires 12 sensors. The current component is using the distance matrix and even says it supports multiple origins and destinations but it just discards them and takes the first one. This would allow a single call to google maps when possible and drastically reduce the amount of calls needed which is super important with the new quotas in place on the APIs.

In an ideal world it would be a list with their own name, origin, and destination.

The waze api does not support multiple origins and destinations, it only support single origin and a single destination. The output can be multiple routes for the same origin and destination.

[frenck]

This architecture issue is old, stale, and possibly obsolete. Things changed a lot over the years. Additionally, we have been moving to discussions for these architectural discussions.

For that reason, I'm going to close this issue.

../Frenck