Skip to content

0.84.3#19391

Merged
balloob merged 5 commits intomasterfrom
rc
Dec 17, 2018
Merged

0.84.3#19391
balloob merged 5 commits intomasterfrom
rc

Conversation

@balloob
Copy link
Copy Markdown
Member

@balloob balloob commented Dec 17, 2018

Frontend:

balloob and others added 5 commits December 17, 2018 10:21
* 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
* Fixed manual alarm control panel restore state

* Revert "Fixed manual alarm control panel restore state"

This reverts commit 61c9faf.

* Fixed manual alarm control panel's state restore
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.
@balloob balloob requested review from a team as code owners December 17, 2018 09:50
@homeassistant homeassistant added cla-signed integration: config integration: frontend core merging-to-master This PR is merging into the master branch and should probably change the branch to `dev`. platform: alarm_control_panel.manual labels Dec 17, 2018
@ghost ghost assigned balloob Dec 17, 2018
@ghost ghost added the in progress label Dec 17, 2018
@balloob balloob merged commit f55ab9d into master Dec 17, 2018
@ghost ghost removed the in progress label Dec 17, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cla-signed core integration: config integration: frontend integration: manual integration: zwave merging-to-master This PR is merging into the master branch and should probably change the branch to `dev`.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants