Control from the Dashboard: Switch, Script, Scene, Helper

Every view built so far displays state well, this lesson focuses entirely on the other half of a dashboard's job, triggering something. Five genuinely quite distinct control types recur across this course, and knowing which one an entity actually needs is exactly what this lesson teaches.

Five genuinely distinct types of control

A switch toggles a persistent on/off state, a script runs a reusable sequence of actions, a scene applies several device states at once, a helper stores a value an automation later reads, and an input_select cycles between named modes. Each genuinely behaves differently when tapped, and treating them interchangeably is exactly where dashboard confusion tends to begin.

A YAML example: controlling a switch

type: tile
entity: switch.led_status_hallway
name: Hallway LED

A tap here genuinely flips a persistent state, on becomes off and stays off until tapped again, exactly the behavior a household member expects from a simple light switch.

A YAML example: a script button

type: button
entity: script.evening_routine
name: Evening Routine

A tap here genuinely runs a whole sequence once, it doesn't toggle anything persistent, tapping it again simply runs the same sequence again from the start.

A YAML example: an entities card input_number

type: entities
entities:
  - entity: input_number.office_temp_threshold

This genuinely renders an inline slider or stepper directly on the card, letting a household member set a specific value without ever needing to open a separate settings screen at all.

A scene on the dashboard

A scene genuinely behaves like a script in card terms, a button that triggers once, but conceptually it's genuinely different, applying a whole snapshot of device states rather than running a logical sequence of steps, which is exactly why this course keeps scenes and scripts on visually separate cards despite both using the same button card type.

Tap versus hold: a genuinely useful distinction

Many card types genuinely support a separate hold action alongside the default tap, a tile might toggle on tap but open its more detailed settings on hold, letting one single card serve both the everyday quick action and the occasional deeper adjustment without needing two separate cards for the same entity.

A decision map for choosing the right control

Ask in order, does this entity hold a persistent state, use a switch or tile. Does it run a sequence, use a script button. Does it set several devices at once, use a scene button. Does it store a number or mode an automation reads later, use an entities-card slider or an input_select. This simple map genuinely covers nearly every control decision this course's entities will ever require.

What can genuinely go wrong

A script button styled like a persistent toggle genuinely confuses a household member expecting it to "stay on." A scene and a script sharing identical visual styling genuinely blur a distinction worth keeping clear. And a slider with no visible current value forces a household member to guess whether their adjustment actually registered at all.

An exercise: classify five of your own entities

List five entities from your own home and run each through the decision map above, confirming the card type you'd choose actually matches the control type this lesson describes, before building a single card for any of them.

A real-life example: tapping movie-night twice

Picture a household member tapping scene.movie_night, then a few minutes later tapping it again out of habit, expecting the second tap to genuinely turn everything back to how it was before. Nothing about a scene actually works that way, it simply reapplies the exact same snapshot a second time, dimming lights that had already been manually brightened back in the meantime. Understanding that a scene has no memory of "before" and no built-in undo is precisely the kind of practical detail that prevents this exact moment of genuine confusion.

Why input_select genuinely deserves its own control type

Module 12 introduced input_select as a home-mode alternative to a separate automation for every situation, Home, Away, Night, Guest, and on a dashboard this genuinely renders as a dropdown or a row of selectable buttons rather than a simple on/off toggle. Choosing "Night" from this list doesn't directly turn anything on or off itself, it simply records a mode that other automations then read and react to, a genuinely important distinction from every other control type covered so far in this lesson.

Confirmation dialogs for genuinely consequential actions

Several card types genuinely support an optional confirmation step before actually executing an action, useful for anything with real consequences beyond a simple light toggle, a script that unlocks a door, for instance, though this course's running examples don't genuinely need one. Reserve confirmation dialogs for truly consequential actions only, adding one to every single card indiscriminately genuinely defeats their entire purpose by training people to tap through them without reading a single word.

Voice control as a genuinely parallel path

Every control type this lesson covers genuinely works identically whether triggered by tapping a dashboard card or by a voice assistant integration, the underlying switch, script, scene, or helper doesn't know or genuinely care which interface triggered it. This is precisely why this course consistently designed automations, scripts, and helpers as clean, independent building blocks from the very beginning, the dashboard is simply one interface among potentially several pointing at exactly the same underlying logic.

Feedback: confirming an action genuinely registered

A genuinely well-built control card gives visible feedback the instant it's tapped, a tile's icon changing color, a slider's displayed value updating immediately, so a household member never has to wonder whether their tap actually registered or simply silently failed somewhere between the tap and the entity itself. A control that provides no visible feedback at all is genuinely one of the more common, avoidable sources of a household member tapping the same thing three or four times in frustrated succession.

Bringing all five control types together on Office

Revisiting the Office view built two lessons ago, it already genuinely demonstrates three of these five control types working side by side, a switch tile for the LED, a scene button for movie night, and an entities-card slider for the temperature threshold, without a household member ever needing to consciously notice they're actually three genuinely different underlying mechanisms. That seamlessness, five different control types feeling like one single coherent interface, is precisely the goal this lesson has been building toward the whole time.

Long-press menus as a genuinely richer alternative to hold

Beyond a simple tap-versus-hold split, some card types genuinely support a full popup dialog on long-press, showing an entity's complete history, its attributes, and a more detailed set of controls beyond the single default action a tile normally exposes. This is genuinely worth using for entities with a naturally richer set of options, a light with adjustable brightness and color, for instance, letting the everyday tap stay simple while the occasional deeper adjustment remains just one long-press away.

Grouping controls versus grouping scenes and scripts

It's genuinely worth keeping persistent-state controls, switches and tiles, visually separate from one-shot triggers, scenes and scripts, even when they sit within the exact same section of a view. A small blank space, a subtle divider, or simply ordering persistent controls before one-shot triggers within a card genuinely helps a household member's eye distinguish "this stays how I leave it" from "this just runs once and is done," without needing to read every single label carefully to understand which is which.

Testing every control type before calling a view finished

Before considering any view genuinely finished, actually tap every single control on it at least once, confirming a switch toggles, a script runs its full sequence, a scene applies correctly, and a slider updates its stored value as expected. This concrete testing step catches configuration mistakes, a script button accidentally pointed at the wrong script entity, for instance, that a purely visual review of the finished dashboard would never actually reveal on its own.

A closing thought on control as the dashboard's actual purpose

This module's very first lesson insisted a dashboard displays and triggers, it never decides, and this lesson has genuinely been the full deep dive into that second half, triggering, that the earlier lessons in this module only briefly touched on so far. Getting the five control types genuinely right, matching each entity to the interaction it actually deserves rather than defaulting to whatever card type happens to be closest at hand, is exactly what genuinely separates a dashboard that feels effortless to use from one that quietly frustrates its own household day after day, week after week.

Key takeaways

What's next

With control types genuinely sorted out, the next lesson turns to the phone, and why a mobile dashboard should be a remote control, not a shrunken command center.