This has been really annoying for me. More often then not, when I’m scrolling through long list of entities using touchscreen, I do it using the right side of screen where my right thumb is. If during multiple scroll vertical swipes I accidentally touch a horizontal slider that belongs to a number entity, I usually change it because my thumb movement is not perfectly vertical.
Is it possible to somehow disable changing entities while the viewport is still moving during scrolling?
The slider is designed to move when its bar is touched at a new position and that’s what your thumb is doing (accidentally). So what exactly is your suggestion to prevent it from doing what it’s designed to do?
I may be wrong but I am not sure it’s able to discern the difference between being touched when scrolling or when not scrolling. Because that would be the only way to tell if it should, or should not, respond to touch.
Slider should definitely not respond to touch while it is moving. If you swipe the page up, page accelerates scrolling, and when it starts slowing down, you swipe up again before it actually stops. The problem arises if your second (or subsequent) swipe happens to hit part of the page where the slider is. I’d even like to have slider start responding to touches something like 200ms after it has stopped moving definitely…
Or maybe make that you must first tap on slider before you are able to move it at all. This would prevent accidental change if you happen to start scrolling right from the slider position on the screen.
It sounds trivial, but it has recently caused some spoiled food in my fridge because I accidentally set its setpoint temperature too high while I was looking for something completely different.
That’s unfortunate. I can empathize with how a seemingly trivial operation can have significant consequences.
Until your FR is implemented (if ever) you may wish to consider using one of the available custom cards that gives you more control over its appearance and operation. I seem to recall there was one that allowed you to lock a control (not sure if it works with a slider) and there’s another that lets you ‘fold’ an entity row which requires tapping the row first to reveal the hidden control(s).
BTW, what kind of refrigerator do you have that offers remote-control of its settings (like temperature)? Which integration are you using?
Bosch Series 6 combined fridge-freezer with Home Connect, using Home Connect Alt integration. A prime example how should commercial, closed-source, cloud based IoT platform treat its open source customers - well documented public API with properly generated API key for each user.
Honestly changing setpoint temperature remotely is not that useful (I’ve disabled that entity in the meantime for good measure), but setting superfreeze or supercool mode remotely before you come back home from shopping with a lot of supplies is quite handy.
I think other also have settings with critical behavior on their cards (like me, I always adjusted my house heating curves unintentionally by scrolling).
I help myself in these cases with the HACS Restriction Card and protect either an entire card or individual entities with a simple double_tap protection, some settings (e.g. alarm system) are protected by PIN.
The extension is really practical for this.
I also have this problem and I can’t believe this request doesn’t have more votes!
In my experience with the Home Assistant Android app and UI in browser, any touch (including starting a swipe) along the length of a slider bar will immediately move the handle to the location that was touched, and any swipe starting on the handle will move the handle. In both cases this is regardless of the direction of the swipe.
I’ve tested in a different app that also has sliders (the Philips Hue app) and it doesn’t have this problem. Its sliders will only respond to a tap, or a swipe that is less than 45° from horizontal. They don’t respond to a swipe that is less than 45° from vertical. So if that behaviour could be implemented in HA I think that would be a great solution.
The other suggestions (E.g. require a tap first to unlock, and tap and hold for 200ms) would also work, but I think slightly less intuitive.