PowerView API // Shade capabilities table #16
Comments
|
That's looking good ! Many thanks for this. Also your repo looks very well documented. Better than mine ! ;-) I used to be working on the European Powerview team as a technical product manager. That's why it was easy for me to get a lot of info of the internals of the system. Unfortunately for this project I am no longer involved in PowerView. Going through the list see my remarks below: Silhouette: Can move and tilt-at-bottom That's about it I guess. |
|
^ |
|
PS I got the |
|
Just for info: here are the Shade Types and Shade Capabilities in code. => If anyone has additions of correc6tions to this list, please feel free to post the information here!
|
|
"Silhouette" can also be type 18 example: |
@pessorrusso many thanks for the feedback; I will update the table above. |
|
@andrewfg The capabilities of type 6 'Duette' is indeed 0. It's a regular bottom up behaving screen. |
|
@carpaij many thanks for the confirmation. |
|
As mentioned in the home-assistant community, I have (horizontal) Venetian blinds of Type 51. This might be the same as Type 62? aio-powerview-api/aiopvapi/resources/shade.py Line 235 in 89711e2 |
|
@nixpanic many thanks for the feedback.
Concerning your request on that home-assistant thread.. Unfortunately I cannot solve your request directly. However I can tell you that on openHAB we have already implemented support for dual motor shades (i.e. those with independent rail position and tilt actions, or those with top down and bottom up rail positions). And if any of the home-assistant developers want to "borrow" from that code, they can see it HERE.
Indeed. I had already picked up type 51 from that thread. You will be able to see the latest version of my ShadeCapabilitiesDatabase starting at line 59 in the source code below.. openHAB Shade Capabilities Database |
|
@nixpanic Just checking: they can move and tilt independently from each other ? |
Yes, attached to the ceiling:
|
|
I have Hunter Douglas "Vignette" Modern Roman Shades with Duolite that report as type 65, and I don't see that in your table. If you defined 100% as completely closed and 0% as completely open, 75% would have the room darkening shade halfway up, 50% would be the darkening panel all the way up but Roman shade down, 25% would be the Roman shade halfway up. I also have Silhouette shades that report as type 23. These raise and lower and can tilt when all the way closed. I'd be happy to help improve this integration if I can. |
|
@jeffdeal many thanks for the feedback. I think we already have the type 23 shades covered. But the type 65 is an interesting new one. And I have some questions about it, so that we can understand more fully.
|
Thanks! |
|
@jeffdeal do these currently work on HomeAssistant - I don’t recall code well enough to remember if they would or not but from your description they should function as a normal shade all given with some strange positioning based on the percentage value of the blind I did think if they don’t match a defined type they default to bottom up but could be wrong. are you just asking for them to work in general or are you wanting specific functionality? Given there is only one motor and they can’t function independently not sure what we could do there |
@jeffdeal could you post the response when you open the link http://(hub-ip-address)/api/shades in a browser? |
|
I added type 65 to my openHAB Shade & Capabilities Database with the provisional |
|
^
|
|
I believe 8 will be correct for this shade - lift only Duolite operation. |
@jeffdeal many thanks for the info about the capabilities. Do you also confirm that the above is an exact description of the rail positions? Do you therefore have any thoughts about how one would model this behaviour in a UI in an ideal world? For instance, perhaps having two sliders where the first one controls the front shade (UI slider 0..100% maps to raw position 0..50%), and the second slider controls the blackout (UI slider 0..100% maps to raw position 50..100%), and it’s operation is disabled and it’s position displays as “N/A” whenever the position of the first UI slider is less than 100%. Or something like that? |
|
Hi, I was just using the percentage descriptions to try to describe the way these shades work. In the official Power View app, the UI shows the shade and the back panel as separate entities. But as previously described, they cannot operate independently. The shade has to be all the way down before the back panel will come down. For example, if I have the shade halfway up, by definition the back panel must be all the way up. In the UI, if I ask to put the back panel halfway down, the shade has to close first, then the back panel will come down to the requested position. If HA can replicate that functionality it would be consistent with the official app. The Silhouette shades (type 23) are shown similarly in the UI. On the left side is the shade position, and the right side are the vanes. The shade must be all the way down to operate the vanes. If the shade is down and the vanes are open, and you want to have the shade 50% up the vanes have to close first, then the shade will travel to the requested position. I'll try to attach a screen shot of the way the shades show in the app: These are the Vignette Duolite:
These are the Silhouette:
|
|
@jeffdeal thanks for the screen shots. Does it work at all in HA at the moment? And if so, what do you actually see in HA in the following cases?
|
|
@jeffdeal as a better alternative (in particular if it does not work for you at all in HA at the moment), can you please post the results of moving the shades to each of the 5 cases mentioned above, and then loading this url |
|
Yes, these shades show up in HA and I can do some rudimentary control like open and close. There is an attribute called "position" that varies from 0 to 100 where 0 is fully closed and 100 is fully open. There are up, down, and stop controls available, plus a slider that shows and can control the position. However, this has no effect on the back panel. Home Assistant seems unaware of the position of the back panel. Setting position to "closed" only closes the front shade. Here's what the entity card of Home Assistant shows when I click on it:
|
|
@jeffdeal that is really interesting; but it opens more questions than giving answers; so I think it would be very interesting to see the 'positions' values of the five cases mentioned above. |
|
@jeffdeal That's perfect! As you say, the functionality of type:65 capabilities:8 shade seems to be analogous to the regular 'bottom up / tilt when closed' shades when the shade is fully down, except that
Many thanks for your support! |
|
@kingy444 do you have any user data on shades type 55 or 56 ? My reason for asking is that I have a user whose shades report as below (his type 56 is basically the same as the 55), and they have vertical vanes with main position / tilt anywhere / tilt 180. So I think that we may have the following errors / mix ups..
|
definitely have report of both 54 and 55 being capability 3 but the same post also has type 55 as capability 4 -wtaf Linked and copied important part below but as you can see they have 4 of these and 2 are reporting capabiity 3 and 2 are reporting capability 4 the two reporting capability 3 have completely different motor revisions EDIT: I'm thinking maybe our code is right control wise - but we perhaps need to treat these similiar to the type 1 that have tilt - ie need an override. The code here would always treat them as capability 3 because we have it hard coded via they type number {
"shadeIds": [3433, 58444, 58722, 731],
"shadeData": [{
"id": 3433,
"type": 55,
"capabilities": 3,
"batteryKind": 1,
"smartPowerSupply": {
"status": 0,
"id": 0,
"port": 0
}
}, {
"id": 58444,
"type": 54,
"capabilities": 3,
"batteryKind": 1,
"smartPowerSupply": {
"status": 0,
"id": 0,
"port": 0
}
}, {
"id": 58722,
"type": 55,
"capabilities": 4,
"batteryKind": 1,
"smartPowerSupply": {
"status": 0,
"id": 0,
"port": 0
}
}, {
"id": 731,
"type": 54,
"capabilities": 4,
"batteryKind": 1,
"smartPowerSupply": {
"status": 0,
"id": 0,
"port": 0
}
}
]
} |
|
^ |
|
@jlaur could you please give me your thoughts about how we should handle these type 54/55/56 shades, where some instances report capabilities:3 and other instances capabilities:4 ??? |
|
@andrewfg I was suggesting that capability 3 is tilt 180 and capability 4 is plain open close as we have them currently and that type 54,55 & 56 should be forced to use capability 3 to get a tilt functionality regardless of what capability they return in the json. (this is how HA and this API function atm) Really we need JSON for either 69,70 or 71 to confirm what capability 4 looks like on a different shade type. Essentially i am saying for these shade types we now cannot trust the capability value and need to force the capability type |
This is our current order of precedence:
So if some of these shades actually report wrong capabilities, and they all actually share the same capabilities, we should simply use capabilitiesOverride like we did for type 44 (Twist). If actual capabilities are different from shade to shade for same type, we have to make capabilities configurable as we have no reliable way of determining correct one. Last possibility, if the reported capabilities are correct, it will already override the type capabilities, so it should work (although we currently log a warning in this case). But from @kingy444's last comment this doesn't seem to be the case. |
|
This is just an FYI on this API V2 which will be packages soon has two methods to identify a shade. First via hard coded shade “type” - this makes sure shades are given the type we want them to and this is passed to HA Second (this is the new part) does a smart check via capability and assigns an educated guess to the type of shade it should be using. the only shortfall will be we don’t have any friendly name for them in that case but functionally they should be fine |
@kingy444 picking up from the thread on the HA forum concerning capabilities 3 vs 4.
=> @kingy444 do you agree with that?
|
|
^ |
|
@andrewfg just added 26/27/28 type definitions - Skyline Panels with capability 3 ** thought i had replied to the previous too - agreed with your definitions and we are doing the same in HA now too |
|
Good day folks, I have installed ARC and have successfully sent commands to my shades, type 23 and 65. I am happy to run any tests you need.
I've done a little playing around with my shades this morning. For my testing I have only sent values in posKind1 and position1. I did not include posKind2 and position2 in the JSON at all.
For the type 23s:
When posKind1 = 1, sending a value in position1 between 0 and 65535 moves the shade, with 0 being fully down (closed) and 65535 being fully open (up).
Sending posKind1 = 3 and a value between 0 and 32767 will lower the shade regardless of current position and tilt the vanes. 0 is closed, 32767 is open 90 degrees.
For the type 65s:
When sending posKind1 = 2, this refers to the back panel. Sending posKind1 = 2 and position1 between 0 and 65535 will place the back panel in the requested position, with 0 being completely closed (down) and 65535 being up (open). Since the back and front panels cannot operate independently, the front panel will always close when commanding the back panel. For example, if the front panel is open (up) and you send posKind1 = 2 and position1 = 65535, the front panel will close and the back will be fully open. This is equivalent to sending posKind1 = 1 and position1 = 0.
Sending posKind1 = 1 always refers to the front panel, with position values of 0 representing down (closed) and 65535 up (open). Since the shades cannot operate independently, the back panel always has to fully raise to achieve the desired setting.
To me, the simplest way to represent this would be a toggle switch to select the front or back panel (which would set the value of posKind1) and then a slider to represent 0 to 100% to represent the position. Of course, I don't know if the HA architecture would permit this type of interface.
For these shades, I don't think you should filter for impossible combinations. Just send the command and allow the shade to do what it needs to do to achieve the result. For example, on the 23s it is impossible to tilt unless the shade is fully down. A command to tilt the shade shouldn't be filtered, just send the tilt position and the shade knows to close first.
I'll be glad to help in any way I can, so let me know if you need any special testing or other information.
Jeff
…________________________________
From: Andrew Fiddian-Green ***@***.***>
Sent: Sunday, May 22, 2022 6:12 AM
To: sander76/aio-powerview-api ***@***.***>
Cc: jeffdeal ***@***.***>; Mention ***@***.***>
Subject: Re: [sander76/aio-powerview-api] PowerView API // Shade capabilities table (Issue #16)
not sure on how to implement for type 9 (they are tdbu and tilt right ? @andrewfg<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fandrewfg&data=05%7C01%7C%7C285f1c2ea82e444c1f9008da3bdb9c40%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637888111660098813%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=vG4tswDeCKVyJhFgHzZchG3jpKHGsEgsF87CgM7ZkMo%3D&reserved=0> ))
A caps 9 shade is like a caps 8 but with a tilt motor added.
* Caps 8 and Caps 9: the primary and secondary shade positions are packed using the interlock logic in position1/posKind1
* Additionally Caps 9 only: the tilt position is independently in position2/posKind2
________________________________
“what is an impossible position”
From my perspective the following are impossible positions, and how they interlock..
// Tilt on closed (a)
if (shadePosition != 0) {
vanePosition = 0;
}
// Tilt on closed (b)
if (vanePosition != 0) {
shadePosition = 0;
}
// Tilt shades in general
if (tilt90degrees) {
vanePosition = Math.Min(vanePosition, 32k};
}
// Top down, Bottom up
bottomPrimaryShadePosition = Math.Min(bottomPrimaryShadePosition, (64K - topSecondaryShadePosition));
topSecondaryShadePosition = Math.Min(topSecondaryShadePosition, (64K - bottomPrimaryShadePosition));
// Duolite (a)
if (primaryShadePosition != 0) {
secondaryShadePosition = 64k;
}
// Duolite (b)
if (secondaryShadePosition != 0) {
primaryShadePosition = 0;
}
—
Reply to this email directly, view it on GitHub<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsander76%2Faio-powerview-api%2Fissues%2F16%23issuecomment-1133862818&data=05%7C01%7C%7C285f1c2ea82e444c1f9008da3bdb9c40%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637888111660098813%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=uX25EJhriwTX37vZvyyMelf7n3sopiETUAbdE8XhTxM%3D&reserved=0>, or unsubscribe<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FARIKP2P2KV55J6STVUIHIXLVLICBVANCNFSM5IXFKYCA&data=05%7C01%7C%7C285f1c2ea82e444c1f9008da3bdb9c40%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637888111660098813%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=y9Oq0z0jgO%2B197L2cC82m4Ov7xZ3pAN5jy5xnixKtXw%3D&reserved=0>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
@jeffdeal i think we have all types sorted over on the HA forum a custom version of the component is posted to test the only thing reported there was the open close buttons not working for type 8/9/10 (oversight in me transferring code to new format) you’re welcome to install and test that - I’ve been working on the PR to get these into core HA this week - hopefully I can get the PR in time for 2022.11 |
Many thanks @kingy444 |
|
@andrewfg how far along are you with the implementation of the hen 3 hub? I know some of the naming changed such as poskind1 / tilt / primary etc but do the actual endpoints still take the same json format (using new names ?) just getting this to where it needed to be for complete gen2 support now and I’ll start v3 soon - need to work out how much I need to do |
Hi @kingy444 .. a few updates..
|
@kingy444 .. it is 'all of the above' see this link (you can expand the buttons) https://www.tdrs.info/Swagger%20UI.html |
Fingers crossed - i got a lot of work to get gen 3 into HA so that would be amazing Its not clear from the api docs - do you know how shades that require both attributes to be sent behave in gen 3 ? ie in Gen2 - if you didnt post both positions the shade wouldnt return the data until a force refresh occurred |
|
also another set of capability 0 added |
|
@andrewfg did you have contact with the HD rep still / the swagger UI is no longer active |
Yes I and @jlaur have been in email contact with him. He promised to share the final spec with us. But apparently there is still some work to be done on it, and they have to push some new firmware, so it seems to be taking him a bit longer than he originally expected. But I will keep you posted.
I guess you are referring to the API that was posted / hosted by another HA user? Yes I also noticed that he had taken it down. For me it’s not a big issue since I think I already have enough info to work on until I get the final version from the HD guy. But if you need it then perhaps contact the OP on the HA forum and ask if he can put it up again? |
|
Heya folks - Shade type = 52 So are these being advertised incorrectly with capability 1 instead of capability 0? Should we just "fix" this here and add the mapping from type 52 to capability 1? |
I think that on such banded shades, the ‘tilt’ capability actually does exist. You just need to interpret ‘tilt’ as ‘transparency’, so when you set tilt=0% the bands adjust to let the maximum light through, whereas when you set tilt=100% bands adjust to let the minimum light through. This is certainly the case on type 44 Twist shades.. |
Thanks; i've tested and it's not the case, in reality, on the banded shades. The Shade Status might imply that it's doing this, but it's not physical functionality on the shade. When the shade is set to closed and you adjust the tilt, the shade status does say that And of course this is a real pain, as exposing this entity to a voice assistant, the VA needs to now disambiguate the setting: There's a super hacky workaround in HA which is to manually create a new Template Cover that only adjusts the |
|
@jpearl for the avoidance of doubt, could you please post the JSON from your type 52 shades? |
@jpearl from your description this sounds like this is what will be needed. Unfortunately this is working by design and we can’t trust Hunter Douglas are reporting type correctly. Another user with type 52 could very well have JSON reporting capability 0 as it should. The code in this API will attempt to map via the hard coded shade type (52) and if that fails (and it will as we don’t have these defined) it will fall back to the capability (1). This was added in version 2 and works great when the blind firmware is working correctly but we have had this issue pop up where the shades think they have capabilities they don’t. Please still post the JSON though at the end of the day we really need to take user advice on each model functionality and work from there as Hunter Douglas don’t provide this info. |
|
Sorry for the delay, here it is: When closed fully: Half open (only posting positions for brevity): Fully open: |
|
@kingy444 - thoughts^? |
|
Yea it’s as I suspected and the shades are reporting capability 1 incorrectly. as we don’t have them defined, they fallback to capability matching and give tilt based on that I am working on an the active PR submission to support v3 atm - I have included those shades there. |
I am a code contributor for the openHAB binding for Hunter Douglas PowerView shades (see info below).
Just as you guys have, we are also facing the issue of how to fine tune the binding functionality and UI to match the physical capabilities of the different types of Hunter Douglas shades. As a result of extensive Googling of shade JSON payloads, and developer repositories on GitHub (including yours), I was able to build the following (tentative) table of shade
typeattributes versuscapabilitiesattributes. And I am pleased to (hereby) share it with you.=> Any further inputs or corrections would be very much appreciated - especially from @sander76 and (perhaps) @kingy444
The text was updated successfully, but these errors were encountered: