GH-34: Expose Z-Wave Generic and Specific Device Class#35
GH-34: Expose Z-Wave Generic and Specific Device Class#35silabs-borisl wants to merge 1 commit intoSiliconLabs:mainfrom
Conversation
Forwarded: SiliconLabs#34 Bug-SiliconLabs: UIC-3224 Bug-Github: SiliconLabs#34
UCL precision is now always 2 whild Zwave is trying to adapt to the UCL precision.
UCL precision is now always 2 whild Zwave is trying to adapt to the UCL precision.
nobriot
left a comment
There was a problem hiding this comment.
We (used to) recommend to have a separate proprietary cluster for things specific to a technology that does not fit in the ZCL, like described in the documentation
Also it kind of feels wrong to have Z-Wave... in the shared clusters, now applications start to see some of the details that Unify is supposed to abstract.
Further, I would argue that this information is not needed for any application to achieve what they need. 😁 But you decide 😉
|
Hi @nobriot, We didn't come to an satisfying solution to this problem. For example in this PR : https://github.com/SiliconLabs/UnifySDK/pull/33/files#diff-cf34b875af33637282939b69e5153da28622226044225d7dc32824b84254fc1c we should not add those properties into the FanControl cluster directly but in our Z-Wave proprietary cluster alongside the others attributes we could not fit anywhere ? |
We also had this problem earlier, and we would recommend to have Z-Wave non-fitting functionalities be put in separate proprietary cluster, rather than extending the standard clusters. As a IoT service developer, I would prefer not to have to understand or be exposed to Z-Wave functionalities. If I want to get started with Unify, after this change, the basic ZCL cluster would show me Z-Wave functionalities and I would have to Plus, the Z-Wave Device Class information is "weak", it does not tell much about the device itself. I hope it makes sense. |
|
Ok thanks a lot for your feedback, we'll push the cluster adjustment in that direction then. I'll update the PR. |
|
Now we can get the generic and specific device type. Will this solution be a better way or not? Will you add in next release? |
|
This solution have a high chance to be in the next release, but with a different MQTT topic. I'll update the PR here when things will be ready. |
|
Is this is not part of 1.6.0 release? |
Forwarded: #34
Bug-SiliconLabs: UIC-3224
Bug-Github: #34