[Question] Writing Zigbee attribute value in Octet format (0x41)?

Heya all,

According to the documentation, zigbee.writeAttribute() doesn’t support octet format (0x41),

How does the SmartThings “st wattr” command expect the octet? with commas? a list? separated by commas? just the octet with spaces?

“st wattr 0x${device.deviceNetworkId} 1 0 0xFFF0 0x41 {octect_payload}”

where octect_payload might be:

  • 0xaa, 0x10, 0x05, 0x41, 0x47, 0x01, 0x01, 0x10, 0x01
  • [0xaa, 0x10, 0x05, 0x41, 0x47, 0x01, 0x01, 0x10, 0x01]
  • 0xaa 0x10 0x05 0x41 0x47 0x01 0x01 0x10 0x01
  • [0xaa 0x10 0x05 0x41 0x47 0x01 0x01 0x10 0x01]


There is a some older documentation at https://stdavedemo.readthedocs.io/en/latest/device-type-developers-guide/building-zigbee-device-handlers.html if that helps.

Hey Graham,

Thanks for that one, I do have it on my favorites as a good old source of info :stuck_out_tongue:

I can’t seem to find just one zigbee attribute in my devices with an octet value to see how it comes in the catchall. And I don’t wanna spend more money in either a CC2231 with Zigbee2Mqtt or the ConBee with DeConz just to see what’s there and find a octet value field :frowning: (Might be a good investment though if I’m gonna keep going the zigbee train :stuck_out_tongue: )

Maybe @nayelyz would know how the format is expected :slight_smile: ?

Hi, there! I’ve talked with our engineering team about your question, the suggestion is using zigbee.writeAttribute with DataType.pack. It would be something similar to:

zigbee.writeAttribute(cluster_id, attr_id, DataType.UINT16, DataType.pack(0xDEAD, DataType.UINT16))

0xDEAD would be the hole payload you receive in hex.


Thanks @nayelyz! will give it a try :slight_smile:

Hey @nayelyz !

Sorry it took me a while to test this, I had to circumvent somehow the other problem first (that runEveryXXMinutes() no longer works).

Unfortunately it doesnt work,

doing this:

zigbee.writeAttribute(0x0000, 0xFFF0, DataType.UINT16, DataType.pack("0xaa, 0x80, 0x05, 0xd1, 0x47, 0x07, 0x01, 0x10, 0x01", DataType.STRING_OCTET))

gives the following error:

java.lang.IllegalArgumentException: Currently data type 65 is not supported @line 357 (refresh)

Packing the data doesn’t seem to do the trick, and it still doesnt make sense to me, why would I attempt to write in UINT16, if the expected type is STRING_OCTET? Or am I missing something from the example?

The docs do say that DataType.pack() ONLY supports STRING_CHAR for variable lengths types, so if STRING_OCTET is of variable length (which I guess it is), I don’t understand why engineering would recommend using the pack() method.

If the last comment I made is correct (pack() doesnt support STRING_OCTET), then I guess I have to go back to the original question, on how does “st wattr” expect a STRING_OCTET value? like this?:

st wattr 0x${device.deviceNetworkId} 1 0 0xFFF0 0x41 "0xaa, 0x80, 0x05, 0xd1, 0x47, 0x07, 0x01, 0x10, 0x01"


Edit 1: yup its definitely of variable length, by doing:

zigbee.readAttribute(0x0000, 0xFFF0, [mfgCode: 0x115F])
trace.log "Unknown cluster number ${descMap.cluster} with attribute Id ${descMap.attrId} has been detected with value ${descMap.value}"

I got:

trace Test 1: Unknown cluster number 0000 with attribute Id fff0 has been detected with value 00
warn Unhandled variable length attribute, assuming a single attribute.

So zigbee.writeAttribute() cannot be used, dataType.pack() cannot be used, and probably I’m stuck on using “st wattr”, but it bears the question again on how to properly pass a STRING_OCTET to it, and now with a specific mfgCode (as I haven’t seen/found an example of “st wattr” targeting a manufacturer specific cluster).

Edit 2:

Well, I found a hidden reference in a post of apr’ 2020 on hubitat, which theoretically this should work for the mfgCode, but not yet sure on the STRING_OCTET:

st wattr 0x${device.deviceNetworkId} endpoint cluster attribute datatype {data} mfgCode

Hi, @Chares :smiley:
Our enginnering dept. reviewed the information you gave and this is their feedback:

  • You’re right, the “pack” won’t work for STRING_OCTET, the suggestion now is as follows:
zigbee.writeAttribute(0x0000, 0xFFF0, DataType.STRING_OCTET, "09AA8005D14707011001")

Note: the 09 at the beginning is added because the STRING_OCTET data type defines the first byte as length. This is not necessary if the device already has a process to get this value.

  • If you want to keep using st wattr, the data portion would be { 09AA8005D14707011001 } as you mention in your last edit.
  • The mfgCode is only used when the command needs to be manufacturer-specific.
1 Like

Hey @nayelyz, thnkas for the answer :slight_smile:

Unfortunately as mentioned earlier zigbee.* doesn’t support variable lenghts except for STRING_CHAR, that’s why my insistance on using “st wattr” though considered ‘legacy’, unfortunately zigbee.* doesnt yet support all dataTypes :frowning:

Thanks for the example! (that now makes more sense, no 0x in the string, all concatenated, and most likely in little Endian).

1 Like