New Zigbee Device (Securifi Key Fob)

So far, no luck. Nothing shows in the log when paired. I built this basic shell device type using the code from the link @tgauchat referred to, but the only thing I get in my log is my debug statement

Here’s my device type (updated with basic parse)

metadata {
	definition (name: "Zigbee Test", namespace: "tierneykev", author: "Kevin Tierney") {
    command getClusters
	}

	tiles {
		standardTile("thing", "device.thing", width: 2, height: 2) {
			state(name:"default", icon: "st.unknown.thing.thing-circle", label: "Please Wait")
		}
         standardTile("refresh", "device.image", inactiveLabel: false, decoration: "flat") {
          state "refresh", action:"getClusters", icon:"st.secondary.refresh"
        }


		main "thing"
		details(["thing","refresh"])
	}
}


def getClusters() { 
     "zdo active 0x${device.deviceNetworkId}" 
       log.debug "Get Clusters Called";
}

def parse(String description) {
    log.debug "parse description: $description"
    }

Yeah, so far it seems noone has had any luck with it. @chevyman142000 didn’t think anyone got it working

Cheap was what drew me to it. It’s a little thick (about the thickness of a matchox) but if it’ll work I’ll take the trade-off. I can give one to my wife, one to my petsitter, and it should allow easy triggering of HH phrases

2 Likes

I’ll look into this :smile: no promises but think we should be able to get this working

@kevintierney

PM me the screenshot of the entire device properties screen if you don’t mind. I’d like to see it.

Also, anything come through on the logs when any of the buttons are clicked?

1 Like

So far, nothing comes through when I click the buttons. I tried adding a parse() section to the device code with a simple log.debug “Parse Called” and nothing. That’s what bugs me. It almost immediately is discovered when put into pairing mode, but after that, nada

Out of curiosity, I changed my smart sense motion to this device type, and the getClusters command doesn’t return anything in the log either

Here’s the device properties

I don’t have one so its difficult to write anything. I have helped people in the past remotely if they send me their device’s join log entry. They need to watch the hub’s log while the device joins the network for the first time. Open the “join” entry and cut and past the description into this thread it will look something like this:

description 	desc: 38 0104 0007 00 03 0000 0003 0004 01 000C

Once we have that information I will look up the cluster numbers and if they are public clusters we will be able to control the device. If they are private clusters then we will need the documentation for the usage of those clusters.

Finally found it. I was looking in the live log, and not the hubs log

desc: 08 0104 0401 00 03 0000 0003 0500 02 0003 0501

Okay good job: You have 3 client clusters and 2 server

Client clusters on end point 0x08

  • 0x0000 - Basic
  • 0x0003 - Identify
  • 0x0500 - IAS Zone

Sever clusters on end point 0x08

  • 0x0003 - Identify
  • 0x0501 - IAS ACE

Clusters 0x0000 and 0x0003 are standard clusters on almost all ZigBee devices. 0x0000 has attributes for manufacture name, hardware and firmware versions etc… 0x0003 is used to identify the device for binding not really useful for a key fob I don’t think.
Clusters 0x0500 and 0x0501 are where you need to focus your attention. I need to read up on those clusters I have meetings this morning so it will be a bit later. Or maybe someone else can chime in.

My next step would be to bind the key fob to the hub and see if it will generate packets you can parse in your custom device type.

Since you now know what cluster to focus on (0x0501) you can bind the hub to that cluster and end point. Once you do that with some luck you should be able to push buttons on the device and see if it will generate calls to your device type’s parse method.

Here is a bind command that will bind cluster 0x0501 on endpoint 0x08 to your hub’s endpoint 0x01. You need to place this command in your device type’s configure() method.

zdo bind 0x${device.deviceNetworkId} 0x08 0x01 0x0501 {${device.zigbeeId}} {}

Thanks @JohnR!

I am going to be leaving town today actually and won’t have much time to get into this. @JohnR you do good stuff, stick with him and i’ll check in on Manday and see if this has been resolved :smile:

EDIT: I’m leaving it because it’s the mose awesome typo ever, but i’ll define it for you.

Manday - The manliest of all the Mondays

4 Likes

I’ll try this when I get home tonight and report back. Thanks

Because this uses the IAS cluster 0500, it probably needs to be “enrolled” in order to report to the hub. It’s an extra step that I’ve seen on pretty much all IAS devices (like Open/Closed). A security measure of some sort.

Try using the below as your configure section. I incorporated the suggestion by @JohnR for binding to the 0501 cluster. I added the command for writing to the IAS Zone cluster, which will cause the device to “enroll” itself.

"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}} {}"

Try adding this block of code into your parse() section. It tries to look for the “enroll request” and triggers the response, which is the function in the 2nd code block.

if (description?.startsWith('enroll request')) {
        List cmds = enrollResponse()
        log.debug "enroll response: ${cmds}"
        result = cmds?.collect { new physicalgraph.device.HubAction(it) }
    }
    return result

This piece can go pretty much anywhere. It’s a standalone function like parse().

def enrollResponse() {
    log.debug "Sending enroll response"
    [    
        
    "raw 0x500 {01 23 00 00 00}", "delay 200",
    "send 0x${device.deviceNetworkId} 0x08 1"
        
    ]
}

Edit: I just fixed the last portion for the enrollResponse. I forgot to update the endpoint to 0x08.

1 Like

Right, this is intended for use by the manufacture with a security system panel. So there is supposed to be a match code that you use to tell the panel that this device does in fact belong to your install, and then it enrolls the device to your panel.

If this works I would buy one or two of these just to keep on our keys as a backup to SmartAlarm not disarming with presence. Would make my wife happier then having to pull up the app on her phone.
Great work so far, this looks promising :smile:

1 Like

@Sticks18 Great stuff Scott!!

I modified my device type, but nothing’s really changed. I do get the same events (join, ep_cnt:1, ep:08) in the hub’s log every time I press one of the buttons. I have tried pressing the buttons as I trigger the configure, but that didn’t seem to help

metadata {
	definition (name: "Securifi Key Fob", namespace: "tierneykev", author: "Kevin Tierney") {
    command getClusters
    capability "Configuration"
	}

	tiles {
		standardTile("thing", "device.thing", width: 2, height: 2) {
			state(name:"default", icon: "st.unknown.thing.thing-circle", label: "Please Wait")
		}
         standardTile("refresh", "device.image", inactiveLabel: false, decoration: "flat") {
          state "refresh", action:"getClusters", icon:"st.secondary.refresh"
        }
		standardTile("configure", "device.power", inactiveLabel: false, decoration: "flat") {
			state "configure", label:'', action:"configuration.configure", icon:"st.secondary.configure"
		}
		main "thing"
		details(["thing","refresh","configure"])
	}
}


def getClusters() { 
     "zdo active 0x${device.deviceNetworkId}" 
       log.debug "Get Clusters Called";
}

def parse(String description) {
    log.debug "parse description: $description"
    
    if (description?.startsWith('enroll request')) {
        List cmds = enrollResponse()
        log.debug "enroll response: ${cmds}"
        result = cmds?.collect { new physicalgraph.device.HubAction(it) }
    }
    return result
    }
    
def enrollResponse() {
    log.debug "Sending enroll response"
    [    
        
    "raw 0x500 {01 23 00 00 00}", "delay 200",
    "send 0x${device.deviceNetworkId} 0x08 1"
        
    ]
}

def configure(){
    log.debug "Config Called"
    def configCmds = [
    "zcl global write 0x500 0x10 0xf0 {${device.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


}

Try adding the fingerprint section, so it will pick it up when it pairs, then reset and re-pair. I believe the security part has to be done during the commissioning process.

I think this should work. Good luck!

fingerprint profileId: “0104”, deviceId: “0401”, inClusters: “0000,0003,0500”, outClusters: “0003,0501”

1 Like

We are making some progress. ST immediately sees the key fob correctly now, and when the configure is sent, we get back

Securifi Key Fob updated

But no progress on registering the button presses. I see the same three events in the hub log, but no parse events in the live log

OK. Reset and tried again and here’s what I got in the live log

0cb23a70-ec07-4fdf-b766-cdbc6aa416a8 8:55:06 AM: error groovy.lang.MissingPropertyException: No such property: result for class: script1429966506586177738848
Possible solutions: request @ line 45
0cb23a70-ec07-4fdf-b766-cdbc6aa416a8 8:55:06 AM: debug enroll response: [raw 0x500 {01 23 00 00 00}, delay 200, send 0x321F 0x08 1]
0cb23a70-ec07-4fdf-b766-cdbc6aa416a8 8:55:06 AM: debug Sending enroll response
0cb23a70-ec07-4fdf-b766-cdbc6aa416a8 8:55:06 AM: debug parse description: enroll request endpoint 0x08 : data 0x0115
0cb23a70-ec07-4fdf-b766-cdbc6aa416a8 8:55:06 AM: debug parse description: updated
0cb23a70-ec07-4fdf-b766-cdbc6aa416a8 8:55:06 AM: debug Config Called

Line 45 is
result = cmds?.collect { new physicalgraph.device.HubAction(it) }

1 Like

Success! Result just had to be initialized. Now we have results when the buttons are pressed. I have to run out, but I’ll take a stab later at parsing what is sent when a key is pressed (looks like only 3 of the 4 buttons actually work - the 4th may just be for reset/program)

f48eef26-b225-438b-be02-42a65588a918 10:29:28 AM: debug parse description: catchall: 0104 0501 08 01 0540 00 7CC8 01 00 0000 00 00 00303030303132333400
f48eef26-b225-438b-be02-42a65588a918 10:29:28 AM: debug parse description: zone status 0x0008 – extended status 0x00
f48eef26-b225-438b-be02-42a65588a918 10:29:27 AM: debug parse description: zone status 0x0008 – extended status 0x00
f48eef26-b225-438b-be02-42a65588a918 10:29:27 AM: debug parse description: catchall: 0104 0501 08 01 0540 00 7CC8 01 00 0000 00 00 02303030303132333400
f48eef26-b225-438b-be02-42a65588a918 10:29:25 AM: debug parse description: zone status 0x0008 – extended status 0x00
f48eef26-b225-438b-be02-42a65588a918 10:29:24 AM: debug parse description: catchall: 0104 0501 08 01 0540 00 7CC8 01 00 0000 00 00 03303030303132333400
f48eef26-b225-438b-be02-42a65588a918 10:29:05 AM: debug parse description: zone status 0x0008 – extended status 0x00
f48eef26-b225-438b-be02-42a65588a918 10:29:04 AM: debug enroll response: [raw 0x500 {01 23 00 00 00}, delay 200, send 0x7CC8 0x08 1]
f48eef26-b225-438b-be02-42a65588a918 10:29:04 AM: debug Sending enroll response
f48eef26-b225-438b-be02-42a65588a918 10:29:04 AM: debug parse description: enroll request endpoint 0x08 : data 0x0115
f48eef26-b225-438b-be02-42a65588a918 10:29:04 AM: debug parse description: updated
f48eef26-b225-438b-be02-42a65588a918 10:29:04 AM: debug Config Called

3 Likes

Great work. One of the reviews on Amazon I think mentioned that only 3 of the 4 buttons worked.