Skip to main content
NestGrid logoNestGrid

How to set up Meta Quest 3 VR smart home control

Set up Meta Quest 3/3S smart home control with one of the two routes that actually work: the Home Assistant Companion app (minimal flavor) installed via SideQuest, or the headset browser pointed at an HTTPS-served Home Assistant dashboard. Both routes carry a verification date and status label, and the headset's limits — display client, not Matter/Thread controller — are stated before you start.

If the question is how to set up Meta Quest 3 VR smart home control in Q3 2026, the answer is short before it gets fiddly: use Home Assistant, and pick one of two routes. Route 1 is Confirmed: install the Home Assistant Companion app’s minimal Meta Quest flavor through SideQuest. Route 2 is Confirmed: open a Home Assistant dashboard in the Quest browser, with Home Assistant served over HTTPS. In both cases, the Quest 3 or Quest 3S is a headset display and Wi-Fi client. The protocol controller remains Home Assistant and whatever radios or hubs your installation already uses; the cited Quest routes do not document the headset as a native Matter controller, Thread border router, Zigbee coordinator, or Z-Wave controller.

White Meta Quest 3 headset with dark front visor and lens area

Verification date for the route status in this guide: August 25, 2026. That date matters. The Quest software and store environment have been moving quickly enough that “I saw it in a store once” is not a setup plan.

RouteStatus in Q3 2026What you getCondition you must accept
Route 1: Home Assistant Companion app minimal Quest flavor via SideQuestConfirmedApp login, device entities, headset sensors, and automation hooks inside Home AssistantIt is the minimal flavor without Google services, so do not promise standard notifications, widgets, or shortcuts
Route 2: Quest browser pointed at a Home Assistant dashboardConfirmedA dashboard/control surface in the headset browserHTTPS is part of the route, not an optional hardening step

For Matter, Thread, Zigbee, and Z-Wave expectations, keep the same boring architecture you would use without the headset: the headset reaches Home Assistant over the network; Home Assistant talks to your devices through its integrations, dongles, bridges, or border routers. If you are still sorting out which protocols need a hub, the hub-required framing is the same kind of split covered in this protocol compatibility check.

Diagram showing a VR headset connected by Wi-Fi to a smart-home hub, which connects to lights, thermostat, camera, and door sensor

Choose the route by what you are willing to maintain

Use the Companion app route if you want the headset to appear in Home Assistant as more than a pretty screen. The official Companion documentation lists Meta Quest support for Quest 3/3S, Quest 2, and Quest Pro, and points installation to SideQuest for the Quest build. The same documentation also states the awkward part clearly: the Quest app uses the minimal flavor, which does not include Google services; as a result, standard notifications, widgets, and shortcuts are unavailable there.[1]

Use the browser route if you mainly want a dashboard in passthrough or in a floating browser window and do not need the headset itself to expose richer device sensors to Home Assistant. It is less app-like, but it avoids sideloading. The price is not imaginary: the dashboard needs to be served securely over HTTPS, as shown in the July 2026 first-person browser-dashboard build.[2]

If Home Assistant itself is the unfinished part, stop here and fix that first. A headset control surface is not a substitute for a reliable Home Assistant host, integrations that survive restarts, and a network path that keeps working when the novelty has worn off. For the hardware side of that base layer, see Home Assistant hub hardware prerequisites.

Route 1: Install the Home Assistant Companion app through SideQuest

This is the route to try first if you already live in Home Assistant and want the Quest to participate as a device. It is also the route with the most explicit official support: the Companion docs include a Meta Quest page, list the supported Quest headsets, identify SideQuest as the distribution channel, and document the missing Google-services features for the minimal flavor.[1]

Home Assistant Companion app dashboard running on a Meta Quest virtual screen

Before installing, verify the current channel

Start at the official Companion Meta Quest documentation, not at an old forum thread or a cached store link. As of this guide’s August 25, 2026 verification, the documented route is the minimal Quest flavor distributed through SideQuest.[1] The July 2024 hands-on account also noted that the app was not yet in the official Quest store at that time, which is useful history but not a permanent store-status claim.[3]

Then check the SideQuest listing itself. SideQuest is not just a download footnote here; it is the install and update surface for this build, so the listing is where you confirm that you are looking at the Home Assistant app and not a similarly named experiment.[4]

  • Supported headset scope to expect from the official docs: Quest 3/3S, Quest 2, and Quest Pro.[1]
  • Distribution path to expect: SideQuest for the Quest Companion build.[1][4]
  • Feature limit to accept before installing: no Google services, which means no standard notifications, widgets, or shortcuts in this flavor.[1]

Install or update from SideQuest

Install the app from the Home Assistant listing in SideQuest, following SideQuest’s current headset connection and sideloading flow. If the app is already present, use SideQuest again when you need to update it; the listing is the maintenance path named for this route, not merely a one-time installer.[4]

The common failure at this point is treating the sideloaded app like an ordinary Android phone install. Do not plan around Google-backed behaviors that the minimal Quest flavor does not have. If your intended setup depends on push notifications appearing like they do on your phone, or on Home Assistant widgets and launcher shortcuts, this route will disappoint you for a documented reason, not because you missed a hidden permission toggle.[1]

Open the app and log in to Home Assistant

After first launch, sign in to your Home Assistant instance. In the July 2024 Quest 3 hands-on test, the app auto-discovered the Home Assistant server on first run and then followed the usual login flow; that account was using Home Assistant 2024.6.4.[3] Treat that as a real working report, not a guarantee that every network will auto-discover cleanly. If discovery fails, enter the correct Home Assistant URL manually and solve network reachability before looking for more exotic fixes.

This is the point where passthrough becomes more than a gimmick. A Home Assistant dashboard in a floating Quest app window can be usable while you are standing in the same room as the lights, blinds, media player, or thermostat you are checking. The 2024 hands-on specifically recommended passthrough for hands-free sensor work, which is a much saner use case than pretending a headset has become the house brain.[3]

Confirm the Quest entities before building automations

Once logged in, go back to Home Assistant on your normal admin screen and check whether the Quest device and its entities have appeared. The official Home Assistant announcement for Quest support said the app could expose more than 40 data points from the headset, including a binary_sensor.in_use entity.[5] The July 2024 Quest 3 test reported 72 entities on Home Assistant 2024.6.4 and called out sensors such as battery-related values, headset in-use state, and current or last app information.[3]

Do not start with the automation editor. Start with entity updates. Put the headset on, take it off, launch an app, plug in power, and watch whether the relevant states change in Home Assistant. The usable control surface is the part you see in the headset; the automation value comes from whether Home Assistant sees the headset accurately enough to act on it.

CheckWhere to lookWhy it matters
Battery-related entity changesHome Assistant device/entities page for the QuestBattery automations are only useful if the level updates predictably
In-use state changesbinary_sensor.in_use or equivalent exposed entityLight or scene changes should not trigger from stale headset state
Current-app or last-used-app style valuesQuest sensor entities reported by the Companion integrationApp-aware automations depend on this state existing and changing
Dashboard usability in passthroughInside the Quest app windowThe person in the room should be able to operate controls without a laptop nearby

Only then add automations

The obvious automation is battery maintenance: if the Quest battery drops below your chosen threshold while the headset is still in use or sitting off the charger, send yourself a reminder through a channel that actually works in your setup. Because the Quest minimal flavor does not provide standard Android notification behavior through Google services, the notification target may need to be your phone, a speaker, a dashboard alert, or another Home Assistant-supported path.[1]

The nicer room automation is in-use lighting. When the headset reports that it is in use, dim nearby lamps or switch to a low-glare scene; when it is no longer in use, restore the normal room scene. Keep this conservative at first. A headset state that lags by a few seconds is fine for ambience and annoying for anything that behaves like a hard safety interlock.

Last-used-app triggers are where the Quest starts to feel amusing in the right way. If the headset’s app state indicates a media or fitness session, Home Assistant can prepare the room around that activity: lower lights for a media app, raise a fan for a workout, or prevent a bright hallway scene from firing during immersive use. These are follow-ons from confirmed entity behavior, not proof that the headset has become a hub.

For more conventional Home Assistant automation patterns after the Quest entities are stable, use the same status-labeled discipline you would use for any other trigger; this weather-to-thermostat automation recipe is a better model than a headset-specific novelty chain.

Route 2: Open an HTTPS Home Assistant dashboard in the Quest browser

The browser route is simpler in one sense: there is no app install. You open the Quest browser, go to a Home Assistant dashboard, and operate the controls as a web interface. It is also less integrated. A browser tab does not give Home Assistant the same headset device and sensor surface that the Companion route can expose.

VR smart-home control dashboard with lighting, temperature, house-load readings, and scene buttons

The hard line is HTTPS. In the July 2026 How-To Geek build, the Quest browser dashboard route required HTTPS; the author used an ADB port-forwarding workflow during development and then described using a Caddy reverse proxy for the served dashboard.[2] That supports a narrow conclusion: for this route, plan to serve the dashboard securely rather than trying to make a plain local HTTP page behave like a finished control panel.

Use the browser route for surface control, not device integration

A browser dashboard is good when the job is visible control: lights, scenes, thermostat cards, camera views your Home Assistant instance already exposes, or a custom panel built for large touch targets. It is not the route to pick if your main goal is to automate from headset battery, in-use state, or last-used-app values. Those are Companion-app territory in the materials available here.

This is also where dashboard design matters more than VR ambition. A panel that works on a wall tablet or old phone often adapts better to the headset than a dense admin dashboard. If you want the non-VR version of that tradeoff first, the same control-surface logic appears in this old-phone Home Assistant panel setup.

Verify secure loading inside the headset

From the Quest browser, load the HTTPS URL for the Home Assistant dashboard you intend to use. Confirm that the page opens without certificate warnings, that login persists well enough for your use, and that the controls you care about respond while you are wearing the headset. This is not a general remote-access tutorial; it is a working check for the one condition that makes the browser route viable.

  • The dashboard loads over HTTPS in the Quest browser.
  • Home Assistant authentication works without leaving you stranded at the login screen every time you put the headset on.
  • The controls are large enough to use comfortably in the headset.
  • The same dashboard still behaves correctly from a normal browser, so troubleshooting is not trapped inside VR.

If the browser cannot reach Home Assistant, fix the layers in order: headset Wi-Fi, Home Assistant host, HTTPS/reverse-proxy path, then dashboard permissions. The recovery order is not special because a Quest is involved; it is the same layered failure pattern covered in this smart-device reconnection troubleshooting guide.

What not to make the headset responsible for

Do not buy or configure a Quest 3 or Quest 3S expecting it to replace a Home Assistant host, a Matter controller already present in your setup, a Thread border router, a Zigbee coordinator, or a Z-Wave stick. The supported routes here make the headset useful because Home Assistant is already doing the controller work. The headset supplies an interface, device telemetry in the Companion route, and a very odd but occasionally excellent room-side control surface.

Also do not hide the limitations from other people in the house. If the only way to turn on a lamp is to find a sideloaded app inside a headset, that is not a household control system; it is a private cockpit. Keep normal switches, voice controls, wall panels, or phone dashboards available for anyone who is not wearing the Quest.

Q3 2026 route status

RouteVerification dateSupported scopeRequirementsLimitsWhat “Confirmed” means
Home Assistant Companion app minimal Quest flavor via SideQuestAugust 25, 2026Official Companion docs list Quest 3/3S, Quest 2, and Quest ProWorking Home Assistant instance; SideQuest install/update path; successful app loginMinimal flavor lacks Google services, so standard notifications, widgets, and shortcuts are not availableOfficially documented Quest Companion route with SideQuest distribution and Home Assistant device/sensor integration
Quest browser pointed at an HTTPS Home Assistant dashboardAugust 25, 2026Browser-based dashboard access from the headset; not an app installHome Assistant dashboard served over HTTPS; browser login that works inside the headsetNo Companion-app device entities or headset sensor integration from the browser route aloneDocumented hands-on route for headset dashboard control where HTTPS is treated as a prerequisite

Meta Quest 3 and Quest 3S smart home control is real in Q3 2026, but the useful version is modest: Home Assistant remains the controller layer, and the Quest becomes either a sideloaded Companion device with useful sensors or an HTTPS browser dashboard. Pick the route whose maintenance conditions you will actually keep.

References

  1. Meta Quest | Home Assistant Companion Docs, Home Assistant Companion Docs
  2. I Built a Virtual Reality Dashboard to Control My Smart Home, How-To Geek, July 2026
  3. Meta Quest 3 in Home Assistant, The Home Assistant Blog, July 5, 2024
  4. Home Assistant, SideQuest
  5. Home Assistant for Android app is now available for the Quest, Home Assistant, January 7, 2022

Related reading

Feedback / Question

Did a step not work as written? Let us know so it can be corrected.

Blogarama - Blog Directory