Format of Zigbee catchall description

I am writing a device type handler for a Color Temperature Light Zigbee device. This uses the On/Off, Level Control and Color Control clusters.

This is mostly working but some of the descriptions I receive in the parse() method don’t make sense to me.

For example, after a Move to Level command, I see this:

catchall: 0104 0008 0A 01 0140 00 EC9A 00 00 0000 0B 01 0400

zigbee.parse decodes this as:

SmartShield(clusterId: 0x0008, command: 0x0b, data:
[0x04, 0x00], destinationEndpoint: 0x01, direction: 0x01,
isClusterSpecific: false, isManufacturerSpecific: false, manufacturerId:
0x0000, messageType: 0x00, number: null, options: 0x0140, profileId:
0x0104, senderShortId: 0xec9a, sourceEndpoint: 0x0a, text: null)

This command 0x0B doesn’t make sense to me. That doesn’t seem to be a valid command ID for cluster 8.

I see this for most commands, andI notice that the data field always seems to contain the command ID of the command I just executed.

Is this some sort of an acknowledgment of the command which the hub is just passing on?


Bill, what device are you communication with? For the custom device types I have created I had to get a good understanding of the ZigBee traffic before I wrote any device type code. This way I knew what the SmartThings Hub was trying to tell me. If this is a Hue bulb or another ZigBee device I have on my network I would be happy to send a set level command and see what it is returning.

Hi John,

It’s a new device, in development. It’s a ZigBee Light Link profile, “Color Temperature Light”. This is similar to a GE Link which is a “Dimmable Light” but the Color Temperature Light also supports some functions in the Color Control cluster.

The GE Link sends the same messages I’m referring to. For example, after a setLevel(48) command, it responds with:

catchall: 0104 0008 01 01 0000 00 6E59 00 00 0000 0B 01 0400

As I understand it, the catchall responses are sent when the hub doesn’t know how to interpret a Zigbee message it receives from the device. I just don’t know the format of the catchall description.

I suspect these are either some sort of acknowledgment of the commands sent or they may be reports. The GE Link driver sets up reports but I don’t see them handled in the parse() method.

I notice a strange thing in the GE Link device type handler. In the parse function, it decodes the “read attr” message which comes back from the refresh operation, but it does not seem to get a read attr message for the on/off value. Instead it gets a catchall which it is decoding to get the on/off value. Not sure why the read attr for on/off generates a catchall while the read attr for the level generates a “read attr” response.

Do you see any catchall responses with the Hue bulbs?

I think I figured this out.

When the messageType=0, the commandId is decoded as a General Command Frame.

These mysterious messages are the “Default Response” coming back from the other commands issued.

And the reports from the device come back as commandId=0xA which is the “Report Attributes” command.