Guidelines / tips / recommendations for implementing new input_box component for arbitrary text / numeric input/storage?

[BioSehnsucht]

Also open to naming suggestions.

It seems there’s some desire for this functionality already, and I could use it for my Elk M1 integration. There’s at least two threads asking for features for either generic variable storage or input boxes of some kind of entering text in the UI.

Looking for a variable component

Hi, I’m wanting to create a variable that increments up +1 each time a sensor in the room is activated, and then decreases -1 each time it is deactivated. Then I want to use the value of this variable to control the lights. e.g. Lights turn on if variable is above 0 Lights turn off if variable = 0 I’m just not sure how to create this variable. It would only need to hold the values 0 to 5. Seems like such a simple thing to implement I just can’t think how to do it! Any help much appreciated.

Input_string component

I often find myself wanting to store string snippets. It’d be great to have a component similar to input_slider or input_select that worked with free-form strings (without needing to resort API calls outside of HA’s services). It would have the following services: set_value (replaces existing value with a specified value) append_value (append without first having to grab existing value) clear_value Like input_slider, you could check its value with a template.

I’m willing to try implementing this, but I imagine it will require dabbling in polymer (which I’ve thus far avoided) to implement the UI side (though it shouldn’t be too complicated, I imagine - it’d be just a labeled text box?), and I’m not sure if implementing a new generic item like this is something I should even try to do or leave to core developers to define and implement.

As I’m sitting here brainstorming this, I imagine something like this for functionality / features:

• Settable / gettable just like input_boolean / input_slider / etc, except UI is an input box
• Supported values (with appropriate validation) of int, float, and str; could support bool possibly though I really don’t think there’s a use for that (can’t think of a case where input_boolean wouldn’t work fine)
• Optional upper and lower bounds in the case of numeric inputs (perhaps can double for string inputs as min / max length)
• Optional regex validation in the case of string inputs
• Optionally can be dynamically marked read-only (this would behave similar to a sensor then, but there might be a use case where enabling and disabling changes from the UI might make sense based on some other thing being set / etc)
• Optional slider in addition to input box for numeric modes (would require min/max be set)? This is sort of a “bonus feature”, in case someone wanted to be able to both make quick adjustments as well as precise ones.

In my case I want to be able to represent read-writable numeric values on the Elk M1 alarm/automation controller (Counters and Custom Settings). I could implement them as sensors and only report on the values, but that’s giving up potential functionality. input_slider isn’t practical because the potential range is 0 to 65535, but often you’ll have users that only use 0 to 30 for example on a counter, and even with requiring the user to manually set the slider min/max settings making precise adjustments if they wanted to be able to may be difficult.

I can also imagine other uses, like an input box to speak arbitrary phrases via TTS or send arbitrary notifications via other means, for example.

[BioSehnsucht]

Well, I whipped up a quick and dirty test by copying input_slider and changing a few bits, and changing the UI to use the polymer text box widget. Still only supports numbers since all I did was reskin it, but this doesn’t look too hard to implement for the most part.

[keithh666 (Keith Hull)]

Sounds like u’r onto something I would welcome it Keep it up

[BioSehnsucht]

I’ll hopefully have an initial PR for review soon. Still need a few improvements (for example, in int or float mode, the min/max currently isn’t validated in the client, but in HASS itself, it should be client side validated). Haven’t attempted to implement slider as additional widget attached to input box yet either.

However, it looks like it works for inputting values, and it can be set to expect strings, integers, and floats, and you can set your own regex for validation as well.

Running my initial tox run now, will probably need to tweak a few things flagged during linting no doubt. Once everything is passing tox, I may go ahead and submit the initial PR even if I haven’t implemented those other two items I listed above, just so I can go ahead and start getting any feedback in general.

[BioSehnsucht]

latest HASS has new component input_text with most of the intended features. in a future HASS update, input_slider will evolve to be a generic number handler with both slider and input box functionality.