Dumb lamp + smart socket = 🔌 Smart Plug Multi-Level Light

Share your Projects! Custom Integrations
, , , ,
1

The integration combines a light fixture without digital control and a smart plug into a single Home Assistant entity. It detects the current state and brightness mode from power consumption, shows them on the card, and can turn the lamp back on even if it was switched off using its own physical button by briefly power-cycling the smart plug.

1844×206 21.8 KB

While traveling through :denmark: Denmark, I was given a tip to try a special kind of hunting — looking for interesting things at local flea markets. At one of them, I found a curious LED floor lamp with several brightness modes. I loaded it into the trunk and, after getting back home a week later, started wondering: should I replace its electronics, or solve the problem with a hack? And I do love hacks =)

For the next week, the lamp basically became a lab bench. I ran it through every mode, measured current and power, caught spikes, edge cases, and dozens of on/off and recovery scenarios. In the end, the system became self-learning, and the integration accumulated a lot of carefully polished details — from stable state detection and physical-button handling to recovery logic, delays, learning, and UI behavior. At this point, it is no longer an experimental hack, but a pretty polished solution for everyday use.

:sparkles: Features and highlights:

  • Creates a native Home Assistant `light` entity compatible with automations, scripts, and the standard HA interface;
  • Turns the lamp on correctly regardless of how it was switched off — through the smart plug or with the lamp’s own physical button;
  • Automatically detects the current mode from the actually measured stable power consumption;
  • Learns during setup: the user switches through the lamp’s modes, while the integration measures and stores the power consumption of each one;
  • Filters unstable readings and borderline values so the detected mode does not “jump”;
  • Supports any number of modes;
  • The card is built on top of the standard Home Assistant Tile Card and visually reflects the current brightness;
  • Lets you configure the off-state power threshold and the power-cycle delay;
  • The interface is localized for 64 Home Assistant locales.

913×655 30.7 KB

:dizzy: Beyond the core logic, the integration includes a lot of small details that I specifically refined for real everyday use.

:electric_plug: Description, instructions and installation (HACS friendly)

I hope the integration will be useful to the community. I’ll be glad to hear feedback, ideas, and unusual use cases :handshake:

2

There’s also the template light ( Template - Home Assistant ) if you don’t want a full blown 3rd party integration for this functionality. You just have to configure it with YAML.

3

I think the comparison with Template Light is fair at a very high level, but saying they do the same thing is misleading.

The core goal of Smart Plug Multi-Level Light is simplicity for the user. It is not trying to prove that Home Assistant cannot solve this problem with its built-in tools. In many cases, it can.

Template Light is a general-purpose building block. With enough YAML, helpers, scripts, and templating, you can reproduce a significant part of what this integration does.

Smart Plug Multi-Level Light takes that specific use case and turns it into a ready-to-use, UI-driven workflow, where the user does not have to design or maintain all of that logic manually.

Feature Template Light Smart Plug Multi-Level Light
Create a light entity on top of other entities :white_check_mark: :white_check_mark:
Determine on/off state from a power sensor :white_check_mark: With a template :white_check_mark: Built in
Convert measured power into a brightness value :white_check_mark: With a template :white_check_mark: Built in
Support multiple discrete physical brightness modes :gear: Must be implemented manually :white_check_mark: Built in
Calibrate modes from actual power measurements :cross_mark: No dedicated workflow :white_check_mark: Directly from the UI
Detect the current physical mode from power consumption :gear: Must be implemented manually :white_check_mark: Built in
Filter unstable/noisy power readings before changing mode :gear: Requires additional logic/helpers :white_check_mark: Built in
Power-cycle the plug when the plug is on but the lamp itself is off :gear: Can be implemented with a script :white_check_mark: Built in and configurable
Automatically limit power-sensor selection to sensors belonging to the selected plug :cross_mark: :white_check_mark:
Configure and edit modes through the Home Assistant UI :cross_mark: :white_check_mark:
Configure filtering and power-cycle parameters through the UI :cross_mark: :white_check_mark:
Dedicated Lovelace card showing detected mode and calculated brightness :cross_mark: :white_check_mark:
Requires the user to design templates/scripts/helpers :white_check_mark: For this use case :cross_mark:

So yes: the underlying idea overlaps with Template Light. This is not a claim that Home Assistant cannot achieve the same result with its built-in tools.

The important difference is the level of abstraction — and, ultimately, the amount of work left to the user.

With Template Light, the user gets the primitives needed to build the solution. For this particular use case, they still have to decide how power values map to modes, implement the state logic, deal with noisy readings, create the power-cycle behavior, maintain the YAML/scripts/helpers, and build the dashboard representation themselves.

With Smart Plug Multi-Level Light, the user selects the plug, switches the physical lamp through its modes, lets the integration measure each mode, and configures the rest through the UI.

That is essentially the point of the project: take something that can be built manually in Home Assistant and make it simple enough that the user does not have to build it manually.

Template Light is the toolbox. Smart Plug Multi-Level Light is a purpose-built tool for this particular job.

There is substantial overlap in what can ultimately be achieved, but not in how much of the solution the user has to design and maintain themselves.