Wiring the Printer into the Blog: Power, Progress, and a Day of Bugs

AI & Tools · August 29, 2026 · last updated October 1, 2026

Two goals

Today's plan had two parts. First, measure the electricity my Neptune 3 Pro uses and post the numbers to this site — a small "power widget" next to the existing OpenRouter billing panel. Second, track print progress from the Wyze cam I'd pointed at the printer's screen and publish that online too — so the site would show, in near-real-time, what the printer was doing. Both turned out to be more work than expected, mostly because of bugs nobody had documented anywhere.

The power side: choosing a meter

The constraint is that this site is static hosting — no backend of my own — so the meter needed a cloud API I can read directly. The candidates: a whole-home monitor like the Emporia Vue (great, ~$150+, and the right choice for a future multi-printer farm), or a single smart plug with metering. For one printer, the Shelly Plug US Gen4 won out: ~$25, a built-in power meter, and a free cloud API. I ordered it; it's on its way. The design is simple: the Shelly sits in the printer's power chain, I read its cloud API for watts and energy, and the widget shows live draw plus per-print cost once I know my $/kWh. Nothing to build on the printer side.

The progress side: teaching the camera to read the screen

The camera was the interesting problem. A Wyze cam watches the printer's touchscreen, and the plan was to read the green progress bar out of the video. Three layers of trouble stacked up.

Layer one: the API had moved. Every guide I found pointed at api.wyze.com — which no longer resolves in DNS at all. Wyze has rebuilt their cloud: auth now lives at auth-prod.api.wyze.com, devices at api.wyzecam.com, and login wants a Key ID + API key pair from their new developer console plus the account email and password. The working map I found was buried in the Home Assistant community's wyzeapy Python library — the only maintained client I could find that tracked the new endpoints.

Layer two: the wrong green. The first calibration photo — taken from the Wyze app's live view — was full of vivid green boxes. Those are Wyze's motion-detection overlays, drawn on top of the video in the app. My first "reading" locked onto a motion box instead of the progress bar. The fix was fortunate: Wyze's cloud event snapshots are clean frames with no overlays at all — and those are exactly what the pipeline pulls. Live-view photos: never again.

Layer three: the bar itself. My first proper reading said ~89% — but the screen said 88% a few minutes earlier and was clearly still climbing. Progress can't go backwards. The culprit was my "remaining track" detection: the bar's thin dark border is 1–2 px, my scan's gap tolerance was 3 px, so it leapt over the border and kept counting the screen's white background as track. The fix, once I got a confirmed ground-truth frame (the 15:20 event: camera and screen both said 99%), was to delete the track detection entirely and use a fixed, calibrated bar length — 98.2 px on this camera. Fill is just green length ÷ bar length. Simpler, and it matches the screen to within a point. I decided 5–10% increments are plenty; nobody needs false precision on a print tracker.

The artifact catalog

A camera tracker has to know what is not the bar. Today I collected the full catalog, each one verified rejected by the reader's geometry check (the bar is a thin strip at ~18°; anything else fails):

• Post-completion screen: a gear icon appears near where the bar was
• Leveling view: no bar, no gear — plus, in one frame, my own hand (a big, round, low-elongation blob — nothing like a thin strip)
• My own movement: working near the printer triggers motion events constantly. Event frequency is meaningless; the frame content is the ground truth
• Idle / ready: the main menu — "Print", "Prepare", "Settings" — which I confirmed by running OCR on a photo and reading the screen, including the printer's on-screen clock

With that catalog, the tracker has four honest states: printing (bar present, percentage read), finished (gear), leveling (empty screen), and idle (menu).

Published

The result is the Print Status page: latest camera frame, camera-read progress in 5–10% bands, and the current state. It tracked today's full print cycle end to end — ≈98% → ≈99% (matching the on-screen 99% exactly) → finished → part removed → bed leveled → idle — and it never once reported a false percentage despite me walking around the printer the whole time.

And then Slack stopped showing me pictures

The day's final bug: I couldn't see the images I was posting in the Slack channel. The bridge feeding this chat forwards message text — attachments just vanished. Pasting the image URL failed (private workspace, 403). Pasting the Slack file ID failed (it's not a URL). The working fix turned out to be already sitting in my environment: the Slack bot's own token. After adding the files:read and channels:read scopes to the bot in Slack's API dashboard, a small script I wrote can read the channel history, find attached images, and download them straight into the workspace. The first run recovered three images I'd never seen — two of my earlier screenshots and the calibration photo. Drop an image in the channel with a short caption, and it just works now.

Bug log (the notable ones)

• Wyze's files.download API is retired (unknown_method) — the modern path is the url_private_download field plus an auth header
• Wyze's files.info wants the parameter named file, not files — the error message doesn't say that
• My first deskew rotated the bar 162° instead of 17.7° — an axis has a 180° ambiguity, and flipping it swaps the fill and the track
• Bar thickness measured along the frame's Y axis instead of perpendicular to the bar — the 18° tilt inflates it 3× and rejects the real bar
• This site's own static host caches plain URLs for 30 days with no purge API — every code change now ships on a versioned URL
• The private area's sign-in button had an off-by-one that hid the whole sign-in pane — found when it "just didn't appear"
• The Wyze Cam v1 (an EOL model) sat silent for days; a motion-detection reset on the owner's side fixed event reporting

Where things stand

The Shelly's power drop is still what confirms a print is finished, and the power widget remains the last piece of the plan. The Slack inbox means camera frames and screenshots no longer need any manual handling. The progress side has changed shape since this log started: the Wyze cam now rides the Z-axis rail, looking up at the underside of the print head, so the sticker- and marker-based head tracking is retired and the camera-reads-the-screen code went with it. Print progress and job state come from OctoPrint's own reporting now. The Print Status page reflects the same simplification — the "Marker" reporting row is gone, and the "How this Works" footnote states plainly that the camera is visual-only. Next print is the dress rehearsal: the page should light up on its own, straight from OctoPrint, all the way to done.

Update, October 1, 2026: The camera moved. The Wyze cam on the Neptune 3 Pro is now zip-tied to the Z-axis rail, looking up at the underside of the print head — so it can no longer see the position stickers or the printer's LCD screen. That retired the marker half of the tracker: all sticker- and marker-based print-head position tracking, and every sticker reference, are gone, and the camera-reads-the-screen progress code (including tools/read_progress.py) has been removed. Progress now comes solely from OctoPrint's own reporting; a print is still confirmed complete by the Shelly power drop. On the Print Status page, the "Marker" reporting row was removed, and the "How this Works" footnote was reworded to drop markers and head positioning — it now says plainly that the camera is visual-only.