Core: Reload of input_text doesn't reset to initial

[kloggy]

The problem

Pretty much as the title says.

The ‘reload’ service should be just that and completely reload input texts as though HA was restarting including the initial value.

At the very least it should be an option.

For that matter, this applies to any input_*

Environment

• Home Assistant Core release with the issue: 110.3
• Last working Home Assistant Core release (if known): n/a
• Operating environment (Home Assistant/Supervised/Docker/venv): Home Assistant Supervised
• Integration causing this issue: input_text
• Link to integration documentation on our website: https://www.home-assistant.io/integrations/input_text/

Problem-relevant configuration.yaml

`service: input_text.reload`

Traceback/Error logs

Additional information

[probot-home-assistant[bot]]

input_text documentation
input_text source
_{^{(message by IssueLinks)}}

[probot-home-assistant[bot]]

Hey there @home-assistant/core, mind taking a look at this issue as its been labeled with a integration (input_text) you are listed as a codeowner for? Thanks!
_{^{(message by CodeOwnersMention)}}

[spacegaier]

Currently, all input_* components use skip_reset=True which means the entity gets not destroyed and recreated and therefore is not receiving the initial value most likely.

https://github.com/home-assistant/core/blob/6273ad85f847afa41a1baacf531935fd1e698c4c/homeassistant/components/input_text/__init__.py#L147-L154

[kloggy]

I don't know Python but it seems in that case that it would be trivial to either correct this (as I consider it a bug) or allow an option to not reset. Which could be even better? (No breaking change ;-) )

[Adminiuga]

The intention of the reload service was so that you could edit the configuration.yaml, add new inputs, call the reload service and have new inputs show up in HA without affecting the existing one. It wasn't intended to emulate the full reset of HA.

[spacegaier]

I just tested it in my local dev instance and changing the skip_reset does not solve the issue. It recreates all the input_text entities, but they keep their state.

Independent of the actual technical solution: Simply changing the behavior could affect users that are already relying on it only reloading the configuration, but not resetting the initial value.

My personal feeling is, that it might be best to keep "reload" as it is and instead add a second service "reset" or "reinitialize" that goes back to the initial state.

[kloggy]

Which is why an option that defaults to the current behaviour could work?

Either way I don't have a strong view on the solution but I do think it should be possible to have the 'initial' value (in all input_*) to be reset.

It's too late now but I suggest 'Reload' is a poorly named service if it was designed to "_add new_ inputs" [my emphasis] and if "It wasn't intended to emulate the full reset of HA".

[spacegaier]

It's too late now but I suggest 'Reload' is a poorly named service if it was designed to "_add new_ inputs" [my emphasis] and if "It wasn't intended to emulate the full reset of HA".

It is not only for "adding new inputs" (since those can actually be added directly in the HA frontend without any YAML and then you don't need the reload for that) but re-loading the whole configuration for the inputs (e.g. min/max lengths).

I think you are actually contradicting yourself a bit since you write that it wasn't intended to emulate a full reset which is true, hence the service name "reload" and not "reset". So we could implement a new service "reset" that sets the state to the initial value.

[balloob]

Initial value is the initial value that it will get at startup of Home Assistant. It is not the value the entity is set to when it is initialized AND when we reload configuration.

[spacegaier]

@balloob But if it is not meant to be reset, what is then the purpose of this initial parameter?

Since it keeps its state between HA restarts via the core.restore_state, this value will only ever be relevant once: During the very first input entity creation. If that is done through the HA frontend directly, then it actually never comes into play, since the frontend is not even providing an input field for it.

[kloggy]

@spacegaier I'm slightly confused that you think I was contradicting myself. I was quoting you.

I did say quite early on that an 'option' (which could of course be a new service) to 'reset' would be a solution. But I really think another new service is a bit of a sledge hammer to crack a nut. Reset, Reload, isn't it just becoming a question of semantics now. It is all part of the same thing, surely?

[balloob]

Input entities that have initial defined will not have their state restored.

[spacegaier]

@kloggy That quote wasn't actually from me, but doesn't matter, especially now that the proposal has already been rejected.

@balloob Shouldn't then the initial parameter be in the frontend so users can change it or was it omitted by design?

[balloob]

Reloading does not the same as a restart.

We're reloading the configuration while the entity is already part of Home Assistant. The initial value is only applied when the entity is added to Home Assistant (on startup).

[mf-social]

I don't have a strong opinion either way (I just clicked the link from the forum question), but this behaviour is not consistent with the reload services that came before it.

Reloading automations resets them to their initial_state: value - thus imo so should reloading anything else, or none should do it.

[kloggy]

Ok, so I get, but do not agree with, the reasoning

"_We're reloading the configuration while the entity is already part of Home Assistant. The initial value is only applied when the entity is added to Home Assistant (on startup)._"

But this just strengthens the view that the Service is at best confusingly named.

Reload: _re_ is shorthand for 'repeat'. i.e. do whatever was done when it was _load_ ed.
Reload should have probably been called 'load' i.e load _new_ input_* because that seems to be what it does.

Obviously this isn't going to change now but we could consider fixing both the inconsistencies (functional and naming) by allowing an option to also reset to initial, defaulting to 'no' to prevent breaking changes.

Except that this has been closed :-(