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
Do not block on reolink firmware check fail #88797
Do not block on reolink firmware check fail #88797
Conversation
Could this be added to the 2023.3.0 milestone? |
@@ -106,9 +106,10 @@ async def async_check_firmware_update(): | |||
) | |||
# Fetch initial data so we have data when entities subscribe | |||
try: | |||
# If camera WAN blocked, firmware check fails, do not prevent setup |
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.
Can we check this before we activate the firmware coordinator?
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.
Not really, the only way to check if WAN is blocked is just try out a command that needs WAN such as the check_new_firmware command and the API will respond with "rspCode" : -17, "detail" : "rcv failed",
.
However I have seen this rcv failed
error before, also when you have a bad wifi connection to the camera or other issues.
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.
Ok. It's just a bit annoying that we need to log an error for a case where users have deliberately blocked WAN access.
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.
@MartinHjelmare I could remove the coordinator initial fetch from init.py and add a initial fetch to async_added_to_hass in the update entity. That way when the user disables the update entity because they blocked WAN, no more errors are logged.
What do you think of that?
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.
The coordinator is meant to fetch data for more than a single entity. Fetching data from the entity isn't in line with the coordinator architecture. If there's a single entity for the data source we don't really need a coordinator.
Do not block on firmware check fail
Breaking change
Proposed change
If Reolink camera WAN blocked (only local control, for privacy reasons), online firmware check will of course fail and raise a API error wich will be caught and re-raised as UpdateFailed and the entity will be marked as unavailable.
However this would prevent the integration from setting up since you would end up in a loop of
ConfigEntryNotReady
.This PR will make sure the
UpdateFailed
will not result in aConfigEntryNotReady
for the online firmware check.Type of change
Additional information
Checklist
black --fast 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: