Hi,
After my upgrade to 0.92.2 and Lovelace UI, my input slider stoped showing the number, I use this with some automations to make it as a timer to turn of my boiler.
See screenshot for reference.
Any ideas?
Thanks for the help
Interestingā¦ Guess I can always try and upgrade and see if it fixesā¦ 
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ā
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? 
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):
-
ssh into your raspberry pi, i.e.,
ssh [email protected] -p 22222 - type āloginā followed by [Enter] to get a shell.
- find the ācompiledā js:
find / -iname "chunk.f81d9a7c375b92ec0a75.js" - 4 locations are reported, but they are all the same file (via mounts), you only need to change one of them.
- modify the file:
vi /PATH/TO/chunk.f81d9a7c375b92ec0a75.jsby searching for 350 and changing it to -350:
...this.parentElement&&(e.hidden=this.parentElement.clientWidth<=-350)}},{kind:"get"...
- move the compressed file:
mv /PATH/TO/chunk.f81d9a7c375b92ec0a75.js.gz /PATH/TO/chunk.f81d9a7c375b92ec0a75.js.gz-DISABLED(otherwise it will be served unedited). - reboot the pi
- 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
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!
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.