-
-
Notifications
You must be signed in to change notification settings - Fork 34.2k
Record Overkiz quality scale #133719
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
base: dev
Are you sure you want to change the base?
Record Overkiz quality scale #133719
Conversation
Hey there @vlebourl, @tetienne, @nyroDev, @Tronix117, @alexfp14, mind taking a look at this pull request as it has been labeled with an integration ( Code owner commandsCode owners of
|
0ac1fd5
to
ad803ee
Compare
ad803ee
to
5f89d9e
Compare
@@ -0,0 +1,68 @@ | |||
rules: |
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.
Why is the update_interval of the coordinator a parameter if you only create 1, and it is a static value? I think you could even optimize this to have the coordinator figure out what update_interval it should poll at (this way you don't need that extra set_update_interval
function to be publicly accessible) (it would also not surprise me if i discover later that this is used in more ways)
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.
I can move the initial logic to the coordinator, and change set_update_interval
to a private setter? (even though still the same in Python). Would that be better? Personally I don't have any preference.
The reason we do set it in __init__
is because we do know if the user has the local API configured, which we don't know at the moment in the coordinator.
if api_type == APIType.LOCAL: |
@@ -0,0 +1,68 @@ | |||
rules: |
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.
alarm_control_panel.py
-> all the *args
of the entity description are just a string, so I am not sure why they can be typed as a list
.
Also, I am wondering if it would be possible to instead use a Callable[[<the type of the executor>], None]
as parameter and just put in a lambda instead
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.
For alarm_control_panel all devices only use a single argument (and a string). Overkiz command execution supports multiple comands args, and thus you can pass a list as well.
docs-removal-instructions: done | ||
test-before-setup: done | ||
docs-high-level-description: done | ||
config-flow-test-coverage: done |
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.
test_form_only_cloud_supported
-> What is this testing? We don't assert the last result. Also, stale docstring
docs-removal-instructions: done | ||
test-before-setup: done | ||
docs-high-level-description: done | ||
config-flow-test-coverage: done |
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.
test_form_local_happy_flow
-> Let's also test the end result + stale docstring
docs-removal-instructions: done | ||
test-before-setup: done | ||
docs-high-level-description: done | ||
config-flow-test-coverage: done |
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.
test_form_invalid_auth_cloud
+ others -> Let's have every test end in either ABORT or CREATE_ENTRY to also test the flow is able to recover from an error
docs-removal-instructions: done | ||
test-before-setup: done | ||
docs-high-level-description: done | ||
config-flow-test-coverage: done |
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.
test_dhcp_flow
-> Also test unique id
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.
same for the zeroconf
docs-installation-parameters: done | ||
integration-owner: done | ||
parallel-updates: todo | ||
test-coverage: todo |
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.
in test_init.py, let's replace assert await async_setup_component(hass, DOMAIN, {})
with the hass.config_entries.async_setup()
one
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.
Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍 |
There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days. |
There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days. |
Proposed change
Bronze
config-flow
- Integration needs to be able to be set up via the UIdata_description
to give context to fieldsConfigEntry.data
andConfigEntry.options
correctlytest-before-configure
- Test a connection in the config flowcore/homeassistant/components/overkiz/config_flow.py
Line 64 in a3febc4
unique-config-entry
- Don't allow the same device or service to be able to be set up twicecore/homeassistant/components/overkiz/config_flow.py
Line 79 in a3febc4
core/homeassistant/components/overkiz/config_flow.py
Line 186 in a3febc4
config-flow-test-coverage
- Full test coverage for the config flowruntime-data
- Use ConfigEntry.runtime_data to store runtime datacore/homeassistant/components/overkiz/__init__.py
Lines 129 to 131 in 619aed3
test-before-setup
- Check during integration initialization if we are able to set it up correctlycore/homeassistant/components/overkiz/__init__.py
Lines 82 to 83 in a3febc4
appropriate-polling
- If it's a polling integration, set an appropriate polling intervalcore/homeassistant/components/overkiz/const.py
Lines 46 to 47 in a3febc4
entity-unique-id
- Entities have a unique IDcore/homeassistant/components/overkiz/entity.py
Line 39 in a3febc4
has-entity-name
- Entities use has_entity_name = Truecore/homeassistant/components/overkiz/entity.py
Line 22 in a3febc4
entity-event-setup
- Entities event setupHandled in coordinator.py
dependency-transparency
- Dependency transparencyhttps://github.com/iMicknl/python-overkiz-api
action-setup
- Service actions are registered in async_setupcommon-modules
- Place common patterns in common modulescoordinator.py, entity.py
docs-high-level-description
- The documentation includes a high-level description of the integration brand, product, or servicehttps://www.home-assistant.io/integrations/overkiz/
docs-installation-instructions
- The documentation provides step-by-step installation instructions for the integration, including, if needed, prerequisitesdocs-removal-instructions
- The documentation provides removal instructionshttps://www.home-assistant.io/integrations/overkiz#removing-the-integration
docs-actions
- The documentation describes the provided service actions that can be usedbrands
- Has branding assets available for the integrationSilver
config-entry-unloading
- Support config entry unloadingcore/homeassistant/components/overkiz/__init__.py
Line 168 in bbb5f9e
log-when-unavailable
- If internet/device/service is unavailable, log once when unavailable and once when back connectedcore/homeassistant/components/overkiz/coordinator.py
Lines 75 to 84 in bbb5f9e
entity-unavailable
- Mark entity unavailable if appropriatecore/homeassistant/components/overkiz/coordinator.py
Lines 75 to 84 in bbb5f9e
core/homeassistant/components/overkiz/entity.py
Line 38 in bbb5f9e
action-exceptions
- Service actions raise exceptions when encountering failuresreauthentication-flow
- Reauthentication flowcore/homeassistant/components/overkiz/config_flow.py
Line 318 in bbb5f9e
parallel-updates
- Set Parallel updatestest-coverage
- Above 95% test coverage for all integration modulesintegration-owner
- Has an integration ownerdocs-installation-parameters
- The documentation describes all integration installation parametershttps://www.home-assistant.io/integrations/overkiz#configuration
docs-configuration-parameters
- The documentation describes all integration configuration optionsGold
entity-translations
- Entities have translated namesentity-device-class
- Entities use device classes where possibledevices
- The integration creates devicescore/homeassistant/components/overkiz/entity.py
Line 90 in bbb5f9e
entity-category
- Entities are assigned an appropriate EntityCategoryentity-disabled-by-default
- Integration disables less popular (or noisy) entitiescore/homeassistant/components/overkiz/sensor.py
Line 233 in bbb5f9e
discovery
- Can be discoveredcore/homeassistant/components/overkiz/config_flow.py
Line 286 in bbb5f9e
stale-devices
- Clean up stale devicesdiagnostics
- Implements diagnosticscore/homeassistant/components/overkiz/diagnostics.py
Line 17 in bbb5f9e
exception-translations
- Exception messages are translatableicon-translations
- Icon translationsreconfiguration-flow
- Integrations should have a reconfigure flowdynamic-devices
- Devices added after integration setupdiscovery-update-info
- Integration uses discovery info to update network informationcore/homeassistant/components/overkiz/config_flow.py
Lines 290 to 292 in bbb5f9e
repair-issues
- Repair issues and repair flows are used when user intervention is neededdocs-use-cases
- The documentation describes use cases to illustrate how this integration can be useddocs-supported-devices
- The documentation describes known supported / unsupported devicesdocs-supported-functions
- The documentation describes the supported functionality, including entities, and platformsdocs-data-update
- The documentation describes how data is updateddocs-known-limitations
- The documentation describes known limitations of the integration (not to be confused with bugs)docs-troubleshooting
- The documentation provides troubleshooting informationdocs-examples
- The documentation provides automation examples the user can use.Platinum
async-dependency
- Dependency is asynccore/homeassistant/components/overkiz/__init__.py
Lines 86 to 87 in 619aed3
inject-websession
- The integration dependency supports passing in a websessioncore/homeassistant/components/overkiz/__init__.py
Line 238 in 619aed3
core/homeassistant/components/overkiz/__init__.py
Lines 255 to 259 in 619aed3
strict-typing
- Strict typingcore/.strict-typing
Line 364 in 619aed3
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
.To help with the load of incoming pull requests: