LVGL's base obj is clickable by default (lv_obj_create sets
LV_OBJ_FLAG_CLICKABLE unconditionally). As full-screen, topmost siblings of
mode_toggle, temp_view and status_view were silently capturing every tap
over the toggle bar via lv_obj_hit_test before the touch search could reach
mode_toggle underneath, even though they have no on_click of their own.
Confirmed via generated C++ (lv_obj_remove_flag ... LV_OBJ_FLAG_CLICKABLE)
and hardware testing.
Root cause of 'only the cool/blue knob drags, regardless of where you
tap': LVGL's default arc hit-testing just uses each widget's full
bounding square (whichever topmost widget's box contains the touch
point wins), not the precise ring geometry. Since cool_arc's 360x360
box is entirely contained within heat_arc's 400x400 box, cool_arc (on
top in z-order) claimed every touch inside its own square, including
touches physically on heat_arc's outer ring, which sits outside
cool_arc's box but still within heat_arc's simple bounding-box test.
Confirmed via lv_arc.c: LVGL has a precise ring-based hit test
(LV_EVENT_HIT_TEST, respects each widget's own radius and angular
span) but it's opt-in via the ADV_HITTEST flag; without it, LVGL
falls back to the simple bounding-box test. Verified the adv_hittest:
true YAML property generates lv_obj_add_flag(..., LV_OBJ_FLAG_ADV_HITTEST)
via an isolated test compile before applying to both arcs.
The differing radii (400/360) from the previous fix are still useful
for visual separation but were never sufficient on their own — this
flag is what actually makes hit-testing respect the radius difference.
Root cause of the Home screen dial rendering tiny and pinned to the
top-left, confirmed via isolated test compile and direct inspection
of generated C++: an explicit main: sub-block on an LVGL arc widget
silently suppresses the implicit top-level MAIN-part style properties
(align, width, height, x, y) instead of merging with them. All three
arcs (dial_bg_arc, heat_arc, cool_arc) used a main: block for
arc_color/arc_width/arc_opa, which wiped out their align/width/height
in the exact same commit that set them (my earlier size/wrapper fix
never had a chance to take effect).
Verified via a standalone test config: an arc with main: nesting
generates zero lv_obj_set_style_width/height/align calls; the
identical arc with the same properties flattened to top-level
generates them correctly. indicator:/knob: are unaffected since those
are genuinely separate LVGL parts that require explicit nesting.
Two bugs found on first hardware test:
1. page_home placed all widgets directly on the page with no sized
wrapper container, unlike every other page in this codebase (which
all wrap content in an explicit width/height obj before using
align:). The dial and its siblings rendered tiny and pinned to the
top-left instead of filling/centering on the real 1024x600 screen.
Wrapped all of page_home's content in a width:100%/height:100% obj,
matching the established pattern.
2. heat_arc and cool_arc were both adjustable:true at the identical
400x400 size, so their rings occupied the same physical pixels.
LVGL hit-tests arcs by distance from center, so a shared radius is
touch-ambiguous, and the topmost widget (cool_arc, declared last)
won every touch regardless of where on the ring you tapped. Shrunk
cool_arc to 360x360 so the two rings are physically distinguishable
by touch position.
The dual-arc setpoint dial uses a Fahrenheit-range scale (60-90) to
match the Lennox reference UI, but climate.control expects Celsius
throughout this codebase. Dragging the dial was sending raw
Fahrenheit values straight into target_temperature_low/high, which
would have commanded wildly wrong setpoints on live hardware.
Also fixes a stale comment pointing at the wrong file after the
panel.yaml extraction.
Waveshare's board wires log output through the same UART USB-C port
used for flashing. ESPHome's default hardware_uart for ESP32-S3 is
USB_SERIAL_JTAG, which is a separate physical port on this board,
so log output was going nowhere the flashing tool could see it.
