Printers move out of Settings into their own table and page: each has an
optional nickname (the model is shown when blank), a model from the Bambu
lineup with a line drawing that follows the selection, an AMS type
suggested from the model, and its address, serial and access code. Access
codes are never returned to the browser. The printer set up in Settings is
migrated automatically and its settings rows removed.
Background sync covers every printer. Grams left are filled in only from an
AMS that measures (AMS, AMS 2 Pro, AMS HT), never from an AMS lite.
Spools now show their RFID tag ID, product code and filament code, and say
which printer they're loaded in.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Every Bambu spool reports an RFID identity — a spool id and a tag id, both
unique — so a printer's report can now keep the Filament page in step: a new
tagged spool is created, named and coded from the bundled filament list; one
already known is moved to its current slot; one you added by hand before the
printer was connected is adopted rather than duplicated; and one the printer no
longer reports is marked as taken out. It runs on "Save & test connection" and
every ten minutes in the background, still only reading from the printer.
Untagged spools are listed, not stored: without a tag, one spool of a colour is
indistinguishable from the next, so guessing would mean duplicates.
The planning is a pure function, tested against the cases that would cause
duplicates. The database side was exercised separately against a real
Postgres: three successive reports created, moved and unloaded spools as
intended, and a deliberate duplicate was refused by the partial unique index.
The amount left isn't taken from the printer yet: an AMS lite only reports full
or empty, so it's left blank until printers can say which kind of AMS they have.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The tray reader kept material, colour, profile and amount but dropped the
spool's RFID fields, so the printer test couldn't have shown a filament's
serial even if the printer sent one. It now keeps tray_uuid (the spool),
tag_uid (the tag) and tray_id_name where the firmware provides it, and turns
the all-zero values sent for untagged spools into "none" rather than a fake id.
The printer test also takes ?debug=1, which returns one loaded tray exactly as
the printer sent it, to see which fields a given printer and firmware provide
before designing around them. It's filament data; no credentials are in it.
Also notes that an AMS lite's "remain" is full-or-empty rather than a
measurement, which the next change needs to account for per printer.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Settings → Printer takes the printer's address, serial number and access code
(the code stored as a secret, like the other tokens). "Save & test connection"
connects to the printer's own MQTT broker on port 8883, subscribes to its
reports, asks once for a full report, and listens for a few seconds — then
says what it heard: its state, and the filament in each AMS slot or on the
external spool holder, with how much is left where the printer knows.
Nothing sent to the printer changes what it is doing; the only thing published
is the request for a full report. If the printer is in cloud mode and treats
even that as a write, the test says it received nothing rather than failing
silently. The access code never leaves the server.
Adds mqtt as a runtime dependency — server.js now loads it at startup, so the
lockfile has to travel with this change.
Not verified against a real printer yet: the printer's ports answer on the
network, but no connection has been made with its credentials.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Found on the live library: setting slot 2 of a four-colour bookmark to "any
colour" made it take the one Jade White spool, leaving slot 4 — which asks for
#FFFFFF — with nothing, and the verdict stuck at "needs 3 colours" when it
should have improved to 2.
The assignment sorts candidate pairs by colour distance and scored a colourless
slot 0, a perfect match, so it always claimed a spool ahead of a slot that
needed that exact colour. Colourless slots now sort last and take whatever is
left over.
Fixed in both the server and the browser copy, which mirror each other, and
pinned by a test built from the reported case.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Some prints don't care about the shade, and some change with the order. Each
slot in the editor now has an "any colour" box: ticking it greys out the swatch
and saves the slot without a colour, which the matcher fills from any spool of
that material. A slot added by hand starts this way, since adding one usually
means you care about the material rather than the shade.
An unparseable colour already became "any colour" rather than being refused;
that stays, and is now covered by tests along with the shapes the checkbox
actually sends — null, empty string, and no colour key at all.
Worth knowing when reading the printable count: ticking "any colour" makes a
model easier to satisfy, so the count now partly reflects your decisions rather
than only what the project files ask for.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The slot list comes from the project file, which is sometimes wrong and
sometimes not what you intend to print. "Edit slots" turns it into fields:
material and colour per slot, with slots you can add or drop. Saved slots are
marked as yours and shown with a "your list" badge, and "Use the project's
list" throws the override away and re-reads the 3MF.
Edits have to outlive the background reader, which is the part that would fail
silently: the reader only picks up models with no status, and reread() now
skips 'edited' rather than nulling everything. Verified on a real model — the
edit survived a reread plus a full worker pass, and the revert restored the
project's own four slots exactly.
Input cleaning moved out of the route into lib/filaments.js so it can be
tested: a slot with no material is dropped, and a colour that isn't a proper
hex becomes "any colour of that material" rather than being rejected.
Not verified: none of this has been seen rendered — the local preview browser
has no session.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Seventeen PLA filaments are #000000 and eleven are #FFFFFF, so slot 1 of a
bookmark came out as "Aero Black" — true, but not what anyone calls it. Naming
now prefers Basic, then Matte, before specialist types.
Also puts a space between the "none" badge and the nearest-spool hint, which
were running together as "nonenearest: Jade White".
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Adding a spool no longer means typing a hex code: choose "PLA Basic — Jade
White (10100)" and the material, colour name, swatch and filament code fill
themselves. Slot colours on the model page are named where they match, so a
slot reads "#586579 · Basic Blue Gray" instead of bare hex.
The filament code is stored per spool. It isn't decoration — the AMS reports
filament IDs, so this is what a later read-only printer connection will match a
loaded tray against.
db/bambu-filaments.json holds Bambu Lab's 325 filaments (material, type, colour
name, code, colours), included by kind permission of 3dfilamentprofiles.com,
whose terms otherwise reserve the data. The permission and source are recorded
in the file itself as well as the README, so nobody reuses it by accident.
Naming uses a much tighter threshold than matching (12 against 50): identifying
a colour and substituting for one are different questions.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Counting slots fixed one half of the problem; this fixes the other. A slot is
now filled by a spool of the same material whose colour is close to what the
slot asks for, one spool per slot, best matches assigned first. So four PLA
slots in black, blue-grey, grey and white are not satisfied by four spools of
white — only the white slot is.
Closeness is redmean distance with a tolerance of 50, which treats genuinely
near shades as the same colour while keeping #000000 and #161616 (about 66
apart) distinct. Slot colours arrive as #RRGGBB and #RRGGBBAA — the alpha
channel is parsed off rather than making the colour unreadable.
The model page now lists every slot: its colour, which spool fills it, and the
nearest thing on the shelf when nothing does.
Two things this fixes in code I wrote an hour ago: renderDetailPrintable still
called a function the rewrite removed, so opening any model would have thrown;
and the README claimed colours weren't matched.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Reported from the library: a four-colour AMS bookmark showed as "printable now"
against a single spool of Jade White. The matching collapsed the project's four
slots into the set of materials it used — {PLA} — and then asked only whether a
PLA spool existed. A sixteen-colour model would have passed the same way.
Ignoring colour is right: printing a bookmark in red instead of white still
prints. Ignoring slot count is not: four slots need four spools loaded. Matching
now counts slots per material and reports the shortfall — "needs 3 more PLA",
and on the model page "Needs 4 × PLA. You have 1 of 4 PLA."
The tests carried the same mistake, asserting that one spool satisfied a
multi-slot project, so they are rewritten around the reported case.
Also documents the feature in the README, which had no entry for it at all.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Three placements: a pill beside the sellable badge on each card, a "Printable
now" section between Source and License on the model page, and a toolbar filter
for "printable now" / "missing filament".
Only the 101 models whose slicer project names its filaments can answer this,
so the rest say so plainly rather than being reported as unprintable. Colour is
not matched — a different colour still prints.
Also fixes a bug from the filament page itself: 'filament' was missing from
SPECIAL_SCOPES, so any data refresh while that page was open (after an AI run,
say) decided the collection had vanished and dropped you back to All Models.
Caveat: the client's printability() mirrors lib/filaments.js by hand. The server
side has tests; this copy cannot easily get them, because app.js touches DOM
globals at load — so the two can drift.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A Bambu Studio or OrcaSlicer 3MF names the filaments its plates use, but
reading that means shelling out to Python, so it can't be done per page load.
A background pass — in the same loop as thumbnails and fingerprints — reads it
once per model into models.filaments, which turns "what can I print now" into
a comparison of two lists.
Adds a Filament page for the spools on hand: material, colour, brand and grams
left, edited in place. Matching is on material only; a project's exact colours
would make almost nothing printable, and a different colour still prints.
Measured on the dev library: 10 models read with no errors, the two Bambu
projects resolving to four PLA colours each, and no plate images written
because the reader skips --images and queues behind anything interactive.
Not done yet: nothing in the library view uses this — no "printable now" badge
or filter — and the Filament page itself has not been seen rendered, because
the local preview browser has no session.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Names the project's dev command and port (npm start, 3100) so the in-app
browser preview can start Printhive without being told how each time.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Checks have imported metadata only since MakerWorld refused bulk downloads.
Today's measurement changed that picture: it refuses bursts a few seconds
apart, but 67 models downloaded in a row about 20 seconds apart without one
refusal. So downloading during a check is viable — at the right pace.
Per watch, off by default: "Files: on/off" on the row, a checkbox when adding
one. With it on, a check spaces downloads 20 seconds apart instead of 3, and
stops after two refusals in a row, coming back shortly rather than collecting
refusals for the whole batch. A model whose files were refused still lands as
'partial', so "Get files" can finish it later.
Auto-imports now get the same AI treatment a manual run does — tags, a clearer
name where the site's is boilerplate, and collections to review — rather than
tags alone.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
It claimed an account may only download "a couple in a row". Measured today:
67 models downloaded in a row, spaced about 20 seconds apart, with no refusal
at all. The refusals happen when downloads are fired a few seconds apart, as a
watch check used to do — so it is a rate limit on bursts, not an allowance.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Neither the FlareSolverr call nor the CDN fetch set a timeout, so a stalled
connection hung the request indefinitely: the button sat on "Downloading…"
with nothing to reset it and no error to show. FlareSolverr calls now give up
15s after the deadline FlareSolverr itself was given (and a timeout counts as
retryable, like other transport failures), and a CDN download gives up after
three minutes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The tag paths are sorted now, but two writers of model_projects still iterated
in caller order: findOrCreateProject over the models it attaches, and
setProjects over a model's collections. Two of either running at once could
take the same rows in opposite orders — the same shape as the tag deadlock, one
table across.
Preventative: unlike the tag case, no failure from these was ever observed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The block was built into a `failed` variable and then never interpolated, so
runHtml computed it and threw it away. Two deploys changed nothing visible
because of this: the API carried the failures and the panel fetched them, but
the template never referenced them.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Two transactions tagging overlapping models could each hold a tag row the other
wanted. tagId used ON CONFLICT DO UPDATE, which rewrites the row and therefore
write-locks it even though the name never changes, and each caller iterated in
whatever order it happened to have. That is what killed "Mushroom Clicker"
during AI run 21, while the collection watcher was importing and rule-tagging
the same tags.
tagId no longer rewrites unchanged rows, and applyAiResult, replaceRuleTags and
setTags all tag in sorted order, so locks are taken in the same sequence every
time. db.transaction retries a deadlock victim up to three times as well, which
covers the paths this doesn't — the victim rolled back and changed nothing, so
running it again is safe.
Measured: the old pattern deadlocks on demand (40P01), and the same collision
run 48 times through the new code fails zero times.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The failures now reach the API, but the page could still not show them: the AI
panel fetches detail for one run — the running one, else the newest — and
renderAiLive passes detail only to that run, so every other run is drawn with
nothing. Run 21's single failure stayed invisible for exactly this reason,
even after the previous fix.
Details are now fetched for any listed run with failures and keyed by run id.
Usually that is no extra request, and at most a handful.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A run's detail only carried the last dozen items, so a model that failed early
scrolled out of reach: run 21 reported "1 failed" with no way to learn which
model or why. The detail now carries every failed item, listed in full.
"Retry failed" existed but could never appear: it needs a run that is finished
with failures, and such a run is 'done', which neither canResume nor resume()
accepted. Both now do; resume() already no-ops when nothing is pending, so a
clean run is unaffected.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A failed "Get files" popped a browser alert: jarring, and the message is gone
the moment you dismiss it — which matters here, because the message explains
MakerWorld's download limit. It now appears on the watch's row until the next
attempt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Three things the live run showed:
- The page only polled while a check was already running when it rendered, so
a page opened between checks showed stale numbers for ever — it missed a
check started by the schedule or another tab. It now refreshes either way.
- Only the five most recent items were listed, so most models still without
files had no "Get files" button anywhere. They're now in a collapsible list.
- Adding a watch read the whole collection twice: once to create it, once in
the first check. Measured on a 535-model collection: the add still takes 52s,
but the first import now lands 6s later instead of another read.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
MakerWorld allows an account only a couple of downloads in a row, so a check
that tried to fetch files left most models empty. A check now imports each
model's page — name, description, picture, licence — and marks it 'partial';
"Get files" pulls the files for the ones you actually want to print.
Verified against a public collection: 11 models imported with descriptions and
thumbnails, no files fetched, no MakerWorld token needed for the check.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Measured against the live site: FlareSolverr reports no challenge on that
endpoint and an unauthenticated call gets a normal reply in 3s, so this is
MakerWorld limiting an account to a couple of downloads in a row, not a
Cloudflare page. Two models retried three times each still came back empty —
the retry only made every failure a minute slower.
Keeps the classification, so a refusal is named for what it is and the model
is flagged as still without files.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
