As a reminder, you can now control shades on Gen 3 hub using the HA’s HomeKit controller. That should cover most of the use cases in this thread. I have a PowerView Gen 3 Gateway Pro with firmware 3.1.472.
To pair:
It would be great if the HomeKit Controller integration covered this, but it has it’s own issues. For example, I can’t install it because during installation it says “No unpaired devices could be found”.
I’ve spent a significant amount of time trying to enable HomeKit as a workaround.
What integration has to be added prior to the Gen 3 blinds being recognized? Should I be installing Apple Homekit, or the old Powerview? Or something else?
I did not have to add any integration. It was automatically discovered. Make sure HA and the Hub are on the same network / VLAN. I also have the “pro” gateway, not sure if it makes any difference.
Amazingly good timing. Just got my Powerview Gen 3 Gateway Pro literally today.
Here’s what I did to set it up in HomeAssistant with thanks to @blicus:
HomeAssistant:
PowerView:
Everything works really well through HomeKit. If there’s a better (native or not) integration I’ll likely switch over but for now I’m happy.
Great writup gpez. I tried everything up to #10 of PowerView. I actually had all the PowerView stuff already done, I have a Gateway that’s on the network and already assigned to a room.
But HA doesn’t see it when trying to add Homekit Controller. I suspect it “may” be because you have the more expensive wired ethernet Gateway, and I have the less expensive wifi gateway. I hope that’s not it.
Knowing how long these things take from the changes i made implementing v2 shades and updating the integration i expect ~6 weeks before v3 support is available to you natively without the need for the HomeKit workaround above. Once native support is enabled it will be a simple add button.
I have been working through the code @alindner19 submitted to the upstream and making required changes to get this work with HA (in a way that aligns with their architecture decisions) and gen 1/2.
The changes in how gen 2 and gen 3 speak has led me to implement an additional wrapper around them both (which to me makes the most sense) as this leads any call to the API to be the same regardless of the generation you are using. Just taken a bit longer due to personal commitments but nearly there 
Once the above is done i will have @alindner19 test before promoting the code to PyPi - at which stage - should anyone here be interested - i can provide a custom component version of the plugin that will allow you to test some functionality (and we can potentially fix before hitting a HA release)
Keeping an eye on this. Once implemented I can test against a pretty good sized system. Cheers!
Just FYI (I think we beat you by a few days…)
@Kingy444 Should we have just gone to a custom integration from the beginning? Having others use HomeKit for the interim seems offensive to me. But I’m a non-Apple guy, so I just can’t do it under any circumstances.
anyone with multiple gateways able to share the result of a call to http://powerviewip/home or @andrewfg would you have this on hand from OpenHAB dev work ?
Also query re multiple gateways. Does the second just act as a repeater, or if the primary fails does it fall over ?
We’ve covered a lot of ground in this thread so it was easy to miss. I posted this back in April:
I’m happy to run any other tests if they will be helpful.
i actually did see this one - but what i am after is the http://gateway1.local:80/home not http://gateway1.local:80/home/id
based on the code provided by @alindner19 it looks like this call should contain the info for all hubs and not just thr primary (thats where the /id call comes in)
But also, as you aluded to in that post, it isnt clear if the primary goes offline, will the secondary start acting as the primary
Here are the two responses from each gateway (more or less):
200 {
"automations": [],
"createdDate": "03-03-2023",
"home": {},
. . .
"remotes": []
}
400 {
"errMsg": "Multi-Gateway environment - this is not the primary gateway"
}
It does contain a section gateways: That lists both my gateways and their IPs. But that only works on the primary gateway.
It also shows the full name of each gateway as named in the app. I think I recall some discussion about that previously.
can you pm me the entire json - redact anything you feel is sensitive by changing to xxx, but i need the json response as a whole if i can please. ie keep the field “ip” but feel free to redact what the IP is
only looking for the response from the primary gateway
I’m sorry to reduce the text to image, but it’s a HUGE blob of json and I don’t have any good tools handy to scrub my personal information. This is what I can do quickly. Here’s a screen cap of the structure with some redaction:
I do have two gateways. But only one of Gen 1/2 and one of Gen 3. In the HD app, one can merge the two gateways into one home. But basically there is no interaction between the two sub-systems. A GET on the Gen 3 gateway IP as you describe above, shows only itself. And ditto a GET on the Gen 1/2…
Perhaps @vves can advise how shades from a secondary gateway would appear via a primary? I am guessing that all shades in such a system would have a unique shade id regardless of whether they are in the primary or the secondary gateway? And therefore I guess that all shades would be automagically visible via their shade id in the primary. In other words, the secondary gateway(s) is/are just forwarding the data. Or ??
As near as I can tell, here’s how it looks (with two gen3 gateways) from calling the /home API endpoint:
All shades in the system – irrespective of which gateway they are paired with – are listed in the results of the /home/shades API call, or the /home API call per room as found in $.rooms[#].shades
Each shade has a numeric Id, as in:
$.rooms[2].shades[0].id = 46
If you’re talking to the primary gateway, you see every shade in the network.
You can determine which shade is bound to which gateway by looking in the gateways array from the /home API endpoint. This information is not present in the /gateway API endpoint data.
$.gateways contains an array of the gateways on the network
$.gateways[#].shd_Ids contains an array of numeric shade IDs that are bound to that gateway number. For instance, my install has:
$.gateways[0].shd_Ids
[
[
54,
60,
27,
36,
13,
10,
33,
46,
30,
63,
51,
413,
2,
130,
7,
118,
57,
124,
395,
121,
22,
400,
66,
416,
127
]
]
$.gateways[1].shd_Ids
[
[
204,
210,
192,
180,
426,
86,
83,
198,
103,
183,
186,
89,
110,
195,
207,
115,
78,
189,
201,
173,
213,
386
]
]
Is that what you were asking?
IMHO that is all that matters. One can simply ignore the secondary gateways…