input_boolean: Your Own Logical Switch

This lesson builds your very first real helper, a genuinely simple input_boolean flag, and wires it into your existing hallway automation as a real safe-testing switch. By the end, you'll be able to flip one toggle and watch your automation log exactly what it would have done, without ever actually touching the LED.

What input_boolean actually is

An input_boolean is genuinely the simplest helper type available, a single flag that's either on or off, with absolutely nothing more complex than that underneath it. It behaves exactly like a light switch that isn't wired to any light at all, flip it, and its own state changes, and that's the entire extent of what it does on its own, waiting patiently for an automation to actually check it.

Step 1: create input_boolean.test_mode_hallway

From Settings, Devices & Services, Helpers, add a new helper of type Toggle and name it test_mode_hallway, giving it a genuinely clear icon like a small flask or beaker to visually distinguish it from real switches on your dashboard. Once created, it appears immediately in developer tools' States, defaulting to off, exactly as any freshly created toggle should.

Recording the helper's logic in your notebook

Before wiring anything, write down in your notebook exactly what this helper means, "on: automation logs its action instead of running it, off: automation runs normally." A one-sentence definition like this, written down the moment a helper is created, prevents the exact kind of confusion that creeps in weeks later when you've genuinely forgotten which direction a flag was meant to point.

Step 2: add a condition to the motion-to-LED automation

Open your Module 11 hallway automation and add a genuinely new condition checking that input_boolean.test_mode_hallway is off, placed directly before the action that turns the LED on. With this condition in place, the automation's real action only fires when test mode is genuinely disabled, giving you a clean, reliable bypass whenever you need to test safely.

Not the same as disabling the automation entirely

Disabling an automation from its three-dot menu stops it from running at all, genuinely useful but blunt, you lose all visibility into whether it would have fired. A test-mode helper is considerably more surgical, the automation still runs, still evaluates its trigger and earlier conditions, and still shows up fully in trace, it simply stops short of the final real-world action.

Temporarily bypassing the helper while diagnosing

If you ever need to confirm the underlying trigger and earlier conditions still work correctly regardless of test mode, temporarily remove just the test-mode condition from the automation's YAML, verify, then restore it immediately afterward. Never leave an automation permanently missing this condition once you're done diagnosing, that quietly reopens the exact risk the helper exists to prevent.

Test A: helper switched on

Flip test_mode_hallway on, then trigger motion and confirm in trace that the automation ran, the trigger fired, but the condition checking test mode genuinely failed, stopping execution right there before ever reaching the LED action. The physical LED should remain completely untouched throughout this entire test.

Test B: helper switched off

Flip test_mode_hallway back off and trigger motion again, confirming the automation now genuinely runs all the way through to completion, the condition passes, and the LED turns on exactly as it always has. Comparing these two tests side by side in trace is the clearest possible demonstration that your helper is doing precisely its intended job.

What can genuinely go wrong

The most common mistake is forgetting to flip test_mode_hallway back off after testing, leaving a real automation silently disabled for days without anyone genuinely noticing. Set a habit of checking this helper's state as the very first step whenever a hallway automation seems to have stopped working unexpectedly.

A hands-on exercise: two traces in your notebook

Run Test A and Test B described above, and paste a short summary of each trace into your notebook alongside the helper's definition from earlier. Having both a written definition and a real recorded example of it working correctly is considerably more useful than either one alone, months from now when you're troubleshooting something else entirely.

Adding the helper to your dashboard

Add test_mode_hallway to your dashboard as a genuinely simple toggle card, positioned somewhere you'll actually notice it, rather than buried several screens deep where it's easy to forget entirely. A visible toggle serves as a constant, gentle reminder that test mode exists and might currently be active, considerably reducing the odds of the exact "forgot to flip it back" mistake covered later in this lesson.

Logging instead of doing nothing at all

A genuinely thorough test-mode implementation doesn't just stop short of the real action, it optionally adds a logbook entry or notification saying what would have happened instead. Add a simple action, a persistent notification reading "Test mode: would have turned on hallway LED", right where the real action would otherwise sit, so test mode gives you positive confirmation rather than simply silent inaction.

Reusing this exact pattern for future automations

The test-mode pattern built in this lesson isn't genuinely specific to your hallway automation at all, the exact same input_boolean-plus-condition structure applies to any automation you'd like to test safely in the future, a security automation, an energy-saving routine, anything with a real-world consequence worth verifying carefully first. Consider whether a single shared test-mode flag, or one dedicated flag per automation, better suits your own growing setup as it expands.

A brief word on toggle helpers versus input_boolean

Home Assistant's helper creation screen labels this helper type "Toggle" in the UI, while its underlying entity id and YAML representation both use input_boolean, the two names refer to exactly the same thing. Don't let this small naming inconsistency cause any genuine confusion, whichever term appears, you're working with the same simple on/off flag described throughout this entire lesson.

Toggling a helper manually versus by automation

Nothing genuinely stops another automation from flipping test_mode_hallway automatically, turning it on overnight and back off each morning, for instance, if that pattern ever became useful. This lesson flips it manually throughout, purely for clarity while learning, but keep in mind that a helper is just an entity like any other, readable and writable from anywhere in Home Assistant, including from within other automations entirely.

Why this lesson used the hallway automation specifically

The hallway motion automation was deliberately chosen for this first helper exercise precisely because you already know its exact expected behavior inside out from Module 11, meaning any unexpected result here points clearly and immediately to the new helper logic rather than to some unfamiliar automation you're still getting to know. Building new concepts on genuinely familiar ground, exactly as this course has done throughout, keeps each new addition considerably easier to verify.

A closing thought on this lesson's small scope

A single on/off flag feels genuinely modest compared to everything Module 11 built, and that's entirely intentional, this module introduces each new piece at the smallest possible scale before combining them later. The safe-testing pattern practiced here, small as it genuinely seems, is exactly the piece the mini project at this module's end will lean on most heavily when several automations run together.

Key takeaways

What's next

With a single boolean flag working correctly, the next lesson introduces input_select, letting you choose between several whole-home modes at once, replacing what would otherwise become a separate, genuinely awkward condition for every single situation you'd want to handle.