-
-
Notifications
You must be signed in to change notification settings - Fork 32.4k
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
Fix nws forecast coordinators and remove legacy forecast handling #115857
Conversation
Hey there @kamiyo, mind taking a look at this pull request as it has been labeled with an integration ( Code owner commandsCode owners of
|
This is still WIP, but opening early, so that it can be contrasted with #115836. |
@@ -355,7 +322,7 @@ async def test_forecast_service( | |||
|
|||
assert instance.update_observation.call_count == 2 | |||
assert instance.update_forecast.call_count == 2 | |||
assert instance.update_forecast_hourly.call_count == 1 | |||
assert instance.update_forecast_hourly.call_count == 2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Failure in this test on line above shows that CoordinatorWeatherEntity.forecast_coordinators["twice_daily"]
is not called on a time basis, at least in this integration implementation. This PR tries to use the CoordinatorWeatherEntity
methods as much as possible here however.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CoordinatorWeatherEntity
does not have a coordinator.async_add_listener
call in async_added_to_hass
.
core/homeassistant/components/weather/__init__.py
Lines 1116 to 1129 in a8025a8
async def async_added_to_hass(self) -> None: | |
"""When entity is added to hass.""" | |
await super().async_added_to_hass() | |
self.async_on_remove(partial(self._remove_forecast_listener, "daily")) | |
self.async_on_remove(partial(self._remove_forecast_listener, "hourly")) | |
self.async_on_remove(partial(self._remove_forecast_listener, "twice_daily")) | |
def _remove_forecast_listener( | |
self, forecast_type: Literal["daily", "hourly", "twice_daily"] | |
) -> None: | |
"""Remove weather forecast listener.""" | |
if unsub_fn := self.unsub_forecast[forecast_type]: | |
unsub_fn() | |
self.unsub_forecast[forecast_type] = None |
It only occurs if a subscription is performed first:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
coordinator.async_add_listener
is now called in async_added_to_hass
to fix this.
|
||
async def async_update(self) -> None: | ||
"""Update the entity. | ||
|
||
Only used by the generic entity update service. | ||
""" | ||
await self.coordinator.async_request_refresh() | ||
await self.coordinator_forecast_legacy.async_request_refresh() | ||
if self.forecast_coordinators["twice_daily"] is not None: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This sort of behavior would be better in CoordinatorWeatherEntity
in my opinion.
@kamiyo this PR goes further than yours by removing unneeded methods, But now the one test for Another thought is that our custom coordinator override of |
These lines are the cause core/homeassistant/helpers/update_coordinator.py Lines 406 to 407 in 2977ec4
Previously, the forecast update would notify the entity to update it's availability. Now it will never update it's availability if it has consecutive failures in a row. Will remove here for feedback. |
@MatthewFlamm Is this change to What was the original issue you were having with core/tests/components/nws/test_weather.py Line 250 in 8a0acf4
|
@kamiyo, (edited) I had a chat with some core devs on discord on this topic. They did not seem keen to change the core code, but suggested moving the multiple retry behavior inside |
I'll test this locally |
Thanks for testing. This should be mostly done so it is ready for codeowner review. |
I have tested locally and it is working well, so I'm opening for full review. |
My local testing is also stable and working. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are unrelated files in this PR
tests/components/geocaching/pycache/init.cpython-312.pyc.139816749228096
Was having problems with dependencies and pre-commit |
I cannot test live now, but can later. In the meantime, this could be the infamous NWS server temporarily returning junk data problem. I plan on adding in a retry also when the data is blank, and returning an error if the data continues to be blank after the specified total retry time. [Edit: currently we only retry if there is a server error like 502]. This is for upstream. Captured this thought in MatthewFlamm/pynws#194 |
I think we can tag this for 2024.5.1 since the removal of the legacy forecast handling shouldn't be considering a breaking change since that was already removed. Let me know if that sounds right or we should wait for 2024.6.x |
I was under the impression that the legacy forecast handling was totally removed in core, if that is true, then I agree with you that this would be good to land 2024.5.x. There are subtle changes in behavior (availability of the entity, for example), but they are intended to support a bug fix. |
A final live check is that the hourly forecast has been updating nicely, which indicates the problem is indeed fixed. From the same example as I posted above running continuously for a few hours, the hourly forecast is current (as of 9 PM EDT, not CDT). So I'm good with this. Thanks for the help and review! |
…15857) Co-authored-by: J. Nick Koston <[email protected]>
Proposed change
This PR adds listeners to the forecast coordinators to fix issue with the forecast updating. In doing so, the NWS handling of retries was discovered to be brittle to changes in core. It was suggested on discord to put the retry behavior upstream into pynws.
This enables further removal of custom code in the integration. Multiple years tests have been pared down now that we do not need to test custom things in the integration.
Release notes for pynws: https://github.com/MatthewFlamm/pynws/releases/tag/v1.7.0
Type of change
Additional information
Checklist
ruff format homeassistant tests
)If user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
Updated and included derived files by running:
python3 -m script.hassfest
.requirements_all.txt
.Updated by running
python3 -m script.gen_requirements_all
..coveragerc
.To help with the load of incoming pull requests: