feat: hub-based architecture for automatic shade discovery

[safepay]

What is this?

This PR introduces a hub-based model for managing PowerView BLE shades. A single config entry represents your PowerView home, and shades are discovered automatically over BLE.

What this PR changes

Architecture — hub-based setup

You set up the integration once — point it at your hub (or enter the key manually) — and shades are picked up automatically as they're discovered over BLE. New shades appear without any additional config. Friendly names come from the hub so they match what you see in the PowerView app.

• __init__.py — manages a collection of coordinators (one per shade), registers a BLE callback for new shades, and fetches metadata (names, powerType) from the hub API
• config_flow.py — a single setup step: choose how to provide the home key (fetch from hub, enter manually, or skip)
• Entity platforms — dispatcher pattern so entities are created for both existing and newly-discovered shades
• One config entry for the whole home; areas and device naming work cleanly with multiple shades

Shade support

• Capability detection (ShadeCapability in api.py) drives which entities get created per shade — top-down, TDBU, duolite, tilt-on-closed
• Top-down shades — dedicated cover entity with inverted position logic (SkyLift-style)
• Tilt-on-closed shades — dedicated cover entity for types 18 and 44 (tilt only available when fully closed)
• Vertical blinds — type 54 support (Vertical Slats, Left Stack), plus the rest of the official aio-powerview-api shade-type table
• Velocity control — new number.py entity for shades that support velocity
• Hardwired vs battery — query_power_type over BLE; battery sensors are hidden on hardwired shades, and the spurious battery_charging control lock has been removed
• Bit-addressing fix that PR Feature/type 8 #16 was trying to address, without breaking other shades
• Position bit extraction fix that prevents pos2 contamination on TDBU shades

Reliability & UX

• Strongest-signal shade is tried first when fetching the home key
• Single discovery notification for all blinds (instead of one per shade)
• Stale BLE device handling
• New scripts/shade_report.py diagnostic tool that dumps shade bytes/metadata for debugging unsupported types

Closes #3
Closes #8
Closes #21
Closes #27

[safepay]

Sorry about the monster PR, but this brings the integration in line with modern HA architecture and should work with most blinds except the ones that have multiple blinds.

Thanks for a great integration. My setup is working perfectly. But I don't own all the blinds so I can't test everything.

At least it has the necessary information to move to the next step regarding dual and triple blind support, but that requires a bit of a refactor.

[TBK1602]

I would if I could, but I don't think I have the skillset for that yet. The little I did took me a long time and involved a lot of trial and error before it worked. And if you asked me to replicate it, I don't think I could. 😂 So if/when I get better at YAML and maybe get the hardware to set up a local LLM, I will try to help out. In the meantime, I am trying to learn by tackling issues here and there on my own setup. I don't think all my trial and error would please the people who use this integration. But would love to buy you a coffee..

[safepay]

I would really appreciate more testing. I'm running this branch on my HA setup with zero issues. The battery detection is something I can't test as my shades are hard wired.

Just note that I'm not in a position to make bug fixes for a couple of months.

[TBK1602]

Sure. Will let you know but since I only have one set of type 54 its limited what I will find :) Thanks for the hard work. U should set up a way to get u a beer...

[safepay]

puh, that is really a huge PR. I think, I will simply test it on my side and then merge and see what happens. 😄 Thanks a lot for that input! If you feel like taking over the repo, I'm happy to transfer as I do not have enough time to really maintain it in good shape.

@patman15 I appreciate that. If you would like, just set me up as a collaborator with merge access. If you test my code and it works for you and you merge, them it's actually not that far from complete anyway.

[patman15]

Just gave it a try, but got immediately stuck. You intend that as a breaking change, as you did not implement any migration scenario, right? In principle I'm ok with it as this integration had no release yet. Just checking.

[safepay]

100% a breaking change because it's a different model to suit auto discovery and a single source for the encryption key. I should have made that clearer. But like you say, I figured the integration was very much alpha and I'm helping to get it to beta. Even IF you merge the code, none of us have all the blinds so it will take a community effort to test before a 1st release.

[safepay]

This branch is ready to merge. Awaiting your approval.

[patman15]

Sorry, I'm trying to upgrade my other integration to the newest HA and it causes a lot of headache because of imported issues. 😓
Did a quick test, wow, cool work, thanks a lot. The hub architecture is really cool!
Issues I saw:

• Half of my shades do not show the battery entities
• The Identify button moves the shade instead of beeping, seems to be related to previous one, because some do beep.

I'll play around a bit more but I guess it look pretty ready to be merged.

[safepay]

Thanks.

The battery detection is hard for me because I don't have any battery blinds. I have tweaked the code to get the battery info from the hub during setup.

The "identify" moving the blinds is normal for me. That's how the hub does it. Note that I have not changed that code!

[patman15]

I need to do a review round, the battery detection does not work, although the API seems to deliver the data correctly.

[safepay]

I need to do a review round, the battery detection does not work, although the API seems to deliver the data correctly.

It might be easier to remove the battery logic and add that as a separate future PR.

[safepay]

Ok. Now I'll add a diagnostics platform so that a user can provide a log of what is actually occuring. From that the correct (hopefully) decisions can be made about how to proceed with battery detection as well as other issues.

The addition of the diagnostics.py file is the final piece that makes this integration more manageable and functional - one of the key goals from this PR.

[patman15]

@safepay please keep the PR limited to the original description, i.e. hub based architecture. I'm really struggling to follow your changes and verify them. If you have new additions, please raise another PR to keep individual features separated and the PRs small. Thanks a lot, I'd really like to merge this PR soon.

[safepay]

Ideally, yes. But the PR has been there for 3 months. Without a merge it's hard to iterate and fix residual issues. It's really up to you.

[safepay]

Specifically, simply let me know what the gaps are that are preventing this from being merged. This will help me stop guessing what to do next and modifying the code unnecessarily. Cheers.