Ha-paneld — make any in-wall Android panel a great dashboard for Home Assistant (free/open-source)

Share your Projects! Custom Integrations
1

Wall panels are great for Home Assistant — until you try to use the panel hardware. The performance probably sucks and you probably won't get access to the LEDs, sensors, buttons or proper screen control depends on which vendor made it, which model, even which firmware the seller happened to ship. Every panel ends up its own little project.

I got tired of that, so I built ha-paneld — a free, open-source Android app that gives one consistent, Home-Assistant-first integration across different in-wall Android panels. I also wanted a modern WebView installed with performance instrumentation without resorting to spam bloated 3rd party App installers.

config-ui
config-ui1600×2320 283 KB

You sideload it on the panel and it pairs itself with HA over MQTT auto-discovery — no YAML. It exposes:

  • disable vendor software with a clean launcher and navbar for HA Companion App
  • RGB LEDs, the physical buttons (as HA events), temp/humidity and other onboard sensors
  • screen brightness + true backlight-off (no keyguard/PIN), and TTS / announce audio
  • reload / reboot / navigate, plus a panel info + config web page

It is optimised to run as a background service alongside the official HA Companion app (which remains your dashboard) — so it's not a kiosk browser and not a paid per-device tool, just the panel-hardware bridge HA can't otherwise reach.

Documentation and performance is a focus too: it has on-device instrumentation (CPU/clock/thermal, a responsiveness metric, a WebView DevTools relay) to find what's actually making a dashboard lag on weak panel hardware, instead of guessing.

Supported today: Sonoff NSPanel Pro, Tuya TPA10, Shelly Wall Panel, Electron WF1589T, Smatek S9E, Zhivai SMT1019 — plus a Generic fallback that works for whatever a panel physically has. The architecture is modular and designed for contributors to extend progressive support for other panels.

It's all free and Apache-licensed; I just want these panels to be properly usable in HA for everyone. Got a panel that isn't supported? Open a GitHub issue with its /diag dump and we'll work it out — I'm UK-based and happy to help.

GitHub: maxlyth/ha-paneld — genuinely keen for feedback.

4 Likes
2

This project is growing much faster than I expected and I have already expanded custom support to Shelly Wall Displays and the some of the latest Android 14 class panels coming out China.

I have not forgotten the bedrock panels either and already have built PoC Thread mesh radio firmware for the Sonoff NSPanel Pro devices.

I realise the UI has exploded and is cluttered but this is still a pre-release project and a user-interface refactor is one of the goals for 0.9 ahead a v1.0 release later this summer.

Right now I am looking for firmware and diagnostics from other panels types to broaden coverage before freezing the requirements set.

If anyone has a panel that they want supported then please get in touch.

3

I'll try and give this a go over the weekend on my Rockchip 15.6" Android 12 wall tablet.

Should I disable the built-in MQTT function?

4

Hi! I got an 'EPOS Expand Control' . This is not really a panel... Seems to run a very locked Android unknown version. There's no USB port, POE ethernet only.
Is this something you can give a try?

5

You should not need the built-in MQTT functionality. My aim is to replace the capabilities of all vendor supplied apps/firmware (yes even cameras and intercoms are on the backlog) with a single unified and open-source product. If ha-paneld does not automatically recognise hardware features then raise an issue on the Github repo and I will take a look.

ha-paneld actually has a recent feature called "Tame" that is intended to seek out and disable vendor supplied cr*pware. I realise that vendors often remove the standard Android NavBar and Launcher to keep users within their own ecosystem so recent versions of ha-paneld have this capability built in so you don't need to install 3rd party launchers. All you need is ha-paneld and HA Companion App.

This product is still pre-release but I have worked hard to check that the installer script preflights every action so should never be detrimental to an otherwise working panel.

6

Theoretically ha-paneld should work on 'EPOS Expand Control' as it is an Android 10 device based on a Rockchip SoC (likely RK3399) so is well covered.

You may be able to install with F-Droid or enable network-ADB through the vendor software but given it is a sales terminal I would imagine it is heavily locked down as it is designed to run in a security sensitive workflow.

I checked the FCC filing and it does appear to have an internal USB connector and reveals it is a SOL-E-HP10S-GAL1LEO-V2-1.3" (Solaborate's "Galileo" RK3399)

From research I think the device is a centrally managed via Microsoft Teams Rooms on Android and unless you are the admin of that system the device is locked. You would need to unenroll the device from MTR and then look in Android settings for an option to enable Developer Options.

7

ha-paneld — a month of progress :rocket:

Since I first posted about ha-paneld here ~4 weeks ago, it's had eight releases (0.8.0 → 0.8.7). Big thanks to everyone testing and sending /diag dumps — a lot of this came straight from your reports.

(What it is: a free, open source Android agent that exposes wall-panel hardware — screen, LEDs, buttons, sensors, relays, audio — to Home Assistant over MQTT auto-discovery + mDNS, consistently across panels from different makers. It leaves the dashboard to the official HA Companion app.)

Reliability

  • MQTT that survives broker/HA restarts and network flaps — panels that used to sit unavailable until an app restart now self-heal in ~2–3 min, over whichever of IPv4/IPv6 actually holds.
  • A panel can never be left dark and dead — stale screen-off commands are ignored, a watchdog re-lights the screen, and touch-to-wake always works. The dashboard app is relaunched if it crashes.

Hardware

  • Full control on locked-down, no-root panels — screen, brightness, density, CPU governor, screenshots, LED and buttons all work via a small peer-authenticated root helper.
  • Broader support — profiles for Sonoff NSPanel Pro, Tuya TPA10, Electron WF1589T, ZHICAI SMT1019 and Smatek S9E (plus preliminary Shelly Wall Display), a soft on-screen nav bar for key-less panels, auto-brightness, and TPA10 room temp/humidity sensors.

Web UI, management & fleet

  • Redesigned :8888 web UI with a schema-driven config form and per-entity "expose to HA" toggles.
  • The Install tab is a software-management hub — update ha-paneld, the Companion and the WebView from the browser, with one-tap self-heal for the common blank-dashboard causes, plus encrypted backup/restore and live logs.
  • Fleet-first — zero-touch provisioning + one-command fleet updates, and 0.8.7 substantially hardened the install scripts (if you hit a provisioning snag, please report it!).

Security — LAN-only control surface, a screenshot-safe info page, a peer-authenticated helper socket, and CSRF/DNS-rebinding protection with HTTPS-only, signature-pinned updates.

Still a v0.x preview but it installs and uninstalls as an ordinary app — no firmware changes. Full notes in the CHANGELOG; code + releases on GitHub. More testers welcome, especially on panels not in my own fleet. :folded_hands:

8

Thanks.

I tried installing it using the curl command from Powershell on Windows 11 but it errored at the bash part.

9

There is no Windows Powershell installer. If you have ADB (Android Debug Bridge) installed (which is a documented pre-requisite) then you already have WSL (Windows Subsystem for Linux) which includes a true version of curl and bash.

Unfortunately Powershell has a an alias for curl that is not fully curl capable so it looks like it a bug in the script but is actually the entire WSL subsystem missing.

I have improved the documentation to make the pre-requisites clearer for Windows users.

10

Thanks. It would seem that I need to revisit the WSL installation which I thought had completed successfully.

ADB was just a case of unzipping some files, no installation per se.

11

No probs. I think I made some incorrect assumptions about ADB on Windows. As I said, I don’t have a single Windows install across my dozens of machines and I don’t know anyone who has one either so it’s a genuine hole in my testing.

I appreciate the feedback and if you find anything else substandard about the Windows experience then please don’t be afraid to call it out.

1 Like
12

Great work @maxlyth! ha-paneld solves exactly the right problem a clean, open-source, multi-vendor hardware abstraction layer for panel LEDs, buttons, sensors, and TTS. The mDNS auto-pairing and fleet provisioning approach is genuinely well thought out. I especially appreciate the performance-first mindset with WebSocket event firehose analysis and DevTools relay — that’s real-world thinking cheap panels actually need.

Building on that, I’d suggest a complementary piece. Your ha-paneld handles the panel hardware layer; knoop7/Ava (https://github.com/knoop7/Ava) extends it further as the backend service layer:

  • Zigbee + Bluetooth (BLE Proxy) gateway
  • Local voice assistant (Wake Word + STT/TTS, on-device, no cloud)
  • Music streaming protocol support (Snapcast, multi-room sync, audio-over-LAN)
  • Floating overlays & intercom
  • Powerful Mod system for custom optimizations
  • Tiny APK optimized for Rockchip PX30/rk3566/rk3576, Allwinner, and similar constrained SoCs

The idea: ha-paneld as front-end hardware agent, Ava as backend service layer. Together they cover the full panel stack from LED/button control to Zigbee mesh, BLE proxy, and local voice. Everything free, no subscription.

Would love to collaborate on making the two work seamlessly side-by-side!

1 Like
13

Those instructions were a synch to follow. I went with Git for Windows and using Git Bash rather than faffing around with WSL.

The app is now installed, thank you.

I’m seeing this error on the Dashboard:
image
however, there is a configured MQTT device in Home Assistant:

image
image865×360 21.1 KB

so I’m not sure if the error message is valid?

EDIT: the message was valid and I’m now connected to MQTT with all the controls and sensors.

14

Thanks for the support, I saw Ava early in ha-paneld development and that inspired me to build a PoC branch that used ESPHome protocol instead of MQTT. I switched back as there was no functional gain but it makes total sense for Ava as it is the protocol the HA Foundation has chosen for its preview voice products.

Your timing to chime-in is uncanny because one of the reasons I stuck promoting Home Assistant Companion App (HACA) was that it was not just a dashboard renderer but also, a wake-work activated, voice assistant. In ha-paneld 0.9.0, I will be releasing a preview of a built-in dashboard renderer as people are still drawn to Free/FullyKiosk, which I believe is a bad fit for the HA panel community.

I don’t intend to include voice assistant functionality any time soon so Ava is genuinely complimentary for users looking to not install HACA.

1 Like
15

I like the idea of managing the HA app installs via Ha-paneld but, since I had originally installed the HA app via the Play Store it didn’t seem to be able to manage an available update. I then uninstalled the HA app and Ha-paneld recognises that there is now no app and that there is a version that can be installed however the Install button is disabled:
image

16

The MQTT credentials error is a thread error because mqtt is a connectionless protocol a single transitional error does not get cleared immediately. I thought I had fixed this problem in 0.8.6 but it must still be there.

I will take another look at the issue but I think you can ignore the error if your MQTT connection is functioning

17

It’s OK. I edited my post a few minutes ago. I entered my MQTT credentials anyway and the additional switches/sensors all appeared so I believe the error message was correct.

18

This feature I wrote a while ago now and I remember I added logic to not stomp on Play Store installed versions of Companion App but did not consider if it was subsequently uninstalled. One of my panels is Play Store capable so I can test this.

The next release is a big one (0.9.0) and does not have a firm ship date. I know the dashboard renderer will not be perfect but I am trying to decide a point to preview it to users.

19

Mine has the Play Store but I read that, for security reasons, it’s best to log out of the Play Store on these types of panels which means the app doesn’t auto-update and it’s a pain for me to go and log into the Play Store to manage this.

I’m more than happy to test :+1:

I’ve opened an issue on your repository with the panel diagnostics since it appears to have a slightly different name/profile. Getting around the lack of su to enable me to turn the screen off would be amazing:

image
image425×451 14.5 KB

20

You are correct that, for panels with side-loaded apps, disconnecting from Play Store is good practice as your Google credentials are at risk, not just from my code but also panels, by definition, are in a public location and unlocked.

I worked as an cloud architect for many years so I am very security conscious, and that should be reflected in the ha-paneld code, but the process does run with escalated permissions and I can’t predict what happens to this project in the future.

At a minimum you should create a single purpose Google Play account that is used for panels. However it is very unlikely that vendors will release security patches to the core Android for these panels so there is little benefit to Google Play as ha-paneld does all the webview and dashboard app updates for you.

1 Like