u/Delannoytheo

A short follow-up to my recent Portal Launcher update.

The response to the project has been much bigger than I expected. People are now testing it on Meta Portals, Echo Shows running LineageOS, regular Android tablets and custom wall panels. The comments have brought bug reports, hardware feedback, translation corrections and some genuinely good feature ideas.

Reddit comments are becoming difficult to follow, especially when a discussion involves screenshots, logs or several rounds of testing, so Portal Launcher now has a Discord server:

Discord: https://discord.gg/WgZQJ4FHj

The server has dedicated spaces for:

- installation and configuration help
- Home Assistant, MQTT and Immich
- compatibility reports for different devices
- photos and videos of your setups
- feature requests and rough UI sketches
- development and pull requests
- English and French translations
- beta builds and focused testing.

GitHub will remain the source of truth for code, confirmed bugs and pull requests. Reddit is still great for public updates and discovering the project. Discord is simply a better place for the conversations that happen in between.

Portal Launcher started as something I made for one abandoned Meta Portal. It has since become a complete Android launcher designed for calm smart displays, from compact Echo Shows to larger wall panels. A lot of that progress came directly from people testing it on hardware I don’t own and explaining what did or didn’t work.

I’m also not particularly experienced at running an online community, and English isn’t my native language, so the server will probably evolve as we learn what is actually useful. Suggestions and corrections are welcome.

If you’re using Portal Launcher, considering trying it, contributing code, helping with translations, or simply experimenting with repurposed Android displays, you’re welcome to join.

Discord: https://discord.gg/WgZQJ4FHj

GitHub: https://github.com/iblur01/portal-launcher

Latest release: https://github.com/iblur01/portal-launcher/releases/latest

Thanks again to everyone who has tested it, forked it, contributed or taken the time to share detailed feedback. This project would still be designed around the single Portal on my desk without you.

Théo :)

Sixteen days ago I posted the first version of Portal Launcher here. At the time, I was honest about its limits: it was French-only, designed almost entirely around my own 10-inch Portal, rough to configure, and barely tested outside that one device.

A lot has changed since then.

The post reached more than 11,000 views, people forked the project, tested it on other hardware and sent the first outside contributions. Thank you to everyone who took an early beta seriously enough to try it, especially adroidian for contributing code rather than just reporting what was wrong.

The most important change is that it is now a complete Android launcher, rather than a Home Assistant screen that happens to open when you tap it.

Portal Launcher takes the real Home role. From the clock you can move to a normal application grid, launch any installed app, place and resize Android widgets, create folders, use app shortcuts, hide or rearrange applications, and apply third-party icon packs. Home Assistant is one native page of the launcher, not the only thing the device is allowed to do. You can keep the calm clock as the default view, control the important things directly, open your full Lovelace dashboard when you want it, or use any other Android app installed on the Portal.

It is also no longer tied to one screen size. I now use it on both my Meta Portal and a 5-inch Echo Show running LineageOS. The same interface adapts from the short Echo display to larger 10-inch panels, and the layouts are designed to keep scaling on 12-inch devices as well.

On compact screens, control panels open full-screen instead of being squeezed into one side. The alarm keypad, media controls, volume page, weather forecast, clock and Home Assistant pills all resize from the space actually available. Less important information disappears before the controls you need do.

The other large piece of work was setup.

The old basic configuration has become a guided onboarding flow for launcher permissions, layout, backgrounds and the optional Home Assistant integration. On a large Portal it uses a wider composition; on a short display it presents one decision at a time.

You also no longer need to type a Home Assistant URL and long-lived token on the Portal keyboard. The launcher can display a temporary QR code, let you complete the configuration from a phone on the same network, then test the connection on the panel. The local server stops when you leave the setup screen and old QR codes stop working.

Since the original post:

- The whole interface is available in English and French.

- Portal Launcher now has a real Home Assistant page with favourites, custom groups, and organisation by room or entity type.

- The HA controls cover more entity types and adapt to each device's capabilities.

- Weather, media, thermostats, lights, covers, locks and alarms have been reworked for both compact and large displays.

- Backgrounds can use the Android wallpaper, a calm offline background, a local photo, or an Immich album.

- The launcher grid now includes free app placement, folders, resizable widgets, app shortcuts, hidden applications, third-party icon packs, notification dots and layout backup/restore.

- A rooted Portal can grant the launcher role and required system permissions automatically from the onboarding flow.

- Home Assistant state updates no longer redraw the entire launcher. On the small test device, updates that previously took roughly 122-145 ms now fit within one frame.

- Controls respond immediately while waiting for Home Assistant to confirm the command, so the interface feels much less remote from the thing it controls.

I also fixed a pile of less exciting problems: taps passing through panels, stale unavailable values, cramped temperature labels, media controls losing space to metadata, excessive image memory use, and several onboarding screens that looked fine on a Portal but fell apart on a shorter display.

One correction from my first post: this is still sideloaded and currently built through Gradle. It is not in an app store yet. The latest tagged release is 0.0.7-beta, while the responsive small-screen work and the new setup flow are part of the next release currently being prepared.

I still see Portal Launcher as a complement to Lovelace, VACA, Kiosk Satellite and the other projects people mentioned last time, not a replacement for all of them. Its job is to make the entire device useful: a quiet clock when the room is idle, a few useful states when you glance at it, native controls when you need them, and a real Android home screen for everything else. Home Assistant and every installed app remain one tap away.

It is still a solo project and it is not finished, but it is considerably more stable and coherent than the version I posted here two weeks ago. More importantly, it is no longer designed around only the Portal sitting on my desk.

Github: https://github.com/iblur01/portal-launcher
Original post : https://www.reddit.com/r/FacebookPortal/s/w0rERZcly2

If you have a Portal, Portal+, Portal Mini or other unusual Android display, photos and bug reports are still extremely useful. I would particularly like to see how the next build behaves on Portal models I cannot test myself.

Théo :)

A couple of weeks ago, I shared Portal Launcher here for the first time.

I expected a few curious people. Instead, the post reached nearly 50,000 views, people started testing it on hardware I don't own, several of you forked the project, and I received the first outside contributions.

Thank you. Seriously.

The first release was built almost entirely around my 10-inch Meta Portal. It worked well there, but some of you quickly discovered what happened on smaller displays: cramped panels, awkward spacing, controls pushed off-screen, and layouts that technically "scaled" without actually feeling designed for the device.

That feedback changed the direction of the project.

Portal Launcher now runs properly on small landscape displays such as an Echo Show 5 running LineageOS, while still making good use of larger 10-inch and 12-inch panels. Panels decide their layout from the space they actually receive. On compact displays they become full-screen, controls resize with the available height, and secondary information gets out of the way before the important controls do.

The clock, Home Assistant pills, weather, media controls, alarm keypad and temperature displays have all been reworked specifically for these smaller screens.

Setup also needed much more attention. The old configuration flow has been replaced with a proper onboarding experience that adapts to the display. On a large panel, it uses the available space. On a small one, it keeps each screen focused on a single decision.

Typing a long Home Assistant token on a five-inch wall display is still a terrible idea, so setup can now be completed from a phone. The panel displays a QR code, you enter the Home Assistant and MQTT details from your phone's browser, and the panel receives the configuration locally. Nothing is sent to an external service.

A few other things that have changed since the first post:

- The interface is now available in English and French.

- The Home Assistant page can be organised by room or by entity type, with favourites and custom groups.

- More HA domains have dedicated controls, including doors, motion sensors, humidifiers, water heaters, valves, sirens, lawn mowers, washing machines and generic entities.

- Media and weather panels now have layouts made for compact screens.

- Backgrounds can use the Android wallpaper, a quiet offline background, a local photo, or albums from Immich.

- The launcher now supports folders, third-party icon packs, notification dots, widgets and layout backup/restore.

- Rooted panels can grant the required system permissions automatically.

- Home Assistant updates no longer cause the whole interface to redraw. On my smaller test device, state updates that previously took around 122-145 ms now fit within a single frame.

- Controls update immediately while waiting for Home Assistant to confirm the action, which makes lights, locks, covers and media feel much more responsive.

There are also many less visible fixes: taps no longer pass through closing panels, unavailable sensor values disappear cleanly, images use bounded caches, and the app now ships with a baseline profile for faster startup.

I especially want to thank adroidian for the first external contributions, everyone who forked the repository, and everyone who installed an admittedly rough early beta and reported what broke on their hardware. That feedback has been much more useful than designing around a single Portal on my desk.

I won't call it finished. There are still devices and edge cases I haven't seen. But it no longer feels like a 0.0.1 experiment built around one abandoned screen. It is becoming the launcher I originally wanted: quiet when nothing matters, useful when something does, and comfortable on the hardware people actually have.

If you tried an early version and bounced off the scaling, translations or setup process, this is probably the right time to give it another look.

GitHub: https://github.com/iblur01/portal-launcher

Original post : https://www.reddit.com/r/homeassistant/comments/1valzqd/portal_launcher_turns_any_android_wall_panel_into/

And if you're running it on unusual hardware, I still want to see it. Photos, bug reports and PRs are all welcome.

Théo :)

This started with a Meta Portal that Meta abandoned and, in the process, left wide open on ADB. So I had this well-built 10" touchscreen with decent speakers and a camera, running software that talks to a service nobody uses anymore. Obvious move: put Home Assistant on it.

I tried the straightforward path first — companion app, full-screen. It worked. It also looked exactly like what it was: a phone app, stretched onto a wall, lit up at full brightness at 2am, a scrolling column of identical cards whether you needed to see any of them or not. Functional. Not something I wanted sitting in my living room.

What I actually wanted was the feeling of a Nest Hub or an Echo Show — the idle screen is dark, still, almost nothing on it, and yet the one thing you glance at is always right there. So I stopped treating this as "get HA on a screen" and started treating it as a design problem: what does an appliance that happens to run Android actually look like at rest, and what happens the moment you look at it?

The rest state is close to nothing. Full-screen clock, true black on OLED, your own wallpaper underneath at whatever opacity keeps it legible. No card grid. No graphs. If nothing needs attention, the screen shows you nothing needs attention — which is itself the information.

What surfaces is computed, not configured. Below the clock there's room for at most three small pills. Which three, and in what order, is decided live: an unlocked front door or a triggered alarm will always outrank the living room lamp, automatically, no matter how you've set anything up. You only ever see what's actually worth seeing right now.

Every control looks like the thing it controls, which is the one idea I took wholesale from Apple Home and never wanted to compromise on. A brightness slider fills with the bulb's actual current color — it doesn't just move a knob, it visually is the light. A color-temperature slider is drawn as the literal Kelvin gradient. A thermostat is a dial with two handles you drag around a ring, not a stepper with plus/minus buttons. Nothing is a generic Material row with a value next to it.

Motion is one spring, everywhere. Panels slide in over roughly a third to half the screen depending on orientation, and settle with the same damping curve every single control panel uses.

No bounce, no popping in, no different animation per screen. If it moves, it moves the same way the rest of the app does.

Frosted surfaces, not flat cards. Translucent panels over the blurred wallpaper wherever a panel needs to sit, wide soft corners (28–40dp), no gradients competing for attention. On API 28–30 hardware there's no real-time Gaussian blur available in Compose, so those surfaces fall back to translucent fills — close enough that most people don't notice, but it's a real constraint I had to design around rather than ignore.

Once the visual language existed, everything else followed the same rule: is this the calmest possible way to show this, or did I just default to a dashboard pattern because it's the one every HA project uses. Real control panels for lights, thermostats, locks, covers, alarm (an actual keypad, not a dropdown), vacuum, media with cover art and multi-room grouping. A presence tray of overlapping avatars instead of a list. Camera snapshots that pop up on a doorbell trigger and quietly go away.

Underneath, it talks to HA over the WebSocket API and publishes the device's own sensors back over MQTT with HA MQTT Discovery, so the panel itself shows up as a device — screen state, brightness, presence, ambient light and sound. None of that is visible in the UI though; it's plumbing, not the point.

And because the visual side ended up being the actual hard problem, not "make it run on a Portal," it stopped making sense to keep this tied to one device. It's a real Android launcher now — takes the home role properly, has its own pages, lets you place icons and widgets exactly where you want them, does app shortcuts on long-press, all of it — and it runs on anything Android 9 and up: the Portal it started on, a generic wall tablet, a PoE tablet on custom AOSP. The clock-first idle screen is just what its home page looks like.

https://github.com/iblur01/portal-launcher.

I'm actively looking for help. It's a solo project so far and there's a real roadmap behind it — a portrait/adaptive layout, broader entity support (input_*, number, select), more device testing beyond my own hardware, and honestly the single highest-impact thing anyone could do right now: the UI is entirely French, close to 600 hardcoded strings, and i18n hasn't happened yet. PRs welcome, issues welcome, "this looks broken on my tablet" reports welcome.

Since ADB opened up, most of us landed on Immortal + the HA companion app. That works, and Immortal is what made my Portal useful in the first place — the presence/screen-off approach in this project is directly lifted from it.

But the companion app is a phone app on a wall. It's a scrolling page of cards, three feet away, lit up at 2am. I wanted something that behaves like an appliance instead: dark and still when nobody's near it, one tap deep when you walk up to it.

So this replaces the stock launcher entirely. The Portal boots into a full-screen clock over your own wallpaper. Walk up, tap, and you get a row of controls ranked by what actually matters right now — an unlocked door outranks the living room lamp, automatically. Tap one and a panel slides in over half the screen.

It talks to Home Assistant directly over the WebSocket API, and publishes the Portal's own sensors back over MQTT, so the device shows up in HA as a device with a screen switch, brightness, presence, ambient light and sound level.

Screenshots and the whole thing here: https://github.com/iblur01/portal-launcher.git

What it does

- Clock screensaver, your wallpaper, adjustable scrim, 10 bundled fonts if you want to restyle it
- Live control for lights (brightness, colour temp, colour wheel, grouped by HA area), locks, covers, thermostats, alarm (real keypad), vacuums, media, switches, fans
- Media panel with cover art and multi-room grouping
- Camera snapshot popup on a doorbell or motion trigger
- Presence, energy gauge, air quality, scenes, weather with forecast
- Browser-based config on your LAN so you're not typing an HA token on a 10" touch keyboard
- Presence inferred from the Portal's own dream/sleep lifecycle, so the screen sleeps when the room is empty and no special permissions are needed

Two things that took embarrassingly long

The Portal's doze kills the HA WebSocket without firing any callback. The socket stays open, state stops flowing, and every reading on screen silently freezes on last-known values — the lock read "unlocked" for hours while the door was actually locked. Fixed with a watchdog: ping every 30s, force-reconnect after 75s of silence.

Before that, an even dumber one: HA requires WebSocket message ids to strictly increase per connection. I sent `subscribe_events` with an id lower than an earlier call, HA rejected it with `id_reuse`, and I got exactly zero state updates while the connection looked perfectly healthy.

If you're building something similar, those two will cost you a weekend each.

What it doesn't do

- The UI is French-only. All ~590 strings are hardcoded. It's the single most useful thing anyone could contribute.
- Landscape 10" only. No portrait layout yet.
- No prebuilt APK — you build it with Gradle and `adb install`. I'd like to fix that.
- I've only tested it on my own hardware. If you run a different Portal model I'd genuinely like to know what breaks.
- No `input_*` / `number` / `select` entities yet.

MIT. Built on Immortal's presence model and portal-ha-bridge's MQTT patterns — both credited in the README