input_number: A Temperature Threshold Without Editing the Automation

Module 11's office temperature automation hard-codes its threshold directly into the automation itself, meaning any adjustment requires opening the editor and changing YAML. This lesson replaces that fixed value with input_number.office_temp_threshold, a genuine slider you can adjust from a dashboard in seconds.

What input_number actually is

An input_number helper stores a single numeric value within a defined minimum, maximum, and step, appearing on a dashboard as either a slider or a small box you can type directly into. Unlike input_boolean's simple on/off state, it holds a genuine number, 19, 22.5, or anything else within its configured range, and remembers that number faithfully across restarts exactly as any other helper does.

Why you shouldn't hard-code a threshold inside an automation

A threshold typed directly into a Numeric State trigger works perfectly well right up until the day you genuinely want it different, colder in winter, warmer once you've adjusted to the room, and at that point you're back in the automation editor hunting for the exact right number to change. Pulling that same threshold out into its own helper means the automation's structure never changes at all, only the helper's value does, and that value is now reachable from any dashboard, any script, and any other automation.

Step 1: create input_number.office_temp_threshold

From Settings, Devices & Services, Helpers, add a new helper of type Number and name it office_temp_threshold, setting its minimum to a sensibly low value like 15, its maximum to something like 26, and its step to 0.5 for reasonably fine control. Give it a genuinely clear icon, a thermometer works well, so it's instantly recognizable next to your other helpers on a dashboard.

Recording the threshold's purpose in your notebook

Write down exactly what this helper represents the moment you create it, "office_temp_threshold: below this value, turn on the LED as a cold-office signal." A short, clear sentence like this genuinely prevents confusion months later when you've forgotten precisely which automation reads this particular number, or why you chose the specific range you did.

Step 2: swap the hard-coded value in the automation

Open your Module 11 temperature automation and replace its Numeric State trigger's fixed "below" value with a template reading the helper's current state, states('input_number.office_temp_threshold') as a number. From this point forward, the automation's trigger genuinely re-evaluates against whatever the helper currently holds, rather than against a number frozen in place when you first wrote it.

Before and after, side by side

Before this change, the trigger read simply "below 19," a fixed number embedded permanently in YAML, only changeable by editing the automation itself. After, it reads the helper's live value through a template, and changing that behavior now takes nothing more than dragging a slider, no editor, no YAML, no automation reload required at all.

Test: set the threshold to 22 degrees, then back to 19

Drag the slider up to 22 degrees, then manually set your office temperature sensor to 20 in developer tools, confirming the LED now turns on since 20 sits below the new, higher threshold. Slide the threshold back down to 19 and repeat with the same 20-degree reading, confirming the LED genuinely stays off this time, proving the automation now reacts to whatever value the slider currently holds.

Verifying in trace and States

Open the automation's trace after each test and confirm the trigger's evaluated condition shows the exact threshold value you set moments earlier, not some stale or cached number. Developer tools' States page also shows input_number.office_temp_threshold's current value directly, a genuinely quick way to confirm what the automation is comparing against without digging through trace at all.

Informational only, not a heating automation

This lesson's LED is genuinely just a visual signal, a reminder that the office feels cold, not a real thermostat controlling actual heating equipment. Treat this threshold and this automation strictly as a notification pattern for now, adjusting a real heating system safely involves considerably more caution and is deliberately left for a later, dedicated module rather than rushed here.

What can genuinely go wrong

Forgetting the "as a number" conversion in the template is a genuinely common mistake, since states() always returns text, and comparing text to a number sometimes fails to trigger the way you'd expect. If the automation ever seems to ignore the slider entirely, check the trace's rendered trigger value first, it usually reveals a template quietly comparing the wrong types.

A hands-on exercise

Run through both tests described above, 22 degrees and 19 degrees, and record each trace's outcome in your notebook alongside the helper's written definition. Try one extra value of your own choosing too, somewhere near the very edge of the helper's configured range, confirming the slider and the automation both behave sensibly right up to those limits.

Choosing sensible minimum, maximum, and step values

A slider's range genuinely shapes how usable it feels day to day, too wide and every small adjustment requires several drags, too narrow and it might not cover a value you'll genuinely want later. For a comfort threshold like this one, a range spanning roughly ten degrees with a half-degree step strikes a reasonable balance, fine enough for genuine control, without requiring excessive dragging to reach any sensible value.

Adding the slider to your dashboard

Place office_temp_threshold on your dashboard directly beside the office temperature sensor it relates to, so both the live reading and the adjustable threshold sit together where you'll genuinely notice them at a glance. Seeing both values side by side also makes it considerably easier to judge, at a glance, whether the current threshold still makes sense for how the room actually feels.

One shared threshold, or one per room

As you add more rooms with their own temperature sensors later, you'll face a genuine choice, one shared input_number.comfort_threshold read by every automation, or a separate helper per room like office_temp_threshold and bedroom_temp_threshold. A shared value is simpler to manage but assumes every room should feel the same, while separate helpers cost a little more setup yet let each room's automation reflect that room's own genuine comfort preference.

Why a slider beats editing YAML every single time

Editing YAML directly is genuinely fine for someone comfortable with it, but it requires opening an editor, finding the right line, saving, and reloading, several steps for what's conceptually a single small adjustment. A slider collapses all of that into one direct gesture, and crucially, it's an adjustment anyone in the household can make confidently, not just whoever originally wrote the automation.

input_number versus input_boolean, choosing the right helper

It's genuinely worth pausing to notice the pattern forming across this module, input_boolean for a simple flag with exactly two states, input_number for anything genuinely continuous, a threshold, a delay, a brightness level, or a percentage. Reaching for the wrong helper type, forcing a continuous value into an on/off flag, or forcing a genuinely binary choice into a slider, tends to make an automation considerably harder to read later, so it's worth taking the extra moment to pick the type that actually matches the value's real nature.

Where an input_number helper's value can come from

Nothing restricts an input_number's value to only ever being set manually from a dashboard slider, a script or another automation can call input_number.set_value directly, letting the threshold itself adjust automatically based on the season, the time of day, or genuinely any other condition you'd like to script. This lesson sets the value by hand throughout, purely to keep the underlying concept clear, but keep this door open for later, once scripts are introduced properly further into this module.

Key takeaways

What's next

With a genuinely adjustable threshold in place, the next lesson introduces scenes, a way to save several devices' states together as one named snapshot you can recall instantly, without writing a single automation at all.