* Check if changing TO a color mode
Changing brightness alone does not change work mode, but changing brightness with a color value will keep the light in white mode.
By verifying the new state has color or not, rather than the existing state being in color work mode, the light will change to color correctly.
Tuya interprets HSV as including the brightness in the (v) value (which is generally what that's used for when setting HSV values). The brightness value given by Home Assistant is still used in this case.
* Fix brightness-only turning colour mode to white
This will take into account the case where brightness is the only parameter for both the case of colour mode and white mode.
Tests passed after this change:
* Brightness only (colour mode) ✅
* Brightness only (white mode) ✅
* Colour only (colour mode) ✅
* Colour only (white mode) ✅
* Colour temp only (colour mode) ✅
* Colour temp only (white mode) ✅
* Colour + brightness (colour mode) ✅
* Colour + brightness (white mode) ✅
* Colour temp + brightness (colour mode) ✅
* Colour temp + brightness (white mode) ✅
* Fix code formatting
* display unit of elevation in met config flow
Co-authored-by: lijake8 <lijake8@users.noreply.github.com>
Signed-off-by: Chris Xiao <30990835+chrisx8@users.noreply.github.com>
* use NumberSelector for met config flow
* met remove unused is_metric param
---------
Signed-off-by: Chris Xiao <30990835+chrisx8@users.noreply.github.com>
Co-authored-by: lijake8 <lijake8@users.noreply.github.com>
* typings to make linter happy
* Moving device_class and native_value to init
* remove is_on and use attr_is_on
* Use try_parse_enum for sensor type
* Remove not needed sensor_type
Co-authored-by: epenet <6771947+epenet@users.noreply.github.com>
* Update homeassistant/components/ihc/sensor.py
Co-authored-by: epenet <6771947+epenet@users.noreply.github.com>
---------
Co-authored-by: epenet <6771947+epenet@users.noreply.github.com>
* Remove async_setup from mqtt integration
* Final update common tests
* Related tests init
* Related tests diagnostics
* Related tests config_flow
* Cleanup and correct test
* Keep websockets_api commands in async_setup
* Look up collaborators only when adding new task.
Also fixed a few api call arguments that were incorrect. The `labels`
key should have been a list of strings and the `assignee` key should
have been `assignee_id`.
* Add missing type in test.
* Remove print
* SharkIQ Dep & Codeowner Update
* Update code owners
* Add EU Region Support
* Update Config Flow Tests
* Standardize Region Comparison Strings
* Add Translation Support to Region Selector
* Fix Validation Tests
* Reduce data sharing between ConfigFlow and DataUpdateCoordinator
Instead of fetching device information from the device once in
`ConfigFlow` and then piping it through in `ConfigEntry.data`,
only use as much as needed in `ConfigFlow.async_step_user`, then fetch
again in `AirQCoordinator._async_update_data` if a key is missing.
Additionally, factor `AirQCoordinator` out into a sumbodule.
Add a simple test for `AirQCoordinator.device_info` update.
Positive side effect: `AirQCoordinator.device_info` is
updated explicitly, instead of dumping the entire content of (a fully
compatible) `TypedDict`, retrieved from `aioairq`.
* Remove tests ill-suited to this PR
`test_config_flow.test_duplicate_error` slipped through by mistake,
while `test_coordinator.test_fetch_device_info_on_first_update` may need
a more thoroughly suite of accompanying tests
* Ignore airq/coordinator.py
...newly separated from airq/__init__.py, that's already in this list
* Reorder files alphabetically
* Fix `quirk_class_validator`
Fix the `quirk_class_validator` for quirks with more than 1 module level
* fix black
* Shorten `quirk_cls` in `clss`
Co-authored-by: TheJulianJES <TheJulianJES@users.noreply.github.com>
* Update comment
---------
Co-authored-by: TheJulianJES <TheJulianJES@users.noreply.github.com>