Skip to content

Add Waveshare ESP32-S3-Touch-LCD-2 support - #1029

Draft
jantoney wants to merge 2 commits into
HASwitchPlate:masterfrom
jantoney:feat/waveshare-esp32-s3-touch-lcd-2
Draft

Add Waveshare ESP32-S3-Touch-LCD-2 support#1029
jantoney wants to merge 2 commits into
HASwitchPlate:masterfrom
jantoney:feat/waveshare-esp32-s3-touch-lcd-2

Conversation

@jantoney

@jantoney jantoney commented Jul 19, 2026

Copy link
Copy Markdown

Summary

  • add a public waveshare-esp32-s3-touch-lcd-2 environment for the 16 MB flash / 8 MB PSRAM Waveshare SKU 29667
  • configure its ST7789 display, CST816 touch controller through LovyanGFX, active-high PWM backlight, and native USB
  • add the environment to the Waveshare CI artifact group
  • add an optional native idle touch lock with configurable inactivity, hold duration, and locked-screen timeout through config/gui

Why

The board could not be represented reliably by the existing standalone CST816 path because LovyanGFX already owns the touch controller for this display integration. Selecting the LovyanGFX touch adapter avoids competing controller instances and provides working coordinates and release events on the physical board.

The idle lock prevents accidental controls while retaining a deliberate hold-to-unlock gesture. The unlocking release is consumed, so it cannot activate the control underneath it.

Validation

  • pio run -e waveshare-esp32-s3-touch-lcd-2
  • pio run -e cyd-2424s012_4MB (representative CST816/LovyanGFX regression build)
  • physical SKU 29667 validation: display orientation and colors, full-screen redraws, touch coordinates and releases, 10/50/100% PWM backlight, native USB/BOOT recovery, Wi-Fi, MQTT, web UI, Home Assistant controls, filesystem persistence, and idle-lock behavior

Documentation PR: HASwitchPlate/openHASP-docs#54

@fvanroie

Copy link
Copy Markdown
Collaborator

Thanks for creating this PR.

I think the Waveshare support and the idle lock feature should be separated. The hardware changes are clear and testable, but the idle lock introduces a new global interaction model and a second touch-handling path.

Before adding a separate idle/touch state machine, I'd like to understand what limitation in the existing wakeup_touch / first_touch_event_handler mechanism requires this approach. If the current implementation cannot handle this hardware or use case, I think we should first identify that as a bug or extension point and fix/extend the existing mechanism rather than introducing a parallel idle system.

The idle lock feature may still be useful, but I think it deserves its own discussion and review because it affects user interaction across all devices, not just this Waveshare target.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants