[OBSOLETE] New Zigbee Device (Securifi Key Fob)

I bought one of these with hopes of figuring out how to make it work with ST.

I’ve written/modified a few device types and several smartapps, but never any zigbee ones. I’m not sure where to start. When I put the device into pairing mode, it is found almost immediately by ST. The probelm is I don’t see anything in the log. Based on reading other threads I thought that there would be something in the log to get me started on building a device type, but there’s nothing there. I’ve unpaired, re-paired a few times, but nothing changes. I’ve watched the live log as well as checking the device log

Any help on where to start is much appreciated

Not sure if this helps

1 Like

I think you start by building a very simple nearly empty Device Type Handler and have it query for the available ZigBee clusters from the Fob. Then the real work begins … ZigBee devices are less standard than Z-Wave as far as I am aware, so you may have to analyze the clusters one at a time … possibly referencing the ZigBee standards to see if they match up.

Cool looking Fob, by the way… if there’s anything I can do to help, I will.

Can you get me the raw outputs. Should be relearively easy to integrate.

1 Like

@JohnR and @chevyman142000 were working on this last year, not sure how far they got:

And, Tim…

Can you get me the raw outputs. Should be relearively easy to integrate.

I’ll have some of whatever you’re drinking. :wink:

1 Like

Cool looking device…and cheap :smile:

1 Like

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


}