An unnecessary attribute when choosing a certain type of blinds & additional cluster`s for EP

[burjakremen]

Board

ESP32h2

Device Description

ESP32-H2 Supermini

Hardware Configuration

Nothing attached

Version

latest stable Release (if not listed below)

IDE Name

Arduino IDE

Operating System

Windows 11 x64

Flash frequency

64 MHz

PSRAM enabled

yes

Upload speed

115200

Description

1. When selecting the blind type - zbCovering.setCoveringType(ROLLERSHADE) - the "Tilt" attribute remains available, which is not possible for horizontal blinds. In this case, only the "Lift" attribute can be available (Zigbee2Mqtt).
2. How can I add additional clusters to the "WindowsCovering" EP, for example, buttons in HA, with which I can set the maximum/minimum position for the blinds in the position they are in at the moment, or a light sensor with reflection in HA for subsequent automations.

Sketch

Example Sketch - "Zigbee Window Covering"

Debug Message

Debug Message for unattached Device:
11:16:07.225 -> Calling Zigbee.begin()
11:16:07.225 -> [  2217][D][ZigbeeCore.cpp:145] zigbeeInit(): Initialize Zigbee stack
11:16:07.225 -> [  2232][D][ZigbeeCore.cpp:152] zigbeeInit(): Register all Zigbee EPs in list
11:16:07.264 -> [  2235][I][ZigbeeCore.cpp:160] zigbeeInit(): List of registered Zigbee EPs:
11:16:07.264 -> [  2236][I][ZigbeeCore.cpp:162] zigbeeInit(): Device type: Window Covering client, Endpoint: 10, Device ID: 0x0202
11:16:07.264 -> [  2237][I][ZigbeeCore.cpp:162] zigbeeInit(): Device type: On/Off Light Device, Endpoint: 10, Device ID: 0x0100
11:16:07.264 -> [  2242][V][ZigbeeCore.cpp:379] esp_zb_app_signal_handler(): ZDO signal: ZDO Config Ready (0x17), status: ESP_FAIL
11:16:07.264 -> [  2243][I][ZigbeeCore.cpp:241] esp_zb_app_signal_handler(): Zigbee stack initialized
11:16:07.264 -> [  2244][D][ZigbeeCore.cpp:242] esp_zb_app_signal_handler(): Zigbee channel mask: 0x07fff800
11:16:07.264 -> [  2247][I][ZigbeeCore.cpp:248] esp_zb_app_signal_handler(): Device started up in  factory-reset mode
11:16:07.264 -> [  2248][I][ZigbeeCore.cpp:255] esp_zb_app_signal_handler(): Start network steering
11:16:07.264 -> Connecting to network
11:16:07.264 -> .......................[  4476][I][ZigbeeCore.cpp:317] esp_zb_app_signal_handler(): Network steering was not successful (status: ESP_FAIL)
11:16:09.590 -> ................................[  7705][I][ZigbeeCore.cpp:317] esp_zb_app_signal_handler(): Network steering was not successful (status: ESP_FAIL)
11:16:12.783 -> ................................[ 10934][I][ZigbeeCore.cpp:317] esp_zb_app_signal_handler(): Network steering was not successful (status: ESP_FAIL)
11:16:15.945 -> .................................[ 14163][I][ZigbeeCore.cpp:317] esp_zb_app_signal_handler(): Network steering was not successful (status: ESP_FAIL)
11:16:19.245 -> ................................[ 17392][I][ZigbeeCore.cpp:317] esp_zb_app_signal_handler(): Network steering was not successful (status: ESP_FAIL)

Other Steps to Reproduce

No response

I have checked existing issues, online documentation and the Troubleshooting Guide

• I confirm I have checked existing issues, online documentation and Troubleshooting guide.

[P-R-O-C-H-Y]

Hi, I think the ZHA / Z2MQTT should make visible only controls related to the selected covering type. Will check how ZHA acts there and give you the feedback.
About additional stuff you mentioned, do you have any attributes that are not implemented in the WindowCovering endpoint you want us to add?

[burjakremen]

1. Zigbee2MQTT - the TILT setting slider does not disappear for any type of selected roller shutter. ZHA - there is no way to check.
2. Yes, at the moment, I would like to add two attributes - setting the maximum position in the current position of the roller shutter and setting the minimum position in the current position of the roller shutter. Setting these positions is provided using physical buttons on the GPIO and / or using software buttons in HA.

[P-R-O-C-H-Y]

1. Zigbee2MQTT - the TILT setting slider does not disappear for any type of selected roller shutter. ZHA - there is no way to check.
2. Yes, at the moment, I would like to add two attributes - setting the maximum position in the current position of the roller shutter and setting the minimum position in the current position of the roller shutter. Setting these positions is provided using physical buttons on the GPIO and / or using software buttons in HA.

1. Will check the ZHA
2. Do you have any manufactured device that is working like that and have the buttons visible in HA?

[burjakremen]

No. At the moment I don't have a working manufactured device. This is what I want to do. I did a similar algorithm before, but via WiFi through MQTT. Now I want to implement it via Zigbee. I'm just learning this direction.

[earcam]

Hello, sounds like we're attempting same/similar (I'm building rollerblinds, open-loop with limit switches).

Don't think Z2M honours the optional/mandatory attributes in the ZCL specification; likely by design to allow not-so-standard devices.
If you provide a standard ZCL device then Z2M will provide controls under the exposes tab, but lists the device as unsupported.
Currently I'm hacking around this with script that adds my device to Z2M container's lists of vendors and devices (these are from zigbee-herdsman-converters).

AFAICT you can use the Z2M supported device definitions to restrict the attributes (in main UI views), but likely the exposes tab will still list these.
I do think that the esp32 libraries should honour these optional/mandatory attributes; where a device developer wishes to add bespoke attributes it would be on them to extend the base EP.

Side comments:

• There's a blind controller cluster that exposes OPEN, CLOSE, STOP (as per the ZCL spec), but I can't see anything to directly bind to level control (so bespoke addition to set percentage pos via buttons/slider etc)
• I need the mode functionality to work for calibration ( Zigbee Window Covering - mode attribute not writable #11392 ), and can then save max and min position in nv ram
• I know nothing of HA
• Comparing the definitions in zigbee-herdsman-converters for window coverings versus, eg. light controllers - it doesn't appear manfacturers have very standard implementations.