Iluminize roller shutter - direction and getting rid of tilt-functionality

mortl · May 5, 2024, 5:21pm

Hi,
I use 8 roller shutter actors (liuminize (5128.10)) and have problems with the directions and with “tilt”.
Have to say, I used them for some year now as a dimming light control without problems.
Lately I updated all my stuff: Raspberry 4B, Pi-OS Bookworm, Homebridge, deCONZ and Conbee III.
In the latest deCONZ-version the devices are recognized as window-shutter-devices, which is fine!

When testing in the deCONZ GUI in Cluster-Info (Window Covering) sending “up/open” moves the shutter up and “down/close” moves it down, so I think they are wired correctly. BUT: in Phoscon → Homebridge and lastly Apple HomeKit the direction is reversed: to open I have to shut them (Siri, shut the shutters), to shut them I have to open them.
Can I simply switch directions or should I change the wires for up an down?
The Open/Close and Lift-States are also displayed wrong, but I managed to change this in state/open and state/lift (by setting Item.val= 100-attr.val) - but this doesn’t change the behavior (switched directions) when I want them to open or close.
How can I disable the tilt-function… my shutters don’t have a tilt. they’re just rolling shutters. the actor thinks, they have a tilt, which leads to a short opening (10%), when they’re fully closed … or a short closing (10%) when they’re fully opened.

thank you for any help
Martin

Smanar · May 5, 2024, 6:17pm

On deconz you are using the onoff cluster or the covering one ? (this device have both)
Strange you haven’t the same result using the GUI or the API

And yes it’s possible to reverse the return like you have done, but not the command

I don’t see something about the “tilt” on the documentation, but the user have used it from his PR DDF for iluminize motion sensor (5128.10) by AndreKoepke · Pull Request #7046 · dresden-elektronik/deconz-rest-plugin · GitHub
It’s not a “calibration” issue ?
The attribute 0x0000 on covering cluster is “Tilt Blind - Lift and Tilt”, and not writable Iluminize 5128.10 · Issue #7045 · dresden-elektronik/deconz-rest-plugin · GitHub

On the DDF i m seing there is a state/mode field, you can test it on the GUI too, on cluster covering, attribute 0x0017

          <attribute id="0x0017" name="Mode" type="bmp8" default="0x0000" access="rw" required="o">
            <value name="Reversed" value="0"></value>
            <value name="Calibration Mode" value="1"></value>
            <value name="Maintenance Mode" value="2"></value>
            <value name="LED feedback" value="3"></value>
          </attribute>

Try checking values not visible on his captures on covering cluster 0x0102 to see if there is a way to disable the “tilt”

mortl · May 5, 2024, 9:04pm

thanks for your reply!
Yes, i am using the covering cluster, not the on/off.

I calibrated my actors, and as said, i used them fore some years now without any issue (exposed as dimmable light).

I tried to check the “reversed” option in the gui (window covering → attributes → mode) nothing changes. (btw, if i check “calibration mode”, the actors calibrate themselves).

I checked all the issues by AndreKoepke (your links), but there’s nothing which helped me.

At the moment i went back to the original (wrong) lift and open states, because otherwise i can’t control my shutters, as apple HomeKit “sees” they are open (which they are with “Item.val=100-attr.val”) and the “close” command would open them. so HomeKit does nothing.
Should i report a bug? Because there’s no way to reverse the shutter-motor? otherwise i will change the motor-wires as i think i get the result i want… then, just in the deconz gui (window covering cluster) the directions are wrong - i could live with that.

Smanar · May 6, 2024, 3:04pm

I m checking the code and there is no “hack” that can reverse classic request. So I don’t see how the API can use reversed command than on the GUI.
You can try direclty with the API but for me phoscon/homebridge will do same.

On manual

After pairing with a Zigbee control panel or a remote control, the shutter actuator is controlled by dimming commands: less than 30% moves “closed”, more than 70% moves “open”.

So perhaps this device is not make to work with covering cluster ?

It’s that is doing Z2M

    {
        zigbeeModel: ['5128.10'],
        model: '5128.10',
        vendor: 'Iluminize',
        description: 'Zigbee 3.0 switch shutter SW with level control',
        fromZigbee: [fz.cover_position_via_brightness, fz.cover_state_via_onoff, fz.cover_position_tilt],
        toZigbee: [tz.cover_state, tz.cover_via_brightness],
        exposes: [e.cover_position()],
        ota: ota.zigbeeOTA,
    },

As “fast hack”, you can try a fake DDF with mimic a dimmable light (just need to change the type and remove open/lift/titlt)
And BTW you have too the 10% reversed move with using open/close with the GUI ?

mortl · May 6, 2024, 4:16pm

Yes, the devices worked as a light dimmer for over a year now. I recently updated deconz, homebridge and switched to homebridge-deconz (from hb-hue) and my devices suddenly were exposed as covering-devices in HomeKit. That’s where it began…

Now for testing I switched the Motor-Wires on the device and now the controls in phoscon/homebridge and HomeKit work like they should: Open moves up, close moves down. Now fully closed has the lift-state 100% in deconz. I think i read somewhere that that’s correct (100% is closed).
But confusing is that sending “up” in the GUI-Cluster does the same as setting lift-percentage to 100% (shutters move down) and “down” does the same as setting lift-percentage to 0% (shutters move up).
But that’s not bothering me, as i control it via HomeKit.
Also confusing: for HomeKit it’s closed at 0%, like “20% open” or “95% open” and 100% is fully open.

No, when sending open/close in the Gui, there’s no 10% reverse movement at all.
Here I set the tilt-percentage to 100% which leads to fully closed shutters (no reverse movement when closing the shutters) but always like 10% reverse when opening the shutters (via homekit).
DeConz first sets the lift-percentage and then the tilt. If i mange to get rid of the Tilt-Movement, i am where i want to be.

Smanar · May 6, 2024, 4:27pm

This, I can understand …
Have checked the code again and the API make the same request, perhaps third app are using the 100%/0% level instead instead of the open=true.
To be sure you can try to get log to see the request made by the application or try yourself direclty with the API Getting Started - deCONZ REST-API

I can promise you, deconz just make a open/close request and no more > deconz-rest-plugin/rest_lights.cpp at master · dresden-elektronik/deconz-rest-plugin · GitHub

Else you have more than just “state/open” in the request made on the API.

mortl · May 6, 2024, 4:36pm

Ok, I will check the logs and try with the api directly… thanks for helping!

mortl · May 6, 2024, 8:56pm

So i have to correct me: When sending open/close in the Gui, there IS the short reverse movement (as it is by controlling it via the rest api) - the device sets the tilt-percentage after reaching the lift-state.

I also discovered, that 5 of my devices are “Tilt Blind - Lift and Tilt” and 3 of them are just “Rollershades” (Window Covering Type at the Attributes in Window Covering cluster). But that value is read only, so i can’t change the type. The Rollershades-types don’t apply the tilt-value, the others do.
They are ALL iluminize 5128.10 bought at the same time.

Tomorrow i try to see, if there’s any zigbee-command, which triggers the tilt-thing. And i will try if it occurs, when switching up/down with a hardware-switch on the device.

mortl · May 7, 2024, 8:07am

When activating open/close by a hardware switch on the device, there’s no “tilt”-action going on.
I thnik, the device sets the tilt-value to “open” (=0%) when opening the shades and “close” (=100%) when closing the shades. That’s what you see when reading the tilt-state with the api.
Does this have to do sth. with it: deconz-rest-plugin/rest_lights.cpp at b6eb920ba3ec919f5f525720e551f9b788bf9fa3 · dresden-elektronik/deconz-rest-plugin · GitHub

Is there any chance to change the covering type from “Tilt and Blind” to “Rollershade”? That would solve my problem.

Smanar · May 7, 2024, 3:20pm

if (hasTilt)

This code part is used ONLY if you have "tilt":14 for exemple, else it’s totaly ignored.

I thnik, the device sets the tilt-value to “open” (=0%) when opening the shades and “close” (=100%) when closing the shades

So can use instead the field “lift” with 1% and 99 % ?

Good question, and you have the same device with different device type, strange too.
For me there is an hardware method to change the device type, but I found nothing in documentation.
And the attribute 0x0000 is read only from zigbee specification

Can try to “cheat”, make it read/write on deconz, and try to change it. On file general.xml

    <cluster id="0x0102" name="Window Covering">
      <description>The window covering cluster provides an interface for controlling and adjusting automatic window coverings such as drapery motors, automatic shades, and blinds.</description>
      <server>
        <attribute-set id="0x0000" description="Window Covering Information">
          <attribute id="0x0000" name="Window Covering Type" type="enum8" default="0x00" access="r" required="m">
            <value name="Rollershade" value="0"></value>
            <value name="Rollershade - 2 Motor" value="1"></value>

Change the access to “rw”

mortl · May 7, 2024, 4:17pm

This code part is used ONLY if you have "tilt":14 for exemple, else it’s totaly ignored.

The devices which are “Tilt&Blind”-Types have a "tilt"state which is between 0 and 100. And whatever it is, the device moves to this tilt-value after reaching the set lift-value.

Change the access to “rw”

I tried, but I get a “writing failed” when changing the type (deConz Gui)
I goto in touch with iluminize to find out, why there are recognized different types and maby a way to change it. Waiting for the reply.

mortl · May 8, 2024, 2:35pm

I got it!!
I talked to iluminize: you can change the actor from “tilt&blind” to just “roller shade” by calibrating it by pressing twice on the calibration-button.
The manual says: calibrate by pressing 4 times on the calibration button. So I did no other than pressing 4 times in the past.
Just calibrate by pressing twice did the thing!

Thank you very much for your time and help!

Smanar · May 8, 2024, 6:39pm

Haaa, realy good to know, lol, have read 3/4 time the manual, without see that.