Shelly Detached Input Blueprint – Switch & Button Mode with Fallback Script (v1.3)

doubleU · January 16, 2026, 8:30pm

Shelly Detached Input Blueprint – Switch & Button Mode with Fallback Script (v1.3)

Hi HA Community!

I’ve released a Home Assistant automation blueprint for Shelly Gen3 & Gen4 devices
configured in detached input mode.

It allows you to use physical switches or buttons to control smart lights or automations
without physically switching mains power, while maintaining predictable behavior
even during Home Assistant restarts.

Typical use case

Do you want to use a physical wall switch to control your smart lights
without cutting power to the bulbs?

This blueprint is designed exactly for that.

Example setup

Smart lights (Hue, Zigbee, Wi-Fi, etc.)
Shelly Gen3 device in detached mode
Classic wall switch or
Shelly Wall Switch (2)

In this setup:

The wall switch does not physically disconnect the lights
The Shelly input only reports user interaction
Home Assistant handles the smart logic
Basic interaction remains functional even if Home Assistant
is temporarily unavailable, thanks to the local Shelly fallback

This results in a much more reliable and partner-friendly smart lighting experience.

Safety note
Shelly devices work with mains voltage.
If you are unsure about wiring, consult a qualified professional installer.

What does the blueprint support?

Input modes

Switch mode
- Uses a binary_sensor
- Triggered on OFF ↔ ON transitions
Button mode
- Uses a Shelly event entity
- Supports:
  - single_push
  - double_push
  - long_push

Action modes

Lamp mode
- Switch mode → toggle
- Button mode:
  - single press → toggle
  - double press → 100% brightness
Custom mode
- Define your own actions per event or state

Optional local fallback (Gen3 & Gen4)

An optional Shelly script provides local confirmation and predictable behavior:

Runs directly on the Shelly
Generates a short confirmation pulse on every input
Continues to work during Home Assistant restarts
Same script for switch and button mode

The fallback works together with a virtual confirm switch.

Confirm switch configuration

On Shelly Gen3 & Gen4 devices, the confirm switch is a Boolean component.

Steps:

Open the Shelly web interface
Go to Settings → Components
Click Create new → Boolean
Set:
- Name: confirm
- View: Toggle
Leave all other options default and save

This component appears in Home Assistant as a switch entity
and can be selected as the Confirm switch in the blueprint.

Required inputs (HA limitation)

Home Assistant requires all trigger entities to be valid.

This means:

Switch mode → switch input is required
Button mode → button event entity is required

If an input is not relevant for your selected mode,
simply select any entity — it will be ignored.

Repository

Blueprint, fallback script, and documentation:
GitHub - willumpie82/homeassistant-blueprints: Homeassistant blueprints

Sneak peek: v1.4

Planned features:

Scene controller support
Advanced dimming options
More flexible per-event actions
Further UI improvements

Feedback welcome!

Let me know:

how you’re using the blueprint
which Shelly devices you’re running
what you’d like to see in v1.4

Happy automating!

doubleU · January 19, 2026, 10:15am

Update: v1.3 → v1.3.1 (Button Mode Reliability Fix)

I’ve released v1.3.1 of the Shelly Detached Input blueprint.

This is not a feature update, but an important stability and architecture fix.

What changed?

In v1.3, Button mode was based on low-level Shelly event entities.
While functional, this proved to be unreliable across firmware versions and device generations.

From v1.3.1 onward, Button mode is built on native Home Assistant Shelly device triggers.

Why does this matter?

Consistent behavior on Gen3 & Gen4
Same trigger mechanism as automations created via the HA UI
No more “automation triggers but nothing happens”
Future-proof against Shelly firmware changes

Additional improvements

One blueprint per physical button (simpler & more robust)
Selectable button number (button1–button4)
Optional local fallback using Shelly confirm output
Remote debugging support via shelly_button_event

If you’re using v1.3, I strongly recommend upgrading to v1.3.1.

Feedback is always welcome!

gmoney · February 2, 2026, 9:57am

Hey @doubleU just wanted to say thank you for putting in the time and effort to this blueprint.

I found it when using AI to research the most optimal lighting automation - I have been trying to achieve this with automations for years but its never been perfect. I’m still not sure if my use case was one that you built your blueprint for; I have 11 shellies (mix of Gen1,2+3) installed behind traditional rocker switches. About half are directly controlling a dumb light through the shelly output and the other half are detached and use automations to drive zigbee bulbs.

I havent been able to use the blueprint, but my understanding is that I will only want switch mode, as none are momentary switches - is that correct? One very small piece of feedback would be just to make it super clear in the UI and expand to say if you want to use ‘Button’ mode with a physical switch this can only be achieved if you have momentary switches… if I’ve got that right?

Two issues I ran into using your blueprint:

1 - [button mode] has button 1 selected by default and it cannot be unselected, even when having switch as the input mode. HA sees this as a required field no matter what, and the automation wont save.

2 - ‘Confirm switch (optional)’, this field is described as optional but in the form its required, and the automation wont save without an entity in this field.

Because of issue number 1 I cant actually save and test this out (I would love too!), so just wanted to feed that back.

For now I’m still using my simple automations to avoid random turn-ons/offs with connection dropouts:

alias: Guest Room Light Switch
description: >
  Controls the guest room light from a Shelly-connected traditional rocker
  switch. Rocker up turns the light on, rocker down turns it off. Designed to be
  robust against device dropouts and Home Assistant restarts.
triggers:
  - entity_id: binary_sensor.guestroom_lightrelay_ch1
    from: "off"
    to: "on"
    id: "on"
    trigger: state
  - entity_id: binary_sensor.guestroom_lightrelay_ch1
    from: "on"
    to: "off"
    id: "off"
    trigger: state
conditions:
  - condition: template
    value_template: |
      {{ states('light.guestroom_light') in ['on', 'off'] }}
actions:
  - choose:
      - conditions:
          - condition: trigger
            id: "on"
        sequence:
          - target:
              entity_id: light.guestroom_light
            action: light.turn_on
      - conditions:
          - condition: trigger
            id: "off"
        sequence:
          - target:
              entity_id: light.guestroom_light
            action: light.turn_off
mode: single

I love the idea of using scripting on the shellies as redundancy - however (forgive my ignorance) I’m not sure I understand why the scripting is needed, as for me the shellies work fine with dumb bulbs when HA is down.

I guess if there was a way to implement scripting that utilises mqtt when HA is down (my broker sits on a separate pi), and then also controls zigbee bulbs, locally without HA. But appreciate most have ZHA or run Z2m as an add-on…

Thanks again for your efforts!

G

martin717171 · February 4, 2026, 11:04am

This looks great! I´m looking forward to try it and follow the development.

Thank you!

doubleU · February 5, 2026, 2:56pm

Thank you for the feedback, I’ll see if I can reproduce the issue and update the BP

The whole BP is build around the Idea of using smart bulbs with the shelly in as button/switch (if you switch off the power of a smart bulb its not considered smart anymore )
If you use it with dumb bulbs (non-detached mode) I assume some weird toggle behavior