My Pixel Board Has an AI Artist Now

I have a 64×64 LED pixel display on my desk. It’s a Divoom Pixoo64 — a tiny square of 4,096 individual pixels sitting at 192.168.2.176 on my home network. I’ve been slowly wiring it into AutoHub, and it’s become one of my favorite things I’ve built this year.

Instead of showing the time or some static image, I wanted it to generate new art automatically — pixel art that reflects whatever’s happening in my day, my mood, or just something visually interesting. I called the feature Pixel Pulse. This post is the whole thing: how it works, every bug that cost me a week, and — at the bottom — the open-source libraries you’d use to build your own, so you don’t have to repeat my mistakes.

What Pixel Pulse Actually Does

On a schedule, AutoHub wakes up a Claude Opus agent and hands it a set of canvas tools. The agent decides what to draw, paints it — sometimes pixel by pixel, sometimes by generating a base image and quantizing it down — and pushes the result to the board over HTTP. The whole thing is activity-gated: if I haven’t been around recently, or if it just drew something, it backs off. No point burning API calls while I’m asleep.

The agent’s running commentary — the “I’m thinking about drawing Fernsehturm at dusk with a beacon and broadcast arcs” part — gets streamed in real time to an AWTRIX clock on my wall while it works. It’s a weird little window into the model’s creative process, running on hardware I can see from my couch.

It started small. Back at the beginning of June it was a cron job firing every six hours. It’s grown into something I actually look forward to checking.

v2, and the Refactor That Broke Everything

The original Pixel Pulse was a 1,336-line renderer plus a pile of raw curl scripts I’d cobbled together. It worked, but it was a mess. In mid-June I ripped it out and rebuilt it from scratch as a clean Claude Opus agent talking to a small set of canvas tools. The architecture was much nicer.

Then nothing worked.

Bug #1: who owns the board?

The first problem was ownership. A launchd daemon (com.local.pixoo.scheduler) runs as the sole owner of the board. But my Spotify now-playing cover art was being pushed by a different process, and it kept stomping on whatever Pixel Pulse had just drawn. Two writers, one device, last-write-wins — a classic race.

The fix was to stop pushing directly and instead hand the frames to the one process that’s allowed to own the board. The agent writes its desired art to a pulse.json file (plus a frames sidecar); the scheduler picks it up, re-asserts those frames against anything that raced it, and holds the board for about eight minutes. Both files are written atomically — temp file, then rename() — so the daemon never reads a half-written frame.

// Don't push straight to the board from multiple processes — they fight over it.
// One owner (a launchd daemon) holds the board; everyone else writes intent to a file.
async function writePulseSignal({ caption, frames, speed }) {
  const dir = process.env.PIXOO_STATE_DIR
    || path.join(os.homedir(), '.local/state/pixoo');
  await fs.mkdir(dir, { recursive: true });

  // atomic write: temp file + rename, so the daemon never reads a half-written frame
  const write = async (file, data) => {
    const tmp = `${file}.${process.pid}.${Date.now()}.tmp`;
    await fs.writeFile(tmp, data);
    await fs.rename(tmp, file);
  };

  const framesFile = path.join(dir, 'pulse-frames.json');
  await write(framesFile, JSON.stringify({
    frames: frames.map(f => Buffer.from(f).toString('base64')),
    speed, width: 64,
  }));
  await write(path.join(dir, 'pulse.json'), JSON.stringify({
    caption, trigger_at: Date.now() / 1000,
    external_push: true, frames_file: framesFile,
  }));
}

Bug #2: the board lies about success

The second problem was sneakier. The hardware was returning error_code: 0 — success — on every single API call, but the art wasn’t showing up. Just blue squares.

It turns out the Pixoo has a specific, undocumented-where-it-matters sequence. You have to call Draw/ResetHttpGifId before Draw/SendHttpGif, and each frame needs a fresh PicID with a PicOffset counter from 0..N-1. Skip the reset and the device silently throws away the whole push — and still reports success. On top of that, the call I’d been using for multi-frame animations, Draw/SendHttpItemList, is flat-out invalid on this firmware and returns "Request data illegal json." I stared at error_code: 0 for a week thinking the bug was somewhere else entirely.

Here’s the actual recipe that fixed it:

// Push frames to a Divoom Pixoo64 over its local HTTP API.
// The catch: you MUST call Draw/ResetHttpGifId first. Without it the device
// returns { error_code: 0 } — success — and then displays nothing. Blue squares.
async function pushArtToDevice(ip, frames, speed) {
  const post = body =>
    fetch(`http://${ip}/post`, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify(body),
    }).then(r => r.json().catch(() => ({})));

  await post({ Command: 'Draw/ResetHttpGifId' });   // <-- the line I was missing

  const picId = (Date.now() % 1000) + 1;
  for (let i = 0; i < frames.length; i++) {
    const res = await post({
      Command: 'Draw/SendHttpGif',
      PicNum: frames.length,   // total frames in this animation
      PicWidth: 64,
      PicOffset: i,            // 0 .. N-1, sent in order
      PicID: picId,            // shared across the whole animation
      PicSpeed: speed,         // ms per frame
      PicData: Buffer.from(frames[i]).toString('base64'),
    });
    if (res?.error_code) throw new Error(`frame ${i}: ${res.error_code}`);
  }
}
// Draw/SendHttpItemList — the "obvious" multi-frame call — is invalid on this
// firmware and returns "Request data illegal json". Send one SendHttpGif per frame.

After the fix, I watched gid 33 become gid 106 on the device while Spotify was playing, and it held stable for 6.5 minutes without getting overwritten. Good enough.

If that “succeeds but does nothing” failure mode sounds familiar, it’s the same shape as a bug I hit on the MCP side a few days later — a tool returning error_code: 0 while its response schema was wrong, so the agent was blind to its own output. I wrote that one up separately in Flying Blind on the Vision Check. Hardware or software, the lesson is the same: a success code is a claim, not a receipt.

Turning a Photo Into Pixels

Not every piece is hand-drawn. The agent can also “imagine” a base image — generate one with Flux, then crush it down to something that reads at 64×64. The trick is to resize with nearest-neighbor (so pixel edges stay hard, not blurred), then quantize to a small adaptive palette with Floyd–Steinberg dithering for that crafted, deliberate look.

// Turn a generated image into 64x64 pixel art the board can show.
const { data, info } = await sharp(png)
  .resize(64, 64, { kernel: 'nearest' })   // nearest keeps pixel edges hard, not blurred
  .ensureAlpha().raw()
  .toBuffer({ resolveWithObject: true });

const { grid, palette } = quantize(data, {
  width: 64, height: 64, channels: info.channels,
  colors: 24,        // adaptive palette size
  dither: true,      // Floyd–Steinberg — the crafted, deliberate pixel-art look
});

The whole imagine path is fail-soft: if generation times out, the budget’s blown, or quantizing chokes, it returns a soft failure and the agent just hand-draws the piece instead. A pulse is never allowed to break because the fancy part failed.

Narrating to the Wall

While the Pixoo composes, the model’s thinking scrolls across a 32×8 AWTRIX 3 clock (a Ulanzi TC001) on the wall. AWTRIX exposes a dead-simple notify API over the LAN, and the push is best-effort — a down clock just drops the line, it never blocks the art:

// While the Pixoo composes, scroll the model's thinking on a 32x8 AWTRIX clock.
// Best-effort: a down device just drops the line, it never blocks the art.
async function pushAwtrixText(ip, text, { color = '#7DCFFF', duration = 6 } = {}) {
  await fetch(`http://${ip}/api/notify`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ text, color, duration, hold: false }),
  });
}

The Gallery

Every piece gets saved to a pixoo-gallery directory and logged to the database. I built a gallery view in AutoHub’s web UI — “AutoJack’s Visual Diary” — that shows all the pieces as a scrollable grid: the art at 256×256 with pixel-perfect rendering, the exact time it was created, the artist’s note the agent writes about each piece, mood tags, and a color palette pulled from the image. Animated pieces get an “Animated” badge and play inline.

One annoyance from the old renderer: it saved multi-frame animations as horizontal spritesheets (frames tiled side-by-side in a wide PNG), which the gallery displayed as a squished mess. Single-frame art saves as a PNG; anything animated now renders to a proper square GIF instead. I wrote a backfill script that slices the old spritesheets back apart with sharp and rebuilds real animated GIFs — idempotent, so re-running it skips anything already converted.

The Pillow Thing

The Python scheduler side uses Pillow for image work. Pillow 12.2.0 had to be installed by hand into the scheduler’s .venv because it wasn’t being picked up from the main environment. One of those “thirty minutes debugging what should be a one-liner” problems. I’m noting it here mostly so the next person Googling the same import error finds a hit.

Build Your Own

If you want a Wi-Fi LED board that an agent can draw on, you don’t need any of my AutoHub plumbing — the hard parts are all open source. Here’s the shortest path:

• The board: a Divoom Pixoo64. It speaks a local HTTP API; the unofficial-but-canonical reference is Divoom’s developer docs.
• Easiest start (Python): the SomethingWithComputers/pixoo library wraps the whole thing — including the ResetHttpGifId dance — behind draw_image() and push():

# pip install pixoo
from pixoo import Pixoo

pixoo = Pixoo("192.168.2.176")    # your board's LAN IP
pixoo.draw_image("scene.png")      # any 64x64 image
pixoo.push()                       # don't call more than ~once per second

• If you’d rather hit the API directly: 4ch1m/pixoo-rest is a FastAPI gateway with Swagger UI that exposes the raw draw/sendHttpGif and draw/resetHttpGifId passthroughs — handy for poking at the device from any language.
• Other stacks: r12f/divoom (Rust library + gateway) and fflorey/pixoo64rgb (ESP32/Arduino).
• The wall clock: AWTRIX 3 firmware for a Ulanzi TC001, with a clean notify API.
• Image work: sharp (Node) or Pillow (Python) for the resize/quantize/dither step, and any image model (I use Flux) for the “imagine” path.

The one thing none of the libraries will hand you is the recipe at the top of this post — if you go raw HTTP and animate, you will hit the silent ResetHttpGifId failure. Now you won’t lose a week to it.

What’s Next

The board currently generates art a few times a day on a schedule. I want to push it toward more reactive triggers — when I start a new session in AutoHub, when a workflow finishes, when the music changes. “The AI reacts to what’s actually happening” feels more alive than a timer.

For now though, I look at my desk and there’s a tiny glowing pixel scene that an AI drew while narrating its thoughts to my wall clock. That’s pretty good.

AutoHub is my personal automation hub running on a Mac mini in my Berlin apartment. autojack.com