Closed sjorge closed 2 weeks ago
Found a workaround for now, as I only need to write and not read, I can just do manual write datatype all provided.
Would be nice to have a way to handle this cleanly in the future somehow though. I guess adding a unique ID to the cluster definition and somehow having the zhc device definition say use this one for me would work.
Since this is the first time we encounter such thing and we can get around it with the manual read/write I propose to not do anything for now (it will have quite some impact on the code base I think).
Can we start a know limitstion list somewhere to track these things? I find it hard to believe I'm the first to hit this.
Yes, I've put the dont-stale
label and will link all similar issues here.
Interesting problem I am hitting,
For the Ubisys H10 we added manuSpecificUbisysHeatingRegulatorThermostat which is the same ID as hvacThermostat but with the ubisys manufacturer code, it has a bunch of H10 specific attributes.
For the Ubisys H1 they just introduce setting vacation mode, it's also on the hvacThermostat cluster ID with ubisys manufacturer code.
Because they both use H10 and H1 use hvacThermostat + ubisys manufc code for custom attribute there is a collision:
https://github.com/Koenkk/zigbee-herdsman/blob/e54db7a20bb442d8be7bef2de837772cdcbfaec3/src/zcl/definition/cluster.ts#L4273C1-L4273C66
Adding a 2nd one with the attribute for the H1 causes issues in zh, also just adding a duplicate attribute obviously doesn't work either.
How do we resolve this cleanly?
Edit: pending hearing back from them on the attribute type, I think boolean or uint8, def not struct.