Binary Value Cluster Attributes not supported?

Hi Community!
I am trying to implement the Binary Value Cluster on my sensor device. The Device also has a buzzer, which will sound when a curtain measurement level is reached. Via the before mentioned Binary Value cluster im planing to set a system variable in order to disable and (re)enable the buzzer.

So far I implemented the Cluster with all mandatory Attributes plus a few extra, all part of ZCL specs. In deCONZ only three attributes are shown properly, the rest is grey, means unsupported.

Have a look:

I double checked my attribute`s IDs and accessibility options with those of the Zigbee ZCL specs aswell as those in the general.xml file in the deCONZ/zcl subfolder.
What am I missing, do you have any ideas?

Greetings, frank

Are you sure the device is whitelisted in deCONZ?

Ih Mimiix,
thanks for your reply!

No, Im creating this device myself. As you could see in the picture i implemented the temperature, the humidity and the analog input clusters aswell. In these clusters all attributes, that i implemented are supported by deCONZ, which means Im able to read them repeatedly and write them (if allowed).

What i forgot to mention is, that even the greyed out attributes of the binary value cluster are read at least once. I checked this by changing their initial values.
Btw: where can i find this Whitelist, Id like to have look on it.

frank

A Dev needs to answer that. So i can’t say.

@smanar perhaps?

Here is the ZCL Debug output when reading the attributes the first time:

14:59:45:160 ZCL read cluster: 0x0011, attribute: 0x0004
14:59:45:160 ZCL cmd-req nwk: 0x7F4F, profile: 0x0104, cluster: 0x0011 cmd: 0x00
14:59:45:186 ZCL read cluster: 0x0011, attribute: 0x001C
14:59:45:186 ZCL cmd-req nwk: 0x7F4F, profile: 0x0104, cluster: 0x0011 cmd: 0x00
14:59:45:374 ZCL got data for node=0x7F4F, cl=0x0011, at=0x0004, status=0x00, type=0x42
14:59:45:395 ZCL read cluster: 0x0011, attribute: 0x002E
14:59:45:395 ZCL cmd-req nwk: 0x7F4F, profile: 0x0104, cluster: 0x0011 cmd: 0x00
14:59:45:415 ZCL got data for node=0x7F4F, cl=0x0011, at=0x001C, status=0x00, type=0x42
14:59:45:428 ZCL read cluster: 0x0011, attribute: 0x0042
14:59:45:428 ZCL read cluster: 0x0011, attribute: 0x0043
14:59:45:429 ZCL read cluster: 0x0011, attribute: 0x0051
14:59:45:429 ZCL read cluster: 0x0011, attribute: 0x0055
14:59:45:430 ZCL cmd-req nwk: 0x7F4F, profile: 0x0104, cluster: 0x0011 cmd: 0x00
14:59:45:436 ZCL got data for node=0x7F4F, cl=0x0011, at=0x002E, status=0x00, type=0x42
14:59:45:456 ZCL read cluster: 0x0011, attribute: 0x0067
14:59:45:457 ZCL read cluster: 0x0011, attribute: 0x0068
14:59:45:457 ZCL read cluster: 0x0011, attribute: 0x006F
14:59:45:457 ZCL read cluster: 0x0011, attribute: 0x0100
14:59:45:458 ZCL cmd-req nwk: 0x7F4F, profile: 0x0104, cluster: 0x0011 cmd: 0x00
14:59:45:478 ZCL got unsupported status: 0x86 for mandatory attribute
14:59:45:479 ZCL got data for node=0x7F4F, cl=0x0011, at=0x0042, status=0x86, type=0x00
14:59:45:479 ZCL got unsupported status: 0x86 for mandatory attribute
14:59:45:479 ZCL got data for node=0x7F4F, cl=0x0011, at=0x0043, status=0x86, type=0x00
    **14:59:45:480 ZCL got data for node=0x7F4F, cl=0x0011, at=0x0051, status=0x00, type=0x10**

** 14:59:45:480 ZCL got unsupported status: 0x86 for mandatory attribute**
** 14:59:45:480 ZCL got data for node=0x7F4F, cl=0x0011, at=0x0051, status=0x86, type=0x10**
14:59:45:481 ZCL got data for node=0x7F4F, cl=0x0011, at=0x0055, status=0x00, type=0x10
14:59:45:481 ZCL got unsupported status: 0x86 for mandatory attribute
14:59:45:482 ZCL got data for node=0x7F4F, cl=0x0011, at=0x0055, status=0x86, type=0x10
14:59:45:500 ZCL got unsupported status: 0x86 for mandatory attribute
14:59:45:500 ZCL got data for node=0x7F4F, cl=0x0011, at=0x0067, status=0x86, type=0x00
14:59:45:501 ZCL got unsupported status: 0x86 for mandatory attribute
14:59:45:501 ZCL got data for node=0x7F4F, cl=0x0011, at=0x0068, status=0x86, type=0x00
14:59:45:502 ZCL got data for node=0x7F4F, cl=0x0011, at=0x006F, status=0x00, type=0x18
14:59:45:502 ZCL got unsupported status: 0x86 for mandatory attribute
14:59:45:503 ZCL got data for node=0x7F4F, cl=0x0011, at=0x006F, status=0x86, type=0x18
14:59:45:503 ZCL got data for node=0x7F4F, cl=0x0011, at=0x0100, status=0x00, type=0x23
14:59:45:503 ZCL got unsupported status: 0x86 for mandatory attribute
14:59:45:504 ZCL got data for node=0x7F4F, cl=0x0011, at=0x0100, status=0x86, type=0x23

As you can see in the lines I marked deCONZ first receives the attribute with status=0x00 (succcess, I guess) but also receives the sama attribute with status=0x86 (which should mean it`s unsupported I think).

Any Ideas on that one?

Sorry, my last post was not formated as intended. The mentioned lines are:

14:59:45:480 ZCL got data for node=0x7F4F, cl=0x0011, at=0x0051, status=0x00, type=0x10 14:59:45:480 ZCL got unsupported status: 0x86 for mandatory attribute 14:59:45:480 ZCL got data for node=0x7F4F, cl=0x0011, at=0x0051, status=0x86, type=0x10

Can be just this device not support this attribute, no ? 0x86 mean “unsupported_attribute”

Hi Smanar,
since this device is under development I assume that the cluster has not been implemented correctly either by me (or by dresden elektronik).
How are the following lines of ZCL debug output in deconz generated:

14:59:45:481 ZCL got data for node=0x7F4F, cl=0x0011, at=0x0055, status=0x00, type=0x10
14:59:45:481 ZCL got unsupported status: 0x86 for mandatory attribute
14:59:45:482 ZCL got data for node=0x7F4F, cl=0x0011, at=0x0055, status=0x86, type=0x10

Do I have to change something in rest-plugin? Might there be something else I did not yet consider when implementing the cluster?

Here are my attributes´ declarations:

#define ZB_SET_ATTR_DESCR_WITH_ZB_ZCL_ATTR_BINARY_VALUE_ACTIVE_TEXT_ID(data_ptr)
{
ZB_ZCL_ATTR_BINARY_VALUE_ACTIVE_TEXT_ID,
ZB_ZCL_ATTR_TYPE_CHAR_STRING,
ZB_ZCL_ATTR_ACCESS_READ_WRITE,
(zb_voidp_t) data_ptr
}
/** Description, see ZCL specification 3.14.11.4. /
#define ZB_SET_ATTR_DESCR_WITH_ZB_ZCL_ATTR_BINARY_VALUE_DESCRIPTION_ID(data_ptr)
{
ZB_ZCL_ATTR_BINARY_VALUE_DESCRIPTION_ID,
ZB_ZCL_ATTR_TYPE_CHAR_STRING,
ZB_ZCL_ATTR_ACCESS_READ_WRITE,
(zb_voidp_t) data_ptr
}
/
* InactiveText, see ZCL specification 3.14.11.13. /
#define ZB_SET_ATTR_DESCR_WITH_ZB_ZCL_ATTR_BINARY_VALUE_INACTIVE_TEXT_ID(data_ptr)
{
ZB_ZCL_ATTR_BINARY_VALUE_INACTIVE_TEXT_ID,
ZB_ZCL_ATTR_TYPE_CHAR_STRING,
ZB_ZCL_ATTR_ACCESS_READ_WRITE,
(zb_voidp_t) data_ptr
}
/
* OutOfService, see ZCL specification 3.14.11.1. */
#define ZB_SET_ATTR_DESCR_WITH_ZB_ZCL_ATTR_BINARY_VALUE_OUT_OF_SERVICE_ID(data_ptr)
{
ZB_ZCL_ATTR_BINARY_VALUE_OUT_OF_SERVICE_ID,
ZB_ZCL_ATTR_TYPE_BOOL,
ZB_ZCL_ATTR_ACCESS_READ_WRITE,
(zb_voidp_t) data_ptr
}

/** PresentValue, see ZCL specification 3.14.11.2. /
#define ZB_SET_ATTR_DESCR_WITH_ZB_ZCL_ATTR_BINARY_VALUE_PRESENT_VALUE_ID(data_ptr)
{
ZB_ZCL_ATTR_BINARY_VALUE_PRESENT_VALUE_ID,
ZB_ZCL_ATTR_TYPE_BOOL,
ZB_ZCL_ATTR_ACCESS_READ_WRITE | ZB_ZCL_ATTR_ACCESS_REPORTING,
(zb_voidp_t) data_ptr
}
/
* StatusFlags, see ZCL specification 3.14.11.3. /
#define ZB_SET_ATTR_DESCR_WITH_ZB_ZCL_ATTR_BINARY_VALUE_STATUS_FLAGS_ID(data_ptr)
{
ZB_ZCL_ATTR_BINARY_VALUE_STATUS_FLAGS_ID,
ZB_ZCL_ATTR_TYPE_8BITMAP,
ZB_ZCL_ATTR_ACCESS_READ_ONLY | ZB_ZCL_ATTR_ACCESS_REPORTING,
(zb_voidp_t) data_ptr
}
/
* ApplicationType, see ZCL specification 3.14.11.19. */
#define ZB_SET_ATTR_DESCR_WITH_ZB_ZCL_ATTR_BINARY_VALUE_APPLICATION_TYPE_ID(data_ptr)
{
ZB_ZCL_ATTR_BINARY_VALUE_APPLICATION_TYPE_ID,
ZB_ZCL_ATTR_TYPE_U32,
ZB_ZCL_ATTR_ACCESS_READ_ONLY,
(zb_voidp_t) data_ptr
}

Thanks for your help in advance.

For me you are fine

14:59:45:481 ZCL got data for node=0x7F4F, cl=0x0011, at=0x0055, status=0x00, type=0x10
14:59:45:481 ZCL got unsupported status: 0x86 for mandatory attribute

the type 0x10 is the bool

I don’t see something bad, can be just the device that don’t support this attribute.

I was able to test this behavior with another Conbee2 stick of a colleague. Unfortunatly the results were the same. Only three Attributes of the BinaryValue cluster appear as being supported in deconz.
Considering deCONZ, I am using its latest version for windows: v2.12.6
The Conbee2 firmware version is: 26580700

Further ideas are still appreciated. :slight_smile:
Greetings, frank

But can be normal.
It can can come from the device, are you sure it is able to use thoses attribute ?

Sure, I am developing this device.
But this is the thing: I am validating my implementation via its effects on the deCONZ GUI.

By the way, is there a guide how to integrate a custom cluster with all its attributes and stuff so that deconz can deal with it?

Ha ok, so it’s not the same thing.
You have something to sniff the zigbee traffic (an external way at the device and deconz) ? The code part in the firmware that use thoses attributes ?

By the way, is there a guide how to integrate a custom cluster with all its attributes and stuff so that deconz can deal with it?

You mean make a DIY device with custom cluster ?

Edit:
Now I remember an issue on Doorlock, it’s a long story but to resume, how are you asking attributes ?
Avoid the “read” button, that ask for all attributes, but try a not working attribute direclty, alone (at the start, all attribute are “askable”, just before they was disabled)
Doorlock device are end-device, less robust than router, so I don’t think you have the same issue but it s something easy to try.

Hell yeah, this did the trick! But Im curious what is the reason for it, since I have set it up as mains powered router device…

Exactly, I did not find something like this in this forum or the github pages.

You have set it as mains powered, but it s a real one ?
And some battery powered device don’t have this problem, I have see it only on doorlock devices and battery siren for the moment, but other need to be awaked.

As DIY project you have this one too https://github.com/diyruz/flower

I checked all declarations and function calls related to the device`s definition as a Router. Also, I double checked how the power management of the device is handled and as far as I can tell it should never go into a sleepy state but stay idle (waiting for events) with rx_on_when_idle set TRUE.
At this point I am absolutely clueless why the BinaryValue cluster isnt read proberly… :disappointed:

Concerning a custom cluster:
Is there a step by step guide on what to add where (e.g. cluster description in general.xml, modifications in deconz_rest_plugin etc.) so it is proberly read in the deCONZ GUI?

But is can come from the hardware, the device don’t use battery at all ?
The difference can come how deconz ask for attribute, it can ask attributes 1 by 1 or many in the same request.

Is there a step by step guide on what to add where (e.g. cluster description in general.xml, modifications in deconz_rest_plugin etc.) so it is proberly read in the deCONZ GUI?

I m not sure to understand, but here you have an exemple for a modification to make deconz able to use a custom cluster, the SOIL_MOISTURE_CLUSTER_ID https://github.com/dresden-elektronik/deconz-rest-plugin/pull/5209

Hi Smanar, the mentioned github project has what Im looking for. Big Thanks!
I`ll have to setup a linux VM first, before going over to add all the necessary stuff for my device…

Back to the Binary Value Cluster problem:
My device is always turned on by hanging on an usb cable. When I was sniffing the traffic during a general read of all the cluster`s attributes, a big pile of read attribute (requests) were sent to a device ID which doesnt exist in the network.
Here I marked this block:

After the block is done, for the first three attributes read attribute requests are generated and answered by my sensor device.
Could this be a problem?

The zigbee network during all of this: