Input Number - Slider Not showing number

Interesting… Guess I can always try and upgrade and see if it fixes… :frowning:

To be honest, I haven’t seen issues like yours at all and not sure upgrade would help…
My issue was Lovelace’s behaviour on small screens.

Noticed this only recently, after biting the bullet and upgrading to the latest HA version and going from States to Lovelace as main interface.

Input_numbers seem to be the only entity domain suffering this (bug). commented with pictures what’s happening, and truly hope the devs are willing to change behavior. This cant be per design for inout_numbers.
Input_numbers are a prominent part of the user interface, and their state needs to be in view at all times, no matter the window size, just like switches, sensors, lights etc etc.

please give this some traction.

Yeah, I hate the fact that if you use a slider, it doesn’t show the value unless you move it and I’d love to see it implemented properly. See it every time I control my HA from my phone, it’s a pain.
However, for now as far as I get, the devs consider it “as expected” :frowning:

which is most peculiar to say the least. Slider states should always be visible, and on mobile device now never is ?!?
this can’t be as per design, should we file another issue giving it more traction? Cant imagine any UX designer thinking this is great user experience, not being able to see what the state is…

not sure if increasing the number of issues would make devs change their mind…
maybe it’s more productive to find a way to bring appropriate devs’ attention to that particular issue and discuss it further?
however, I don’t know how, it’s so complicated with HA that I have almost given up opening new issues, they rarely work at all :\

has anyone seen their input_number states back already? :slight_smile:

been busy with some other Lovelace stuff, and forgot about this rather annoying issue, which, being on 109.6 still is bugging the interface.

the issue https://github.com/home-assistant/frontend/issues/2905 was closed, but not resolved, Ive asked @akasma74 to reopen (is that you @AhmadK ?)

2 Likes

issue still there on 0.114.4

1 Like

Still there in 2020.12.0

Agree here. Dependig on width the state is shown or not. Space is there.

Esp. Confusing, e.g. on iPad is not shown in landscape mode if reloaded in portrait mode first. Or the other way round, load in landscape mode and then turn tomportrait, than it is still shown, even with the smaller columns. Etc. For me, it should be either shown all the time or customizable like in custom:slider-entity-row

The set to/insert of hidden should be completely removed. Anyone knows the source file? Perhaps it makes sence to create a pull request, so that the mentioned issue/bug report will not be closed again and again without any correction/change. I would do this.

<span class="state" hidden>
1 Like

Disclaimer: I’m new to both hass io and this forum, please attribute any gross misunderstandings to this. I stumbled here because I’m having the same problem.

As far as I can tell, the issue appears to arise from the check against a clientWidth of 350px in hui-input-number-entity-row.ts, line 152 during initialization:

element.hidden = this.parentElement.clientWidth <= 350;

In version 2020.12.1, this source is “compiled” into chunk.f81d9a7c375b92ec0a75.js on the raspberry installation. I changed mine to compare against -350, solving the problem. I’m not sure of the implications of submitting a PR that removes this check entirely. Maybe someone with more experience could shed some light on this?

NOTE: If you want to patch yours (assuming version 2020.12.1, substitute 1.2.3.4 with your raspberry’s IP):

  1. ssh into your raspberry pi, i.e., ssh [email protected] -p 22222
  2. type “login” followed by [Enter] to get a shell.
  3. find the “compiled” js: find / -iname "chunk.f81d9a7c375b92ec0a75.js"
  4. 4 locations are reported, but they are all the same file (via mounts), you only need to change one of them.
  5. modify the file: vi /PATH/TO/chunk.f81d9a7c375b92ec0a75.js by searching for 350 and changing it to -350:
...this.parentElement&&(e.hidden=this.parentElement.clientWidth<=-350)}},{kind:"get"...
  1. move the compressed file: mv /PATH/TO/chunk.f81d9a7c375b92ec0a75.js.gz /PATH/TO/chunk.f81d9a7c375b92ec0a75.js.gz-DISABLED (otherwise it will be served unedited).
  2. reboot the pi
  3. check that it serves the modified file at http:// 1.2.3.4:8123/frontend_latest/chunk.f81d9a7c375b92ec0a75.js (making sure to clear or disable your browser’s cache)
1 Like

Would be great to have this merged. Did this locally for now as well. I see no benefit from a UI perspective for this 350 pixel check. Esp. as there is enough space below 350 px as well. If they decline ti merge (hopefully not), perhaps a pixel customizing yaml attribute could be introduced (with 350 px default).

1 Like

I’d really like to be able to see these numbers too without having to alter the value to do so - I use then in some cases to tweak the sensitivity of some medical alarm levels

This screenshot is from a three column layout on a desktop computer - not even small

image

The current status in the PR is to reduce the limit from 350 to 300. Then it should fit. The approvers/coders unfortunately don’t want to remove it completely, nor hav a parameter for this.

Currently the PR is waiting for merge.

coming from

Hi all, any idea if this has been addressed?

As of HA 2021.3.4 the disappearing numbers issue is still a thing. I can temporarily work around it on my regular PC browser by either expanding the left hand Home-Assistant side bar or adjusting the zoom level to 90%, however for obvious reasons this doesn’t work in the mobile app, where the issue is present too.

Hoping to see this snafu fixed soon as my WAF is dropping! :slight_smile:

More than long via issues, PRs, etc. But they do not want to change it or to make it more customizable. I gave it up and switched completeley to

There you can add a paramater to alway show the number.

Still not understand, why they reject the idea to add this to the core as well.

1 Like

Was this ever solved and Ive missed it?

Still no numbers next to sliders on Safari or Chrome on a Mac but have numbers next to sliders on iOS.

No. This is still the status and most probably will be.

1 Like

Ha! This is really an issue? I was looking for the setting so long because I did not even expect that this is a bug

Thank you for this recommendation. Perfect solution to this issue (issue to me).