Ben just helped me revive a V3 whose flash writes had slowed to a crawl (thanks again, board’s fine now). Backstory: earlier this summer my 12-year-old and I put up a 170-pixel WRGB ring around our living room, driven by a Pixelblaze V3. We wanted to keep patterns in git and iterate from a text editor, so I ended up writing a little CLI, and it grew into something other people might find useful: GitHub - tarekrached/pbz: Unofficial command-line tool and JS library for Pixelblaze LED controllers · GitHub
It compiles patterns without a browser: it pulls the web UI off the device and runs Ben’s own compiler and LZString code headless in Node, so the bytecode always matches your installed firmware, including firmware the tool has never heard of. Nothing is redistributed. It borrows the device’s own code at runtime. Same trick for the pixel map, since the device can’t evaluate the map JS either. Very much built on Ben’s work, so thanks Ben.
What it does: compile, run and save patterns from files; playlist and sequencer control; device config as code with a drift check; export and import .epe; pixel map get and set; full device backup and restore; and a power-budget tool that derives a safe maxBrightness from your supply and wiring chain. There’s a kid poking at patterns here, so caps matter. The dead board left its mark too: pbz info now warns as the filesystem fills up, a watchdog flags the slow-write symptom before it gets bad, and pbz defrag rebuilds the filesystem over the air (backup first, always).
If you want Python, zranger1’s pixelblaze-client is the mature library and was useful prior art; pbz’s angle is the compiling. Unofficial, written scratching my own itch, with Claude doing a lot of the typing (same disclosure as my recovery thread). Zero dependencies, Node 22+, MIT. The rough edges are listed in the README (sensor board support is designed but unbuilt, no CI, not on npm yet). Feedback welcome, and happy to change anything that steps on toes.