Validate light supported_color_modes#48247
Conversation
| ) | ||
| except vol.Error as ex: | ||
| _LOGGER.warning("Light %s: %s", self.entity_id, ex) | ||
| supported_color_modes = {COLOR_MODE_ONOFF} |
There was a problem hiding this comment.
Instead of this, should the state update be rejected?
| supported_color_modes | ||
| ) | ||
| except vol.Error as ex: | ||
| _LOGGER.warning("Light %s: %s", self.entity_id, ex) |
There was a problem hiding this comment.
This may spam a lot, should the warning be limited to once per entity?
| ) | ||
| supported_color_modes = self._light_internal_supported_color_modes | ||
| try: | ||
| supported_color_modes = validate_supported_color_modes( |
There was a problem hiding this comment.
We don't validate attributes at runtime as it can get too costly to do it for everything. Instead I once had this idea #37663
There was a problem hiding this comment.
In this particular case, it's a capability attribute which should rarely change, if ever.
If the attribute has not changed, there's no need to re-validate.
In #37663 it's mentioned that:
It's up to each integration to implement a validator platform.
So it's opt-in per integration? Can't it be done in base components instead?
|
Closed in favor of #48836 |
Proposed change
Validate light supported_color_modes and print a warning if the validation failed
Type of change
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:
To help with the load of incoming pull requests: