Confirm the network, scale and controller before discussing compatibility
Use this guide for discovery meetings, fit assessments, phased deployments and acceptance. It applies to Option A (self-hosted) and Option B (managed by WoowTech). Matter Hub bridges Home Assistant entities to an external controller; it does not replace that controller or guarantee that every ecosystem exposes the same capabilities for every device.
What to ask in discovery
Goals and users
Are you solving cross-ecosystem control, adding voice access or consolidating devices?
Who owns day-to-day operations for Home Assistant, Matter Hub and each controller?
Which devices involve locks, alarms, cameras or high-power loads?
What downtime window, recovery time and change-review process are acceptable?
Current-state inventory
Home Assistant version, total entity count, domains and distribution across areas.
How many bridges you plan to create and how many endpoints each will expose.
Hub, app and account status for Apple, Google, Alexa, Aqara and SmartThings.
Current router, VLAN, IPv6, mDNS, Wi-Fi and Thread border-router setup.
Fit assessment
Scenario
Assessment
Reason and next step
HA already has stable entities that an external Matter controller should use
Suitable for a pilot
Start with a small bridge of low-risk lights and sensors; verify names, control and synchronization.
Matter Hub is expected to commission physical Matter devices directly
Wrong role
That is the Matter controller’s job. First clarify how the Home Assistant Matter integration and Matter Hub divide responsibilities.
The deployment crosses VLANs and IPv6 or mDNS is unavailable
Fix the network first
Commissioning and discovery may fail. Complete multicast, routing and firewall tests first.
Every controller must provide identical functionality
Reset expectations
Controllers differ in device-type, cluster and UI support. Accept each type separately.
Many safety-critical devices must switch at once
Do not go directly to production
Run a phased pilot first, take backups, and establish a recovery plan and manual fallback process.
Controller assessment matrix
Controller
Pilot focus
Do not assume
Apple Home
Home hub, room organization, No Response and device-type presentation
Successful commissioning does not mean every cluster and advanced capability is available.
Google Home
Google Home app, device synchronization, rooms, voice and optimized templates
Do not assume HA names, types and controls will appear unchanged.
Amazon Alexa
Port for first commissioning, device scale, voice names and specific feature flags
Do not turn an observed scale into a hard limit or guarantee.
Aqara
Hub firmware, supported device types, region and app presentation
Do not infer Aqara behavior from results on another controller.
SmartThings
Hub status, driver/device-type presentation and multi-fabric behavior
Do not promise that every mapping and third-party feature will be exposed in full.
Sales wording: Say “We can run an acceptance-based pilot against v2.0.55 and the specified controller.” Do not say “fully compatible,” “guaranteed to work” or “supports every device.”
Networking, IPv6 and mDNS
Preproduction prerequisites
A working IPv6 path exists between the Matter Hub host and controller.
mDNS discovery works on the required subnets. Any cross-VLAN reflector has been tested, not merely “enabled.”
Firewall rules permit only the traffic observed to be necessary.
Host time, DNS, network interface and static lease are stable.
Wi-Fi and Thread infrastructure is verified separately against each controller’s requirements.
Diagnostic evidence
Record source and destination subnets, test time and the stage that failed.
Retain de-identified mDNS tests, Health, Network Map and System Logs.
Do not put private IP addresses, hostnames, tokens, QR payloads or pairing codes in deliverables.
If cross-subnet behavior is unstable, return to one subnet for a baseline, then add network restrictions one at a time.
Device, controller and bridge scale
Scale is not just the total number of Home Assistant entities. Also record the bridge count, endpoints per bridge, device-type mix, each controller’s fabric, event frequency, host resources and synchronization time. Usable controller scale may depend on firmware and account environment, so load-test with a representative dataset and never extrapolate one success into a guarantee.
Reason to split
Recommendation
Home/floor/tenant
Use separate bridges to reduce the blast radius of changes and failures.
Safety-critical and general devices
Exclude locks, alarms and similar devices initially or verify them separately; do not batch them with many general endpoints.
Controller differences
Use different filters or feature flags when needed, and retain separate acceptance records.
Synchronization and resource pressure
Add endpoints in batches; observe startup, synchronization, memory and response time.
Recommended deployment phases
Discovery and baseline: Pin v2.0.55, build the feature manifest, network diagram and controller inventory, and gather evidence read-only.
Lab pilot: Test bridges, filters, names and controller presentation with a few lights, switches and sensors.
Representative pilot: Add covers, climate entities, locks and other types; accept each controller separately.
Phased rollout: Expand in batches by area or risk, retaining a rollback point and change record for each batch.
Handover to operations: Deliver backup, diagnostic, upgrade, credential-custody, ownership and periodic reverification procedures.
Key risks and controls
Risk
Impact
Control
Controller support differences
Commissioning succeeds but functionality or UI is incomplete
Accept separately by device type and controller.
Unstable IPv6/mDNS
Discovery failures, failed commissioning or No Response
Establish a single-subnet baseline, then verify VLANs and firewalls.
Overly broad filters
Unnecessary or sensitive entities are exposed
Default to a minimal Include; use Preview and peer review.
Identity or fabric changes
Recommissioning, duplicate devices or service disruption
Persist data, take backups, and use a change window and recovery drill.
Experimental features
Behavior changes or support is limited
Label maturity explicitly and separate them from production bridges.
Security and data boundaries
Do not expose the management interface directly to the public internet. Configure reverse proxies, Ingress, Basic Auth and IP allowlists for minimal exposure in the environment.
Treat Basic Auth as one authentication layer only; do not describe it as multi-account access, RBAC or SSO.
Do not include QR payloads, manual pairing codes, setup PINs, discriminators, fabric/node IDs, tokens, cookies or credentials in documents or screenshots.
Before plugin installation, reset, restore or fabric removal, document the backup, impact, downtime and recovery path.
Apply the principle of minimal exposure. Safety-critical entities require additional business approval and a manual fallback process.
Acceptance checklist
Functional acceptance
The displayed version is Stable 2.0.55 and the source commit is recorded.
Identity, names, endpoints and filter results remain stable after a bridge restart.
Every specified controller passes commissioning, basic control, state reporting and reconnection tests.
Verify every type actually used, including lights, switches, sensors, covers and climate entities.
Test multi-fabric only within the approved scope; record removal and orphan cleanup.
Operational acceptance
Health, mDNS, System Logs and resource baselines are retained.
Backups are verified as readable; restore steps and owners are explicit.
Firewall, proxy, credential and secret management passes security review.
Executable runbooks cover No Response, failed commissioning and synchronization failures.
Experimental features, controller limitations and unaccepted items are recorded as exceptions.