Frient Keypad Not Arming/Disarming HSM

🛎️ Get Help
1

Apolijises if this is not the done thing but I tried to resurrect an old topic (Frient keypad driver - #19 by jd606cummins) that appeared to be having the same issue as me but wasn't getting any responses so perhaps I need to start a new thread.

I have a new Frient Keypad which I have paired and seems to be working as expected except that it will not arm/disarm the HSM.

The logs for the keypad show that the command has been processed but HSM does not respond to these commands even though it has being configured to use this keypad as the arm/disarm device.

Interesting if I arm or disarm from within HSM these changes are reflected in the keypad state variables.

HSM shows that it is subscribed to an "armingIn" event from the keypad as shown below but this event never occurs:

image
image1408Ă—240 20.7 KB

I am assuming that the intended operation is that this event should be triggered when the keypad is operated to allow the HSM to process the keypad command however this event is never produced when the keypad is operated hence why the HSM never responds:

image
image1507Ă—309 32.4 KB

I believe the most likely cause of the issue probably resides within the device driver but as this is a built in driver it impossible to confirm/rule out.

I have also tried this on another C8 pro and C7 hub that I own and I am seeing the same issue.

Hub:C8 pro
firmware: 2.4.4.146

Thanks

2

@JumpJump

Still not getting any joy getting this keypad to directly arm/disarm HSM.

Heres my HSM configuration in case I have done something stupid that someone can spot

image
image1426Ă—705 63.2 KB

Cheers

3

I don’t know if this will make a difference but instead of assigning the keypad buttons in HSM to arm and disarm HSM you could try writing a rule in rule machine to do the same thing. Just to make sure it isn’t an HSM issue. I don’t think it would be HSM but it’s something to try.

4

Great suggestion.

If I create rules within rule machine then HSM reacts based on the rule logic. However I need to think about/test whether the delays programmable from the keypad will work as expected but at least it reacting to the arm/disarm commands.

It feels like a workaround to me but at least its working. I hate it when things don't work as expected ( I think its the engineer in me or maybe some deeper psychological problem :slight_smile: ) so will keep tinkering to see if I can come up with something. Cheers

1 Like
5

I understand completely. I also are from an engineering environment. I don’t fully understand what you mean delays in the keypad as my alarm system doesn’t integrate directly with home assistant. I use HSM as a redundant system on top of that so I use virtual switches exposed to Alexa. When I arm my system Alexa in the background controls those switches and then HSM arms per rules I have written. I didn’t write any delays into them but I did put my arm and disarm delays into HSM directly and those seem to work.

Unfortunately, I have learned that home automation a lot of times is just one big “how can I make it work” scenario.

6

The keypad allows you to program arming/disarming delay which integrates into HSM. I could just ignore these commands and program directly within HSM though I guess.

1 Like
7

If it works with the keypad I would leave it with the keypad.

8

Hi I am posting this in case others come across the same issue. I now have the keypad working as expected but still believe there is a small bug within the keypad driver.

@mike.maxwell

I know you are incredibly busy but I honestly believe there is a small bug within the current Hubitat driver perhaps caused by a slight change within the keypad firmware. This seems counter-intuitive as other users are using the keypad successfully. This was bothering me too, but I think I may be able to explain this as I now believe that those who already have the keypad installed will be fine but it’s likely that new installs may have problems…..

Let me try to explain……

As an experiment I tried to create my own driver using AI not as a serious alternative but rather it’s something that I have been wanting to try for some time and thought this was a good experiment to see how it performs.

Eventually I got a driver that worked (Don’t worry Mike I think your jobs safe it was a very frustrating and time-consuming endeavor)

Installing this driver code and configuring the device (device was already paired using th inbuilt driver) HSM immediately reacts to any arming/disarming commands (SUCCESS). However here’s the funky part if I then replace the driver code created with AI with the in-built driver code and configure the device the HSM also now works with the in-built driver. (OK in-built driver now works)

To try and understand what may be happening. I completely removed the device from the system; factory reset the device and tested again.

Once again after pairing the device and testing with the in-built driver (HSM doesn’t respond to keypad). If I replace driver with the AI generated code (HSM responds to keypad). Replace driver with in-built driver (HSM responds to keypad). OK I am happy

My hypothesis is that others are not having issues because it was already working from a previous driver revision or perhaps device firmware and that any potential subsequent driver updates won’t break it (Similar to me going from the AI generated driver back to the in-built driver)

I won’t post the driver code created from AI on the forum as I believe that would be irresponsible as it is completely untested however I will make it available to anyone if they are interested. Mike I am assuming it might be useful to you if you get chance to look at this issue.

I can also make the AI transcript available it makes some interesting observations around bindings and timings that may provide a clue as to what going on.

Final Thoughts

I have a working system with the in-built driver so I am happy but wanted to post this in case others have a similar issue.

My experience with using AI to generate the driver code was intriguing. It did produce something that worked but it took a lot of prompting and iterations to get something and whilst I appear to have created a driver that works on the surface and help solve my issue my resultant confidence in the driver is low as I haven’t spent any time understanding what it was doing.

I am not marking this as a solution as I believe there is something that needs tweaking within the in-built driver but I am happily using the device with the built-in driver after using the AI driver to "fix" something

9

I actually now have it working as expected without using RM. It a long story post to follow but it was an interesting learning experiment for myself so worth the effort

1 Like
10

Glad you got it going.