Releases: albaintor/homeassistant_electrolux_status
Releases · albaintor/homeassistant_electrolux_status
Fixed modification of target temperature
Development release
v2.0.8 Bump manifest*
Fixes from previous release and others
Finer alerts and fix
Various fixes : simplified entity names, icons for some commands, time to end, setup error
Fixed setup failures
Fixed setup failure when unknown capabilities are reported by the API
Fixes
Added an exclusion list
Added an exclusion list for useless sensors (never updated with fixed or irrelevant values)
v2.0.1
New major release V2
Many thanks to @kingy444 who realized all of these major improvements
Merged from #61
- Rename across the board to Electrolux Status for consistency and clear identification
- Complete code refactor to conform to a core integration including applying pylint, ruff and typehinting throughout
- Reduce code footprint overall, splitting into smaller modules and reusing code snippets
- Use HomeAssistant aiohttp session rather than spinning up our own
- Implement Store for token within the session, allowing infinite restarts and refresh of token rather than re-authentication every 12 hours
- Improve logging for consistency
- Nested elements no longer use root and element seperately, now using root/element as key to remove clashes in device types
- Fix recursive lookup for nested elements (Fridge / Freezer)
- Implement dataclass model for ElectroluxDevice to improve code quality
- Ability to override capability on ElectroluxDevice based on the model / type
- Move catalog to its own module(s) and out of const.py
- Enhance config flow
- add ability to subscribe/unsubscribe to alerts
- add change password / language
- only one instance per account
- Add diagnostics support
- Add sample directory (suggest expanding this with more device types (diagnostics)
- Add Translations for supported languages. (These need to be regenerated when strings change)
- Add support for constant and alert types
- cloud_push over cloud_poll
- Minimise default entities to most useful.
- bump upstream dependancy
- 'Sister' entities capabiity for devices that have their status linked to another (ice maker on/off control and state are different entities, this allows a toggle rather than a button)
- Mapping of values from API to user state
- Mapping of string values to running states for true binary_sensor to work
- Button creation is more dynamic and controllable
- Device type can be forced via the catalog type (simply setting device_class in catalog can chnage the entity type created)