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
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
#2
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.
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
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
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
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:
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.
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.
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
EDIT: I’m leaving it because it’s the mose awesome typo ever, but i’ll define it for you.
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.
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().
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
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
