Hi, for the people that have this working, could you please provide the firmware ID of your Gateway? I’m running 3.1.452 and am unable to activate scenes still. I haven’t tried manually moving the shades. I plan to try that next.
Another question I have is do you need to enable Swagger for the activate command to work? I thought Swagger was just to make it easier to use the APIs and provide documentation.
Thanks in advance!
Just as an FYI, instead of manually hacking something as stated above, I took the liberty of updating the aiovapi base driver as well as the integration. Unfortunately, the new API doesn’t allow you to get the name you assigned in the app, so I’ve been using the IP instead for those users that have multiple gateways.
Fairly minimal changes, still doing testing and then making it friendly to find the generation of API and autodiscover the version of API.
I’ve read previous posts in this thread about Generation 3 Powerview integration. The integration currently available from the Integration tabs in HA doesn’t support Hunter Douglas Generation 3.
I hear a lot of people talking about the Generation 3 hub. I have a generation 3 Gateway (not Gateway +) and it seems that’s what you need for integrations, the hub “seems” to be obsolete. Found this at their website:
A hub is no longer required to experience the full benefits of
the PowerView App. A user’s mobile device can communicate
directly with the shades. The new PowerView Gen 3 Gateway
will be required for integration with third-party systems
and RemoteConnect™, and it provides the best PowerView
experience for the consumer.
Anyway, I was wondering if any progress was being made. I am not a developer by any means, only been discovering HA the last 4 days. But if I can be of any help testing, I do have the new generation blinds.
Are you still working on this? Could you use additional help or testing?
I think that this is a ‘moving target’ as far as Hunter Douglas is concerned. But a few points nevertheless…
Anyway (just so you know) … I am not actually an HA user, I am an openHAB user, I have a Gen 1/2 hub, I am an openHAB developer, I work with the openHAB Gen 1/2 hub in real life, I wrote a significant part of the openHAB / Gen 1/2 code, I have written code for Gen 3 openHAB integration too, I cannot test this latter due to lack of a real Gen 3 hub… … => So to any of you guys with a Gen 3 hub, my proposal is as follows: if you are able/willing to expose your Gen 3 hub to me via a VPN connection, then I could test my openHAB integration code against it, and then once my OH code is proven, I will offer it to the HA developer community (i.e. @Kingy444 ??) as a quick start for the respective HA integration. Or something like that…
+1 interested party.
I have 10+ v2 shades working well with native integration
I have recently added +2 v2 shades and purchased Gen3 gateway.
I’ve been able to enable Swagger; can issue GET commands and activate scenes.
I’ve seen the REST temporary working solution.
Looking forward to native integration.
Can’t wait. Thank you. I also have Gen 3 with a gateway. There are two different gateways I think, wifi and wired. Don’t know if that makes a difference.
FYI I found this thread after much Googling when I had a few new blackout blinds installed behind my existing hunter douglas blinds. I was shocked to discover after the fact that the new blinds couldn’t be controlled with HomeKit (or even the same powerview app) as my original blinds. What a mess.
Anyways, after much searching and even beginning to write my own homebridge plugin with info from this thread, I discovered that someone else already wrote a homebridge plugin. I realize this is the Home Assistant forum, but figured you guys might want to know.
Martin308 created this plugin: GitHub - martin308/powerview and I am pleased to report it works perfectly!
It’s barebones so it doesn’t have all the bells and whistles, but I have been trying it for a few weeks now and it’s solid. You just need to put the Host key in the config for it to work e.g. “Host”: “http://192.168.7.114”. There’s no documentation because it was created for personal use.
I am, I realized I didn’t have notifications on turned on for this.
I have it working. I’ve been spending time on making it work with both versions of the API which takes like 4 times the time to just do it for the current one. I’ve been cleaning it up and only have to rethink how the position logic works for both APIs.
I made no attempt on the event listener within HA, although I can listen to events from the gateway and see them fire. I’ve decided to not implement this for the first release as I’m sure everyone else rather just have something that works without seeing it live update from movements from the remotes.
To me they have a few things to fix in the new API. There is no way to get the gateway name other than the non-documented everything endpoint /home. So I do that to get your name. Also doesn’t support calibrate or favorite (heart). I’m not sure it needs to though.
Anyway, I plan to push this out next week. Will be an update to the aiopvapi driver (most of the work) but some things directly in HA as well.
Oh, forgot to ask. I can only test the Gen 2 API via the tests in the aiopvapi driver. I’ve made it so it ought to keep working, but anyone with a Gen 2 hub/gateway I could use help with testing it.
Thanks so much for the rapid implementation. I’m new to the PowerView ecosystem, so maybe this is a dumb question. My home has two PowerView Gen 3 Gateway Pro units installed. In the app one of them lists as the “primary” gateway. Will this be handled by the work you’ve done so far? Is there anything I can do to help you test a multi-gateway installation?
Good question. Haven’t considered multiple gateways. I’d suspect you’d only use HA to the primary and the primary would talk to the secondaries as needed. I’m assuming that is all done within the app.
Having said that, you ought to be able to connect multiple gateway within HA. Maybe each gateway will have it’s own devices hanging off them as they are configured within the app. Would be a good test case to see if you have any problems with it. I don’t think there would be anything specific for this integration to handle other than ensuring it can add both gateways and operate on both simultaneously. You could, if you feel comfortable with it, use swagger to each gateway and get a feel for how it is configured.
Now that I think of it, I’ll have other limitations. I did not test Scene creation or make any attempt to make that work. Gen 3 also has the ability to set the velocity of the shade movement. I won’t, initially, have any mechanism to set that either. So there will be some followon things to do after the initial release. I also don’t have any tilt shades to test.
My installation is all new hardware, so the shade’s themselves are the latest. Have 10 of them in a variety of configurations including top/down ones.
It looks like this won’t require much work at all on the back end. I enabled swagger on both gateways and it looks like only one of them is responsive to API calls. For example:
Gateway 1:
GET http://gateway1.local:80/home/id
200 {
"id": "{redacted}"
}
Gateway 2:
GET http://gateway2.local:80/home/id
400 {
"errMsg": "Multi-Gateway environment - this is not the primary gateway"
}
The gateway-specific API calls (like /gateway/info) still work on both gateways, but anything related to the rooms and shades only works on the primary gateway.
What I don’t know is if the two gateways hand off being primary occasionally, or if the first one I installed is and will always be the primary.
Well that makes it easier for the integration for sure.
I have pushed my code to get it to work. Will need to update the aiopvapi driver first.
Then home assistant, which should require 3.0.0 version of the aiopvapi driver.
Let me know how it goes. I did my best to ensure the gen 1/2 hardware should still work, but without the hardware to test on it is hard to know. All the driver tests pass, I expanded those some to do a better job acting like the actual hardware.
This is exciting! I only have v3 hardware, so I can’t do any gen 1 or 2 testing, but I am really looking forward to having this integration working!
With the latest update to the gen3 gateway, it now integrates with my HomeKit setup. Mentioning as that might be of use to some folks.
@alindner19 - if you still need hub access, DM me. I already have an ovpn setup and wouldn’t take much to add ya in.
@alindner19, in ways of introdutions I am the one who made the changes to the api to support all shade types. Your changes loog pretty good overall, from my experience in the submission of the v2 changes to core there could be some refactoring required to get this in, but that last 5% is always the hardest
Not near my hub to test but a quick clance over your code i can see a couple of issues.
We need to keep the data in the position data for means of HA, not means of the hub. The hub will ignore the additional data but HA needs it to know where the secondary shades are
HA uses PowerviewShadeMove to store the data for some shades secondary position based on known behaviors. ie, when a tilt shade command is set we know the main will close/open for certain types but HA wont without this info.
both of the below will cause inconsistencies in HA so we need to add the other values back in
Query where this info came from - V2 have a MAX_BATTERY of 4, and previous math was to convert say 3/4 to 75% strength
Doesnt look to be any other breaking changes in the aiopvapi other than the ones regarding open/close position so if you want to submit a PR for those I can get that into a release (the original owner of the api has provided myself and another HA developer admin to the repo)
Once we get that in we can start work on getting it into HA - I had started work on this many months ago but yours is much more progressed. I was looking to make alot more of the changes in the upstream api as they like to clear up HA code as much as possible
ie instead of
return PowerviewShadeMove(
self._shade.convert_to_v2(
{
ATTR_PRIMARY: MIN_POSITION,
}
),
self._shade.convert_to_v2(
{
ATTR_SECONDARY: MAX_POSITION,
ATTR_TILT: MIN_POSITION,
}
),
)
In my changes i was making the upstream API do the calculating changing PowerviewShadeMove to take 0-100, ie true percentages which is what HA calculates them to anyway.
So rather than processing the 0/65355 for v2 an 0/1 for v3 we send the upstream a percentage value and the upstream can calcluate for the api version. Ideally the code in HA is preferred to be as simple as possible.
Doing the above makes the above code example (from yours) into something like the below that should never need to change, and only the upstream would
return PowerviewShadeMove(
{
ATTR_PRIMARY: 0,
},
{
ATTR_SECONDARY: 100,
ATTR_TILT: 0,
},
)
If you want to submit the aiopvapi for pull I can do an actual review of the code, and then help with the HA integration side from there. I only have v2 hub but as i wrote most of the existing code i do know where things may break.
If the HA integration is submitted in its current state, i suspect the merge to take months just for them to review - it is preferred for each commit to be as small as possible, while still being functional.
For instance - we will probably need to break your HA commit into many smaller ones, adding functionality to each. First adding detection with shades only - next commit to include sensors, scenes, buttons etc - this will get it into HA much quicker
Will still need to move a couple things to upstream but nothing wrong with it being 3.0.something when we are ready for core integration
Send me a PM or just hit back here so we can start getting it into core without breaking the current functionality 
Thanks much for the feedback.
For the PowerviewShadeMove, that is how the data must be sent to the gateway. They are in different formats from gen 2 to 3. Gen 2 has them in the format
{
ATTR_POSITION1:position #,
ATTR_POSKIND1: Primary/Secondary/Tilt attribute name,
ATTR_POSITION2:position #,
ATTR_POSKIND2: Primary/Secondary/Tilt attribute name,
}
Whereas gen 3 simiplified this to:
{
primary: position #,
secondary: position #,
tilt: position #,
velocity: num, # This is new to gen 3 (as far as I can tell) and not supported yet in this integration.
}
There are ones that send multiple of these later in the shade.py file. I reviewed these changes and made tests for them to ensure it should work the same on Gen 2 hardware. I don’t know how to send the commands to Gen 3 hardware without this data structure changing. I like the improvements to Gen 3 overall, makes it simpler to do these positional updates.
On this note, I didn’t see how allowed_positions is used and did not change anything with them.
Max Battery change. Good find. I did miss that one. I’ll add:
SHADE_BATTERY_LEVEL_MAX_V2 = 200
When I did it I thought it was the same as HA, 0 to 100 which I even made a code comment on in your picture of the change. This was the also the last thing I did, make these two V2 compliant.
As far as changing the PowerView update from 0 to 100 and then making the underlying driver figure it out, I was thinking the same thing there too. Try to keep HA as vanilla as possible and keep the updates to the aiovpavi driver.
Thanks for the review and the help getting it in HA, I really appreciate it. I feels odd to do this piece at a time as those pieces won’t do any good to anyone by themselves. Just not how I’m use to doing code reviews in the business world.
@Kingy444 just for info:
The Gen 1/2 hubs use a ‘pull model’ (polling model) to get the shade data. An API client can poll the hub in real-time, but the hub would not poll the shades very frequently so as to prevent draining the batteries of the shades due to the energy needed for RF communication. This means that the Gen 1/2 hub would hold a cache of the position of the shades, which may or may not be fully in line with the actual position of the shades.
By contrast the Gen 3 system a ‘push model’ (event driven model). The system uses BLE (Bluetooth Low Energy) to talk to the shades. This means that the shade immediately pushes any position change to the hub, so the hub is always fully up to date. Furthermore the hub will always push that state change onwards to any subscribed API client event sink. You are right that a state change event may contain only the one JSON element that changed; so if the event contains a primary position element and not a secondary element, you have to assume that the secondary value is unchanged from its prior value. And indeed, as you say, that means that the primary / secondary and tilt values do need to be locally cached in HA, (and probably refreshed from time to time by a polling request).
Hey everyone! I’m following this closely. What’s the update here? I’m not a Home Assistant expert, but I’d be happy to test this out if there’s a reasonable way for me to get started!