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.
