TapHome

Hunter Douglas PowerView Hub

Packet Parser → HTTP
Submitted by
Last updated: 06. 2026
Hunter Douglas PowerView Hub

The Hunter Douglas PowerView Hub (sold as Luxaflex PowerView Hub in Europe, Australia and parts of Asia — identical hardware) is a smart-home bridge that connects motorized PowerView window coverings to IP-based home automation systems. The hub runs Hunter Douglas’s proprietary 2.4 GHz RF mesh on one side (the PowerView Shade Network with paired shades and repeaters) and exposes a local unauthenticated HTTP REST API on port 80 on the other side.

TapHome communicates with the hub over this local REST API — no cloud account and no internet connection are required for control. The template drives the primary rail position of a single PowerView shade per TapHome device instance; controlling multiple shades requires adding multiple PowerView Slide devices under the same interface, each addressed by its own shade id.

This template supports the PowerView Hub (Gen 1) and PowerView Hub Gen 2 only. The newer PowerView 3 Gateway (Gen 3) uses a different architecture and does not expose the same local REST API — it is not compatible with this template. See the Gen 3 note at the bottom of this page.

Supported devices

The template exposes one TapHome device type:

  • PowerView Slide — primary rail (shade) position for a single PowerView shade. Maps the hub’s 0–65535 position scale to TapHome’s 0–100 % blinds convention (inverted, so 0 = open and 100 % = closed on the TapHome side).

The PowerView Shade Network itself is compatible with 34+ motorized shade, blind, shutter and drapery models across Hunter Douglas / Luxaflex product lines — Duette, Silhouette, Pirouette, Vignette, Roller, Roman, Skyline Panels, Curtains, Venetians and more. As long as a shade is paired to the hub in the PowerView app, it can be driven by TapHome through the same primary-rail mechanism.

Prerequisites

Before importing the template in TapHome, confirm the following:

  • The PowerView Hub is powered, connected to the LAN by Ethernet (or Wi-Fi on Gen 2) and the front LED is in the normal-operation state (solid blue on Gen 1, equivalent on Gen 2).
  • Your shades are already paired with the hub through the PowerView app — each shade that TapHome should control must appear in the PowerView app’s Shades list.
  • The hub and the TapHome controller are on the same local network (no NAT between them).
  • A web browser on your phone, tablet or computer can open http://<HubIP>/api/shades and returns a JSON response.

Configuration

Step 1 — Assign a static IP to the hub

The hub must be reachable at a stable IP address. The PowerView app has a built-in static-IP setting, which is the recommended way to fix the hub’s address — alternatively, create a DHCP reservation on your router for the hub’s MAC.

Open the PowerView app and tap the menu icon in the top-left corner:

PowerView app dashboard — open the side menu

In the side menu, tap Hub:

PowerView app side menu — Hub entry

Under Connected Hub, tap your hub to open Hub Info:

PowerView app — list of hubs

Scroll to Static IP at the bottom and tap it:

PowerView app Hub Info screen — Static IP entry

Enable Use Static IP, then enter the IP Address, Mask, Gateway and DNS values that match your network:

PowerView app Static IP screen — Use Static IP toggle

Static-IP adjustments are only supported on hubs that are connected to the router by Ethernet. If the hub is on Wi-Fi, create a DHCP reservation on the router instead.

Step 2 — Discover shade IDs

Each shade paired to the hub has a unique numeric id. Open the following URL in any browser on the same network:

1

http://<HubIP>/api/shades

The response is a JSON document; the shadeIds array lists every shade known to the hub:

1

{ "shadeIds": [ 7348, 14922, 30019 ] }

Note down the ids of the shades you want to control from TapHome. If you have only one shade, the array contains a single value.

To match an id to a physical shade, open http://<HubIP>/api/shades/<id> — the name field contains the human-readable shade name from the PowerView app (Base64-encoded; decode to read it). Alternatively, change each shade’s position from the PowerView app one at a time and observe which id’s positions.position1 changes.

Step 3 — Create the Packet Parser interface in TapHome
  1. In the TapHome app, open Settings → Interfaces and either create a new Packet Parser interface or open an existing one.
  2. Choose Add from template and select PowerView Hub.
  3. Enter the hub’s IP address in the IP address field (replacing the 192.168.0.1 placeholder).
  4. Leave the Internal poll interval at the default 10000 ms (10 s) unless you have a specific reason to change it — faster polling does not improve responsiveness and may degrade RF performance on the shade mesh.
  5. Tap Create.

TapHome imports one PowerView Slide device for the template. At this point the device is bound to the hub but not yet to a specific shade.

Step 4 — Set the shade ID on each Slide device

Open the created PowerView Slide device in TapHome, go to Service Settings → Device ID and enter the shade id you noted in Step 2. Save the settings.

To control additional shades, add more PowerView Slide devices under the same Packet Parser interface and set a different Device ID on each.

The SlideDeviceId value is a per-device setting, not a module-wide one. A single Packet Parser interface can drive any number of PowerView Slide devices — only the id changes between them.

Troubleshooting

Shade position drifts after using a remote

Pebble remotes on Gen 1 / Gen 2 hubs use proprietary Bluetooth LE and do not report shade position back to the hub. When a user moves a shade with the Pebble, the hub’s cached position — which the template reads — becomes stale until the next movement command reconciles it. This is a hardware limitation of the Gen 1 / Gen 2 platform, not of the TapHome template. If accurate position feedback is critical, standardise on moving shades through TapHome or through the PowerView app.

Hub returns HTTP 423 “Hub busy for maintenance”

This is a normal transient response while the hub is performing internal maintenance (for example during scene updates or firmware checks). The template surfaces the error via ADDERROR but the next poll cycle typically succeeds. If 423 responses persist, reboot the hub (press Reset on the back).

Secondary hubs not visible in the PowerView app

The PowerView app typically lists only the hub registered to your account. Secondary hubs on the same PowerView Shade Network may not appear in the app’s hub list, but they still respond on the local network and accept the same REST API calls. TapHome can bind to a secondary hub by its IP address — visibility in the PowerView app is not required for local HTTP control.

No response on http://<HubIP>/api/shades
  1. Confirm the front-panel LED indicates normal operation (solid blue on Gen 1). See the LED table in the PowerView Hub Quick Start Guide.
  2. Verify the hub’s IP from the PowerView app (Hub → Hub Info → IP Address) and that it matches what you entered in TapHome.
  3. Ping the hub from a machine on the same VLAN; the hub must not be behind a NAT or firewall relative to the TapHome controller.
  4. The hub listens on HTTP port 80 only — do not prefix the URL with https://.

PowerView 3 Gateway (Gen 3) — not supported

Hunter Douglas’s newer PowerView 3 Gateway is a ground-up redesign: it uses Matter over Thread, is cloud-first, and does not expose the same local /api/shades REST surface that Gen 1 / Gen 2 hubs do. The TapHome Packet Parser template on this page therefore does not work with the PowerView 3 Gateway — attempting to bind it will either return HTML from the gateway’s web UI or fail outright.

If you have a Gen 3 Gateway, the current migration path on the Hunter Douglas side is to keep a Gen 1 / Gen 2 hub in parallel for third-party integrations, or to wait for Matter-based blinds support in future TapHome firmware.

Available devices

PowerView Hub Module
Custom Variables
SlideDeviceId (numeric) = 1PowerView shade id addressed by this TapHome device. Open http://{HubIP}/api/shades to list shadeIds and paste the chosen id into the TapHome Slide device's Service Settings.
Open http://{HubIP}/api/shades in a browser — the shadeIds array lists all ids paired with the hub. Copy the desired shade id into the TapHome device's Service Settings → Device ID.
Slide Slide

Primary rail (shade) position for a single PowerView shade — maps the hub's raw 0–65535 scale to the TapHome 0–100% blinds convention (0 = open, 100% = closed)

numeric Unit: % json_path

Slide

Read blind level
VAR response := SENDHTTPREQUEST("api/shades/" + SlideDeviceId);

IF response.IsSuccess
    VAR responseJson := response.Content;
    VAR pos := PARSEJSON(responseJson, "$.shade.positions.position1");
    RETURN(1 - (pos/65535));
ELSE
    ADDERROR(response.Content);
    RETURN(NaN);
END
Write blind level
VAR pos := ROUND((1 - Bl) * 65535);
VAR contentJson := "{\"shade\": { \"positions\": { \"posKind1\": 1, \"position1\":" + pos + "}}}";

SENDHTTPREQUEST("/api/shades/" + SlideDeviceId, "PUT", contentJson, "Content-Type:application/json");
Connection: Packet Parser → HTTP
Possible improvements (17)
  • Vane tilt — Slat/vane tilt angle for Silhouette, Pirouette, Venetian and similar shades. Range 0–32767. Not exposed by the current template — only primary rail (posKind1 = 1) is driven.
  • Secondary rail (TDBU) — Second independent axis for top-down/bottom-up shades (Duette TDBU, Pleated TDBU). Range 0–65535. Not exposed — TDBU shades are controlled only on the primary axis.
  • Activate scene — Scenes are pre-programmed shade positions within a single room, defined in the PowerView app. Activation would map naturally to a module-level service action.
  • Activate scene collection — Multi-room scene (set of scenes). Activation returns the list of scene ids triggered.
  • Move all shades in a group — Single API call moves a whole group of shades — would save RF bandwidth compared to driving individual shades in parallel.
  • Jog (identify shade) — Briefly moves a shade to identify it visually. Useful during commissioning to confirm which physical shade corresponds to a given id.
  • Calibrate shade limits — Recalibrates end-stop positions on the shade motor. Typically used after a shade has been serviced or reset.
  • Battery strength (per shade) — Last-read battery level for a battery-powered shade. Available on the same GET /api/shades/{id} response that the template already polls — could be added as a read-only service attribute on the PowerView Slide device without extra HTTP traffic.
  • Battery status (enum) — Enum: 0 = No Status, 1 = Low, 2 = Medium, 3 = High, 4 = Plugged In. Available on the same shade GET response.
  • Force battery level refresh — Triggers the hub to query the shade over RF for an updated battery reading. Causes a small physical movement of the shade.
  • Force position refresh over RF — Polls the shade over RF instead of returning the hub's cached position — useful when a Pebble remote or manual movement has caused state drift. Each refresh triggers an RF round-trip, so overuse degrades responsiveness.
  • Request shade firmware revision — Asks the shade over RF to report its firmware build/revision/subRevision. Useful for diagnostics, not for runtime control.
  • Hub firmware version — Hub main processor + radio firmware build. Good candidate for a module-level service attribute for diagnostics.
  • Hub metadata (IP, MAC, RF, network) — Comprehensive hub metadata including serial number, MAC, RF network ID, static IP status, SSID, location/timezone. Useful for module-level diagnostics service attributes (hub name, serial, RF status).
  • Room listing — Lists rooms defined in the PowerView app. Not directly actionable in TapHome — each shade is imported individually by id. Could be used for automated room grouping during import.
  • Base64 human-readable names — Shade/room/scene/hub names are Base64 encoded in API responses. TapHome template uses numeric ids directly, so decoding is not needed for control, but would improve the import UX (auto-named TapHome devices).
  • Hub-busy retry semantics — Hub returns HTTP 423 'Hub busy for maintenance' as a normal transient response. Clients should retry with backoff. Current template surfaces the error via ADDERROR(response.Content) but does not distinguish 423 from other failures.

Sources

Found a problem with this device template?

Tell us what's wrong, what's missing, or how the template should behave. We rely on your feedback to keep the catalog accurate.

Verified by TapHome

Want to use this in your TapHome Core?

Open this template in the Customer Portal to apply it to one of your homes, or to draft a refinement and submit it back to the catalog.

Open in portal