OpenHASP
Open hardware and software for touchscreen controls
openHASP is open-source firmware that turns inexpensive ESP32 touchscreens into smart home control panels. It renders customizable UI pages controlled over MQTT by automation platforms.
Key features
- Touchscreen control panels
- MQTT-driven UI pages
- Runs on cheap ESP32 displays
- Customizable layouts
Pros & cons
Strengths
- Affordable wall panels
- Fully local
Trade-offs
- Requires hardware tinkering
- UI design is manual
OpenHASP replaces
Last reviewed Sep 13, 2026 · 853 words
A working openHASP wall panel costs about $15 to $25 in hardware: one of the cheap ESP32 boards with a 2.8 to 4 inch touchscreen, a USB cable, and 20 minutes with the browser-based flasher on openhasp.com. After that the panel shows buttons, sliders and status text that you defined in a text file, and every tap is an MQTT message your automation platform reacts to. Nothing talks to the cloud, nothing needs a browser, and the panel keeps working when your Wi-Fi is up but your internet is not. The trade is that you design every screen by hand.
Pick hardware that the project has already made work
openHASP is firmware, so the first question is which board. The community has converged on a few: the Sunton ESP32-2432S028 family (often sold as the "cheap yellow display"), the WT32-SC01 and its Plus variant with a larger 3.5 inch screen, the Guition 4-inch square boards, and the Lanbon L8, which is a proper in-wall switch with a touchscreen and relays behind it. The project publishes build variants per board because the display driver, touch controller and pin layout differ; buy one from the supported list and skip the pleasure of writing your own board config.
Sixteen megabytes of RAM in the catalogue is a reminder that this is an ESP32, not a server. It renders a UI with the LVGL graphics library, and the limit that bites is screen complexity: large fonts, many pages and images push it. Keep to a handful of pages with a dozen objects each and it is smooth.
Flash from the browser, configure from the device
Flashing uses ESP Web Tools from Chrome or Edge over USB, no toolchain. The device then boots into an access point, you enter your Wi-Fi credentials, and it comes up with its own small web interface for MQTT settings, file uploads and a live screenshot of what it is displaying. That web page is where pages.jsonl lives, the file that defines your interface.
MQTT is the only integration path, and the natural broker is Mosquitto next to Home Assistant. The device publishes to hasp/<nodename>/state/... topics on every interaction and listens on the matching command topic for updates. Any platform that speaks MQTT can drive it; the home automation category is full of them, but the Home Assistant custom component (installed through HACS) is the one the maintainers actually use, and it maps panel objects to entities with far less YAML than doing it by hand.
The UI is a JSONL file, and that is the whole job
Each line of pages.jsonl is one object: a page number, an object type (button, label, switch, slider, arc, dropdown, image), coordinates, size, and text. A thermostat page is five or six lines. The catalogue's "UI design is manual" con is accurate: there is no drag-and-drop editor, and you iterate by editing text, uploading, and watching the screenshot. Get the coordinates wrong and things overlap.
Two habits make it bearable. Keep a single theme (font sizes, colours) in the device settings rather than per object, and put logic in Home Assistant, not on the panel. The panel should display state and emit taps; deciding what a tap means belongs to your automations. That keeps pages.jsonl short and lets you redesign without touching the automation side.
Where it stops
openHASP is a control surface, not a dashboard tablet. If what you want on the wall is your full Home Assistant dashboard with cameras and graphs, that job belongs to an old Android tablet running WallPanel, with the trade of needing a browser, a charger and a bigger hole. If you would rather define the screen in YAML with sensors and automations on the device itself, ESPHome now has its own LVGL display support on the same boards, integrates natively with Home Assistant without MQTT, and is the bigger project by a wide margin. openHASP's advantage is that it was designed for this one purpose from the start, and its page-and-object model is faster to get to a clean multi-page control panel.
It competes most directly with Nextion HMI displays, and wins on price and openness: a Nextion needs a separate microcontroller and its proprietary editor, whereas an openHASP board is the whole device for a third of the cost.
What I'd do
Buy one WT32-SC01 Plus or a 4-inch Guition board before committing to a house full of them, flash it from the browser, and build one page: lights for the room it sits in, a thermostat, a status line. Run it against Mosquitto with the Home Assistant custom component. If after a week you find the JSONL editing fine, order the rest and 3D-print or buy the wall mounts. If you find it tedious, switch the same hardware to ESPHome's LVGL support and keep the panels. Either way the boards are cheap enough that the experiment costs less than dinner.
Similar home automation apps
Home Assistant
Home AutomationOpen-source home automation that puts privacy first
Replaces SmartThings, Google Home
Frigate
Home AutomationLocal NVR with real-time AI object detection
Replaces Google Home
ntfy
Home AutomationSend push notifications to your phone via simple HTTP
Replaces Pushover, Pushbullet
Homebridge
Home AutomationBring non-HomeKit smart devices into Apple Home
Replaces Apple HomeKit hubs
Tasmota
Home AutomationOpen-source firmware for ESP-based smart devices
Replaces Tuya Cloud
ThingsBoard
Home AutomationOpen-source IoT platform for device management and data
Replaces AWS IoT, Azure IoT