Make dim buttons of the Philips Dimmer Switch usable.

[rbi]

This is a static thing definition for the Philips Dimmer Switch. When the Switch is autodiscovered only the On and Off buttons generate any events that can be used in OpenHab. With this PR both Dimm Buttons in the middle can be used too.

To get the right values I looked at this source code file:
https://github.com/dresden-elektronik/deconz-rest-plugin/blob/2f9c700cdb679de87666abe56c3477b31916e438/sensor.cpp#L96
I tried to use the proprietary definitions which would allow even more fine grained controling with this remote but I failed. I didn't know what I should use for the "*_parameter_name" properties. The commented out values work for me however.

[cdjackson]

Thanks. Please can you sign your commit and the PR.

[rbi]

Thanks. Please can you sign your commit and the PR.

Do you mean I should add this "Signed-off-by" line to the commit? I've done it now and replaced the original commit.

[cdjackson]

Yes, that's correct - as per the contributors guidelines, you are signing off that you accept the conditions.

Thanks.

[rbi]

The generically discovered version contains battery channels which work fine. This static thing version does not contain them yet. Should I add them?

At the moment, when you add a remote to the system you get the auto discovered device in the Inbox first. You add it and discovery completes while it is already added. Only then you get static thing as a new thing in the Inbox. When you add it you have 2 things for one remote. The temperature can then just be taken from the generic thing and the Dimm buttons from the static thing.
Sometimes discovery completes in the Inbox already. Than the static thing replaces the generic thing and you can only add the static thing. Then it would not be possible to use the battery channels.

[rbi]

May Zigbee standard knowledge is not that good but I do not understand why the parameter zigbee_shortpress_parameter_name is needed in the static thing definition. It is the only thing where I did not find an equivalent for here. The zigbee_shortpress_parameter_value is in that list however. If the zigbee_shortpress_parameter_name would not be needed maybe the proprietary clusters could be used which provide more information.

I also think there is something like a zigbee_longpress_released_* attribute set missing. In the innr rc-110 thing definition there is an extra channel just for long press release. Long press release should be possible on the channel that did the long press start.

[hsudbrock]

Thanks for adding this, @rbi!

To my knowledge, it is currently not possible in the binding to have some channels of a thing from a static channel definition in the XML thing type, and to have some other channels being dynamically generated by the binding. Hence, it would be good if you could add the low-battery channel.

Regarding the attribute for the parameter name, and why this is needed: It is necessary to somehow specify the parameter value to distinguish different buttons for which the device emits the same command, just with different parameter values. The library used by the binding for ZigBee communication provides parameter values of commands via getter methods that include the parameter name, hence the use of the parameter name in the thing type. You are correct, this is nothing from the ZigBee standard. When implementing this feature, @cdjackson and I discussed briefly whether to extend the underlying ZigBee library to permit a different way to access the parameters, but decided that simply using the parameter name should be good enough. You probably do not find this in the link you provided, because this information is encoded by the hex values listed there.

Regarding the option to add additional triggers like 'long-press-release': When implementing this, I wanted to use the standard system channel types from Eclipse Smarthome, and not introduce custom channel types. I think that in ESH, there are currently no suitable system channel types that cover all the options (hence the 'workaround' for the release channel for the innr remote). I don't see any other option than introducing ZigBee-binding specific channel types for this, extending the list of system channel types in ESH after some discussion there, or just using a workaround similar to the one used in the innr remote thing type.

[rbi]

@hsudbrock Thanks for the explanation. I think I understand now the need for the for the parameter name.

The dimmer emits events on the cluster "0xfc00" too. I guess that is a proprietary one? As I understand it the underlying library has generated classes for well-known clusters. These classes contain the getters with the parameter name. I guess for proprietary clusters no class is generated so I can not access them at all? Or is there some kind of generic class which can be used in that case? What would the parameter_name be?

[hsudbrock]

Yes, clusters with IDs in the range 0xfc00 – 0xffff are so-called 'manufacturer-specific' clusters; there is not so much support for manufacturer-specific clusters in the underlying ZigBee library - yet. I am currently working on that, maybe we can add support for those events from cluster 0xfc00 when this is done.

[rbi]

I've seen the batteryLevel and the batteryVoltage channel to have values at least once. They do only work sporadically for me however. The auto-discovered channels work only sporadically to so I guess it is no problem in the binding.

I've never seen a value for the batteryAlarm channel but I guess it only has a value if the battery is low?

I just recognized that I forgot the sign-off again. I fix this in the afternoon.

[hsudbrock]

I've never seen a value for the batteryAlarm channel but I guess it only has a value if the battery is low?

This channel type is based on the attribute BatteryAlarmState of the power configuration cluster. As this attribute is an optional one, it could be that the dimmer switch does not support it - in this case it would be good to not add the battery alarm channel to the thing type. Do you happen to know if the attribute is supported by the device?

[rbi]

Unfortunately I don't know this so I have commented out it for now. I've added the Signed-Off Line.

With this definitions all button channels generate SHORT_PRESS events. When doing a long press on a dimmer button a SHORT_PRESS event is generated each second until the button is released. I guess when switching to the proprietary cluster that last behavior would change.

[hsudbrock]

Sorry, one last question, as I overlooked this before: Should it be 012 or 021 in the ID? It looks as if the digits were accidentally transposed on one side of this property entry.

[rbi]

It should be rwl021. Thanks for the hint. I've fixed it.

[hsudbrock]

Unfortunately I don't know this so I have commented out it for now.

I will probably get one of those switches myself and take a look; then I can add the channel or remove the commented section for the channel with an additional PR at a later point.

[hsudbrock]

Looks good to me, thanks @rbi!

[openhab-bot]

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/zigbee-binding/15763/2087