Input numbers vs Template numbers

Configuration
1

Hi,

Relatively new to Home Assistant (Green platform), I have trouble understanding the differences between an « Input Number » and a « Template Number ».

For an Input Number I understand that :

  • As its name suggests, it is intended for the end user to be able to enter a numeric value (by typing in a value into the Input field or using the slider)
  • As far as I know, it cannot be linked to a device. Why should this be the case? I would like to offer the End User the possibility to set the value of a parameter associated with a device.

Whereas a Template Number :

  • Can be linked to a device, so it is displayed under « Device Info » (three dots menu of any entity linked to that device) this is great!
  • Defines a numeric value directly in Jinja code written into the « State » field. The end user cannot define the value. Why then is does the interface present the user with the same options as for an Input Number (slider and input field, which appear to active, but are overridden but the Jinja code in the template state field)?

Or maybe my understanding is incorrect?

2

I’ve never used them, but looking at the docs, the value of a template number can change the state of another thing, which in turn changes the state of the number itself. So it’s like a link to a “real” number.

For example, you have a distance in kilometers, but you also want it in meters. So you could have just one “real” number (km), and the other could simply be a template that, when set, divides the value by 1000, and puts it into the other entity (and also multiplies it by 1000 when displaying).

1 Like
3

Template * - derive something that is [domain] but use that stuff (points at foo) to make it.

Input * - gimme a place to store something of type [domain]

Don’t over think it. :wink:

4

History, Inertia, and/or Architecture decision… no one has gone through the process to get that approved and added the code for that feature.

A state template is optional for a Template number. A Template number without a defined state will operate optimistically, making it essentially the same as an Input number in day-to-day use.

That is incorrect. A Template number has the same frontend interface and similar available script/automation action as an Input Number.

On it’s own, having the value “associated” with the device will do nothing to the device or any of its functions… you still have to construct the set of actions to take on other entities. You can do the same thing with an Input number and an automation.

5

TL;DR - Inputs have state, templates don’t have (their own) state.

Inputs

There are multiple types of input, the main ones you will use being:

  • Booleans (Checkboxes - On/Off)
  • Selects - List of items
  • Text Boxes

The critical point is they are stand alone (don’t require anything else) and they store whatever value you enter in the HA database, so that if you restart home assistant the value is still there.

If you want them to trigger anything to happen you typically need to also create an automation that is triggered by a state change on the input.

Templates

Don’t have any state of their own, the simplest example is a Template binary sensor which allows you to basically create a new binary (on/off) sensor by using logic (AND, OR, NOT) to combine other sensors together.

The template doesn’t have any “state” of its own it derives the state by evaluating the condition you give it.

Most of the other templates, have two primary sections:

  • A “state” section which allow the template to derive the current value.
  • An “actions” section which runs whenever a user takes an action in order to update something.

With templates you typically have to think about how to tie the state back to the action for example you could have an “is blue” template switch.

  • When turned on it would turn on a light and set the color to blue.
  • When turned off it would turn off the light.
  • The state would need to check if the light was on and also check if it was blue.

Template Examples

These are not particular good examples - they are just cases I have in my own automations:

  • Dewpoint (Template Sensor) - I want to calculate the Dewpoint of a room (you can Google the formula) but it basically just combines a temperature and a humidity sensor.
  • AC mode (Template Switches) - The real AC has 3 useful modes (Off, Cooling and Heating) I want to expose that as two switches Cooling (on/off) and Heating (On/Off) both of which are template switches. Switching either off turns off the AC, turning on either switches the AC on and selects the correct mode.
6

This is not true for any of the Template entities that can function optimistically.

7

Agreed, also for anything that has a delay_on or delay_off set.
But for clarity of a newbie - it’s best to consider them stateless.

They can experiment with optimization and implied states once they get the basics down.

In my own mind I still ask “where is the state stored” and I don’t think of templates as having state - other than for specific purposes where I am leveraging it.

8

I “link” an input number to an entity in an automation.

      - data:
          value: "{{ states('input_number.zonetowaternumber')|int }}"
        target:
          entity_id: text.zone
        action: text.set_value

where text.zone is sent to my irrigation device which has several other entities, eg. ON/off, TimeToWater, etc. (This particular device only receives text not numerics)

9

The HA community is truly impressive! Thank you all for your very interesting replies to my newbie question. I have spent the last days reflecting on them and thinking about my way forward.

I understand now that « input numbers » have their own state, and thus survive restarts.

This is not the case for template numbers, unless you « hardwire » the value into the state field :slight_smile:

This is what I have doing for various constants associated with my shutters (pre-set positions, and compass orientations). To allow these constants to be set by the end user, I would to have use input numbers. But then I would lose the convenience (for me) of « linking » these constants to the shutter devices (so that they appear in « device info »). I suppose that I could group them all together in a dashboard « shutter » card, which would have the same effect. That’s probably what I’ll do if I go for user-settable constants.

I amused myself by creating an « input number » + « template number » pair, where the initial state of the template number is obtained from the input number, and where an action « on set value » is defined that writes back the modified value to the input number. A bit cumbersome but it works!

I don’t know what is the correct procedure for requesting features, but two features that would seem really useful (to me) are:

  1. The possibility to link an input number to a device (so that it appears in device info).
  2. The possibility to display template numbers as simple numeric fields, without a movable slider or up-down increment arrows.

Regarding (2) above, I would be interested to see other use cases of the up-down increment arrows (or slider) on a template number. I found the examples at Template - Home Assistant rather contrived. Until now, I have been using template numbers as either constants or calculated « variables », much like template sensors.

Finally, I should point out that since I am using Home Assistant Green then, as far as I understand, all entity definitions must be carried out via the UI, which in the case of template numbers, requires a definition of state, and does not have any notion of « optimistic ».

Again, thanks to all.

1 Like
10

Small addition: if you do not want users to be able to interact, create a template sensor (not template number) and make sure to supply a unit_of_measurement.

The simplest way to look at a template number is a numeric entity that has the ability for user input, but with embedded templates and actions for describing where the actual state resides and what to do with the state when it is set by the user.

11

For future reference, a Trigger-based Template Number’s state value survives a restart.

I was wrong; I apologize for misleading you or anyone else.

I made the mistake of assuming all Trigger-based Template entities (Sensor, Binary Sensor, Number, Lock, Cover, etc) restore their state after a restart. The fact is only some do and Trigger-based Number is (currently) not one of them.

I created a simple Trigger-based Template Number entity, assigned it a state value via its trigger, restarted Home Assistant, and its value was not restored (it was unknown).

The linked table posted by petro (see below) shows which Template entities have values that survive restarts.

1 Like
12

I also plan on making all template entities survive restart, it’s just quite a bit of work. Template images will likely be last because the image platform is goofy and I’m not sure what to do.

4 Likes
13

You got me asking myself “Will this new behavior break any of my existing (non Trigger-based) Template entities?”

I don’t think so but I will need to confirm when the time comes.

1 Like
14

I’m not sure.

Before this change, trigger based template entities that do not restore data will start up with an unknown state. this will also be populated with unknown state.

After this change, trigger based template entities will restore the previous value during startup. this will be populated with the previous value.

1 Like
15

Here’s a list of template entities and what they currently support

1 Like
16

You have grasped the basic concepts behind inputs and templates.

It’s not that common to tie two similar controls (input-boolean ↔ template-switch) together as in most cases its easier to just use the input directly, but I have around 10 inputs that provide the state to various templates - I don’t show those inputs on any dashboards because I don’t need to input them directly.

I think you can use a textbox combined with a RegEx to achieve that.
But I haven’t found a need to do that, as almost all the numbers I want to enter in home assistant have a sensible range of values, so number inputs work fine for me.

17

I landed here because today I tried to manage to create UI for read/write Modbus based entities. During the investigation, I found that there are more differences between the template number and the input number.

One of the most user-facing issues is that the template number offers no HA-native option to edit the value using an edit box. It renders as a slider always. Really don’t understand the reasoning behind this limitation.

On the contrary, input_number cannot call the service on the value change. So to make it happen, automation is needed. Also, it cannot carry information about the device class.

Not sure about the input number, but I failed to secure the template number with confirmation. I mean, when rendered by the entities card.

18

They are 2 different platforms and the number platform doesn’t offer that option. I.e. It has nothing to do with template integration

Also, input_number was built specifically to use in automations. It was not built to emulate an entity, which template integration was. Input’s are all “User input” entities, where template entity is something that you piece together other entities to represent a full state with usable known actions.

19

Yes I know they come from different integrations. But your answer makes me even more wonder why the template number can’t be displayed as edit box optionally. I believe that entering data numerically is a typical use case (I understand that the slider is more mobile device-friendly), providing more certainty in the selected value.

But whatever. Just wanted to point out differences.

20

It can’t because number entities cant. That’s the literal reason why template numbers cant. If someone adds that functionality to number, then template number will automatically gain that functionality without any dev work.

1 Like