Add Homekit locks support

[philk]

Description:

Adding lock support for Homekit. It's largely a copy and modify from the covers device, but feel free to point out if I missed something.

Future work might include integrating LockLastKnownAction but that would require upstream lock components to report their status in a standard way (feels way out of scope for this).

cc: @cdce8p

I'll can do the minor PR for docs (add to list of supported components) if you're good with the way this looks.

Will depend on #13534 for the naming changes to self._hass and self._entity_id.

Pull request in home-assistant.github.io with documentation (if applicable): home-assistant/home-assistant.io#5093

Checklist:

• The code change is tested and works locally.
• Local tests pass with tox. Your PR cannot be merged unless tests pass

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated in home-assistant.github.io

If the code does not interact with devices:

• Tests have been added to verify that the new code works.

[houndci-bot]

blank line contains whitespace

[cdce8p]

I'm looking forward to adding this to Home Assistant. A small home-assistant.github PR would be great. Left a few comments.

[cdce8p]

Just order it alphabetically, like the rest is already.

[cdce8p]

Don't pass *args. I changed that in #13534 as well. For init as well. It should be enough if additional parameter are passed via **kwargs. That mainly applies to aid.

[cdce8p]

One empty line would be enough here, for consistency.

[cdce8p]

The service doesn't need to be an instance attribute, since it is only used in __init__.

[cdce8p]

Unsecured should be 0.

[cdce8p]

This if statement isn't necessary, since a call from HomeKit implies that it is different. type_cover might not be the best example, since it tries to set a continuous value (and I didn't had the chance to optimize it yet). A good example is type_lights.

[cdce8p]

Print statement

[cdce8p]

Target State can only be set to 0 or 1 from HomeKit. The else clause will never be called.

[cdce8p]

This block needs improvement. HomeKit uses transition states, like opening and closing for covers and I would guess locking and unlocking for locks. To use them, I think the the best way is to use a flag variable (e.g. self.flag_target_state). Initialized in init to false, set to true in the set_state and reset in update_state. You might want to take a look at type_security_systems.

If you have questions about that, I'm happy to help.

[philk]

Unless I'm looking in the wrong place LockCurrentState doesn't have transitional states. The only one I see with opening/closing is CurrentDoorState

[cdce8p]

It isn't really a state. The Home app does its own interpretation when current_state != target_state, at least for a short moment.

[cdce8p]

Please remove that.

[philk]

Sorry for the kind of sloppy initial PR, forget to push all my rebased changes originally. Thanks for the advice on security_system, I used a lot of that and the code feels much cleaner now.

I'll do the _hass, _entity_id, and args* fixes then squash rebase once #13534 is merged. Doc PR is done as well.

[cdce8p]

Just some minor suggestions. Otherwise looking good

[cdce8p]

You don't need an extra line here

[cdce8p]

Same here

[cdce8p]

L71-73: Nobody will see the debug statement.
L85: Shouldn't be necessary.

Maybe that should work:

        hass_state = new_state.state
        if HASS_TO_HOMEKIT.get(hass_state) is not None:
            current_lock_state = HASS_TO_HOMEKIT[hass_state]
            self.char_current_state.set_value(current_lock_state,
                                              should_callback=False)
            _LOGGER.debug('%s: Updated current state to %s (%d)',
                          self._entity_id, hass_state, current_lock_state)
            if not self.flag_target_state:
                self.char_target_state.set_value(current_lock_state,
                                                 should_callback=False)
            self.flag_target_state = False

[philk]

I have that check in case additional STATE_* are added to the lock component in the future, that seems like a reasonable possibility to me? (STATE_JAMMED for instance).

Right on L85, curious why security_system does it now that I think about it. Taking a look at that (and turning up logs in test) did lead me to noticing an exception (that for some reason doesn't cause tests to fail even though they cause it?):

ERROR:homeassistant.core:Error doing job: Future exception was never retrieved
Traceback (most recent call last):
  File "/Users/pkates/.pyenv/versions/3.6.4/lib/python3.6/concurrent/futures/thread.py", line 56, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/Users/pkates/pksrc/home-assistant/homeassistant/components/homekit/type_locks.py", line 84, in update_state
    should_callback=False)
  File "/Users/pkates/.pyenv/versions/3.6.4/envs/hass/lib/python3.6/site-packages/pyhap/characteristic.py", line 150, in set_value
    raise ValueError
ValueError

This happens when Hass sets STATE_UNKNOWN which target_state doesn't support as a valid value.

My first thought was just if state == STATE_UNLOCKED but that feels lazy and brittle, I went with a try/except but I definitely willing to hear alternate opinions.

[cdce8p]

Maybe try: if hass_state in (STATE_UNLOCKED, STATE_LOCKED). I wouldn't agree that it's lazy, just practical and easier to read.

You don't need any debug statements for state not supported. That would get out of hand otherwise.

[cdce8p]

# Set from HomeKit

[cdce8p]

Personally I'm not that big a fan of using HASS_TO_HOMEKIT and HOMEKIT_TO_HASS. It might make it a bit harder to read then an if clause. It works nevertheless so I will leave it up to you what you prefer.

[cdce8p]

I extracted the style changes from #13534 to #13654
If you want, take a quick look at it. It should be ready for merging.

[philk]

Rebased this on #13654 if you notice the commits look slightly weird.

[cdce8p]

Hi, sorry that I haven't replied. I somehow missed that you had already updated the PR.
I did some last changes:

• rebase to resolve a merge conflict (in homekit/const.py)
• Replace if HASS_TO_HOMEKIT.get(hass_state) is None: with a positive if statement. That will make upgrading the type much easier in the future. I will update security_types.py in another PR.

Only waiting for travis before I'm merging this.