Securifi Key Fob

🛎️ Get Help Devices
1

I received my hub yesterday and after migrating a few devices over, I decided to take a stab at porting over my driver for the Securifi Zigbee key fob tonight. So far I've had no luck. I've reset the fob, put it into pairing mode, but the hub doesn't see it at all as far as I can tell. The fob stays in pairing mode until it times out

I even re-paired it to ST to make sure it was still working, reset it, and tried again

Here's my post where we got it working on ST.

I'm sure I'll have to make more changes to the code, but if the hubitat won't detect it at all, I don't believe that will matter

2

If you can find a place where I can order one of these, I’ll write a driver for it.

3

I believe those are discontinued.

4

Looks that way

This is the DH I wrote for ST
https://github.com/tierneykev/SmartThings/blob/master/devicetypes/tierneykev/securifi-key-fob.src/securifi-key-fob.groovy

This is what's in the hub log on ST when it joins. Is there somewhere I should be looking on the hubitat end to see a join attempt

2018-03-14%2007_50_42-Events%20List
2018-03-14%2007_50_42-Events%20List1646×651 37.9 KB

5

Open another tab and keep the log open. Also @ritchierich had a lot of trouble with Zigbee water sensors and found a workaround to the issue. Read from here for some ideas.

I’ve had better success with Zigbee devices by resetting, then removing the battery for 10 sec, reinsert and put them in pairing again.

6

Thanks for the pointers. I’ll take a look tonight. I did have the logging open in another tab. I just wasn’t sure if the join attempt would show up in the regular log or somewhere else. On ST it wasn’t in live logging, but instead in the hub event log

7

Have not tried using it that way myself. Just what I have read mentioned for events in Hubitat. When I have paired, I see “Initializing” in the discovery page, then the fingerprint when it completes. If you then click “More” before leaving the discovery page, you can copy the entire fingerprint.

8

The problem right now is that I never see anything in pairing and the key fob continues to blink green for pairing mode until it eventually times out. I had the fob right next to the hub. I wonder if it has something to do with IAS

9

You can also get some additional Zigbee data from the SETTINGS->Zigbee Information->Zigbee Logging page.

2 Likes
10

Try the battery trick. I’ve had several Zigbee devices show that they were in pairing mode by the led pattern, but do nothing until I removed the battery and put it back in, and then it worked.

11

Your device handler will need to be re-worked for Hubitat. The button capability implementation is different (see here). Also any reference to physicalgraph such as in physicalgraph.device.HubAction needs to be changed to to habitat. See this thread for more information on porting apps and device drivers to Hubitat.

As for pairing, the Hubitat does not present Hub Event logs with a zbjoin event. When you enter "Discover Devices" mode in the Devices page of the Hubitat web-interface, if the hub recognizes a Zigbee device, you should see its Zigbee ID listed, with a message that it's initializing. Do you see that? If not, then the hub isn't seeing the device being ready to pair, and you should double-check the pairing procedure of the device.

If you do see the Zigbee ID listed, but the initialization never completes, there's a workaround I came up with to manually add a device. It involves copying down its Zigbee ID when displayed at pairing, and also keeping open the Zigbee Logging page that @ogiewon mentioned. In the logging page, a device being paired will first show up with its 4-digit hexadecimal DNI (Device Network ID). Those two pieces of information can be used to add the device manually using "Add Virtual Device".

For a complete list of instructions of this manual method, please see this post. I wrote it with Xiaomi Zigbee devices in mind, but it should work with any Zigbee device.

2 Likes
12

@tierneykev

I have reworked your SmartThings device handler code to be a Hubitat-compatible device driver, and created a Pull Request on a fork of your GitHub repository.

You can view the differences between the ST and Hubitat code here, and copy the new code from this raw text link.

Please keep in mind since I don’t have the Securifi Key Fob, I am unable to test the code. But based on my experience so far with Zigbee device drivers on Hubitat, and the all the information from the SmartThings Community Forum thread you started when you first bought the device, I’m pretty sure this reworked code should work for you.

The key information to guess what the Hubitat would receive when the buttons are pressed comes from this post:

catchall: 0104 0501 08 01 0540 00 7CC8 01 00 0000 00 00 00303030303132333400
catchall: 0104 0501 08 01 0540 00 7CC8 01 00 0000 00 00 02303030303132333400
catchall: 0104 0501 08 01 0540 00 7CC8 01 00 0000 00 00 03303030303132333400

I am not well-versed in Zigbee IAS (Intruder Alarm Systems), but here’s what all of that represents:

0104    = Zigbee Profile: Home Automation
0501    = Cluster ID: IAS ACE (Intruder Alarm Systems - Ancillary Control Equipment)
08      = Source endpoint (your fob)
01      = Destination endpoint (the hub)
0540 00 = ?? (Likely IAS ACE specific)
7CC8    = DNI (Device Network ID)
01 00 0000 00 00 =`?? (Likely IAS ACE specific)
00303030303132333400 = Data Payload, first byte corresponds to button pressed

The most important thing we need out of all of that is that messages tagged as cluster: 0501 contain the button number information, and the first byte of the data (e.g., 00 corresponds to which button was pressed).

With that in mind here are the changes I made to your code:

  • removed the tile definition, because the Hubitat hub does not have a mobile app user interface
  • added cluster, attrId, valueHex objects to parse() function, which are grabbed from the incoming zigbee report message, because Hubitat does not parse Zigbee messages in the same way, and they are received in more of a “raw” format
  • changed if (description?.startsWith('catchall:')) to if (cluster == "0501") because the Hubitat will receive button press messages tagged as cluster 0501
  • on button push (cluster = 0501) the first byte of the value: portion of the message are sent to buttonPush() to create the event map that is sent to the hub
  • buttonPush() now uses two list arrays to map the Securifi button numbering to their names and their respective Hubitat button numbering
  • buttonPush() now returns a map back to parse() which calls createEvent()

If I was wrong about the cluster: 0501 message, it should be fairly easy to fix by looking at the debug log messages when you press the buttons.

I hope this helps!

2 Likes
13

Wow. Thanks. Even if I can’t ever get it to pair, I can learn from how the code changes

I tinkered with it again tonight and it never is seen by the hub

I replaced the battery, reset the fob numerous times, restarted the hub, disabled/Re-enabled zigbee and even unplugged the ST hub. Still no attempt to pair.

I’m out of ideas and will probably put these aside for now. We hadn’t been using them for some time and this was more of a learning project to see how the hubitat device code differs from the ST DH

I’m still hopeful I can get it to work at some point, but I still have many devices (switches,open/close,motion) to bring over that I could be working on

14

So now that I’ve moved everything over from ST I figured I’d give another go at this. I’ve at least got the key fob attempting to connect this time around. Now to work on the driver

dev:1512019-08-12 08:41:08.844 pm debugSecurifi, parse description: catchall: 0000 0013 00 00 0040 00 FF26 00 00 0000 00 00 8326FF9BE64F04006F0D0000

dev:1512019-08-12 08:40:59.963 pm debugSecurifi, parse description: enroll request endpoint 0x08 : data 0x0115

Here’s my old ST one

15

Just dropping this here so I have it

ID: 1E19
Manufacturer: Sercomm Corp.
Product Name:
Model Number: SZ-KFB01
deviceTypeId: 13
manufacturer : Sercomm Corp.
idAsInt : 8
inClusters : 0000,0003,0500
endpointId : 08
profileId : 0104
application : 33
outClusters : 0003,0501
initialized : true
model : SZ-KFB01
stage : 4

Attempting to pair

dev:1522019-08-13 08:36:54.275 pm debugSecurifi, parse description: catchall: 0000 0013 00 00 0040 00 1E19 00 00 0000 00 00 B3191E9BE64F04006F0D0000

dev:1522019-08-13 08:36:46.157 pm debugDevice, parse description: enroll request endpoint 0x08 : data 0x0115

17

And, it looks like I've been wasting my time the last couple days as @snell beat me to it

1 Like
18

@tierneykev:
Not mutually exclusive. I have some updates to mine in the works I need to publish, lessons learned making my own Lightify Button driver. I made changes to the Keyfob as a result (the reason for the split from one combined driver was all these new features I was working on).

19

So. I had no luck with @snell’s code so I went back to my own. I still have to clean it up and send the button events, but it pairs easily and logs every button press

One interesting thing is when the button is pressed after not being used for a short time I get a message from endpoint 00 (all the button messages are on 08). I may just ignore it, but didn’t know if there was anything useful going on there.

Mystery Message

[raw:catchall: 0000 0013 00 00 0040 00 494D 00 00 0000 00 00 994D499BE64F04006F0D0000, profileId:0000, clusterId:0013, clusterInt:19, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:494D, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[99, 4D, 49, 9B, E6, 4F, 04, 00, 6F, 0D, 00, 00]]

Button Press

[raw:catchall: 0104 0501 08 01 0040 00 494D 01 00 0000 00 00 03303030303132333400, profileId:0104, clusterId:0501, clusterInt:1281, sourceEndpoint:08, destinationEndpoint:01, options:0040, messageType:00, dni:494D, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[03, 30, 30, 30, 30, 31, 32, 33, 34, 00]]

20

I found a page on the digi.com site that describes the cluster 0x13 as a "ZDO Device announce" broadcast... The data is [ 8 bit sequence number] + [16 bit address] + [64 bit address] + [ capability]. The 16 and 64 bit addresses are LSB and, as you discovered (NICE CATCH!!!! - All the other driver attempts missed that!) need to be byte reversed to be usable on HE... The info does not provide guidance on what should (or needs to) be done with the packet...

So... Now that you have discovered the secret... I did some testing...

I have an Almond plus that I have had a Fob attached to... I sits about 30 feet away from my desk, and has two gypsum walls in between... I can pair the Fob to the Almond plus from my desk... first time, every time...

My HE is located in the same room as the Almond plus, about 5 feet from the Almond plus (the room is a 6' x 6' utility closet)... same two gypsum walls in-between... In order to pair the Fob to the HE, I have to actually be IN the room with the Hubitat. It also does not detect button presses unless

I can pair other devices (IE: Light bulbs) from my desk... So I don't know what the issue is... but It makes the Fob kinda useless when used with HE...

21

I found early on that the Fob does NOT like to pair with the HE but once it does it usually needs to be configured first before it does (or responds) to anything else. Still have not worked that out in my code (which is maybe why mine did not seem to work). But usually it was detected as a Moisture sensor so I just hit configure there, then switched it to my driver.

@tierneykev:
Were you using the SecurifiKeyFob.groovy driver I made? I was checking on mine and it seems to be working fine, but I noticed some other items so I have made a couple changes and updated to version 0.2. That would should actually configure as well.

As for 0013 I do not handle it yet but it increments each time a button is pressed after there has been a pause. Even the "*" button that does not report otherwise. So I am thinking that might be a way to "see" that button, if no other button reports. Not implemented yet though.