Honor target_range in number min/max; fix Frizzlife LP365P volume scaling#5324
Honor target_range in number min/max; fix Frizzlife LP365P volume scaling#5324nalditopr wants to merge 3 commits into
Conversation
DpsConfig.range() applied scale but ignored target_range, so a number entity whose displayed value comes from a target_range remap reported its min/max in raw dps units. The slider then shows raw units, and values outside the raw range are rejected by core before the target_range write conversion runs. Return the target_range bounds when one is configured.
The allowed flow volume is offset-encoded by the firmware (gallons = raw * 20 + 20, raw 0-64 <-> 20-1300 gal). The previous mapping used scale 0.01 with a raw-0 -> 50 special case, which mis-read (about 900 for a real 200 gal) and could not be written. Use a target_range remap with the correct 20-1300 gal range.
|
Root cause of the volume write failure isolated on a live LP365P: it is the |
…rect) Routing the volume value through value_redirect (mode4/5/6 -> modeN_val) does not apply the leaf target_range on write, so sets never reached the device (verified: redirect write left dp115 unchanged, direct write of the same value lands correctly). Bind the value directly to dp115 with the target_range remap so it reads and writes in gallons. This tracks the Mode 4 register; auto-following the active advanced mode would require the value_redirect write path to apply the redirected dp's target_range.
| - dps_val: us_units | ||
| value: gal | ||
| - value: L | ||
| - id: 111 |
There was a problem hiding this comment.
The problem with simplifying this is it will now only work in one mode.
Did you try putting the target_range in each mapping here where it will be picked up by the logic to report the min and max to HA, as well as on the target dp of the value_redirect to use when calculating actual changes?
When range is called for determining the HA side range, we should use target_range instead when available. PR #5324 by @nalditopr
2 participants
Fixes #5323
What
DpsConfig.range()now honorstarget_range. Anumber'snative_min_value/native_max_valuecome fromrange(), which appliedscalebut ignoredtarget_range, so numbers with atarget_rangeremapexposed their bounds in raw dps units. That made sliders show raw units
(e.g. a 0.01–0.1 min-flow showing 0–9) and rejected values outside the raw
range before the
target_rangeconversion could run.range()now returnsthe
target_rangebounds when configured (guarded byscaled; the writepath reads the raw range from config directly, so it is unaffected).
Frizzlife LP365P "Allowed flow volume" fixed (scale + writability).
The firmware offset-encodes this value:
gallons = raw*20 + 20(raw
0–64⇄20–1300gal). The old mapping usedscale: 0.01plus a{dps_val: 0, value: 50}special case, which mis-read (~900 for a real200 gal). It also routed the value through
value_redirect(mode4/5/6 → modeN_val), which does not apply the leaf
target_rangeon write — so sets never reached the device. Replaced with a direct
target_rangemapping on the value DP.Verified on a live LP365P (protocol 3.5)
(raw 0/7/9/64 ⇄ 20/160/200/1300 gal). ✅
raw 9, confirmed by direct device read. ✅ (Through
value_redirectthesame set left dp115 unchanged; direct binding fixes it.)
Note on multi-mode
The direct mapping tracks the Mode 4 register (dp115). The previous
value_redirectform auto-followed the active advanced mode but wasnon-writable for this offset encoding. If preserving auto-follow is
preferred, the
value_redirectwrite path would need to apply theredirected dp's
target_range(it currently honorsscalebut nottarget_range); happy to take it that direction instead.