Securifi Key Fob

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

@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

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

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

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

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.

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] - #145 by vjv 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/examples/drivers/haloSmokeCoDetector.groovy at master · hubitat/HubitatPublic · GitHub that clued me into the fact that for Hubitat, the enroll is super simple

zigbee.enrollResponse(1200)

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

Yours

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

Mine

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)

https://www.amazon.ca/Securifi-FBA_AL-KFB01-Key-Fob-AL-KFB01/dp/B00TBXMA8C


Securifi Key Fob, AL-KFB01-CA | www.staples.ca (bit pricey!!)

I have a securifi key fob that is detected by hubitat as a device I have installed your [Securifi KeyFob driver] is there anything else I need to do ? Currently for the device this is what I see.


is there anyway that a rule I create can see the 4 buttons separately and initiate different actions,

In Rules you can set a Button as the Trigger capability. It will as which button to trigger off of and what the value (pushed, held, double Tapped, etc...) happened. You could create Rules with as many of these as you want.

You can also set up a Rule with a Trigger capability based on "Button Device". This will automatically make it have 4 buttons (because the fob has 4) and you can set actions for each. This one is a bit simpler if you want just an immediate action to set up.

However, this key fob only readily detects 3 buttons. The * CAN be detected under certain circumstances but only because of a workaround I figured out. It does not work like the rest do. So I would only recommend using the 3 other buttons for things you want to really work. If you use the button device, you can always ignore button 4 (*).

I appreciate the quick response to my query, its such a nice community to be in.
Using the trigger capability and "button device" I can see the four buttons I am presuming the order is as per the drop down list in the device. upper left lock = 1 and home =2 etc.
I created a rule to test it but doesn't seem to work when I go to the device and manually click on the push button it works fine have two actions 1 button puts the plug on the second one puts it off .( I haven't used button 3 or the *... But the actions don't excite from the key fob button . what could I be doing wrong this is the screen shot of my rule.


The plug I am using is a peanut( securifi) which operates pretty well. I have a bunch of them connected to an Alexa through the hubitat.

Oddly, I have not tried the Button Device one before and I am not even sure where my keyfobs wandered off to at this time... So...

Can you enable Debug level logging for the keyfob device (I just looked at the code... wow... this one has not been edited in some time, I never even moved it over to my current version standards) and post a copy of the log when you press button 1, then button 2 (you have the right idea about which one is which). Also, if you can edit the Rule to enable Logging there... that could help as well.

I have a bunch of Peanut Plug devices around also. First thing I want to make sure is that the keyfob is actually sending it's button presses.

1 Like

the key fob is sending the button presses yes... I checked in the device and every time I click a button the button press count goes up ( upto 4 then resets)


pasted here is the log when I press 1 and then 2

ClearPauseShow Past Logs

search

dev:1712020-10-12 09:55:55.061 am debug4buttonremote - Button presses = 2

dev:1712020-10-12 09:55:55.057 am debug4buttonremote - MultiState Asterisk = true and Repeat = true

dev:1712020-10-12 09:55:53.987 am debug4buttonremote - MultiState Asterisk = false and Repeat = null

dev:1712020-10-12 09:55:53.983 am debug4buttonremote - clusterId = 0013, attrId = null - cmd = 00, data = [CF, 18, F3, 79, D7, 4F, 04, 00, 6F, 0D, 00, 00]. value = null

dev:1712020-10-12 09:55:44.201 am debug4buttonremote - Button presses = 1

dev:1712020-10-12 09:55:44.197 am debug4buttonremote - MultiState Asterisk = true and Repeat = true

dev:1712020-10-12 09:55:43.159 am debug4buttonremote - MultiState Asterisk = null and Repeat = null

dev:1712020-10-12 09:55:43.156 am debug4buttonremote - clusterId = 0013, attrId = null - cmd = 00, data = [CE, 18, F3, 79, D7, 4F, 04, 00, 6F, 0D, 00, 00]. value = null

--- Live Log Started, waiting for events ---