Oh, interesting. So, what is happening is that the button is reporting the same attribute twice in the same message (cluster 0x0006 attr 0x0000) with both the 0 value (off) and the 1 value (on). Previously we had what I would call a bug in that we were stripping that second attribute value out and instead just sending it as an on/off message. Now that we have expanded the capabilities of our messaging to handle more messages properly, when I go to convert it to existing messages for backwards compatibility, it’s not matching what an “on/off” message would be because it has 2 attribute values included. I’ll have to think about to handle this as the previous behavior was a bug, but it was a bug that people developed against. In the mean time if you use
zigbee.parseDescriptionAsMap(description)
you should get back something that looks like
[raw:48A4010006100000100000001001, dni:48A4, endpoint:01, cluster:0006, size:16, attrId:0000, result:success, encoding:10, value:00, additionalAttrs:[[attrId:0000, attrInt:0, encoding:10, value:01, isValidForDataType:true, consumedBytes:8]], isValidForDataType:true, clusterInt:6, attrInt:0]
which includes both values for the attribute (one in “value” and one in “additionalAttrs”). Also use of zigbee.getEvent should generate an switch event based on the first attribute listed.