v3: slider does not handle out-of-bounds values well

[sybrenstuvel]

The problem

With Web Interface v3, sliders can be long-pressed to edit their value in a text field. However, if the currently-set value is out of bounds for the slider (in my case, it's larger than the UI max), the slider malfunctions:

1. The text field shows the "UI max", not the actual value of the setting.
2. Pressing Enter to set the "UI max" value does nothing, presumably because it thinks the value hasn't changed. This is a premature optimisation -- if I don't want to set, I won't press Enter.

In my case I have this issue with the Climate/PID control.

Which version of ESPHome has the issue?

2024.7.2

What type of installation are you using?

pip

Which version of Home Assistant has the issue?

No response

What platform are you using?

ESP32

Board

Self-made PCB with an ESP-WROOM-32 module

Component causing the issue

web

Example YAML snippet

## Here is a stripped-down config with some fake stuff just to show the issue.

esphome:
  name: koelbox
  comment: "Config for bug report"
  platformio_options:
    upload_speed: 921600

esp32:
  board: frogboard
  framework:
    type: arduino

logger:
api:
ota:
  - platform: esphome
safe_mode:
wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  ap:
    ssid: "Koelbox Hotspot"
    password: !secret wifi_fallback_ap_password
  power_save_mode: none
captive_portal:
preferences:
  flash_write_interval: 10min
web_server:
  port: 80
  local: true
  log: false
  version: 3

sensor:
  - platform: template
    name: Fake Temperature
    id: temp_inside
    unit_of_measurement: "°C"
    state_class: measurement

output:
  - id: fan_and_peltier_pwm_out
    platform: template
    type: float
    write_action:
      - logger.log: Fan speed changed

climate:
  - id: pid_climate
    platform: pid
    name: Koelbox Control
    sensor: temp_inside
    default_target_temperature: 15°C
    cool_output: fan_and_peltier_pwm_out
    control_parameters:
      kp: 0.56532
      ki: 0.002
      kd: 0.5
      output_averaging_samples: 5
      derivative_averaging_samples: 5
    visual:
      min_temperature: 5°C
      max_temperature: 20°C
      temperature_step:
        target_temperature: 1.0
        current_temperature: 0.1

button:
  - name: "Koelbox Setpoint 40°"
    platform: template
    on_press:
      - climate.control:
          id: pid_climate
          mode: COOL
          target_temperature: 40°C

Anything in the logs that might be useful for us?

The slider limits are configured in the Climate control's visual section, and thus are not hard limits to the allowed value. They are just meant as min/max for the slider interface. This makes me expect that I would be able to set any value in the numerical input. This isn't the case, though.

To give an example of how I'd expect it to work: Blender also has value sliders, with two bounds: a 'soft' bound for the slider, and a 'hard' bound for the values. This means that it's possible to make the slider work comfortably in the 5-20 °C range, while accepting any temperature when it's numerically entered. I think that's quite a nice UI, although I'm sure that implementing this is out of scope for this bug report ;-)

This bug report is really about this case:

• Press the custom button to set the set-point to 40°C.
• I want to lower the set-point to 20°C with the slider.
• Long-press the slider, the displayed value is already set to 20.
• Press Enter, expecting the set-point to go to 20°C, but it remains at 40°C.
• Long-press the slider again, change the value to 19.
• Long-press the slider again, change the value to 20.
• Now it's set to 20°C.

[sybrenstuvel]

In esphome/issues#6080 (comment) @ssieb wrote:

The visual settings are hard values for the interface. If you want to go past those limits, then change them. The only fix here would be to stop it from allowing values entered outside those limits.

I'm fine with those settings being hard values for the interface. However, if the interface doesn't allow going past 20°, and the actual value is 40°, reconfirming the 20° should IMO set the value back to 20°. It shouldn't leave it at 40°.

[RFDarter]

I'm fine with those settings being hard values for the interface. However, if the interface doesn't allow going past 20°, and the actual value is 40°, reconfirming the 20° should IMO set the value back to 20°. It shouldn't leave it at 40°.

I agree, I cant think of why it would not set it to 20°.

I think the real but is in the climate component. If there are min and max values set in the config you should not be able to set the target to a value out of bound.