Add generic support for Device ID 0x0203 "Window Covering Controller" (e.g. Sunricher SR-ZG9080A)

[slugzero]

This adds support for Sunricher window covering controller SR-ZG9080A cf.

https://sunricher.en.alibaba.com/product/62134471426-811954196/Zigbee_3_0_Zigbee_Curtain_Motor_Controller_Zigbee_Curtain_Controller_Smarthome.html
https://en.robbshop.nl/rollershutter-control-400w-zigbee-robb-smart?sqr=rollershutter%20controller&

[ebaauw]

Did you check the open/close logic? Some devices have it reversed. When fully closed open, state.bri should be 0 and state.on should be false; when fully opened closed, state.bri should be 254.

[mauhau]

I'm very interested in this device, but unfortunately for me the patch doesn't work. See the debug output of deConz (deCONZ --dbg-info=1 --dbg-aps=1 --dbg-zcl=1 --dbg-zdp=1 --http-port=8080) here: deConz.txt

[manup]

Any news here?

[slugzero]

Did you check the open/close logic? Some devices have it reversed. When fully closed, state.bri should be 0 and state.on should be false; when fully opened, state.bri should be 254.

If it is wired according to the manual (i"up" is connected to Q1 connector and "down" to Q2), it follows the proper logic. I.e. state.on is true when opened and false when closed.

[cgiraldo]

Hi! thanks a lot @slugzero, It works like a charm!

The only think to point out is that I need to use { "bri_inc":0, "on": true } instead of {"bri_inc":0} to stop the cover while it is closing.

If not the API returns an error with description parameter, /lights/14/bri, is not modifiable. Device is set to off.

By the way, @ebaauw, can you confirm this is the expected cover behavior for the deconz API?

When fully closed, state.bri should be 0 and state.on should be false; when fully opened, state.bri should be 254.

Because deconz integration in home-assistant do it the other way around. If it is a home-assistant bug, I can fill an issue and provide a PR to fix it.

[ebaauw]

By the way, @ebaauw, can you confirm this is the expected cover behavior for the deconz API?

I'm afraid it's not, sorry for that. Updated my comment. This always confuses the hell out of me (I sure hope I got it right this time):

• In ZigBee, Current Position Lift Percentage is supposed to be 0 for fully open and 100 for fully closed. You could read it as "percentage closed". However, Xiaomi and some other vendors have reversed this (using 0 for fully closed and 100 for fully open);
• The REST API should normalise these differences and expose state.bri as 0 for fully open; state.bri as 254 for fully closed. You could read it as "level closed". As there's no Zigbee equivalent, state.on is derived from state.bri > 0, meaning: "not fully open";
• In HomeKit, Target Position and Current Position are 0 for closed and 100 for open. You could read them as "percentage open". Home lights up the tile when Current Position > 0, so when "not fully closed";
• My latest PR (Multiple enhancements and bug fixes. #2658) adds state.open and state.lift to the /lights resource: state.lift follows the ZigBee attribute: 0 for open and 100 for closed (so "% closed"). state.open is derived from state.lift < 100 (so "not fully closed"). Note the subtlety here: state.open is not the inverse of state.on.
• Note that state.on and state.bri will still work, but should be considered deprecated. I will only add support for action.open and action.lift to groups of window covering devices.

Because deconz integration in home-assistant do it the other way around. If it is a home-assistant bug, I can fill an issue and provide a PR to fix it.

I don't know if HA uses "percentage open" or "percentage closed". Best double-check; as I mentioned before, this always confuses the hell out of me.

[cgiraldo]

So with your updated comment, I can confirm the open/close logic is reversed for the Sunricher SR-ZG9080A. Should this issue be reopen or we create a new one just for SR-ZG9080A?

HA uses "percentage closed", so Its integration of the deconz REST API is correct.