Add support for Sense Keypad

drinfernoo commented 2 years ago

This PR adds support for only the Sense Keypad, when using this firmware, flashed to a Sense V1 bridge dongle, via the WyzeSenseUpgrade project. It is (or was?) also possible to dump this firmware for yourself by following these steps by @HclX.

I would like to also support the V2 leak and climate sensors (like #61 attempted to do), but I don't have them available to test with, so I've excluded them from this PR in particular. I have done considerable refactoring in an effort to make them trivial to add support for, if that opportunity ever comes, but have stashed their code away for now.

In addition to simply supporting them, this adds full support for MQTT auto-discovery by Home Assistant:

Exposes an alarm_control_panel entity for the panel itself
Two-way control from keypad <-> Home Assistant for all states (except triggered, which can only be controlled from the physical keypad. It is detected properly inside of Home Assistant when activated on the keypad.)
Does not hold PIN entries in MQTT broker longer than necessary, unless desired
Supports "local" and "remote" validation as described in the MQTT Alarm Control Panel docs; more on that later.
Exposes a binary_sensor for motion detection
Exposes sensor entities for battery level and signal strength

Keypad devices can be configured in sensors.yaml (and are added automatically when paired, defaults shown below):

'ABCDEFGH':
  class: alarm_control_panel
  pin: '0000'
  expose_pin: false
  arm_required: true
  disarm_required: true
  invert_state: false
  name: Wyze Sense ABCDEFGH
  sw_version: 48

class must be alarm_control_panel
arm_required works as described here
disarm_required works as described here
invert_state acts on the motion detection, similarly to the current behavior of regular sensors
pin must be a string of digits, but can be any length. Setting this to 'REMOTE_CODE' will allow Home Assistant to send any PIN to wyzesense2mqtt for validation.
expose_pin determines whether or not to expose the last PIN as an entity and in the MQTT broker

This PR, though containing significant refactoring, should not affect the behavior of other sensors (either already paired ones, or ones added in the future).

drinfernoo commented 2 years ago

~~Ah, I realized I need to update README.md accordingly for the configuration options. I'll do that before this gets merged.~~

EDIT: Done :+1: I did link to @AK5nowman's WyzeSenseUpgrade project... I hope that's ok 😅

drinfernoo commented 2 years ago

Though this is mostly all working, I have a couple more features I'd like to try to get working, so I'm converting it to a draft.

drinfernoo commented 2 years ago

My latest commit (17ff5d8) sets this up to follow the state delay timings as described here: https://www.home-assistant.io/integrations/manual/#state-machine

Unfortunately, I'm having an issue where the state is not updated quickly enough, because the process are being blocked by time.sleep(...). Hopefully one of you guys (@AK5nowman or @raetha) can see a smarter way to do this than I'm coming up with 😅

That being said, reverting back to 5b98a7e, and this was pretty stable from my testing. I wanted to try and implement the delay timings so that (for example) the keypad wouldn't arm immediately when pressed, giving some grace period while walking out the door, for example.

drinfernoo commented 2 years ago

Thanks for the feedback @raetha! Unfortunately I don't feel like this one's going to be ready to merge until I can figure out the race condition in my delay process... Seems like being able to delay arming and triggering is a big deal that would be broken/nonexistent if I merged now 😫

raetha commented 2 years ago

@drinfernoo, are things mostly working? Without the right hardware I can't really help on the race condition, but if it's like 90% of the way there, you could update the readme saying that piece is a work in progress and has some issues, then merge. Maybe someone else would even see it and be able to help with the race condition aspect.

As a side question, just because I haven't been able to keep up reliably, what is the actual issue you are seeing, maybe I can spot something, even if I can't test.

drinfernoo commented 2 years ago

Basically, the only thing that's not working, as far as I can tell, is "canceling" from a "pending" state.

What happens is that if the system is armed, and a delay_time is set (60 seconds by default), this makes it so that when the keypad gets the message to go into "triggered", it first transitions to a "pending" state for delay_time seconds. During this time, it would be expected that you could disarm (or re-arm) the system, and it would simply cancel out of this "pending" state, without triggering the alarm.

The bit of code I have for this (https://github.com/drinfernoo/wyzesense2mqtt/blob/1d0b7f7347b517008ef16a8487d9285c157df6ac/wyzesense2mqtt/wyzesense2mqtt.py#L640) uses the new method I added (mqtt_simple_subscribe), which leverages a blocking subscribe.simple(...) call to repeatedly check if the topic was set to a "cancelable" state in the meantime. Unfortunately, what I'm seeing is that the topic never gets set that way... until after the "pending" state has expired, and the alarm has been triggered for trigger_time seconds (at https://github.com/drinfernoo/wyzesense2mqtt/blob/1d0b7f7347b517008ef16a8487d9285c157df6ac/wyzesense2mqtt/wyzesense2mqtt.py#L735). Only at that point does the state change to whatever would've been desired.

For the time being, this means there isn't a way to disarm the system before the alarm gets triggered, like when returning home (where you might expect to have a grace period to do so), for example. Writing this out, I guess there is also no mechanism at this point to cancel out of the "triggered" state either, so once triggered, it will stay that way for the specified trigger_time (120 seconds by default).

drinfernoo commented 2 years ago

I'm planning on testing this out during the week, in order to integrate it into Alarmo for Home Assistant. There is a Z2M -> Alarmo blueprint (by the author of Alarmo, in fact), and I should be able to get this to work with that (or a similar) blueprint, so that we can use the physical keypad with Alarmo for better integration into Home Assistant.

However, I still haven't really been able to figure out how to effectively "cancel out" of a pending or triggered state... which means it won't correctly send those states to Alarmo when appropriate either.

@AK5nowman or @raetha, any ideas on that?

drinfernoo commented 2 years ago

After playing with Alarmo for a couple days, I think this needs a bit of rework. While this is mostly functional (save for the race condition I still haven't nailed down when trying to cancel out of a pending state before triggering) as an MQTT alarm_control_panel in Home Assistant, Alarmo seems to be a very good way to get much of the functionality implemented here integrated into Home Assistant in a simple and user-friendly way.

Alarmo allows to set MQTT topics which it will subscribe and publish to, which allow it to interface with an external keypad or other MQTT source. This should actually be mostly possible with the current changes, but I think it would be simpler to allow Alarmo to verify codes, determine states, etc... So I'm going to look into reworking this to respond in a way that Alarmo can easily parse.

Ideally, this will make it easy to integrate into Alarmo, Home Assistant (without Alarmo), or other home automation systems, with minimal configuration on any side.

kalyway101 commented 2 years ago

After playing with Alarmo for a couple days, I think this needs a bit of rework. While this is mostly functional (save for the race condition I still haven't nailed down when trying to cancel out of a pending state before triggering) as an MQTT.....

I don't want to add unnecessary comments to this discussion, but I just had to say, thank you so much for your work on this! Especially when most others have given up on attempting to implement future Wyze products/services (I don't blame them) into Smart Home Hubs such as Home Assistant.

drinfernoo commented 2 years ago

Thanks @kalyway101! I honestly ended up with the HMS "starter kit" because I had a few of the old Wyze Sense sensors that went bad, and that was the only way to get the V2 sensors at the time.

I wish we could get better integration with the Sense Hub, as it has a siren (and a speaker?)... but I don't think it would be possible given what we have right now.

christophermichaelshaw commented 1 year ago

@drinfernoo, are things mostly working? Without the right hardware I can't really help on the race condition, but if it's like 90% of the way there, you could update the readme saying that piece is a work in progress and has some issues, then merge. Maybe someone else would even see it and be able to help with the race condition aspect.

As a side question, just because I haven't been able to keep up reliably, what is the actual issue you are seeing, maybe I can spot something, even if I can't test.

@raetha @drinfernoo

Any chance we could get the keypad integration merged into main, with the aforementioned disclaimer regarding the race condition? I do think it could be easily remediated with a custom blueprint/automation within HA, and I've already begun working on a potential solution.

Thanks so much!

raetha / wyzesense2mqtt

Add support for Sense Keypad #63