Skip to content

Waze travel time last updated fix #146803

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.

Sign up for GitHub

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

Jump to bottom
Draft
wants to merge 9 commits into
base: dev
Choose a base branch
from
Draft

Waze travel time last updated fix #146803

wants to merge 9 commits into from
+309 −268

Conversation

etiennec78
Copy link
Contributor

@etiennec78 etiennec78 commented Jun 14, 2025 •
edited
Loading

Proposed change

Previously, when Waze Travel Time sensor was failing to update (often because of a 503 error), its state was left untouched, but its last_updated value was refreshed.
However, to calculate an ETA in an automation, the sensor value and the time at which it was updated needs to be summed up.
So, with the previous behavior, the ETA was slowly getting off at each failed update.

Now, with the added coordinator, the sensor is left untouched when an update fails, to avoid propagating a wrong last_updated timestamp.

#146798

Type of change

  • Dependency upgrade
  • Bugfix (non-breaking change which fixes an issue)
  • New integration (thank you!)
  • New feature (which adds functionality to an existing integration)
  • Deprecation (breaking change to happen in the future)
  • Breaking change (fix/feature causing existing functionality to break)
  • Code quality improvements to existing code or addition of tests

Additional information

Checklist

  • The code change is tested and works locally.
  • Local tests pass. Your PR cannot be merged unless tests pass
  • There is no commented out code in this PR.
  • I have followed the development checklist
  • I have followed the perfect PR recommendations
  • The code has been formatted using Ruff (ruff format homeassistant tests)
  • Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

If the code communicates with devices, web services, or third-party tools:

  • The manifest file has all fields filled out correctly.
    Updated and included derived files by running: python3 -m script.hassfest.
  • New or updated dependencies have been added to requirements_all.txt.
    Updated by running python3 -m script.gen_requirements_all.
  • For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.

To help with the load of incoming pull requests:

etiennec78 added 3 commits June 9, 2025 20:14
@etiennec78
Add coordinator to waze_travel_time
a3ce0cf
@etiennec78
Simplified types
55c9a73
@etiennec78
Prevent Waze sensor from reverting to 'unknown' on update failure
f6faa13 
When the Waze Travel Time sensor fails to fetch new data, it currently reverts to 'unknown'.
This change retains the last known value instead, as it still provides a coherent estimation when combined with the sensor's last_updated attribute.
@home-assistant
Copy link

Hey there @eifinger, mind taking a look at this pull request as it has been labeled with an integration (waze_travel_time) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of waze_travel_time can trigger bot actions by commenting:

  • @home-assistant close Closes the pull request.
  • @home-assistant rename Awesome new title Renames the pull request.
  • @home-assistant reopen Reopen the pull request.
  • @home-assistant unassign waze_travel_time Removes the current integration label and assignees on the pull request, add the integration domain after the command.
  • @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the pull request.
  • @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the pull request.

@etiennec78 etiennec78 marked this pull request as ready for review June 14, 2025 13:21
@etiennec78 etiennec78 marked this pull request as draft June 15, 2025 14:25
@etiennec78 etiennec78 marked this pull request as ready for review June 17, 2025 21:58
eifinger
eifinger suggested changes Jun 26, 2025
View reviewed changes
Copy link
Contributor

@eifinger eifinger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for this big investment and huge amount of work. There is currently a lot going on and its easier to review and approve when we split this up. Here is my suggestion for a list of PRs:

  1. Make async_get_travel_times return [] instead of None
  2. Remove _LOGGER.warning statements inside async_get_travel_times and catch the error conditions where the function is used
  3. Introduce a coordinator

homeassistant/components/waze_travel_time/coordinator.py

SCAN_INTERVAL = timedelta(minutes=5)

PARALLEL_UPDATES = 1
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This has no effect here.
Since we are using a semaphore this is not needed anymore anyways.

For history see #100191 and #101514

homeassistant/components/waze_travel_time/coordinator.py
destination_coordinates = find_coordinates(self.hass, self._destination)

if (
self.config_entry is None
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How could it happen that config_entry is None?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't remember why I've put that there, but you're right, it seems pointless. I'll remove it.

homeassistant/components/waze_travel_time/coordinator.py
route=route.name,
)

await asyncio.sleep(SECONDS_BETWEEN_API_CALLS)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This has to happen before releasing the semaphore on line 134

homeassistant/components/waze_travel_time/coordinator.py
SECONDS_BETWEEN_API_CALLS = 0.5


class WazeTravelTimeData(TypedDict):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why a TypedDict instead of a dataclass?

Copy link
Contributor Author

@etiennec78 etiennec78 Jun 27, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I took HERE as inspiration (which was using TypedDicts), but I'll try to restore the dataclass in the new PRs to avoid unnecessary changes

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I remember again why a TypedDict is better. This way you can use the key attribute in SensorDescrptions and you don't have to write custom code for native_value etc:

core/homeassistant/components/here_travel_time/sensor.py

Lines 53 to 61 in c7b2f23

SensorEntityDescription(
translation_key="duration",
icon=ICONS.get(travel_mode, ICON_CAR),
key=ATTR_DURATION,
state_class=SensorStateClass.MEASUREMENT,
device_class=SensorDeviceClass.DURATION,
native_unit_of_measurement=UnitOfTime.SECONDS,
suggested_unit_of_measurement=UnitOfTime.MINUTES,
),

homeassistant/components/waze_travel_time/sensor.py
@callback
def _handle_coordinator_update(self) -> None:
"""Handle updated data from the coordinator."""
if self.coordinator.data["duration"] is not None:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if self.coordinator.data["duration"] is not None:
if self.coordinator.data is not None:

The coordinator automatically handles failed updates. We do not need to set a custom object with none values. Or is this the only way to achieve your desired behavior? If yes I have to take a closer look

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had put this as I was returning a WazeTravelTimeData object filled with None at line 89 of the coordinator, but since you suggested to raise UpdateFailed instead, we can remove that

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can self.coordinator.data even be None here ?
The coordinator calls this function only after successfully fetching data.
Here is more info

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The BaseCoordinatorEntity doesn't check this at all:

core/homeassistant/helpers/update_coordinator.py

Lines 558 to 561 in c7b2f23

@callback
def _handle_coordinator_update(self) -> None:
"""Handle updated data from the coordinator."""
self.async_write_ha_state()

Used in combination with

core/homeassistant/helpers/update_coordinator.py

Lines 590 to 592 in c7b2f23

def available(self) -> bool:
"""Return if entity is available."""
return self.coordinator.last_update_success

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will however not do what you want to do, as in instead of becoming "unavailable" continue to show the latest update/state.
When you open your PR we should ask the core team if your wanted behavior would be accepted from a UX point of view.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The BaseCoordinatorEntity doesn't check this at all:

Thanks for the explanation, it's clearer for me now 👍

When you open your PR we should ask the core team if your wanted behavior would be accepted from a UX point of view.

Of course ! But in my opinion this is the behavior that makes the most sense for a travel time integration, so it shouldn't be too hard to convince them.

@etiennec78 etiennec78 marked this pull request as draft June 27, 2025 15:11
@etiennec78
Copy link
Contributor Author

Thanks for all your suggestions!
I will split this PR as you requested and apply your changes.
For now, I'll keep this PR open in case I have any more questions.

@etiennec78
Copy link
Contributor Author

etiennec78 commented Jul 1, 2025 •
edited
Loading

I think I'll make the following PRs :

  1. Use a Typed Dict to store waze data
  2. Add a coordinator
  3. Catch errors with UpdateFailed
  4. Add a custom available function to avoid reporting "unknown"
  5. Split attributes into distinct sensors

I will start tomorrow

@eifinger
Copy link
Contributor

eifinger commented Jul 1, 2025

I think I'll make the following PRs :

1. Use a Typed Dict to store waze data

2. Add a coordinator

3. Catch errors with UpdateFailed

4. Add a custom available function to avoid reporting "unknown"

5. Split attributes into distinct sensors

I will start tomorrow

I am missing the changes to async_get_travel_times. Where do you want to put them?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@eifinger eifinger eifinger requested changes

Copilot code review Copilot Awaiting requested review from Copilot Copilot will automatically review once the pull request is marked ready for review

At least 1 approving review is required to merge this pull request.

Assignees
No one assigned
Labels
bugfix cla-signed integration: waze_travel_time Quality Scale: No score
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Waze Travel Time last_updated attribute is not reliable
2 participants
@etiennec78 @eifinger