Adding Tilt to the Hunter Douglas PowerView Cover integration (Luxaflex)

[Kingy444]

@ApriliaEdd

firstly, this one is probably personal for everyone but for me, the blind should only be considered closed if it is completely closed and tilted closed. my blinds have been showing closed since I finished testing for you yesterday but the blinds were what we consider open (tilted 50%) as in they let light in. we only really fully open the blinds if we are opening the doors.

I will need to discuss with the core team as the positioning of shades and the positioning of tilt are currently seperate - it makes sense to treat them as closed only if tilt is closed too so i will look at adding that

EDIT: issue i could see is the shade and the tilt have different controls - there is no master close all - the only thing i can think of there is make it so the close shade button also sets tilt to close - ie the down arrow. You would lose ability to only control the shade with that button then so i dont know whether that is desired
There is only an is_closed for the blind as a whole and not the tilt seperately - i can caluclate it as one - but you would need to, currently at least, close both the shade and the tilt independentaly.
Appreciate user feedback on this type of functionality

@ApriliaEdd

Secondly my blinds are on mains power can you tell this during discovery and disable the battery entity for these as it always reads 0% except for one that is reading 90% randomly…

Each little piece is being added 1 by 1 - this is on the cards (I have the code but had to seperate it to have it accepted into core) - this will also allow us to poll these ones more often as we dont need to worry about the battery

@ApriliaEdd

is the intention for this to replace the official integration in due course or will it remain a custom component?

Getting it added to core as above will just take some time to get them all in

The most recent code i submitted as for top down bottom up which was the starter for all this and to get it into core required a lot of code refactoring to how the whole integration runs (and it runs much better now btw) so unfortunately it wont be a straight lift and shift for these into core.

I will say hopefully in the core in next 2-3 months at best accounting for the Pull Request process, their internal beta cycle etc.

[Kingy444]

@ApriliaEdd

firstly, this one is probably personal for everyone but for me, the blind should only be considered closed if it is completely closed and tilted closed. my blinds have been showing closed since I finished testing for you yesterday but the blinds were what we consider open (tilted 50%) as in they let light in. we only really fully open the blinds if we are opening the doors.

@andrewfg how do you treat open/closed for tilt shades on OH? Do you have the equivelent of an is_closed property ?

[andrewfg (Andrew Fiddian-Green)]

@Kingy444

how do you treat open/closed for tilt shades on OH? Do you have the equivelent of an is_closed property ?

No. We just have a 0…100 slider.

[andrewfg (Andrew Fiddian-Green)]

@Kingy444

They are Tilt 90

Many thanks for the support. So the caps 9 is really ‘tilt on closed’ but where the ‘closed’ refers to the front shade rather than the back one. ??

In other words, the single motor first lowers the front shade, then moves the tilt, and finally lowers the back shade. i.e. transitioning posKind=1 => posKind=3 => posKind=2 … Or??

[pessorrusso]

Hey @andrewfg and @Kingy444 ,

Type 18: Pirouette Pirouette® | Sheers Shadings | Hunter Douglas
Type 1: Roller (no tilt) Roller Shades | Solar Shades | Hunter Douglas

[andrewfg (Andrew Fiddian-Green)]

@Kingy444 see my PR for the capabilities changes in OpenHAB …

[hdpowerview] Corrections to shade database and capabilities

[Kingy444]

@andrewfg

Many thanks for the support. So the caps 9 is really ‘tilt on closed’ but where the ‘closed’ refers to the front shade rather than the back one. ??

In other words, the single motor first lowers the front shade, then moves the tilt, and finally lowers the back shade. i.e. transitioning posKind=1 => posKind=3 => posKind=2 … Or??

I guess if you look at it that way they are still tiltonclosed in the traditional sense of poskind1=1 being position=0 they just have the additional element that that poskind1=2 is =65k at the same position

So from all rollers closed the rear shade would open before a tilt and inverse from all open the front shade would close before tilting

Sending poskind 3 does put them into this position automatically - but in HA we need to store these other states or the info will be stale because as you know the shade won’t return other positional data

[Kingy444]

@pessorrusso
Could you confirm they are the ‘designer roller shades’ from the link ? There are a few models there so I’m curious if they would all have a different ‘type’ as that has seemed to be the case with others to date

These would have worked in HA core for you already given the standard up down functionality but we are trying to document them all thoroughly so if we can name type accurately down fo the model that would be great

Edit : almost certain each of these will have a different type definition as the designer shades appear to have a second fabric much like capability 8/9 I believe. One sheer and other normal, how those are controlled is to be determined.

@pessorrusso it would appear from your description these may not be designer shades and fall into one of the others listed on that page ?

@andrewfg just tagging so you don’t miss it

[ApriliaEdd (Edd)]

@Kingy444

I will need to discuss with the core team as the positioning of shades and the positioning of tilt are currently seperate - it makes sense to treat them as closed only if tilt is closed too so i will look at adding that

EDIT: issue i could see is the shade and the tilt have different controls - there is no master close all - the only thing i can think of there is make it so the close shade button also sets tilt to close - ie the down arrow. You would lose ability to only control the shade with that button then so i dont know whether that is desired
There is only an is_closed for the blind as a whole and not the tilt seperately - i can caluclate it as one - but you would need to, currently at least, close both the shade and the tilt independentaly.
Appreciate user feedback on this type of functionality

we very rarely use the individual controls for the blinds from HA, if I need them in a specific place I’m generally in the kitchen watching them so will use the pebble. Mostly the day to day use of the blinds is by automation i.e. if we’re home and the sun comes up set the blinds to all middle scene, which is shade @ 0% tilt @ 50%. if the last person leaves or the sun goes down set the closed scene. if someone comes home and the sun is up set all middle. we then have a scene for fully open and one for opening the bifold doors where the 2 blinds over doors fully open and 2 that are over windows shade close and tilt to 50%. outside of this we generally use scenes from a dashboard or my wife will close them using the pebble controller. So I don’t really see this as a problem for our use case, obviously others may differ.

IMO from a privacy/security point of view the blind should only say its closed if its truly closed and no one can see in. In my head closed is a binary state where as things can be a little bit open or fully open.

I guess technically there are 2 closed states for these blinds:
1- shade @ 0% & tilt @ 0%
2- shade @ 0% & tilt @ 100%
which makes it more difficult

like you said lets get the core functionality set first then we can figure out the little bits

[pessorrusso]

@Kingy444 @andrewfg

In my receipt they are defined as “Hunter Douglas Designer Roller”. They have just one motor and one mechanism (up/down).

[Kingy444]

@pessorrusso

In my receipt they are defined as “Hunter Douglas Designer Roller”. They have just one motor and one mechanism (up/down).

Thanks mate - that’s really interesting given the designer roller seems to indicate it has two pieces of fabric from the link you gave

Do yours have this? And do they function fine currently ?

[Kingy444]

@ApriliaEdd

I guess technically there are 2 closed states for these blinds:
1- shade @ 0% & tilt @ 0%
2- shade @ 0% & tilt @ 100%
which makes it more difficult

I think that’s an excellent point for the control of the tilt and shade to remain seperate- coding two closed points is not an issue - it will just be an architectural thing at the end of the day when I submit tje PR

Happy to have these conversations now as want to get it right to start with and many of these things won’t hold up implementation

[pessorrusso]

It is just a regular roller:

[TonyInHiro (Anthony Douglas)]

Great to see tilt added to the official integration and the shoutout to @Kingy444 in the home assistant update release notes. Thanks again for all the work!

[Kingy444]

Thanks @TonyInHiro
Just remember current core tilt support is generic and not the code tested here - it will work for some people but not all.

The code tested here will be added to core too, the issue is core requires higher code quality and upstream api where I can test code without the upstream api changes here

Once upstream api is updated (PR waiting to be merged) all the code here will be included into core

Good place to confirm where your shades functionality stands is the documentation (but I’m happy to answer questions too) - we updated doco to include a chart with all known shade types

Hunter Douglas PowerView

Seems every time I make a PR the core team find another improvement in the code we can make so the plug-in is working better than ever now - not mentioned in the release notes (but in the doco) is the ability to run the update_entity service to update entity position (force shade position update)

This was introduced before the polling for hardwired was added (so not required for hardwired now) and while I don’t recommend using this on a schedule for battery powered devices (you’ll drain them) you can add a button to force position update to your UI using that service if you wish (one button can do multiple shades too)

[psg8064]

I recently installed Vignette Modern Roman Shades that have top down, bottom up capability (Shows up as type 33). Curious to know if there is a way to manage the top down, bottom up capability in the current release (2022.7.0)?

[Kingy444]

@psg8064
Not at the moment but I can include them in future for sure. We haven’t seen these and unfortunately this is all community based (HD won’t provide the info, I’ve asked) so until someone asks for support we can’t add it

I actually wrote some smart code to pick them up capability type which ‘should’ work for every shade even unknown in the future though without the nicety of names ie the number here

Vs the name here

Effectively if you see a number and not text then your shades aren’t supported by default code in the upstream api and have fallen back to basic support.

There is still a chance that doesn’t work if your shades are ‘special’ (we only know of one shade that it doesn’t work for)
So let’s make sure these will since we don’t have the code published yet and not make yours the second

Can you please provide the json of the shade in the below positions - on new release just hit ‘Visit device’ as above

Top fully open / bottom fully closed
Top fully closed / bottom fully open
Both shades open somewhere around middle

Hopefully it’s just adding the shade in but I’ll know once I see the json.

[jpearl]

Also have type 33. Added comment here

I can try to get you the various positions, though I suspect it matches exactly the tdbu support you just added, @Kingy444

[psg8064]

Here’s what I got:

Top fully closed / bottom fully open :
{“shade”:{“id”:26154,“type”:33,“capabilities”:7,“batteryKind”:3,“smartPowerSupply”:{“status”:0,“id”:0,“port”:0},“batteryStatus”:3,“batteryStrength”:152,“roomId”:18835,“firmware”:{“revision”:2,“subRevision”:0,“build”:3197,“index”:43},“name”:“TWFzdGVyIDE=”,“groupId”:14422,“signalStrength”:4,“positions”:{“posKind1”:1,“position1”:65535,“posKind2”:2,“position2”:0}}}

Top fully open / bottom fully closed :
{“shade”:{“id”:18918,“type”:33,“capabilities”:7,“batteryKind”:3,“smartPowerSupply”:{“status”:0,“id”:0,“port”:0},“batteryStatus”:3,“batteryStrength”:146,“roomId”:18835,“firmware”:{“revision”:2,“subRevision”:0,“build”:3197,“index”:43},“name”:“TWFzdGVyIDI=”,“groupId”:14422,“signalStrength”:4,“positions”:{“posKind2”:2,“position2”:65535,“posKind1”:1,“position1”:0}}}

Both shades open somewhere in the middle :
{“shade”:{“id”:26154,“type”:33,“capabilities”:7,“batteryKind”:3,“smartPowerSupply”:{“status”:0,“id”:0,“port”:0},“batteryStatus”:3,“batteryStrength”:152,“roomId”:18835,“firmware”:{“revision”:2,“subRevision”:0,“build”:3197,“index”:43},“name”:“TWFzdGVyIDE=”,“groupId”:14422,“signalStrength”:4,“positions”:{“posKind2”:2,“position1”:19676,“position2”:21460,“posKind1”:1}}}

I have three of they type 33 shades. The first and third json listings were from shade 1 and the second listing was from shade 2.

Hopefully I captured that all correctly.

[Massamino]

My device (code 51) has fallen back to generic device while it worked before (in your test code) … what changed?