DDF for iluminize Multi 5 (4A)

[bluemoehre]

Controller by iluminize, which can emulate multiple controllers (Dimmer, CCT, RGBW, RGBCCT).

Will solve #7985

All Screenshots

Dimmer

CCT

RGBW

RGBWCCT

[github-actions[bot]]

Hey @bluemoehre, thanks for your pull request!

[!TIP] Modified bundles can be downloaded here.

DDB changes

Modified

• iluminize/led_controller_multi_5.dim.json : LED Controller Multi 5 (DIM mode) :heavy_check_mark:

• iluminize/led_controller_multi_5.rgbw.json : LED Controller Multi 5 (RGBW mode) :heavy_check_mark:

• iluminize/led_controller_multi_5.cct.json : LED Controller Multi 5 (CCT mode) :heavy_check_mark:

• iluminize/led_controller_multi_5.rgbcct.json : LED Controller Multi 5 (RGBCCT mode) :heavy_check_mark:

Validation

[!TIP] Everything is fine !

_{:clock830: Updated for commit 1adcf5d8b785d4b2384ba0d293c5f34190536880}

[bluemoehre]

The device is missing some items because a device with "state/x" or "state/y" need the corresponding cap/color/xy/{red,green,blue}/{x,y} items

That cluster/attribute 0x0300 / 0x003a is not present. How to deal with this conflict?

[ebaauw]

Just define the capabilities with static values.

[bluemoehre]

@ebaauw Seems like my idea to copy from another DDF was not the best. Since we have the bot checking DDF files. Are you able to add these hints/rules to it? Then we can run it vs all existing files and do a clean up? This way the next person won't trap into the same problems.

[bluemoehre]

You didn’t post screenshots of the Basic cluster, so I don’t know what ZCL version the device supports, but I would expect it to support attribute reporting.

I already mounted it behind a wall ... but I gonna try to upload these as well.

Did you re-read the endpoints and Simple Descriptor each time after changing the mode? It might not make sense to expose an RGBW light as Extended Color Light. The colour temperatures will be ugly, mixing RGB and W.

Since re-reading didn't work all time, causing deCONZ to show old stuff, I deleted the node from the network and then hard reset the controller each time.

[bluemoehre]

added Basic cluster for Dimmer Mode (2nd image in PR description)

[ebaauw]

@Zehir maintains the DDF validator; I haven’t looked into its internals. It does check for mandatory items, but I don’t think it currently checks for superfluous or deprecated items. Of course, the validator cannot check against the actual device features.

I often copy an existing DDF as a start to create new DDF, but I do check the validity and appropriateness of each item in the GUI. There’s also some hidden (from API clients) capabilities that change the API behaviour, like using Move to Level (with On/Off) or Off with Effect. You need to check in the GUI if the device supports these. There’s a brief description in each item’s JSON file (under devices/generic/items/*_item.json) but there’s definitely room to improve the documentation. The use of the red, green, and blue points, to specify what colors the light can display, is best explained in the Hue API documentation.

[ebaauw]

added Basic cluster for Dimmer Mode (2nd image in PR description

ZCL Version 3 is Zigbee 3 and should support attribute reporting.

[bluemoehre]

ZCL Version 3 is Zigbee 3 and should support attribute reporting.

So we need to additionally add some reporting config everywhere?

[bluemoehre]

We would like to ask you to create a new device support request (new issue -> device support) in this repository and to link it against your pull request.

done

[SwoopX]

Thanks a lot 👍

[manup]

@ebaauw is the PR ready for merging?

[ebaauw]

I suppose so. I don't have the device so I cannot validate the DDF.

[bluemoehre]

@ebaauw it would help (me) to understand the status of an issue, if you could resolve all started conversations, where you think it now looks good. This prevents to miss something we had been discussing without having a solution. (Additionally I am not sure if someone could merge with unsolved discussions.)

I will also check myself everything here and in other tickets …

[ebaauw]

Since the DDF (by design) won't affect any other devices, merging an incomplete or even wrong DDF would cause no harm, other than the device not working as expected.

The idea of a DDF, particularly of the capabilities items, is to indicate what actually works for this device, not just what attributes it advertises. Checking this requires trying out the features in the GUI, and visually checking the light's reaction. Support for attribute reporting can be checked by the GUI showing the changed values automatically (without having to re-read the attributes), through the deCONZ log, or using a Zigbee sniffer.

So for example, if the DDF advertises the device supports Execute If Off, the deCONZ REST API assumes it does, and will happily send a Move to Level while the device is off, and update state/bri accordingly (rather than raising an API error that the light is off). If the light subsequently is turned on, but doesn't reflect the changed brightness it doesn't live up to the promise the DDF makes to API clients.

[github-actions[bot]]

This pull request is now merged. The new DDB files have been uploaded to the store.

DDB Files

Modified

• iluminize/led_controller_multi_5.dim.json : LED Controller Multi 5 (DIM mode) : with hash (e808f2d67a)

• iluminize/led_controller_multi_5.cct.json : LED Controller Multi 5 (CCT mode) : with hash (ce87fb2f2a)

• iluminize/led_controller_multi_5.rgbcct.json : LED Controller Multi 5 (RGBCCT mode) : with hash (5d806336f5)

• iluminize/led_controller_multi_5.rgbw.json : LED Controller Multi 5 (RGBW mode) : with hash (0603a8231d)

_{:clock830: Updated for commit 5bf4142a439bed50d713645daf0b8d7c007c73a4}