Securifi Key Fob

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

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.

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

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


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.

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.



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!


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

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

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

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

1 Like

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).

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

I found a page on the 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...

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.

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.

I had to dig through several posts/drivers to get to the point where it pairs successfully and reads the button presses. There's several things that I still don't entirely understand how it works on the zigbee side that I want to read up on to understand better

This post - Went back to smarthings [But came back] clued me on to changing my configure function

From this (ST)

def configure(){
	log.debug "Config Called"
	def configCmds = [
		"zcl global write 0x500 0x10 0xf0 {${device.zigbeeId}}", "delay 200",
		"send 0x${device.deviceNetworkId} ${endpointId} 1", "delay 1500",
		"zdo bind 0x${device.deviceNetworkId} ${endpointId} 0x01 0x0501 {${device.zigbeeId}} {}", "delay 500",
		"zdo bind 0x${device.deviceNetworkId} ${endpointId} 1 1 {${device.zigbeeId}} {}"
	return configCmds

To this (plus adding the two functions (swapEndianHex and reverseArray)

def configure(){
	String zigbeeId = swapEndianHex(device.hub.zigbeeId)
	log.debug "Config Called"
	def configCmds = [
		"zcl global write 0x500 0x10 0xf0 {${zigbeeId}}", "delay 200",
		"send 0x${device.deviceNetworkId} 0x08 1", "delay 1500",
		"zdo bind 0x${device.deviceNetworkId} 0x08 0x01 0x0501 {${device.zigbeeId}} {}", "delay 500",
		"zdo bind 0x${device.deviceNetworkId} 0x08 1 1 {${device.zigbeeId}} {}"
	return configCmds

From there, I needed to figure out what was different in how to respond to the enroll request:

Eventually I found this driver: HubitatPublic/haloSmokeCoDetector.groovy at master · hubitat/HubitatPublic · GitHub that clued me into the fact that for Hubitat, the enroll is super simple


Rather then adding it to the configure cmd like that driver does, I decided to add it into my parse function

if (description?.startsWith("enroll request")) {
    if (logEnable) log.debug "RECEVED ENROLL REQUEST: ${description}"
        List cmds = zigbee.enrollResponse(1200)
        result = cmds?.collect { new hubitat.device.HubAction(it, hubitat.device.Protocol.ZIGBEE) }

Once I did that, reset, and re-paired, it all worked.

@snell - I did try that Securifi driver. One thing I noticed right off the bat is that you have a different fingerprint, which probably is why it's not detecting correctly. It looks like you were still using the almond click fingerprint


fingerprint profileId: "0104", inClusters: "0000, 0001, 0003, 0013, 0402, 0500, 0501, 0B05", outClusters: "0019", manufacturer: "Securifi", model: "ZB2-BU01", deviceJoinName: "Almond Click"


fingerprint profileId: "0104", inClusters: "0000,0003,0500", outClusters: "0003,0501", manufacturer: "Sercomm Corp.", model: "SZ-KFB01", deviceJoinName: "Securifi Key Fob"

1 Like

Frames tagged with profileId 0000 are ZDO messages and in the context of this driver should be ignored.

Ha! That fingerprint error is because I used to have them all combined and identified by model. Then I separated the buttons out because driver capabilities are not dynamic... Then I split the Keyfob and click drivers apart due to differences... And did not notice I deleted the wrong fingerprint. Thanks! I will get that corrected tonight. I typically set the driver per device specifically rather than rely on it being detected. Guess I need to remove and add them more often.

Plus, the configure information is interesting. Have to review that more.

Ok, my Securifi KeyFob driver is now fixed for the fingerprinting and I added the enroll as version 0.3.

I also have the workaround for the * button, based on if an 0013 is called without another button being reported within a second. So basically someone can only press (and expect to work) the * button if nothing (including *) has been pressed for ~10 seconds. Better than nothing though.

Somewhere in this thread it was mentioned that the AL-KFB01 keyfob has been discontinued... Dunno about the offical manufacturing status, but

they are still readily available from Canada, and
being Zigbee, they will work anywhere in the world (with @snells driver)

Securifi Key Fob, AL-KFB01-CA | (bit pricey!!)

Download the Hubitat app