Hubitat custom driver using zigbee.writeAttribute() and getting a parse() catchall

I was debugging this "issue" for quite a while with whenever I used zigbee.writeAttribute(), it would come into the parse() catchall, and I couldn't figure out why it kept bouncing out of parse() from the catchall.

Ultimately -- the catchall is benign -- your packet went out just fine.

So, for example, in my driver code:

def write_custom_attr_value(value) {
    def cmds = []
    cmds += zigbee.writeAttribute(0xFCAE, 0x0040, DataType.UINT16, value, [:], 200)
    cmds += zigbee.readAttribute(0xFCAE, 0x0040, [:], 0)
    return cmds

def parse(String description) {
    if (logEnable) log.debug "parse() ${description}"
    if (description.startsWith("catchall")) return                    // not something we can handle
    def descMap = zigbee.parseDescriptionAsMap(description)
    if (logEnable) log.debug "parse() DescMap: ${descMap}"
    // ... normal packet

In the log, I would see these lines, this being the successful zigbee.readAttribute():

2020-04-22 02:18:33.745 pm [debug] parse() DescMap: [raw:D6D40AFCAE0C4000210F27, dni:D6D4, endpoint:0A, cluster:FCAE, size:0C, attrId:0040, encoding:21, command:01, value:270F, clusterInt:64686, attrInt:64]

... and this being the zigbee.writeAttribute() landing in the catchall:

2020-04-22 02:18:33.539 pm [debug] parse() catchall: 0104 FCAE 0A 01 0040 00 D6D4 00 00 0000 04 01 00

I watched debugging at my zigbee device, and the written attribute came into there OK.

I found that all zigbee.writeAttribute() seem to always be prefixed by "0104 " in the ${description}, so, I'm wondering if after the catchall, to see if it is prefixed by "0104 ", and then to also do a return without logging anything.

0104 is the zigbee profile Id, the catchall here is likely the device response to the write attribute command (though I didn't take the time to decode it...)
It would be a bit easier to decode if parsed using parseDescriptionAsMap...

1 Like

The parseDescriptionAsMap gives this

2020-04-22 05:02:19.880 pm [debug] parse() [raw:catchall: 0104 FCAE 0A 01 0040 00 D6D4 00 00 0000 04 01 00, profileId:0104, clusterId:FCAE, clusterInt:64686, sourceEndpoint:0A, destinationEndpoint:01, options:0040, messageType:00, dni:D6D4, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:04, direction:01, data:[00]]

which I suppose can be determined to be a write by the direction value?

Command tells you what's going on, direction is obvious as everything sent to parse is data from the device...

1 Like

Thanks! I'll inspect for a non-null "command" map member containing "04".