# Prism Desktop puts a Home Assistant dashboard in your system tray > Prism Desktop is a Python and PyQt6 client for Home Assistant's WebSocket API that runs on Windows, Linux and macOS, with drag and drop tiles, morphing controls, desktop notifications, global keyboard shortcuts and an optional beta Assist panel. It is MIT licensed and packaged as installers, an AppImage, a dmg or a Nix flake. **lasselian/prism-desktop** — A customizable desktop dashboard for Home Assistant. - Repository: https://github.com/lasselian/prism-desktop - Stars: 537 · Forks: 48 - Language: Python - License: MIT - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/lasselian-prism-desktop ## What it is: a tray-resident client, not a browser tab Prism Desktop is described as a lightweight Home Assistant client for Windows, Linux and macOS. It lives in your system tray and gives you instant access to your smart home, lights, thermostats, cameras, sensors and more, without opening a browser. The mechanism underneath is stated plainly: it is built on Home Assistant's WebSocket API, and it keeps your dashboard in real-time sync with your home. Control entities, trigger automations, and receive PC notifications, all from a customizable dashboard. The README frames the audience explicitly, calling it perfect for Home Assistant users who want a native desktop experience on Windows, Linux or macOS instead of a browser tab. That framing sets the boundary clearly. This is not a Home Assistant frontend replacement, and it is not a remote access solution. It is a panel on your desktop for the entities you actually toggle often. The application is Python, with PyQt6 for the interface and pystray for the tray. The dependency list in requirements.txt shows the rest of the stack: aiohttp for the WebSocket connection, qasync for the asyncio and Qt event loop integration, Pillow for images, requests and certifi for HTTP, cryptography and keyring for secret storage, pynput for global keyboard shortcuts, psutil for process information, and platform-specific packages for Windows toast notifications and Linux secret storage and D-Bus. The win11toast and winrt packages carry the marker sys_platform == 'win32' and winrt-Windows.Devices.Geolocation brings in location services for Windows, which suggests the app can do something location-aware on that platform. The repository layout is a plain Python application: main.py at the root, a core/ directory, a services/ directory, a ui/ directory, translations/ for localisation, three build scripts for the three platforms, setup.iss for the Windows installer, and a flake.nix with a flake.lock for Nix users. ## The feature set is mostly about how you interact The feature list is short and each item is a different kind of interaction, so it is worth taking them one at a time. System Tray Integration is the foundation: the app lives in your tray until you need it and never gets in your way. PC Notifications receive Home Assistant alerts directly as desktop notifications. Morphing Controls are the most distinctive idea. Click and hold a widget and it expands into granular controls, like dimmers or thermostats, rather than being a fixed tile with a single on and off. Drag & Drop Dashboard lets you rearrange tiles freely around the grid, and Resizable Dashboard lets you adjust the dashboard size to fit your screen and workflow. Customizable Appearance covers border effects, with Rainbow and Aurora named as examples, plus custom button colors. Keyboard Shortcuts bind global shortcuts to toggle the app or trigger individual entities. Then there is Assist (beta), which lets you talk or type to Home Assistant's Assist pipeline from the dashboard. It is off by default and you turn it on under Settings to Assist (Beta). The fact that it is labelled beta and buried behind a setting rather than being a headline feature is a fair signal about how far along it is. The Adjustable Grid and Widget Overlays sections are each demonstrated with an animated GIF rather than described in prose, which is a hint that the layout behaviour is visual and easier to see than to explain. The Supported Entity Types table is the practical list of what you can put on the dashboard. Lighting and Power covers Light and Switch. Climate covers Climate and Fan. Media is Media Controller. Covers is Curtain or Cover. Outdoor is Lawn Mower and Vacuum. Monitoring is Sensor, Sun, Weather and Camera. Automation is Automation, Scene and Script. There is also a dedicated 3D Printer Tile, with a live camera feed, nozzle temperature and target, bed temperature and target, and print state, which is the kind of specific entity support that suggests the author builds this for their own home. ## Installing on each platform, and the awkward bits The installation section is organised per platform, and each has one step that is a nuisance. On Windows you download the latest PrismDesktopSetup.exe from the releases page, and the installer sets up the app and optionally configures it to start with Windows. If you prefer not to install anything, there is a standalone .exe that runs portably and stores its config in the same directory. On Linux you download the .AppImage, and then: ```bash chmod +x PrismDesktop-x86_64.AppImage ./PrismDesktop-x86_64.AppImage ``` The nuisance there is FUSE. Ubuntu 22.04 and newer requires libfuse2, and the fix is the command `sudo apt install libfuse2`. The desktop environment matters more on Linux than on the other platforms, and the README is specific about it. On GNOME you install AppIndicator and KStatusNotifierItem Support via the Extension Manager for system tray support, and Wayland users bind a custom shortcut in system settings to toggle the app, which runs `/path/to/PrismDesktop-x86_64.AppImage --toggle`. Per-entity shortcuts are not supported on GNOME Wayland. On KDE the system tray works out of the box, the app-toggle shortcut is supported through org.freedesktop.portal.GlobalShortcuts, and per-entity shortcuts are not supported on KDE either. So on Linux the global app toggle is the reliable path, and the per-entity shortcuts that the feature list advertises are a Windows and macOS story. macOS has a .dmg or .zip, with separate builds for Apple Silicon covering the M1 through M4 and for Intel Macs. You drag PrismDesktop.app into /Applications, and then the first launch shows a Gatekeeper notice, because the open-source build is distributed without a paid Apple Developer certificate. The README gives two ways through it, a terminal command `xattr -cr /Applications/PrismDesktop.app` or right-clicking the app, selecting Open, and clicking Open in the dialog. The certificate costs $99 a year, and the notice is the price of not having one. Nix users have two one-liners, either running it without installing: ```bash nix run github:lasselian/prism-desktop ``` or adding it to a profile: ```bash nix profile add github:lasselian/prism-desktop#default ``` ## The macOS token storage is a deliberate trade, and it is worth understanding One paragraph in the macOS section is the most interesting security content in the README, and it concerns where your Home Assistant long-lived access token lives. The reasoning is technical. Because the builds are ad-hoc signed, with no paid Apple Developer certificate, the macOS Keychain is not used. The stated reason is that the app's code signature changes with every update, which would otherwise trigger repeated Keychain password prompts. That is a real and well known problem with ad-hoc signed macOS builds. The Keychain ties saved credentials to the signing identity, and when the signature changes on every build, the user gets a prompt every time the app launches. For a background tray application that starts with the machine, that would be intolerable. The alternative used instead is an encrypted file keyed to this Mac's hardware UUID. The README states what that buys and what it costs: it protects the token at rest, but is weaker than the Keychain, because other software running under your user account could potentially recover it. That is a correct and fairly candid statement of the trade. The token is not in plaintext on disk, but the key is derived from a hardware identifier rather than being protected by the OS credential store, so anything running as your user is a candidate for reading it. The rest of the platform is different, and the requirements file shows it. keyring is required on every platform except darwin, secretstorage is required on Linux, and cryptography at version 41.0.0 or newer is in the base list. So on Windows and Linux the token goes through the platform's own credential store via keyring, and only on macOS does the app roll its own. For a Home Assistant token, which grants control of your entire home, that asymmetry is the thing to check before you install. If you run macOS and you are comfortable with the token sitting in a hardware-keyed encrypted file, the convenience of not being prompted on every update is worth it. If you are not, the alternative is a platform where the Keychain is used. The other macOS permission to grant is Accessibility, for global shortcuts. You open System Settings to Privacy and Security to Accessibility, click the plus button and add PrismDesktop or toggle its switch on. That is the OS's own gate on reading keyboard input globally, and the app asks for it because a global shortcut requires it. ## Global shortcuts, and where the desktop environment gets in the way The Keyboard Shortcuts section is short but it defines what the feature actually does. There are two kinds. The App Toggle is a global shortcut set in Settings to App toggle, which shows or hides the window from anywhere, so the app can live in the tray and still be summoned with one key. The Entity Shortcuts are custom shortcuts assigned to any button tile through the Add and Edit menu, so a specific light or switch can be toggled directly. Both sound simple, and on Windows and macOS they are. On Linux they run into the desktop environment's own model of global keys, and the README is honest about the boundaries. The mechanism on GNOME Wayland is a custom shortcut bound in system settings that runs the application with a --toggle argument. The AppImage invocation shows exactly that: That is the whole integration. There is no daemon and no X11 key grab; the desktop environment owns the shortcut and calls the application when it fires. The cost is that GNOME Wayland does not support per-entity shortcuts. The README states that plainly. On KDE the app-toggle shortcut is supported through org.freedesktop.portal.GlobalShortcuts, which is the freedesktop portal for global shortcuts, and again per-entity shortcuts are not supported. So the advertised capability of binding global shortcuts to individual entities is, on the two most common Linux desktops, limited to the app toggle. Per-entity shortcuts are Windows and macOS behaviour. Anyone buying this app for its keyboard-first workflow on Linux should know that before they install it, because the workflow is the point of the feature rather than an extra. The pynput dependency in requirements.txt is the library behind the global key handling, and on the macOS side it needs the Accessibility permission for the same reason a global shortcut needs it on any platform: the OS must allow the process to observe input outside your app's own window. The Windows side has the additional win11toast dependency, which is how the PC Notifications feature is implemented there, since Windows desktop notifications need a native toast API rather than something cross platform. ## Where a desktop client stops and the frontend takes over The first limit is scope. Prism Desktop is a customizable tile dashboard with a fixed set of supported entity types and a few special tiles such as the 3D printer view. It is not a Home Assistant frontend, and it does not attempt to render arbitrary Lovelace cards. If your dashboard is doing something unusual with custom cards, or you want the mobile app's layout on your desktop, this is not the tool. The second limit is the platform asymmetry that has already been described twice, and it deserves restating as a buying criterion rather than a footnote. Per-entity global shortcuts do not work on GNOME Wayland or on KDE. The system tray on GNOME needs an extension installed. macOS needs a manual Gatekeeper override on every update, because the ad-hoc signature changes. And the Home Assistant token on macOS lives in a hardware-keyed encrypted file rather than the Keychain, which the README itself says is weaker. The third limit is the beta Assist panel, which is off by default and needs enabling in the settings. Anything you rely on for voice control of your home is riding on a feature the project labels beta. The alternative to weigh is the browser tab, which is what the README positions itself against. The difference in approach is startup and integration rather than capability. A browser tab needs a browser open and a tab pinned, and the Home Assistant frontend is by far the most capable renderer of your dashboard. A tray application starts with the operating system, sits in one place on every screen, gives you one keypress to summon it, and can push notifications to the desktop. For the common case of toggling a few lights and checking a couple of sensors on the way to work, that is the whole argument, and it is a real one. There is also the Home Assistant mobile app, which covers Android and iOS with a real native app and push notifications through the Home Assistant companion app infrastructure. Prism Desktop is not trying to replace that, it is covering the desktop gap. On maintenance, the last push was on 2026-10-17 and the repository is not archived. The release history shows Prism Desktop v1.6 on 2026-09-23, v1.5.5 on 2026-07-19 and v1.5.4 on 2026-06-09, which is a steady cadence over a short version line. The licence is MIT, recorded in the README badge and with a LICENSE file at the root, so there is no copyleft constraint on the build, and the flake.nix makes the Nix package reproducible. That is a licensing note rather than legal advice. ## Conclusion Adopt Prism Desktop if you run Home Assistant and want a native desktop panel instead of a browser tab, since the tray integration, the WebSocket sync and the platform packages cover all three major desktop systems. Do not adopt it if you need the full Home Assistant frontend, because this is a customizable tile dashboard rather than a complete Lovelace view, and note that the macOS build stores your token in an encrypted file rather than the Keychain. Verify first which Linux desktop you use, since per-entity shortcuts are unavailable on GNOME Wayland and on KDE, that your Home Assistant instance exposes a WebSocket API you can point it at, and that the Assist panel is acceptable for you as a beta feature. ## FAQ ### How do I install Prism Desktop on Linux? Download the latest .AppImage from the releases page, then run chmod +x PrismDesktop-x86_64.AppImage and ./PrismDesktop-x86_64.AppImage. Ubuntu 22.04 and newer also needs libfuse2, installed with sudo apt install libfuse2. Nix users can run it directly with nix run github:lasselian/prism-desktop. ### Why does macOS block Prism Desktop on first launch? Because the open-source build is distributed without a paid Apple Developer certificate, so Gatekeeper shows a security notice. Run xattr -cr /Applications/PrismDesktop.app from a terminal, or right-click the app in /Applications, select Open and click Open in the dialog. ### Where is my Home Assistant token stored on macOS? Not in the Keychain. Because the builds are ad-hoc signed and the code signature changes on every update, the Keychain would prompt repeatedly, so the token is stored in an encrypted file keyed to the Mac's hardware UUID. The README states this protects the token at rest but is weaker than the Keychain, since other software running under your user account could potentially recover it. ### Do global keyboard shortcuts work on Linux? Only the app toggle, and only as a desktop environment shortcut rather than a key grab. On GNOME Wayland you bind a custom shortcut in system settings that runs the AppImage with the --toggle argument, and on KDE the toggle is supported through org.freedesktop.portal.GlobalShortcuts. Per-entity shortcuts are not supported on either GNOME Wayland or KDE. ### Which Home Assistant entities can Prism Desktop show? The supported entity types are Light, Switch, Climate, Fan, Media Controller, Curtain and Cover, Lawn Mower, Vacuum, Sensor, Sun, Weather, Camera, Automation, Scene and Script, plus a dedicated 3D printer tile with live camera feed, nozzle and bed temperatures with targets, and print state. ## Sources - [Issues](https://github.com/lasselian/prism-desktop/issues) - [lasselian/prism-desktop on GitHub](https://github.com/lasselian/prism-desktop) - [License: MIT](https://github.com/lasselian/prism-desktop/blob/main/LICENSE) - [README](https://github.com/lasselian/prism-desktop/blob/main/README.md) - [Releases](https://github.com/lasselian/prism-desktop/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lasselian-prism-desktop