ZigBee Abstraction Documentation!

It will look at the Simple Descriptor for each endpoint in order until it finds one that matches a fingerprint. Generally this means it will use the first endpoint.

In the case of the Osrams, the stock style devicetypes weren’t working; but simply changing the endpoint variable to a constant 3 got them working.

Are you still experiencing this problem with the stock device type? I just joined an OSRAM Lightify bulb to my hub and seems to be working fine with the stock “ZigBee White Color Temperature Bulb” device handler. This particular bulb only has one endpoint (endpoint 3). I know in the past some of the device handlers hard coded an endpoint of 1 but if that was the case for OSRAM in the past then I think it’s been fixed. Let us know if you see something different though.

Thanks, Tom.
Are there any utility functions or logs that show the Manufacturer and Model values coming from a device? For more and more devices, especially ones with multiple endpoints, these qualifiers are essential to the fingerprints, but they don’t show up in the Hub Event’s “desc:” entry…?

Great question. If the fingerprint contains manufacturer and model then you can read the values from within the device handler with code like this device.getDataValue("manufacturer"). I don’t remember if this is part of the documented API but it is in some of the device handlers in SmartThingsPublic. If you don’t know the Manufacturer and Model and its not in the fingerprint then I’m not sure if there is currently a way for you to get at that info. I’ll talk to the team about exposing that information because it’s definitely really useful info to have.

1 Like

Great Tom! With both “mystery” and “custom” ZigBee device development, the more information we can get in the Hub Event log (or wherever?) during the join process – and beyond – the better. Ideally we could put the Hub into “debug mode” and have it show extreme levels of detail of the raw messages it is receiving… i.e., I find it tremendously comforting to see “real text” like Manufacturer and Model right in the join attempt, as it is a warm-feeling confirmation that the device and SmartThings will communicate…

1 Like

This is a really good idea to see that info as part of the join events. Maybe the below commands/messages could be part of the join process for “Things” that don’t find a fingerprint.

Both manufacturer and model come from the Basic cluster in zigbee, so for writing a new devicetype you could use the below commands and it should print the response in the Live Logs since it will be an unrecognizable message and bypass the auto-parse:

To get manufacturer info:

To get model info:


Tom, if you guys do add end point support for calling the new API can you also include it in the inbound parse method. This is a bigger deal as you guys completely strip the source end point for some ZigBee cluster reports like temperature. Here is a thread where I discuss this ZigBee Temperature reporting question for Cluster 0x402 - #3 by pstuart

Text from previous thread follows:

With a ZigBee device there are two ways to get information out of a cluster’s attribute. The first way is to send a read attribute command to the cluster and endpoint’s address . That is what the poll method is often used for in the custom device type. And this works great no problems! I can read the temperature of both end points all day long!! They come in like this:

description: catchall: 0104 0402 39 01 0C40 00 0509 00 00 0000 01 01 000000290080

The second way to get information from a ZigBee device is to configure its reporting, and bind to the cluster / endpoint. That is what happens when the configure method fires. Once a ZigBee device has been configured to report one of its attributes and has been bound to the hub it will send reports from that point on. This also works for me I can bind to the two temperature end points and they both send reports to the hub. The problem is instead of the catcall string I was getting above what I get is this:

description: temperature: 35.00

That would work for me except I have two thermostats in this device and they both report on unique endpoints. In the above description I don’t get the endpoints. So I cant match up the value to the correct probe.

It looks like there is a method parsing the temperature report and handing me the result instead of passing the whole packet like in the catchall above. IF I could find a way to get the endpoint of that report I will be good to go!!


I’m sure you know this but just to state it, there are several off the shelf ZigBee certified products that require unique end points to function properly. For example, this dual relay from smartenit use a unique end point for each relay.

Thanks very much for the response!


That’s a good point and definitely required in order to allow device handlers to really support devices with multiple endpoints. I will make sure we have an internal ticket for that.


Hi Tom

Has there been any progression on this. Looking at the diagnostics it still just find the first match with the fingerprint. Is there going to be multiple end point support soon or at least the ability to unpublish a device handler so when I make a new iteration ST doesn’t just keep selecting the old iterations fingerprint when adding new device.



Hi Cam,

There is a change going through QA right now to try to fingerprint each endpoint until a matching Device Type Handler is found instead of giving up after the first endpoint and leaving the device as a “Thing”. I’m not sure that would help in your situation. Are you trying to fingerprint on an endpoint that isn’t the first one? Or are you trying to send and receive messages from multiple endpoints?


1 Like

Hi Tom

That’s great to hear should be a useful feature. I managed to get mine working fine. The main issue is if I create a version 1 of code with one end point, publish it and test it. Now knowing that version 1 works I want to add another end point, so I copy my code and create a version 2 piece of code with 2 end points and publish to test. When I try to pair the device with the ST hub, the hub will always go to version 1. A useful feature would be to have the ability to unpublish version 1. Because the current alternatives are to copy the code to another site and delete the code from the ST site or go in and comment out the fingerprint of version 1. These are ugly solutions to a potential unpublish button on the my device handlers page.



1 Like

This is what typically do but I agree that it’s not optimal. I filed a ticket to make sure it’s our on dev tools team’s radar.


Wondering if there’s been any advancement on handling attribute reporting on multiple endpoints? Sure would be useful…


On the multiple endpoint front, we released the ability to fingerprint on any endpoint that I mentioned earlier, plus we’ve added the ability to send commands like zigbee.readAttribute and zigbee.command to different endpoints. That was possible before with the legacy st rattr and st cmd commands but not with the zigbee.* commands. We also added the ability to send manufacturer specific commands to different endpoints which previously wasn’t possible, even with use of the legacy raw command.

As for including the endpoint in the attribute reports, it’s a lot more complicated to implement without breaking backwards compatibility so it’s not something we’ve made much progress on yet.


Great :smiley: Is there documentation for this on the docs?

Any update on possibly supporting group broadcast messages? It really holds ST back vs dedicated zigbee systems like Hue and Lightify.


It hasn’t been published yet but it is coming

1 Like

No updates on this yet

1 Like


In this post you say you can use zigbee.readAttribute against a different endpoint but this doesn’t seem to be documented anywhere. Can you point me to some docs?

I have a device where I am pretty sure everything I need is in the second endpoint, or atleast not in the primary endpoint that smart things attaches too. There seems to be very little documentation about accessing other endpoints.

We are still finalizing the documentation changes but you can target a different endpoint by passing destEndpoint into additionalParams. For example, to read the Current Level from the Level Control Cluster on endpoint 2:

zigbee.readAttribute(0x0008, 0x0000, [destEndpoint: 0x02])

You can pass destEndpoint in a similar way to zigbee.writeAttribute, zigbee.command, and zigbee.configureReporting.