[Question] Strategy for manufacturer-specific attributes in standard clusters?

As already mentioned in my last pull request, I am implementing support for some ubisys devices at the moment. To e.g. calibrate their shutter controller to the run-time from fully open to fully closed, they use quite a lot of manufacturer-specific attributes within standard clusters (e.g. attributes 0x1000 and up in closuresWindowCovering). Currently, I have these implemented as numeric values in code but thought it might be nicer to have them somewhere in a central location, but could not really figure out an obvious way to do it. One idea is to implement them in additional clusters that have numerical ids with the manufacturer id as upper bytes, e.g. for ubisys (manufacturer id is 0x10f2) and the cluster closuresWindowCovering (258 = 0x102) it would be 0x10f20102 = 284295426. But even this would mean that I will need to touch quite some central code inside zigbee-shepherd and zigbee2mqtt to implement it correctly…
Do you have any opinion or suggestions for me or should I rather stick with the way I have it implemented currently?

Current implementation in my code: https://github.com/felixstorm/zigbee2mqtt/blob/f41f754135f918a9b60ad14501311e48f5ae1114/lib/extension/ubisys.js#L166 ubisys documentation (if interested): https://www.ubisys.de/wp-content/uploads/ubisys-j1-technical-reference.pdf

Thanks, Felix

[felixstorm]

Sorry for the delay, just came back from vacation.

Option 2 without the zigbee object could probably work if the array returned from the converters is allowed to contain both objects to publish to zigbee as well as promises which would then all be processed sequentially so that we can write an attribute, wait, send a command, wait etc.

[felixstorm]

Great, sounds very good to me! If you find a way to also take care of manufacturer-specific properties inside standard clusters that would sure be helpful as well (so we won’t get in trouble in case of duplicate attribute ids either).

I’ll then go ahead with my personal implementation for now and will update it to the new spec as soon as it is available.

Thanks, Felix