Add support for Sense Keypad

[drinfernoo]

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]

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

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

[drinfernoo]

This will let us pass the payload to the logging easier in the event of adding new devices in the future.

[drinfernoo]

I'm really guessing here on the battery level for the keypad...

The max value I could get from it was 155, with brand new batteries, and swapping out the oldest batteries I had laying around gave me a minimum value of 142, so I don't know that this calculation is quite right, but it's still open to change.

[drinfernoo]

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]

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.

[raetha]

These look good to me, nice job on the cleanup and adding support for the keypad. Unfortunately I can't directly test them as I don't have any of the newer sensors, still seems like Wyze isn't selling them without signing up for the HMS. I also didn't have time to fully read all code, but it looks good and as long as you are able to test things I'm happy. Feel free to merge whenever you are ready.

[drinfernoo]

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]

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]

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]

@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]

@drinfernoo I just took the huge set of fixes and updates from @nabahr which changed a fair amount, and may have included some, but not all, of this PR. Could you rebase and then resubmit this PR? I know some folks wanted this, even with the race condition issue that I'm not sure you ever solved.

Alternately, if you resolve the conflicts we can take this existing PR, just might be safest to start clean.

[drinfernoo]

@raetha Oh my gosh! I kind of feel off of smart home things for the better part of the last year 😬 I've recently gotten back to it, and when getting my sensors and stuff set back up, I thought to check here...

I'll definitely try to find time to get this (or some equivalent) PR worked out.

I've been using the V2 (contact and motion) sensors for ages, and am quite happy with them. I even had a few run completely dead, and changing the battery got them back online without even re-pairing! I'm wondering if anyone has been able to get the HMS base station working, as it'd be really sweet to use as an alarm, but I'll stick to trying to figure out the keypad for now 😅

[drinfernoo]

Hmm... I think I made a mistake while rebasing. I've got a lot of unrelated files now 😓

I'll try to get this working another time soon!

[dmyoung9]

@drinfernoo Yeah, it looks like there's even some conflict markers committed here...

I've got one of the keypads too, so maybe I can play around and get this working with my dongle. Not sure if I can get the firmware flash working.

[dmyoung9]

Just thought I'd drop these here, some payloads I grabbed from the keypad:

---

Pin start (only fired on the first pin entry):
ea,37,37,43,30,37,34,42,46,05,07,0d,7f,00,06,ff,00,e4,21

Pin confirm (pin 1234, fired after checkmark pressed):
ea,37,37,43,30,37,34,42,46,05,0a,0d,80,00,08,01,02,03,04,00,e6,23

Pin confirm (pin 5, fired after checkmark pressed):
ea,37,37,43,30,37,34,42,46,05,07,0d,7f,00,08,05,01,02,2d

Press disarmed:
ea,37,37,43,30,37,34,42,46,05,08,0d,7e,00,02,01,00,00,e7,1f

Press home:
ea,37,37,43,30,37,34,42,46,05,08,0d,80,00,02,02,00,00,e8,21

Press away:
ea,37,37,43,30,37,34,42,46,05,08,0d,80,00,02,03,00,00,e9,21

Keypad motion active:
ea,37,37,43,30,37,34,42,46,05,08,0d,80,00,0a,01,00,00,eb,26

Keypad motion inactive:
ea,37,37,43,30,37,34,42,46,05,08,0d,7f,00,0a,00,00,00,ea,1d

Keypad alarm (only fired after holding alarm button, a single press does nothing):
ea,37,37,43,30,37,34,42,46,05,08,0d,7d,00,02,04,00,00,e2,1d

---

The "cancel" button seems to never fire events, regardless of any other state, and the "confirm" button only fires an event if there is a pin entry. The "cancel" button does clear any previous pin digits that were input between the last time either "cancel" or "confirm" were pressed; there just isn't an event fired.

The "pin confirm" event has the first digit in the "state" byte (payload[15]), with subsequent digits being in the following bytes, and signal strength at the end (I think). The "pin start" even is basically the same, except "state" is always 0xff. In either case, the byte just before (payload[14]) seems to indicate the length of the pin... this is a bit of a weird way to do this in my opinion, but it looks like what @drinfernoo figured out is right: you take the index of the state byte, add the value of the byte just before, subtract 6, and you are left with how many digits (bytes) long the pin is.

Great work on figuring out this initial payload @drinfernoo! I am going through and adapting the changes from this PR to fit the new 3.x code, so just thought I would share what I found so far!

[dmyoung9]

Just to add to this, it seems like the "second to last two" bytes from the keypad are "number of events"... not sure if that's useful, relevant, or common to other devices yet.

[dmyoung9]

I also double checked today, looks like I have firmware 0.0.0.48 on my keypad, and 4.32.2.91 on my hub.

EDIT: These are the earliest firmwares for both, not even listed on the changelog page 👀

[raetha]

Hmm... I think I made a mistake while rebasing. I've got a lot of unrelated files now 😓

I'll try to get this working another time soon!

@drinfernoo I just changed this PR to point at the devel branch which seems to have cleaned up a bunch of the "errant" unrelated files. So I think it now shows more cleanly what you are working on. Definitely verify before we pull it into the devel branch though in case something is non-obvious!

[raetha]

@drinfernoo Just checking if this was ready to merge once I changed the base and the changes are more obvious. Can you let me know when you get a chance? Even if not perfect, if it's partly working that will get this out there for others to test as well.

[drinfernoo]

@drinfernoo Just checking if this was ready to merge once I changed the base and the changes are more obvious. Can you let me know when you get a chance? Even if not perfect, if it's partly working that will get this out there for others to test as well.

@raetha Hey, I still need to go through and fix the merge conflicts... Definitely don't want it going in like that. I'll try to get that done this week!

I have started to have some additional second thoughts here though, as I had a go at setting up the keypad in the Wyze app, and found that there is a bunch of functionality dependent on the Hub being able to send packets to the keypad 😮‍💨 Seems a bit obvious in retrospect, but I had never actually tried this for myself.

[drinfernoo]

@raetha I actually had a computer failure in the last week, and haven't been able to get back to this. Hopefully I'll be able to soon.

[raetha]

@drinfernoo No worries at all! Sorry to hear about the computer failure, those are never fun, hopefully you have good backups of at least the important stuff.

I'm not in a rush on this or anything, just hoping to clean up some old things for v3.1. My home setup isn't really working at the moment so I can't test much but when I found out others are still using this I wanted to stabilize things as best I could! :)