We're not yet configuring full motion-based automations or schedules: that's Lessons 11 through 13. We're focusing on giving every light point understandable manual control, and on knowing what still works when the server, router, or coordinator goes down. Further on I'll shorten Home Assistant to HA.

Plan on about 110 to 120 minutes.

A real-life problem: "your smart home doesn't work"

Sunday evening. You're restarting HA. A household member clicks the switch: nothing. Or the light flickers and goes out, because an automation is restoring a previous state. Or they say, "I'm not installing an app just to turn on a lamp": and they're right.

A second scenario: a Hue remote works fine in the Hue app, but HA doesn't have any mapping for it yet. A third: a guest holds down a button and triggers a scene that shuts off half the house. These problems don't come from "bad Home Assistant." They come from having no plan for manual control.

Four paths of manual control

1. A wall switch with a module in the box: the input locally controls a relay or dimmer. With correct mounting and a local input mode, it can work without HA. That isn't a physical workaround for a broken module: the module's electronics still have to be functioning.

2. A battery-powered remote or button: no 230V involved. It can work through HA, through the manufacturer's bridge, or through a direct Zigbee binding.

3. A direct binding: on compatible Zigbee devices, a remote controls a lamp or a group without going through HA. This is an important Plan B, but it has to be configured and tested.

4. The app or the HA dashboard: a convenient extra, never a Plan B.

A remote can work three different ways

The Philips Hue Dimmer Switch: a remote, not an in-box dimmer

The Hue Dimmer is a battery-powered remote with on / off / brighter / dimmer buttons: the layout and labels vary by generation. It doesn't replace a 230V dimmer in the box. An electrician doesn't mount it behind a wall switch.

Hue remotes don't have a classic on/off state. The official Hue integration exposes presses as hue_event events. The simplest approach is to build an automation from the device page in the UI, or inspect the event data in Developer Tools. Don't promise a specific event.hue_dimmer_switch_action entity: how it's exposed depends on the integration version and the model.

A double click isn't guaranteed. Start by only using gestures the integration actually exposes: don't emulate a double click at the outset. Plan B: if the group lives in the Hue Bridge, the remote can control the bulbs even when HA is down. If the path runs solely through HA, HA going down means the remote going down too.

IKEA: RODRET, STYRBAR, and SOMRIG

• RODRET: a simple wireless dimmer for on, off, and brightness adjustment: not a five-way remote.
• STYRBAR: a more full-featured light remote, with several buttons and additional configuration-dependent functions (including white color temperature on compatible sets).
• SOMRIG: a shortcut button meant mainly for triggering saved scenes.

Don't copy the mapping from a different IKEA remote just because all the devices are Zigbee. A sensible RODRET mapping: a short top press: turn on; holding the top: brighten; a short bottom press: turn off; holding the bottom: dim. Check the actual events in your own integration.

Aqara, SONOFF, and Shelly

The Aqara Wireless Mini Switch supports single, double, and long presses in the manufacturer's ecosystem. In HA, the available gestures depend on the integration and the full model. Don't assign it a "shake" gesture: that's a feature of other devices (e.g. vibration sensors), not a typical Mini Switch.

The Aqara Light Switch H2 EU is a complete wall switch that can operate in Zigbee or Thread/Matter modes. Before buying, check whether your chosen mode exposes the entities, button events, and local Plan B you need in HA. Don't assume every key generates a free-form event in every ecosystem.

The SONOFF SNZB-01P is a simple single-button Zigbee remote. Before buying, check the full model's support in ZHA or Zigbee2MQTT. In-box modules (MINI, ZBMINI): with correct mounting and a local input mode, the switch can control the relay without HA: that's the module's local electronics, not a physical workaround for a broken device.

A Shelly in the box: in standard mode, the input can locally switch the output without HA. In detached mode, the input alone doesn't switch the output: behavior depends on local logic, HA, or another path. Click types (single_push, double_push, long_push) depend on the generation, firmware, button/switch mode, and integration: don't build on universal naming.

The Shelly BLU Button needs a compatible gateway within the Shelly Smart Control ecosystem. When integrating directly with HA, check Bluetooth/BTHome support, range, and whether you have a Bluetooth adapter or proxy in place. Bluetooth follows a different range model than Zigbee.

ZHA, Zigbee2MQTT, Hue, and Shelly can expose clicks differently

• ZHA: start with a device trigger in the UI; use the zha_event event only when the UI isn't enough.
• Zigbee2MQTT: an MQTT device trigger, an action field, or an optional/experimental event entity.
• Hue Bridge: hue_event events.
• Shelly: an event entity, a device trigger, or an input event: depending on the model and configuration.

Don't copy YAML between integrations. Event names can be: single, single_press, on_press, short_release, button_1_single: copy from your own integration.

The UI first, YAML second

For a beginner, the best path is: Settings → Automations & Scenes → Create automation → Add trigger → pick the remote's device → pick the press → add one action → save → press the button → check the execution trace. Copy YAML from the UI once you actually need it.

How to inspect the actual event

1. Check the integration's documentation for the event name, e.g. hue_event or zha_event.
2. Open Developer Tools → Events.
3. Listen for just that specific type: not every event in the system.
4. Press the button once. Record the identifier, the command, and the click type.
5. Repeat the test for double and long presses, if they're exposed.

The event entity: a timestamp and the event_type attribute

An event entity doesn't have a single_press state. Its state is usually a timestamp of the last event. The event type sits in the event_type attribute. A trigger that only watches for the attribute changing to single_press may not fire again when two consecutive events share the same type.

- id: bathroom_button_single
  alias: Bathroom - single button press
  mode: single

  triggers:
    - trigger: state
      entity_id: event.bathroom_button_action

  conditions:
    - condition: template
      value_template: >
        {{ trigger.to_state.attributes.get('event_type') == 'single_press' }}

  actions:
    - action: light.toggle
      target:
        entity_id: light.bathroom_ceiling

The name single_press is an example. Check your own entity's actual event_type. Not every integration creates an event entity: Zigbee2MQTT may use an MQTT device trigger or an action field instead.

Settle on one button language for the whole house

A household member learns several similar remotes faster than one remote with lots of exceptions.

• a short press: the basic light,
• the top button: turning on or brightening,
• the bottom button: turning off or dimming,
• a long press: an extra function: not a hidden critical one.

To start: a short click, one simple double click if it's native, a long press only as an unambiguous manufacturer event. Mark smooth dimming through holding (hold/release/brightness_move) as an extension.

Don't hide critical functions (blind STOP, emergency opening, disarming an alarm, cutting off all lighting) behind a long or double click. "Leaving" or "Night" scenes on a long press can get triggered by accident: a separate, clearly labeled button is better, with only safe, reversible actions, and no blinds at this stage.

toggle, a timer, and a manual override

light.toggle is convenient for a single lamp. With a group in a mixed state, with unknown/unavailable, or with a duplicated event, it can cause flickering or "no response." A remote with two buttons: top turn_on, bottom turn_off.

Simply calling input_boolean.turn_off doesn't implement an "hour-long" lockout. A persistent local lockout is input_boolean.bathroom_motion_lockout; a timed override after a manual switch-off: timer.bathroom_light_manual_override. Don't mix the two up. Recall the lighting_automation_enabled helper from Lesson 1: don't recreate it. Leave the global master off until Lesson 11. Manual scenes and deliberate remote clicks usually shouldn't be blocked by the automation master: the master blocks motion, schedules, and sun-based logic.

timer:
  bathroom_light_manual_override:
    name: Bathroom light manual override
    duration: "01:00:00"
    restore: true

# A long press: a timed override (not a persistent bool lockout)
- action: timer.start
  target:
    entity_id: timer.bathroom_light_manual_override

If a button changes a mode or a lockout, provide a clear confirmation: a dashboard status, a device LED, or a gentle light change: only if that's acceptable to your household. A brief flash of the lamp can be irritating or inappropriate in some rooms. A household member shouldn't have to guess whether a long press was recognized.

Every manual action from a remote needs a defined effect on later automations: details in Lesson 11. The rule already applies now: a manual turn-off can't be reversed a moment later by motion detection. mode: single is usually enough for an instant action. If a sequence runs longer, decide what a subsequent click should do (restart, queued, parallel).

Don't map a button to "turn the fan on permanently" without a timer or a way to turn it off: a 15-minute script is better, or leave the topic to the ventilation module.

Plan B: separate your failure tests

These are separate tests: HA turned off; HA running but without internet; the Zigbee coordinator unavailable; the router/LAN unavailable. Don't lump them together as one generic "HA offline."

A battery remote needs upkeep

Ergonomics: mounting height, reach from the bed, a magnetic holder (not a loose remote under the pillow: a long press could trigger a scene). A small label under the holder helps: don't block access to the battery or the LED.

What to check before buying a button

A remote mapping card

Testing a remote after configuration

Common mistakes

Hands-on exercise

Key takeaways

• A wired switch, a battery remote, a local binding, and a dashboard are different control paths.
• A remote can work through HA, through the manufacturer's bridge, or directly with the device.
• The Hue Dimmer is a remote, not a 230V dimmer.
• RODRET, STYRBAR, and SOMRIG have different button layouts and different purposes.
• ZHA, Zigbee2MQTT, Hue, and Shelly can expose clicks in different ways.
• You build a simple trigger in the UI first, and only later expand into YAML.
• An event entity's state is a timestamp of the last event; the type sits in an attribute.
• Don't assume every button supports single, double, and long presses.
• A short click should perform the most common, obvious function.
• Don't hide critical functions behind a long or repeated click.
• A local button should usually control a local point or a local lockout.
• Turning off an input_boolean alone isn't an hour-long lockout: use a timer for that.
• Manual control can't be reversed a moment later by an automation.
• You test Plan B separately for HA, internet, the local network, and the coordinator.
• A battery remote needs battery monitoring, range checks, and periodic testing.

In Lesson 10 you'll build lighting scenes. The buttons from this lesson will trigger them: before you add schedules and motion in Lessons 11 through 13. If a household member can turn on a light without your help, the module is heading in the right direction.