Tilt Angle for Window Covering

[oliverrahner]

Hi,

I'm thinking about getting a Shelly 2.5 for an office where we have outside window coverings like these:

I now want to use the HAP feature Horizontal Tilt Angle to control the slat angle, but I couldn't find support for this in the source code. Did I miss something? If not, is it planned to support this scenario?

[timoschilling]

How is it controlled? What kind of wiring is needed for it?
I would expect a 4 wire setup:

1. window cover down
2. window cover up
3. tilt angle increase
4. tilt angle decrease

If it's like that you can't use a 2.5, you would need a 4 channel devices, which didn't exist in the shelly stock.

[oliverrahner]

No, it's mechanically coupled.
When the motor starts turning in the "down" direction, first the slats are rotated to fully closed, then the down motion begins.
When the motor starts turning in the "up" direction, first the slats are rotated to fully opened, then the up motion begins.

The Fibaro Roller Shutter supports this, for example:
https://manuals.fibaro.com/content/manuals/en/FGR-223/FGR-223-EN-T-v1.2.pdf
see page 11: "Slats positioning in venetian blinds mode"

If needed, I can provide a video showing the function in real life.

[zsolt-dev]

Something like this is a much needed feature, but not sure if possible.

There could be a parameter, something like this:

// how much time in miliseconds to tilt the cover slates
timeToTilt: 250
After that it would expose a new button called tilt.

But not sure how to implement the tilt sequence in homekit (fully close blinds and then press button)

[timoschilling]

The Problem what I see is that you can create a state from the home app which your cover can't achieve.
You can say in HK the cover is 50% and the title angle is 50% closed, that something your WC can't do. It can only have close 0%-99% close / tilt 0% or 100% closed / 0%-100% tilt. Because in your planed setup you only can change on parameter at a time, but HK allows both.

[oliverrahner]

I actually started implementing this, but am not currently working on it anymore. I think it would be perfectly possible.
First, you can tell Homekit if your cover is capable of (vertical) tilting, and also by how much.
But even if we don't want to do that, because of the added configuration needed to be done, 100% can just mean exactly that: fully tilted. 0% can mean "not tilted" or "tilted in the other direction".

"timeToTilt" or something like that would be the only required configuration, assuming it takes the same amount of time in both directions to reach the extreme positions.

We receive a command like "50% open, 30% tilt" from Homekit. Say we are coming from "0% open, 100% tilt".
We would then start the motion in the up direction for timeToTilt (to reach 100% -> 0% tilt) + 50%*move_time_ms. Then, we start the motion in the down direction for 30% of timeToTilt. The needed logic wouldn't be too complex, but involves some thinking (or trial-and-erroring :)).

[timoschilling]

If I understand you right you want to fix that problem that you can’t change the angle while the WC isn’t fully closed by telling HK that the angle has a min and max of for example 0, is that right?

If that’s your workaround, you have the problem that you can’t change that min/max value at runtime. You can only set it on boot time of the HK Server. So yes in theory your plan can work, in practice not.

[oliverrahner]

Sorry I don't understand what problem you see there. Maybe I didn't describe the way the covering works precisely enough?
You can physically reach any combination of opening and tilting levels.

[timoschilling]

You can physically reach any combination of opening and tilting levels.

ok, then never mind, I have misunderstood you

[zsolt-dev]

We receive a command like "50% open, 30% tilt" from Homekit. Say we are coming from "0% open, 100% tilt".
We would then start the motion in the up direction for timeToTilt (to reach 100% -> 0% tilt) + 50%*move_time_ms. Then, we start the motion in the down direction for 30% of timeToTilt. The needed logic wouldn't be too complex, but involves some thinking (or trial-and-erroring :)).

This sounds amazing. If this would possible it would be great. But not sure if HK support the tilt feature. If this solution is not possible I would at least like to have some "dumb" solution, like exposing extra HK button that would just run the motor up for the specified timeToTilt. I would set it to the time it takes for the slates to be in my most commonly used position.

[oliverrahner]

Homekit does support it. Even in two separate flavors of horizontal and vertical tilt.
It's not implemented very beautifully in the UI, but it is there:

[zsolt-dev]

@oliverrahner Thats great news! Your proposed solution is the way to go then.

Is there anyone here who knows c++ and would like to implement it? If there was a crowdsourcing for this I would even pay something.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Comment or this will be closed in 7 days.

[github-actions]

This issue has now been closed, as no update was provided after it was marked stale. Feel free to provide updates to reopen this issue.

[brancooo1]

That would be much appreciated feature. I know in many countries are usual blinds without tilt, but in multiple countries it’s the only standard solution. All models I know work exactly the proposed way and the implementation would be awesome.

[timoschilling]

It may be a good request But I think it’s something that must be implemented by someone how has this kind of window covers. So if some would like to implement it, PRs are welcome.

[oliverrahner]

I already started this but got sidetracked 😄 maybe I can share the work in progress in a PR in the next days

[stresli]

I already started this but got sidetracked 😄 maybe I can share the work in progress in a PR in the next days

that would be nice to share.

[oliverrahner]

PR #707 includes my current working progress

[simonproebstl]

Is there any news here?

[oliverrahner]

I watched my own blinds a bit more and saw that my previous analysis wasn't 100% accurate:

When the motor starts turning in the "down" direction, first the slats are rotated to fully closed, then the down motion begins.
When the motor starts turning in the "up" direction, first the slats are rotated to fully opened, then the up motion begins.

The slats are, in both cases, rotating while the up/down motion is already in progress.
This complicates the calculation a bit, but it should be handable.

@brancooo1 can you confirm that your blinds behave the same way?

[WatsonDue2]

Hi,
my blinds works exactly the same way.

When the motor starts turning in the "down" direction, first the slats are rotated to fully closed, then the down motion begins.
When the motor starts turning in the "up" direction, first the slats are rotated to fully opened, then the up motion begins.

So, slats are moving (tilting) first when I press up/down. When they are fully open/close, the blind starts going up/down.

This happens at any height of the blind.

Just like this video, but with an electrical motor :D
https://www.youtube.com/watch?v=eXACkwB8ZRI

[zsolt-dev]

@oliverrahner

Just played with mine today and you are right, they are rotating while moving. I have never noticed it before, you have to look for it to test it.

@WatsonDue2 In the provided video (with the manual blinds) you can tilt the blinds the other way around. With electric (at least mine) you can tilt it only one way... I have never seen motor blinds that would work like the one on the video.

How mine work:

1. When they go down, they tilt to the closed position
2. When they go up, they tilt to open

[kodi83]

Hi,

just found this issue and the current perperations made by @oliverrahner.

I took his code and updated the codebase to 2.11.1. While implementing the movement logic, I ran into a couple of questions:

• My blinds behave like them, @WatsonDue2 posted in the video. But just motor-driven. If I am interpreting the description of @zsolt-dev correctly, you have just closed (vertically alignment of the blinds while moving down) and open (horizontal alignment of the blinds when moving up) as endposition when moving your blinds up and down. If I would like to have my blinds transparent, I need to adjust the tilt to 50% (90 degree, because I have 0 and 180 degree as endpoints).
• Is the reset of the tilt necessary after moving of the blinds? We use them just closed (with tilting) or fully open. I assume, if you close the blind you do not want to tilt to the transparent mode. Right?

The tilting logic is implemented the following:

1. You need to configure a slat movement time. This is to be measured manually and describes the time, tilting needs from endposition to endposition. If this setting is 0, the feature is described.
   
2. When moving the venetian blind to one endposition, the tilt will be set to its corresponding endposition
3. When moving the blind to any other position, the tilt is not adjusted automatically
4. If the blind is in closed endposition (blind down) and the tilt is adjusted, the blind position will also be adjusted. This happens because the slat movement time is part of the calibrated movement time the blind needs to fully open or close. So if we adjust the tilt when the blind is in down-endposition, we are moving it a bit up.
   

At the moment I have an alpha-version for testing arround a bit.

I tried to commit my changes to oliver´s repo to update the PR, but wasn´t successful. Maybe someone can help me out?

[oliverrahner]

Hi @kodi83,

I just added you as a collaborator to my repo so you can contribute here!

BR

Oliver

[kodi83]

Hi @oliverrahner,

I faced into several issues trying to build your fork. So I decided to create a new mergeable fork and a new pull request, containing my changes (#1033)

I'm running this build till 2 days in my constellation without any issues.

Cheers

[ReToCode]

Until this is implemented and merged I've used a hacky shortcut to achieve something similar, might be helpful to someone: