GH-34: Expose Z-Wave Generic and Specific Device Class

[silabs-borisl]

Forwarded: #34
Bug-SiliconLabs: UIC-3224
Bug-Github: #34

[nobriot]

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 😉

[silabs-borisl]

Hi @nobriot,

We didn't come to an satisfying solution to this problem.
Which approach do you recommend when we need to expose a specific Z-Wave attribute that is not mappable directly in ZCL ? A single Z-Wave proprietary cluster that contains all the data we want to expose ?

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 ?

[nobriot]

Hi @nobriot,

We didn't come to an satisfying solution to this problem. Which approach do you recommend when we need to expose a specific Z-Wave attribute that is not mappable directly in ZCL ? A single Z-Wave proprietary cluster that contains all the data we want to expose ?

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
learn / look up all what these mean to know what I should do it with these.

Plus, the Z-Wave Device Class information is "weak", it does not tell much about the device itself.
I am not sure about the Z-Wave Fan mode thing, I did not look into details for that PR, but in general I would perhaps recommend to map what can be mapped to the standard ZCL clusters and then keep all the additional information in a separate cluster.

I hope it makes sense.

[silabs-borisl]

Ok thanks a lot for your feedback, we'll push the cluster adjustment in that direction then.

I'll update the PR.

[sohail-shareef]

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?

[silabs-borisl]

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.