* WeMo - Various fixes and improvements
Various fixes & improvements to the WeMo components, including:
-- Fixes to rediscovery
-- New reset filter service for the WeMo Humidifier
-- Switched the remainder of the WeMo components to async IO
-- Removed any remaining IO in entity properties and moved them to the polling/subscription update process
* WeMo - Fix pywemo version and remove test code from WeMo fan component
* WeMo Humidifier - Add services.yaml entry for reset filter life service
* WeMo - Update binary_sensor component to use asyncio
* WeMo - Add available property to binary_sensor component
* WeMo - Fixed line length issue
* WeMo - Fix issue with discovering the same device multiple times
* WeMo - Fix for the fix for discovering devices multiple times
* WeMo - Fix long lines
* WeMo - Fixes from code review
* WeMo - Breaking Change - entity_ids is now required on wemo_set_humidity
* WeMo - Code review fixes
* WeMo - Code review fixes
* WeMo - Code review fixes
* complete(?)
* fixed linting
* update requirements
* added to coveragerc
* fixed linting
* added ability to set custom name
* fixed linting
* added filter
* spacing
* Added list of possible fuels
* Minor updates
In HomeAssistant 0.84.3, the range filter would not work due to the unexpected precision filter parameter.
The default range scheme has been edited to remove the unexpected precision parameter.
Verified and tested.
* Adjusted api for new library version.
* Added support for output monitoring. Added initial status check for the alarm.
* Added default values to the configuration as per review notes.
* added gtt sensor
* removed trailing space
* updated requirements_all
* fixed two errors in the code style
* fixed imperative in docstring
* disabled pylint false positive
* fixed description on top of the file
* added files to .coveragerc
* fixes
* linting
* fixed linting 👍
* left a trailing space, now it's gone.
* fix
* Provide charging indicator for mychevy
This expands the mychevy sensor for the battery level to also know if
the system is currently charging to get the correct icon.
* address review feedback
When editing an entity in the frontend dialog, pressing save causes a "save failed: Entity is already registered" error. This is because the frontend always sets `name` and `new_entity_id` in the websocket command even if they haven't been changed. This adds a check that the `new_entity_id` is actually different from `entity_id` before erroring that the `new_entity_id` is already registered.
* Fixed manual alarm control panel restore state
* Revert "Fixed manual alarm control panel restore state"
This reverts commit 61c9faf434.
* Fixed manual alarm control panel's state restore
* Set lock status correctly for Schlage BE469 Z-Wave locks
PR #17386 attempted to improve the state of z-wave lock tracking for
some problematic models. However, it operated under a flawed
assumptions. Namely, that we can always trust `self.values` to have
fresh data, and that the Schlage BE469 sends alarm reports after every
lock event. We can't trust `self.values`, and the Schlage is very
broken. :)
When we receive a notification from the driver about a state change,
we call `update_properties` - but we can (and do!) have _stale_
properties left over from previous updates. #17386 really works best
if you start from a clean slate each time. However, `update_properties`
is called on every value update, and we don't get a reason why.
Moreover, values that weren't just refreshed are not removed. So blindly
looking at something like `self.values.access_control` when deciding to
apply a workaround is not going to always be correct - it may or may not
be, depending on what happened in the past.
For the sad case of the BE469, here are the Z-Wave events that happen
under various circumstances:
RF Lock / Unlock:
- Send: door lock command set
- Receive: door lock report
- Send: door lock command get
- Receive: door lock report
Manual lock / Unlock:
- Receive: alarm
- Send: door lock command get
- Receive: door lock report
Keypad lock / Unlock:
- Receive: alarm
- Send: door lock command get
- Receive: door lock report
Thus, this PR introduces yet another work around - we track the current
and last z-wave command that the driver saw, and make assumptions based
on the sequence of events. This seems to be the most reliable way to go
- simply asking the driver to refresh various states doesn't clear out
alarms the way you would expect; this model doesn't support the access
control logging commands; and trying to manually clear out alarm state
when calling RF lock/unlock was tricky.
The lock state, when the z-wave network restarts, may look out of sync
for a few minutes. However, after the full network restart is complete,
everything looks good in my testing.
* Fix linter
Adam Belebczuk
Fabian Affolter
Otto Winter
Eliseo Martelli
timkoers
Morten Lüneborg
Rohan Kapoor
Paulus Schoutsen
John Mihalic
Nick Horvath
Marius Retegan
c-soft
jumpkick
Erik Eriksson
Sean Dague
Fredrik Erlandsson
Paulus Schoutsen
Glen Takahashi
liaanvdm
Andrew Hayworth
Pascal Vizeli
Aaron Bach
Anders Melchiorsen
PeteBa