Add Avri config flow #34288
Add Avri config flow #34288
Conversation
|
I checked the |
|
@timvancann Thanks for adding the config flow. Config flows require test coverage. There is a helper script that can help you get started: |
|
@bdraco Thanks for the comment. I'll pick it up and implement the tests soon! |
timvancann
force-pushed
the
tvc-avri-config-flow
branch
from
c264c76
to
dc4f38c
Compare
|
@bdraco I added some useful tests, however |
Co-authored-by: J. Nick Koston <nick@koston.org>
Co-authored-by: J. Nick Koston <nick@koston.org>
Co-authored-by: J. Nick Koston <nick@koston.org>
| if user_input[CONF_HOUSE_NUMBER] <= 0: | ||
| errors[CONF_HOUSE_NUMBER] = "invalid_house_number" | ||
| return await self._show_setup_form(errors) | ||
| if not pycountry.countries.get(alpha_2=user_input[CONF_COUNTRY_CODE]): |
There was a problem hiding this comment.
It looks like this look up might do I/O if the data hasn't been loaded yet. There's a lazy load mechanism in the library.
We're not allowed to do blocking I/O inside the event loop, ie inside coroutines. We need to schedule I/O on the executor thread pool with hass.async_add_executor_job.
|
|
||
| VERSION = 1 | ||
|
|
||
| async def _show_setup_form(self, errors=None): |
There was a problem hiding this comment.
There's no await inside this function so it doesn't need to be a coroutine. We prefer callbacks if a coroutine isn't needed since awaiting a coroutine has an overhead cost.
| return self.async_create_entry( | ||
| title=unique_id, | ||
| data={ | ||
| CONF_ID: unique_id, |
There was a problem hiding this comment.
We have access to the unique_id of the config entry via entry.unique_id. We don't need to store it separately.
| country_code=config[CONF_COUNTRY_CODE], | ||
| ) | ||
| client = hass.data[DOMAIN][entry.entry_id] | ||
| integration_id = entry.data[CONF_ID] | ||
|
|
||
| try: | ||
| each_upcoming = client.upcoming_of_each() |
There was a problem hiding this comment.
If this does I/O it must be scheduled on the executor thread pool.
|
|
||
| async def test_form(hass): | ||
| """Test we get the form.""" | ||
| await setup.async_setup_component(hass, "avri", {}) |
There was a problem hiding this comment.
I don't think we need to set up the avri component here.
| await self.async_set_unique_id(unique_id) | ||
| self._abort_if_unique_id_configured() | ||
|
|
||
| return self.async_create_entry( |
There was a problem hiding this comment.
We should check that we can connect with the avri client before creating the entry.
I see now that there's no authentication. We might not have to check with the client of we're sure that the checks above are enough. Could the user somehow enter a non supported zip code or similar?
| assert result["errors"] == {} | ||
|
|
||
| with patch( | ||
| "homeassistant.components.avri.async_setup_entry", return_value=True, |
There was a problem hiding this comment.
We also need to patch all I/O of the library that happens in the config flow.
Breaking change
The Avri component must now be setup using the Integrations page in the UI. Remove the integration from
configuration.yamland re-add it in the UI.Proposed change
Implements the Config Flow for the Avri integration.
Type of change
The format of the unique id of the entities changes. Orphaned entities (created by manually adding the integration to the
configuration.yaml) must be removed manually. This may be accomplished by nativating to theConfiguration->Entitiesmenu from the Home Assitant application and searching forsensor.avri. Removed any entities found.Example entry for
configuration.yaml:# Example configuration.yamlAdditional 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.The integration reached or maintains the following Integration Quality Scale: