Philips Hue

The Hue bridge and Home Assistant

My Philips Hue integration uses the bridge's V2 API. Home Assistant communicates with the bridge on the local network, and the bridge handles its joined lights. V2 state updates reach Home Assistant through the bridge's local event stream.

Home Assistant ↔ local Hue bridge API ↔ Hue lighting

Pairing and Hue scene management remain in the Hue system. Home Assistant exposes those lights and scenes so they can participate in dashboards, scripts and automations alongside other integrations.

The Hue bridge and my ZHA coordinator manage separate Zigbee networks. A light joined to Hue is controlled here through the Hue integration. Home Assistant can coordinate it with ZHA or Z-Wave devices without moving the light to a different radio network.

MQTT is not required for the Hue bridge connection. When an MQTT message triggers one of my Hue automations, the broker carries the input and the Hue integration carries the lighting action.

What I bring into Home Assistant

I use these controls in dashboards and configured routines. Keeping the control types distinct helps explain what each dashboard choice or automation action targets.

Scroll the table horizontally to compare all four columns.

The examples below show how those controls connect to physical inputs, sensor reports and shared scripts.

Physical controls and sensor-driven lighting

Z-Wave controls for Hue lights

My WallMote scene-control events trigger Hue light toggles through Home Assistant. The remote is a Z-Wave device, while the lights remain on the Hue bridge. Home Assistant translates the received button event into the selected lighting action.

Z-Wave button press → Home Assistant automation → Hue bridge → light

The Z-Wave JS article describes the input side. This path depends on both integrations and the automation between them; it is not a direct radio binding between the remote and the Hue light.

Sensor state into color and on/off actions

Z-Wave binary sensors also trigger Hue lighting actions in my configuration. These include turning lights on with selected RGB colors and turning them off. Another path combines a sensor condition with a color change, a transition and a notification involving Alexa Media Player.

That makes lighting one output of a wider routine. The sensor supplies information, Home Assistant evaluates the conditions, and Hue receives the requested light settings. A notification action has its own integration and dependencies.

MQTT and other physical inputs

An incoming MQTT message is configured to toggle Hue lighting. A separate device-triggered path uses a physical button input for Hue on/off actions. These controls reach the same Hue lights through Home Assistant without requiring the input devices to join the Hue network.

The MQTT article explains that message path. If a Hue action fails, checking whether the input arrived and whether the bridge accepted the lighting request are separate steps.

Groups, bridge scenes and temporary snapshots

Grouped lights

My integration has Hue grouped-light entities enabled for rooms and zones. These represent groupings maintained on the Hue bridge, alongside the entities for the individual lights.

A Home Assistant light group is a separate grouping defined in Home Assistant. The two can appear similar on a dashboard, but they have different membership and control paths. When checking a routine, I need to identify which kind of group it targets.

Scenes stored on the Hue bridge

Hue scenes are imported into Home Assistant, and my dashboards reference those scene entities. I can activate them from Home Assistant while keeping their creation and editing in the Hue app.

The Hue integration documentation recommends bridge scenes for coordinated changes across multiple Hue lights. The bridge applies the scene as a coordinated operation instead of receiving individual light settings from Home Assistant.

Snapshots inside a wider routine

My configuration also contains a shared script that includes Hue lights in a Home Assistant scene snapshot before turning selected lights off. The script contains a corresponding scene-restoration action, alongside media, switching and other lighting actions.

This snapshot records selected entity states for the routine to restore. It does not create a new scene on the Hue bridge. Its result depends on which entities were captured and whether the restoration action runs successfully; the presence of that action is not proof that every interrupted run restores the lights.

The Home Assistant scene documentation explains snapshots and restoring states. Keeping this separate from Hue scene management makes the script easier to understand and troubleshoot.

Dependencies and limits of the lighting path

The bridge connection is local

Home Assistant's connection to my Hue bridge uses the local API. A wider automation can still depend on an MQTT input, another radio integration or a service with a cloud dependency. Local Hue control does not remove those other requirements.

If Home Assistant is unavailable, the Home Assistant routines described here cannot translate Z-Wave or MQTT inputs into Hue actions. The bridge remains a separate system, but that does not keep those cross-integration automations running.

Availability and the requested result

A reachable bridge and a reachable light are different conditions. A light that has lost power or its connection to the bridge cannot be controlled simply because Home Assistant can still communicate with the bridge.

Likewise, receiving a trigger does not establish that a light changed. Inspect the automation action and the reported result separately. V2 push updates provide a state-update path, not a guarantee of a particular response time or physical outcome.

Features depend on the target

Brightness, color and other controls depend on the light and the integration's exposed features. A product's Hue app capabilities should not be assumed to map one-for-one to Home Assistant controls. For a missing feature, check the specific light or scene behavior in the official Hue integration documentation.

Checking the full path from input to light

For a missed lighting change, the useful checks follow the configured path:

1. Check the input. Confirm the expected button event, sensor update or MQTT message reached Home Assistant.
2. Check the automation or script trace. Inspect the conditions, selected action and whether the sequence reached the lighting step.
3. Check the target type. Identify whether the action uses an individual light, a Hue group, a Home Assistant group, a bridge scene or a temporary snapshot.
4. Check the bridge and light. Separate an integration connection problem from a light that is unavailable to the bridge.
5. Verify the result. Check the resulting lighting state. For a snapshot routine, also check whether the restoration step ran.

This is why I keep Hue connected through its bridge: it retains the Hue lighting and scene system while Home Assistant connects that system to the controls, sensors and routines used elsewhere in my build.