* Unused pylint suppression cleanups
* Remove outdated pylint bug references
* Add flake8-noqa config and note to run it every now and then
* Add codes to noqa's
* Unused noqa cleanups
* Moved climate components with tests into platform dirs.
* Updated tests from climate component.
* Moved binary_sensor components with tests into platform dirs.
* Updated tests from binary_sensor component.
* Moved calendar components with tests into platform dirs.
* Updated tests from calendar component.
* Moved camera components with tests into platform dirs.
* Updated tests from camera component.
* Moved cover components with tests into platform dirs.
* Updated tests from cover component.
* Moved device_tracker components with tests into platform dirs.
* Updated tests from device_tracker component.
* Moved fan components with tests into platform dirs.
* Updated tests from fan component.
* Moved geo_location components with tests into platform dirs.
* Updated tests from geo_location component.
* Moved image_processing components with tests into platform dirs.
* Updated tests from image_processing component.
* Moved light components with tests into platform dirs.
* Updated tests from light component.
* Moved lock components with tests into platform dirs.
* Moved media_player components with tests into platform dirs.
* Updated tests from media_player component.
* Moved scene components with tests into platform dirs.
* Moved sensor components with tests into platform dirs.
* Updated tests from sensor component.
* Moved switch components with tests into platform dirs.
* Updated tests from sensor component.
* Moved vacuum components with tests into platform dirs.
* Updated tests from vacuum component.
* Moved weather components with tests into platform dirs.
* Fixed __init__.py files
* Fixes for stuff moved as part of this branch.
* Fix stuff needed to merge with balloob's branch.
* Formatting issues.
* Missing __init__.py files.
* Fix-ups
* Fixup
* Regenerated requirements.
* Linting errors fixed.
* Fixed more broken tests.
* Missing init files.
* Fix broken tests.
* More broken tests
* There seems to be a thread race condition.
I suspect the logger stuff is running in another thread, which means waiting until the aio loop is done is missing the log messages.
Used sleep instead because that allows the logger thread to run. I think the api_streams sensor might not be thread safe.
* Disabled tests, will remove sensor in #22147
* Updated coverage and codeowners.
Thank you 👍
* added zwave lock state from alarm type workaround
* fixed test indents
* more linting fixes
* one more linting fix
* simplified logic
* fixed lint new lines
* fixed merge conflict issue
* fixed definition of _alarm_type_workaround in zwave lock
* 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
* Allow verisure locks to be configured with a default code
* linting fix
* PR feedback
* PR feedback - try harder to prevent future typos
A python mock is a magical thing, and will respond to basicaly
any method you call on it. It's somewhat better to assert against
an explicit variable named 'mock', rather than to assert on the
method name you wanted to mock... could prevent a typo from messing up
tests.
* PR feedback: convert tests to integration-style tests
Set up a fake verisure hub, stub out a _lot_ of calls, then test
after platform discovery and service calls.
It should be noted that we're overriding the `update()` calls in
these tests. This was done to prevent even further mocking of
the verisure hub's responses.
Hopefully, this'll be a foundation for people to write more tests.
* more pr feedback
* Add workaround to use notification state for zwave lock state
There are several zwave lock models out there which do not seem to
update the lock state on non-rf events (see #11934#14632#14534 for
examples) including kwikset smartkey zwave plus locks (which I own).
In these cases it seems that the notifications for non-rf events the
access_control value is updated but not the primary value for the
lock state, which is what is used to set the is_locked property. To
properly have the lock state accurate for all types of notifications
on these models we need to use the access_control field. This commit
adds a workaround for the 4 models reported to exhibit this behavior
so that home-assistant will reliably set the lock state for all
device notifications.
* Add YRD220 as per adrum to workaround list
* Inline constants
