Firmware variants
One panel, more than one firmware. Core is the one that has to keep working; a variant adds what not everyone wants. You can move between them over Wi-Fi, and your patterns, Wi-Fi networks and settings come with you.
Core is the one that has to keep working: the panel, the pattern loader, Wi-Fi, sleep, OSC, and the update path out of anything. It is what ships on the board and what you can always return to.
Home Assistant works against core as it is. Reading the panel was always plain HTTP, and setting the four knobs is POST /api/params — no broker and no variant in between. OSC is core too, for the same reason: it needs nothing but the network already in the room.
The shelf
There are no variants yet. The seam they plug into is built and in the firmware, but nobody has published one, and this page is not going to list firmwares that do not exist or name people who have not agreed to maintain them. When somebody does, they go here. Until then the rest of this page is the useful part: what a variant is, what it has to promise you, and how you would move to one and back.
Moving between them
Switching to a variant
Download that maintainer’s firmware .bin from their own releases, open your panel’s console, and drop it on /update. The panel flashes itself over your network and reboots — the same way a core update works.
Coming back
The same way, with a core .bin — or from patternflow.work/update if the console is not reachable. Every listed variant agrees to keep this route open. A firmware you cannot leave is not a variant, it is a fork, and it does not go on this page.
What you keep
Your Wi-Fi networks, your uploaded patterns, and the storage they live on. An update rewrites the program only, and listed variants keep those settings where core keeps them, so switching does not mean setting the panel up again.
What changes
Whatever that variant adds or removes — pages appear or disappear from the console accordingly, because the console asks the device what it actually has rather than assuming. Patterns are the exception by design: every variant runs the same community .pfm modules, so your library works everywhere.
Building your own
The rules a variant agrees to are short and all of them are about not stranding the person holding the hardware. They are written down in the RFC, along with the seam a variant plugs into — a variant adds files, it does not edit core ones, which is what lets it take a core update without a merge fight. To get on this shelf, open a pull request adding your entry to variants-data.ts. You write your own description; somebody still reads it before it goes up, because a stranger’s binary on somebody’s hardware is what this page is asking people to trust. If a pull request is not your thing, get in touch instead.
Building your own console
The pages your panel serves are ordinary HTML files in the firmware repository, not markup buried in C++, and they come with a mock device so you can open them in a browser and edit them with devtools — no panel, no toolchain, no flashing. Everything they do goes through the same /api/ endpoints, so a console you write yourself has exactly as much reach as the one that ships. Start at firmware/patternflow/console.