Problem reading custom cluster 0xFF66

[vk496]

Hello,

Some days ago my device stopped reading or reporting any attribute from custom cluster (0xFF66). I thought the problem come from the library where I was creating support for this device (Z2M, Koenkk/zigbee-herdsman-converters#3493 (comment)) but the maintainer confirmed me that when I receive a UNSUPPORTED_ATTRIBUTE, it comes from the device itself. An example:

Error: Read 0xfffffanfdadfadf/1 liXeePrivate(["currentTarif"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":4151,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Status 'UNSUPPORTED_ATTRIBUTE')

The firmware is v4. Already tried to reflash the device by serial.

Someone else have the same issue? Any way to debug what/why is happening?

Thanks in advance

[drlibre]

Bonjour,
Problème aussi de lecture du cluster oxff66 avec ConbeeII et l'intégration ZHA de Home Assistant: aucun attribut disponible pour le cluster oxff66.
Zlinky flashé en V4.0 via OTA (sans problème).
Zlinky supprimé puis réappairé, le problème subsiste...

[kfran78]

On se parle de quelle entitée au final ? Suis aussi en V4 et même config hardware.

[vk496]

@drlibre it was working to you before?

@kfran78 any attribute that come from 0xFF66 cluster

[drlibre]

@vk496 No, it didn't work in V3.0. I've been told that it would in V4.0 but it seems not...

[kfran78]

@drlibre it was working to you before?

@kfran78 any attribute that come from 0xFF66 cluster

Nope.

[kikili]

I have the same issue with ZHA but only if I try to define the attributes in a quirk. If I don’t define those attributes then I can read them by issuing a read command directly. It means then I have to use zha.toolkit to get their value in HA as the list of attributes is not exposed

[kikili]

I described my issue here, as I thought too it was an integration issue :
zigpy/zha-device-handlers#1321

[vk496]

In my case, it just happened from one day to other. I was not sure why it was not possible to read that attributes from 0xFF66 cluster.

At the beginning I thought it was something related with Z2M when I was developing the integration, but after @Koenkk confirmed me that this message comes from the device itself. So....

• I don't know why it happens
• Is not related with the platform used (@kikili confirm that in ZHA too)
• Is not clear how to reproduce it

However, @kikili you say that you are able to read them? what is the difference of setting up a quirk or not?

[vk496]

@fairecasoimeme I found the problem for this.

Koenkk/zigbee2mqtt#11431 (comment)

The device is not answering when the request is sent with Manufacturer specific flag in the ZCL header. I think Zigbee standard requires it for vendor specific clusters like 0xFF66.

Right now what I do in Z2M is forcing the requests without that header

[kikili]

@vk496 Nice Job
@fairecasoimeme Will you release soon a new firmware correcting that issue or should we put that in quirks (for ZHA I mean as they already do the the job for MQTT)?

[fairecasoimeme]

Hi, I have to verify and see the impact on all the plugins.
There is the same issue on ZHA ?
If you can fix with plugin, I think it's better for all plugins

[kikili]

Well I’m pretty new with zha and not sure how I can override the fact it writes manufacturer specific flag in the quirk. Btw as it is supposed to be the spec. should it not be better to have it right at the source ?

[Hedda]

There is the same issue on ZHA ?
If you can fix with plugin, I think it's better for all plugins

Well I’m pretty new with zha and not sure how I can override the fact it writes manufacturer specific flag in the quirk. Btw as it is supposed to be the spec. should it not be better to have it right at the source ?

FYI, this is still an issue for ZHA and according to the developers there it will need to be fixed by @fairecasoimeme in ZLinky_TIC firmware as per dicussions zigpy/zha-device-handlers#1165 (which mention this as blocker) and zigpy/zha-device-handlers#1146