Philips Hue Smart Plug exposed as a Light? Here’s my workaround

Share your Projects!
1

Hi everyone,

I recently ran into an annoying limitation when using Philips Hue Smart Plugs with Home Assistant.

My setup uses a Philips Hue Bridge Pro, with Home Assistant connected through the native Hue integration.

The problem is that a Hue Smart Plug is exposed by the Hue Bridge as a light entity, even when the device connected to the plug is obviously not a light.

For example, I use one of my Hue Smart Plugs to control a bathroom heater.

This creates a practical problem: a command intended to control the lights can also affect the heater.

For example:

“Turn off the bathroom lights”

can potentially turn off the heater as well, simply because the Hue Smart Plug is represented as a light.

I initially looked for a way to change the device type, but as far as I can tell, the Hue Bridge does not currently provide a way to change a Smart Plug from light to switch/outlet.

I also contacted Philips Hue about this

I opened a support ticket with Philips Hue specifically about this limitation: the fact that the functional type of a Smart Plug cannot currently be changed, even when it is used to control a non-lighting device.

Philips Hue created ticket #321723 and confirmed that the request has been registered as a suggestion and forwarded to the appropriate team for consideration.

So, rather than waiting for a possible product change, I decided to build a workaround in Home Assistant.

The idea

I wanted three things:

  1. Keep the Hue Smart Plug connected to the Hue Bridge.
  2. Prevent unwanted lighting commands from changing its state.
  3. Still have a normal-looking ON/OFF control in the actual bathroom.

My solution has three levels.

1. Move the Smart Plug to a “virtual” room

I moved the Hue Smart Plug into a fictitious room called:

Machine Room

This room is not assigned to any floor in my Home Assistant/house structure.

The reason is simple: I don’t want the physical location of the plug to make it part of the lighting controls for the bathroom or the floor.

So the actual Hue entity is effectively isolated from normal room/floor lighting commands.

However, this alone is not enough, because the entity is still a light.

2. Protect the state of the Smart Plug

I then created two automations.

One automation monitors the Smart Plug for an unwanted OFF command and immediately turns it back ON.

The other does the opposite: if the Smart Plug is unexpectedly turned ON, it immediately turns it back OFF.

The two automations temporarily disable each other while correcting the state. After the correction, they are re-enabled after a short delay.

This effectively creates a state lock around the physical Hue Smart Plug.

If an unwanted automation, scene or lighting command changes its state, the change only lasts for roughly one second before the previous state is restored.

So even if a global lighting command manages to reach the Hue Smart Plug, it cannot leave the heater in the wrong state.

3. Create a user interface in the bathroom

Finally, I created a virtual switch in Home Assistant and placed that switch in the actual bathroom.

This is the control I use for the heater.

When I operate this switch:

  1. The state-protection automations are temporarily disabled.
  2. The actual Hue Smart Plug is switched to the requested state.
  3. Home Assistant waits briefly.
  4. The protection automations are enabled again.

So from the user’s point of view, I now have a normal ON/OFF control in the bathroom that controls the heater and reflects its state.

Conceptually:

                Bathroom

                   │

          Virtual Switch

                   │

                   ▼

          Disable protection

                   │

                   ▼

          Hue Smart Plug

            (light entity)

                   │

                   ▼

          Re-enable protection

An unwanted command takes the other path:

   Global lighting command

             │

             ▼

    Hue Smart Plug changes

             │

             ▼

   Protection automation

             │

             ▼

    Previous state restored

Why I don’t consider a simple Template Switch to be enough

A simple virtual/template switch can certainly provide a nicer interface.

But it doesn’t solve the underlying problem.

The original Hue entity is still a light.

Therefore, a Home Assistant command targeting all lights can still target the original Hue Smart Plug.

In my case, I needed to protect the underlying Hue entity itself, not merely create another entity pointing to it.

That’s why the second level of the workaround is important.

The downside

Obviously, this is not a real solution to the underlying problem.

It is a workaround built around a device classification imposed by the Hue Bridge.

Ideally, the Hue Smart Plug should be exposed according to its actual function, for example:

  • light for lighting applications
  • switch / outlet for non-lighting applications

Or, even better, Hue could allow the user to select the functional type of the Smart Plug.

That would allow platforms such as Home Assistant, Apple Home and Matter to treat the device appropriately.

Why I’m sharing this

I spent quite a bit of time trying to find a clean solution to this problem, so I thought this workaround might be useful to other Hue users.

At the same time, I’m very interested in hearing from more experienced Home Assistant users:

Is there a simpler or more robust way of achieving the same result?

In particular, I’d be interested in solutions that:

  • keep the native Hue integration;
  • prevent global light commands from affecting the Smart Plug;
  • provide a proper ON/OFF control in the physical room;
  • and avoid unnecessary state-change loops or delays.

If anyone is interested in the implementation details, I can also provide the YAML for the automations.

If anyone has a cleaner approach, I’d be very happy to test it.

Thanks!