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

Just loaded up the integration. The Silhouette’s (type 23) work fine, with the exception of the vane tilting (which I believe you already are aware of)

There’s also type 38 called Silhouette Duolite that I believe are dual motor. Any chance I could help integrate that?

    "shadeData": [
        {
            "id": 48556,
            "type": 38,
            "capabilities": 9,
            "batteryKind": 2,
            "smartPowerSupply": {
                "status": 0,
                "id": 0,
                "port": 0
            },
            "batteryStatus": 3,
            "batteryStrength": 177,
            "roomId": 49569,
            "firmware": {
                "revision": 2,
                "subRevision": 1,
                "build": 2757,
                "index": 20
            },
            "name": "TWFzdGVyIEJlZHJvb20gMQ==",
            "positions": {
                "position1": 32713,
                "posKind1": 3
            },
            "groupId": 23871
        },
        {
            "id": 19192,
            "type": 23,
            "capabilities": 1,
            "batteryKind": 2,
            "smartPowerSupply": {
                "status": 0,
                "id": 0,
                "port": 0
            },
            "batteryStatus": 3,
            "batteryStrength": 181,
            "roomId": 9189,
            "firmware": {
                "revision": 2,
                "subRevision": 1,
                "build": 2690,
                "index": 12
            },
            "name": "TWFzdGVyIEJhdGhyb29tIDI=",
            "groupId": 19501,
            "positions": {
                "posKind1": 1,
                "position1": 0
            }
        },

Thank you so much for your effort and let me know if there’s anything I can contribute

@Massamino - check the google drive link out and give it a try now - i’m sure it will need some cleanup before i push to core but i wreckon this will get tilt working for some of the blinds

Just installed the latest version. Using the tilt slider I’m able to tilt the blinds, however anything over 50 tilt starts to open the blind, so setting tilt to 51 would close the veins and open the blind to 1 out of 100. So I guess with the Silhouette shades the max tilt will need to be adjusted. Still, it’s a great start. Awesome work!

You were using type 23 weren’t you ?
I thought I accounted for them having a smaller number but obviously not working

I’ll add some debug so I can see what it is sending

Would be great if someone with one of the other tilt types (ones that aren’t 18/23/38) so I could confirm behaviour when they use the integration (I don’t have any tilt blinds so trying to build this straight from logic)

Things we prob need to check

  1. how blind behave when everything is closed
  2. how blind behave when everything is open
  3. how blind behave when half open

Be great if when we respond to include your type - hard to keep track of everyone :slight_smile:

I did include your blind type in the HA UI now too (both number under hardware ID and name under type)

I have type 23, similar to @TonyInHiro 0-50 moves the tilt from 0 (closed) to 50 (fully open, 90 degrees different to position 0). Anything above 50 has no additional effect, the tilts are open but my blind doesnt rise as Tony seems to be suggesting

My expected behaviour would be 0 = tilted closed, 100 = tilted open

Edit

Actually, setting it to 51-100 has no effect, as in, it doesnt make them open to maximum amount, it causes no effect. Changing between 51-100 values also has no effect, e.g going from 100 to 60 to 90 does nothing. Presumably the tilt value for 51+ is out of bounds and so is ignored by the blinds, rather than rounding it down to its supported maximum

Hi all - I’ve looked as best I can but I can’t find an answer to this issue. Apologies if its’ already out there. I installed a set Hunter Douglas shades a couple of weeks ago and I’m trying to integrate w/ HA but it’s been problematic. The default integration will not connect to my hub. I’m not sure if this is because my hub is too new - is there a new gen coming out now that isn’t covered by the integration? Anyway, what I do know is that when I try to visit my ip address in the browser, I get a 404 response: “404 error at: [/] params:{“0”:”"} body:{}"… similar thing if I visit [ip address]/api: “404 error at: [/api] params:{“0”:“api”} body:{}”. Has anyone else seen this? Right now, it seem the only integration I have possible is through Homekit Controller, but that is acting up all the time and seems like it doesn’t really work.

@Kingy444 - I’ll give it a go. Thanks for your work.

The behavior @trullock wants is not right for me :slight_smile: .
The behavior I want is like it is (except that it should go beyond 50). So for example 0 is closed tilting inward, 50 is fully open and 100 is closed tilting outward.

@massamino makes sense for type 51, type 23 only tilt ~90 degrees from vertical to horizontal

That explains it :slight_smile:

I tried the custom integration (didn’t remove the original, so it could be that the problem is because of this). I tried it this way first because I use them in automations.
The blinds don’t move when I try to tilt them.

Logger: homeassistant.helpers.integration_platform
Source: loader.py:589
First occurred: 9:55:32 PM (6 occurrences)
Last logged: 9:55:32 PM
Unexpected error importing hunterdouglas_powerview_custom/diagnostics.py
Unexpected error importing hunterdouglas_powerview_custom/group.py
Unexpected error importing hunterdouglas_powerview_custom/media_source.py
Unexpected error importing hunterdouglas_powerview_custom/logbook.py
Unexpected error importing hunterdouglas_powerview_custom/system_health.py
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/integration_platform.py", line 34, in _process
    platform = integration.get_platform(platform_name)
  File "/usr/src/homeassistant/homeassistant/loader.py", line 572, in get_platform
    cache[full_name] = self._import_platform(platform_name)
  File "/usr/src/homeassistant/homeassistant/loader.py", line 589, in _import_platform
    return importlib.import_module(f"{self.pkg_path}.{platform_name}")
  File "/usr/local/lib/python3.9/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1030, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
  File "<frozen importlib._bootstrap>", line 984, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'custom_components.hunter_douglas_powerview_custom.recorder'

I did some more testing with my type 23 blinds and got the following results.

When changing the tilt from fully closed, it works as expected up to 50 percent (as @trullock said these blinds only tilt 90 degrees), when setting over 50 percent the blinds act strangely. The veins will fully close and the the blind will open a small amount, but if I set the tilt to 100 percent it will fully close the blind again (veins closed, blind closed). Looking at the api, despite my blind only having a maximum tilt of “position1”:32767, it still accepts values greater than that.

When changing the tilt value from fully open, the blind closes completely, then sets the tilt to the correct position. Setting tilt to over 50 has the same effect as above in that it will close the blind to almost completely closed and not affect the tilt.

Changing the tilt value from half open has the exact same effect as changing the value from fully open.

Also setting the blind level while the veins are open will fully close the blinds and set the blinds to the correct position.

However there is some logic that will need to be added, as the hunter douglas API only reports one kind of position at a time. So if I have the blind half open, the api reports the position as {“position1”:32767,“posKind1”:1}, if I then change the tilt value to fully open the veins, it will close the blind and fully open the veins and the value from the API is {“position1”:32767,“posKind1”:3}, which means that HA has not seen the value change for the blind position, the blind position slider stays at 50 and the tilt position is set to 50. When opening the blind while the veins are fully open, the veins slider will stay at 50 while the blind position slider will move to the correct position.

As type 23 blinds only support opening veins while the blinds are fully closed, if the veins are opened the integration will need to set the blind position to 0. Similarly, if the veins are open to any value and the blind position is changed, the integration will have to set the vein position to 0.

That makes sense because of of how the backend in HD works (it just stores whatever is sent and we only send 1 command)

This is why the TDBU blinds needs to send two commands too - can you try and post the below to your blind (might need some format correction just typing out on my phone

Be good if someone with blinds that tilt anywhere can confirm too - I assume I would need to post the current position same as I do for TDBU

“{‘shade’: { ‘positions’: { ‘posKind1’: 3, ‘position1’: 15420, ‘posKind2’: 1, position2: 0 } } }”

If you don’t want to remove your original integration I would suggest setting up a temp HA instance in a docker, vm etc just to test

The integration I sent you is renamed to prevent conflict with internal integrations

Not sure on the error you got - I haven’t seen anyone else get that yet - it is being built as an internal integration not for HACS etc so I actually have to do some extra tests before I post here to make sure my conversion to external worked correctly

All that being said - I have run both side by side without issue too - but it can get confusing which integration is being used when testing

Type 23 shade.

Just tested out

“{‘shade’: { ‘positions’: { ‘posKind1’: 3, ‘position1’: 15420, ‘posKind2’: 1, ‘position2’: 0 } } }”

this code (quotes were missing on position2 but I fixed it). This closes the blind and sets the tilt position, and reports both positions in the api, and consequently in HA as well. I then tried inversing the numbers

“{‘shade’: { ‘positions’: { ‘posKind1’: 3, ‘position1’: 0, ‘posKind2’: 1, ‘position2’: 15420 } } }”

which closed the veins but did not raise the blind, I then tested

“{‘shade’: { ‘positions’: { ‘posKind1’: 1, ‘position1’: 15420, ‘posKind2’: 3, ‘position2’: 0 } } }”

which closed the veins and raised the blind to the correct position. I suspect that while the api will report back posKind2, it has no actual affect on the blinds movement. I tried out

“{‘shade’: { ‘positions’: { ‘posKind1’: 1, ‘position1’: 0, ‘posKind2’: 3, ‘position2’: 15420 } } }”

which closed the blind but did not change the tilt position of the veins. So I guess we can use posKind2 and position2 for reporting the correct position in HA, but it has no effect outside of that. But that would mean opening and closing the blinds/veins using the physical remote or hunter douglas app would not correctly update the values in HA.

However I then came across a problem with the hunter douglas api. After using the physical remote, the api does not report the blind position correctly (it will continue reporting the previous value) unless you view the blind in the hunter douglas app/change the position in the app or HA, I’m not sure if this is by design or a bug, but it would mean that there would be no way to be certain of the shades current position if there is a physical remote also being used.

`[quote="mperone, post:66, topic:233720, full:true"]
Hi all - I've looked as best I can but I can't find an answer to this issue. Apologies if its' already out there. I installed a set Hunter Douglas shades a couple of weeks ago and I'm trying to integrate w/ HA but it's been problematic. The default integration will not connect to my hub. I'm not sure if this is because my hub is too new - is there a new gen coming out now that isn't covered by the integration? Anyway, what I do know is that when I try to visit my ip address in the browser, I get a 404 response: "404 error at: [/] params:{"0":""} body:{}".... similar thing if I visit [ip address]/api: "404 error at: [/api] params:{"0":"api"} body:{}". Has anyone else seen this? Right now, it seem the only integration I have possible is through Homekit Controller, but that is acting up all the time and seems like it doesn't really work.
[/quote]

`

Think you need to contact Hunter Douglas Support mate - if your hub isnt presenting anything when you browse to http://POWERVIEWIP/api/shades then your not going to be able to get the data into HomeAssistant - that’s where the communication comes from

There is a delay usually about 60 seconds or there is a force refresh called when you hit the stop button - if you can play with that there shouldnt be any issue reporting in HA - check out a manual browse to http://POWERVIEWIP/api/shades and that should tell you what is being reported after the press from the physical remote

i am surprised that
“{‘shade’: { ‘positions’: { ‘posKind1’: 1, ‘position1’: 0, ‘posKind2’: 3, ‘position2’: 15420 } } }”
doesnt close and tilt - this is the exact command i would have been sending (i was just lazy when i sent you posKind1 as 3 the first time. From my testing the api hadnt seemed to care which poskind was defined in which position as long as they were defined correctly 1 being the main motor, 2 being the top down and 3 being the tilt

Looking at the base API perhaps this is a shortfalling in the Powerview side as they are only sending either poskind 1 or 3 at a time and never both - but they only do this methon on blinds of type ShadeBottomUpTilt and Silhoutte which both appear to be similiar in design

If you can test scenarios in which posting to the blind works for you (as you have above) and find something that consistently works i can create a class specific for these that treats them special to the other tilt shades - really hard to try and test this without some silhoutte shades of my own sorry :slight_smile:

edit: unfortunately the shades reporting their position post a physical press has always been a bit slow and unreliable - appears i dont have the service calls implemented in this branch yet but i have made a custom service that you can then script to do a refresh of data at a specified time. depending on your use case you could call hourly, against just some of the them etc - just remember that everytime that is implemented it wakes the blind and interrogates the motor so will use (ever so little) power. but it will use some and your batteries will be used as a result. All we normally get is the cache from the hub

An alternate way to prove HA isnt the issue is to open the PowerView App and browse to the shade - the app calls a refresh in the background, updating cache and then HA is up to date. There must be something in the PowerView app that does this in the background as i have had good results keeping position up to date with no intervention post a physical press just by having used the app recently

Thanks - I’ll try to contact them. Just curious - what firmware do you have on your hubs? I have 2 and they’re both on firmware 3.1.379 (ModelID = Standard, Radio = 3.0.15). Are you having success with this firmware?

@Kingy444 remind me of how the API looks for posting the data and I can test it

Invoke-WebRequest -Method PUT -ContentType "application/json" -UseBasicParsing -Uri http://POWERVIEWIP/api/shades/SHADEID -Body '{ "shade": { "positions": { "posKind1": 1, "position1": 0,  "posKind2": 2, "position2": 0 } } }'

posKind 1 is standard motor poskind 2 is top motor poskind 3 is tilt - put the value between 0 and 65535 for the position attribute

check above some examples for tilting from @TonyInHiro

My hub is Firmware 2.0.1056 and Radio 2.0.2610