mirror of
https://github.com/maziggy/bambuddy.git
synced 2026-10-08 23:21:58 +02:00
9bb2a01f9e752a2e56fcdb600d433ad1d7a7447b
871
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 M2ABRAMSTANK
|
568702486b | feat: Wait for sustained AMS humidity before an ambient auto-dry starts (issue #2518) | ||
|
maziggy
|
6855d65d12 |
Let other applications send messages through the notification channels
POST /notifications/app-message delivers an app's message to every channel with the new "Messages from connected apps" switch on (off by default), through quiet hours, the digest and the log. API keys need the new "Send notifications" permission, and their owner notifications:update; plain text, http(s) links, 20 messages a minute per key. The electricity-price door and this one now share one scoped-key check. /queue?batch=<id> opens and highlights one batch order. |
||
|
Adam Spice
|
858f8c772f | feat: add optional printer model to stream overlay (#3099) | ||
|
maziggy
|
bdc1fc68d0 | Tell a framed external link which theme Bambuddy shows | ||
|
maziggy
|
b9e3fdc84f |
Post work PR #3047
fix(#1898): keep Telegram link previews, and keep the outcome prompt's failures its own Four follow-ups to the post-print outcome confirmation merged in #3047. Telegram: link previews were switched off for every message rather than only for the outcome prompt, so a print_complete template carrying {finish_photo_url} lost its photo preview whenever the photo was too large to attach. _send_telegram now takes link_preview, and only the prompt turns it off, as the Slack unfurl change already did. Archives: Reset left the new Unconfirmed filter on, so the list stayed narrowed and the button seemed to do nothing. Print start: when the external-print check hit a failed statement, it rolled back the caller's whole transaction, which expired the printer and the just-created archive; on an async session the next read of either raises, and the start notification, energy reading and timelapse baseline were skipped. The check's reads now run in a savepoint, and a failed flag write reloads the archive and printer after its rollback. Print complete: a failed outcome prompt left the notification session needing a rollback, so the per-user print email sent on it next failed too. The dispatch now rolls back on failure. |
||
|
Thomansky
|
44c7e6fb39 | Post-print outcome confirmation: good/reject verdicts, one-tap links, yield stats (#3047) | ||
|
maziggy
|
d56b48c499 |
feat(auth): connected apps - sign in to external applications with Bambuddy
Minimal OAuth 2.0 authorization-code flow with PKCE (S256): admins register an app with one exact callback URL (Settings > API Keys > Connected Apps); /connect/authorize asks for consent once and returns a single-use, 60 s code bound to app, callback and challenge; POST /api/v1/connect/token swaps it, with the client secret, for the user's identity and permissions. Codes and secrets stored hashed, exchanges rate-limited per client and IP, no redirect before the callback is validated, API keys cannot authorize, refused while auth is disabled. i18n for all 15 locales. ----- fix(db): upgrading from 0.2.4.0 or older no longer crashes at startup The #2974 failure-reason conversion ran before the #1378 migration that adds print_log_entries.failure_reason, so older databases stopped with "no such column: failure_reason". It now skips a table without the column, only runs where a legacy label exists, and on SQLite rebuilds archive_fts first, since archives created before that index existed trip "database disk image is malformed" when updated. |
||
|
Thomansky
|
12dddada0a | File Manager: external link, notes and photos on library files (#3128) | ||
|
maziggy
|
0db028f9e6 |
fix(inventory): one structured 409 for a tag another spool holds (issue #3110)
The two tag-link routes answered the same conflict differently. The
built-in one said "Tag UID already linked to another active spool" and
named nobody -- while holding the conflicting spool row it had just
loaded -- and Spoolman mode named the spool inside a different English
sentence. Neither was machine-readable, so a client had to parse prose
to learn which spool to look at, and could only do it in one mode.
Both now raise one shared constructor: code tag_already_linked, the
holder's id, and which identifier collided. That is the detail shape
insufficient_filament and printer_connection_failed already use, so
ApiError parses it with no frontend change.
Two active spools can carry one tag -- no unique index on either
column, no conflict check on PATCH /spools/{id}, and /spools/bulk
copies one payload including the tag into every row it creates -- and
the lookup read that with scalar_one_or_none(), which raises on two
rows. The exception escaped into the auth middleware's fail-closed
handler, so the caller was told the authentication service was
unavailable. Both lookups are now ordered and take the first row, as
get_spool_by_tag earlier in the same file always has.
Naming the lowest id means the Spoolman scan reads every row where it
used to stop at its first match, so it now reads extra.tag defensively:
that field is edited outside Bambuddy, and a single null further down
the list would otherwise take the request down in place of the 409.
The kiosk reads the new code: a refused link showed a flat "Failed to
assign spool" and now names the spool holding the tag, reusing the
inventory.tagAlreadyLinked key that no code referenced.
|
||
|
maziggy
|
4a85e033c0 |
fix(finance): show the currency the install is configured for (issue #3123)
The Finance page was the only surface in Bambuddy that read its currency from a data row rather than the `currency` setting, and it fell back to EUR where every other page falls back to USD. One variable drives every amount on that page, so the personal balance, the cost-center budgets and the whole transaction list were wrong together on any install not set to euros. It now takes the configured currency from /settings/ui-flags, which is readable by anyone who can see Finance -- /settings needs SETTINGS_READ, which a cost_centers:read_own user does not have. The backend was the other half. Of the four places that settle on a currency, three wrote a hardcoded "EUR": the wallet the API mints on demand, the wallet a print charge mints when none exists, and the balance returned for a user with no wallet row at all. All four now go through one resolver, which lives beside the rest of the balance logic. The wallet's currency column is removed outright rather than merely ignored. An install has one currency and nothing here converts between them, so a per-wallet copy could only ever drift from the setting -- and a column nothing reads is a trap for whoever finds it next. A startup migration drops it on both SQLite and PostgreSQL, after the raw CREATE TABLE that would otherwise re-add it on an install whose finance tables predate the ORM. SQLite builds older than 3.35 have no DROP COLUMN and keep it, harmlessly, since it has a default and no reader. Saving settings now invalidates the ui-flags query too. Nothing did, so a changed currency sat behind that query's staleTime before showing up. The sponsor prompt's own EUR fallback is now USD, matching AppSettings. |
||
|
maziggy
|
e4a9ef4550 |
fix(spoolbuddy): show the colour name the rest of Bambuddy shows (issue #3090)
SpoolBuddy said "Unknown color" under a correctly-coloured swatch for spools the inventory page names without trouble. The name was never in the spool record. Bambu's RFID tags frequently carry no readable colour name -- some carry an internal code instead -- so Bambuddy has always resolved the swatch's own hex against the colour catalog, and the kiosk was rendering the empty column. Exactly one SpoolBuddy file already did it right, which is what marks this as an inconsistency rather than a kiosk simplification. Route every SpoolBuddy colour-name display through resolveSpoolColorName, which also stops the spools that do carry a code from showing "A06-D0" at the user. The write-tag edit form keeps the raw stored value on purpose: offering a derived name for editing invites the user to save it as though they had typed it. Spoolman has no colour-name field at all, so _map_spoolman_spool puts the spool's subtype there and sets color_name_is_synthesized. That flag now travels on the tag-matched broadcast, and resolveSpoolColorName takes a third argument to honour it -- a synthesised name loses to the catalog and survives only as a last resort. Spoolman installs were reading "Silk+" as a colour on the Inventory page and the AMS hover card too, so those call sites pass the flag as well. Searching by a colour you can read on screen now finds it, in the kiosk and in Bambuddy: the shared inventory filter matches the resolved name as well as the stored one. That makes the filter depend on the catalog, which loads asynchronously, so the three memoised call sites take its version as a dependency -- without that, a query typed before the catalog arrives keeps its empty result and reproduces the very symptom being fixed. The fallback label was hardcoded English in components that already import useTranslation; it is now spoolbuddy.spool.unknownColor in all 14 |
||
|
maziggy
|
2c7c97c130 |
fix(jog): send the nozzle-bed gap the API promises on every model (issue #1334)
POST /printers/{id}/bed-jog takes a signed nozzle-bed gap, documented since it
was written: positive asks for more room between the nozzle and the plate. On
an A1 it did the opposite. The reporter sent distance=5 for clearance and
watched the toolhead come down.
The sign had been flipped on A1 models since the original report on this issue,
where an A1 Mini owner clicked an arrow labelled "move the plate up" and watched
the nozzle dive. That is a labelling problem -- a bed-slinger's plate does not
move in Z at all, so closing the gap shows up as the toolhead descending -- and
it was solved in the transport layer, which turned a parameter documented as
model-independent into one that meant the opposite thing on part of the fleet.
Z is the nozzle-to-bed distance on every Bambu model, by definition of the
coordinate system rather than by convention: G1 Z+ opens the gap whether the bed
drops away from a fixed nozzle (X1/P1/H2, whose end G-code parks with
G1 Z{max_layer_z + 100}) or the nozzle rises off a fixed bed (A1/A2L). The
finish-photo plate restore already relies on exactly that and carries no model
branch. So distance goes onto the wire unchanged and one call means one physical
outcome everywhere: positive is the safe direction on every printer.
Which way an arrow points is a different question, about the machine in front of
the user rather than about G-code, so the printer card answers it and asks for
the gap it wants. The buttons move what you would expect them to move, exactly
as before; on a bed-slinger they now say toolhead rather than plate.
The A2L never had the old fix. It slings its bed the same way the A1 does, but
the inversion listed the A1 names and the A2L was not among them, so its up
arrow has been sending the toolhead at the plate for as long as the machine has
been supported. The new classifier also covers the alternate internal codes
A04 / A11 / A12, which LINEAR_RAIL_MODELS and SINGLE_NOZZLE_FLOW_MODELS both
carry and the old gate did not.
is_bed_slinger is gone from the backend rather than widened: with the route
model-independent it had no caller, and a kinematics helper sitting unused in
the service layer invites the next person to assume the backend handles
direction. It does not, deliberately.
Separately, the soft-endstop comments on both jog routes claimed the firmware
clamps a bare move at the travel limit. It does not, and #2579 measured that:
an H2D at its Z limit ran straight past a clean G91/G1 Z-1.00/G90, while its own
touchscreen refuses the identical move. What #2579 removed was M211 S0, which
disabled the limits globally and took the touchscreen's protection with them.
The jog popover has warned about this correctly the whole time; only the code
comments disagreed with it.
|
||
|
maziggy
|
48244bcfcf |
fix(queue): tell a pinned queue item why it is waiting (issue #3074)
A job queued as "Any X1C" explains itself when it cannot start: the model-based branch builds a reason for every candidate printer and puts it on the row, so the queue shows "Busy: X1C-01" or "Waiting for filament: X1C-02 (needs PETG)". The same job pinned to one printer showed nothing. It sat at Pending with waiting_reason NULL for as long as that printer was busy, which from the outside is indistinguishable from a queue that has stopped working -- the reporter watched fourteen minutes of it while his X1C ran a print he had started from its own screen. The fixed-printer branch had six ways out and none of them wrote the field. The sensor interlock (#1148) was its only writer, and it cleared the field up front on every pass where no sensor was holding the printer, so NULL was not an oversight on those paths but a guarantee. Every exit now writes, through one helper. The reasons reuse the model-based branch's vocabulary so _is_busy_only() keeps deciding what is worth a notification: a printer that is printing, drying, or working through the item ahead of this one reads as "Busy: <printer>" and stays silent, because it resolves itself. A printer that is off with no Auto On plug, and one whose plug could not switch it on, are worth saying. A finished plate nobody has acknowledged is split out from plain busy and named as itself. _is_printer_idle() returns the same plain False for that and for a running print, but they are not the same thing to the person looking at the queue: one clears itself and the other needs somebody to walk over to the printer. That notification fires on the transition into asking, where a busy-only reason counts as not asking. Testing whether the item was waiting at all -- which is what the model-based branch does -- would never fire it here: nobody's queue goes straight from idle to an unconfirmed plate, it waits behind the print first. The cost is that a printer dropping offline, returning busy and dropping again asks twice rather than once. The interlock stays silent. It has never sent this notification, and a change about what the queue displays is not the place to start. Clearing the field up front is gone with it. It existed so a shut door could not leave "Waiting on Enclosure Door" standing while the printer stayed busy with something else, and the new rule carries that guarantee instead -- whichever exit runs next overwrites it, and the dispatch path clears it. Two paths clear it that the report did not mention. A staged item and a future-scheduled one skip before this branch and never reach it again, so anything written on an earlier pass would outlive its condition for the life of the row. That includes the filament-deficit check, which stages the item itself. The notification is wrapped: a queue that cannot say why it is waiting is the bug being fixed, and a queue that stops dispatching because a provider timed out would be a worse one. On the frontend, the queue timeline drops any pending item carrying a reason, on the grounds that such an item will not auto-dispatch. That held while only the model-based branch wrote the field; "Busy: <printer>" is now the commonest reason there is, and it describes the very chain the timeline forecasts, so the rule would have emptied the view for anyone whose queue is pinned. It now asks whether the reason needs the user, via a small shared reader of the same shape the scheduler encodes. Which job goes out, and when, is unchanged: running the previous scheduler and this one over the same 768 states dispatches the same items in the same order with the same statuses, across 1452 rows that now carry a reason. |
||
|
maziggy
|
a4cfbd4212 |
fix(archives): come back for a 3MF whose transfer ran out of time (issue #3063)
The reporter's P1S had the sliced file on its card and was serving it. The 19MB transfer just did not finish inside the budget while the printer was also running its camera, its status messages and the upload of the job itself. Bambuddy wrote an empty fallback archive and never looked again -- then downloaded that same file successfully three times over the next two minutes and discarded every copy, because the only code that would have attached one had already run. The recovery machinery was there. It was armed for exactly one give-up, the FTPS cool-off, on the grounds that the three storage verdicts are settled: a job on internal eMMC never appears at any FTPS path, and sweeping for it again is what where the file is demonstrably still on the card. The sweep already had the signal and never used it. A file that is genuinely not there is answered with 550, which surfaces as FileNotOnPrinterError and is caught by name; a timeout returns falsy instead. So "the printer says no such file" and "we never got a straight answer" are distinguishable without guessing, and only the second schedules anything. Not scheduled either for a 3MF that downloaded fine and turned out to be another plate's. Recovery checks that a candidate is a readable 3MF but not which plate it holds, and the names a retry would use are the same stale ones that fetched the contradicted file -- so it would put back exactly what #2957 discards. The ladder follows the cause: a cool-off has to expire, so its first attempt sits past the 300s; nothing has to expire here, and this reporter's file completed 48 seconds after the budget was spent. The archives banner gets its own wording for this, because the old text sends an owner whose card is working to switch on a setting that is already on. It names the Connection Timeout setting instead. |
||
|
maziggy
|
30e530a881 |
fix(archives): let Items Printed go to 0 for a ruined plate (issue #3051)
A jam can destroy everything on the plate while the printer still reports the job as a success, so the honest count of usable parts is zero. The edit dialog floored the field at one, and a project's completed-items count sums that column, so there was no way to record that a job produced nothing. The floor was in the dialog only; the API stored whatever it was given, which also meant a negative count was accepted and would have subtracted from the project totals. The column is now bounded at zero instead. Filament Trends counted prints as `quantity || 1`, which would have read a deliberate 0 as "unset" and charged the ruined plate as one print while the project page counted none. |
||
|
maziggy
|
f5cdc86689 |
fix(queue): chain the Timeline in the scheduler's order, not queue position (issue #3043)
Turning Shortest Job First on reordered the pending list and the scheduler, and left the Timeline drawing the pre-SJF queue for good. It chained each swimlane's bars by queue position alone and was never told the setting existed -- so the one view whose whole job is to say when each print will run was the one view answering for an order the scheduler had no intention of using. Bars now chain in the order the scheduler will dispatch: jumped items first, then shortest print time with an unknown duration last, then position. The starvation guard is visible there too, so a long print that has finally come up reads as next rather than staying buried behind every short job on the lane. Three surfaces claim to show queue order -- the pending list, the "if started now" ETA, and the Timeline -- and each had its own copy of the comparator, which is how one of them came to be missing a whole clause. They now share one, written against the scheduler's ORDER BY. Grouping came along with it: the pending list folded a model name down to its first character to build a lane key, so Any X1C and Any X2D both landed on -88 (as did Any P1S and Any P1P) and the two lanes interleaved into a single run of rows. Backend untouched. The scheduler was dispatching correctly the whole time; only the drawing of it was wrong. |
||
|
maziggy
|
e2493132bf |
fix(slicer): offer the desktop handoff only for formats the target slicer accepts (issue #3029)
The Slice action and Open in Slicer offered .stl, .step and .stp alongside .3mf, on the assumption that a slicer which opens an STL from its own File menu will open one from a link. Bambu Studio does not. Every bambustudio:// and bambustudioopen:// URL reaches one import path that refuses any filename which is not .3mf, and refuses it before fetching anything: "Download failed, unknown file format." The message names the format, so the failure reads as a broken model rather than an unsupported handoff. OrcaSlicer has no such limit. Only MakerWorld links take its equivalent path; a link to the user's own Bambuddy goes to its general downloader, which does not inspect the extension. So the format list becomes per slicer. isSliceableFilename and isSliceableFileType take the target as a required argument -- a default would quietly reintroduce the handoff that cannot work -- and an unrecognised value falls back to the Bambu Studio list, which is where openInSlicer sends anything that is not exactly 'orcaslicer'. The File Manager offers Slice only when the configured desktop slicer will take the file. The 3D preview reaches both slicers from one split button, so instead of hiding it promotes whichever can take the file to the primary action, naming that slicer when it is not the configured one; the split collapses to a plain button when no alternative is left. The sidecar path is untouched: with Use Slicer API on, Slice still takes STL and 3MF whatever the desktop target is. |
||
|
maziggy
|
b9bd312826 |
fix(slicer): keep protocol-handler download tokens valid for their whole TTL (issue #3029)
The Slice and Open in Slicer actions mint a short-lived token and put it in the URL, because a protocol handler cannot carry an Authorization header. That token was spent by the first request to reach the endpoint, which made the handoff depend on the slicer fetching the URL exactly once. Nothing guarantees that: Bambu Studio's downloader retries three times after a failed attempt, transfers get resumed, on-access scanners fetch. The first request won and the slicer was handed a 403. verify_slicer_download_token takes a keyword-only single_use flag. The default still consumes via DELETE...RETURNING; single_use=False verifies with a SELECT and leaves the row for the rest of its five-minute TTL. The stored row is the same either way, so the endpoint decides, not the mint. The three protocol-handler downloads pass single_use=False: a library file, an archive's sliced 3MF, an archive's source 3MF. Resource binding and expiry are untouched. The two browser downloads keep consuming, because what they hand over is itself consumed -- the prepared printer bundle is deleted the moment it has been streamed. Also: add "/source-dl/" to PUBLIC_API_PATTERNS. Those patterns match by substring and the source 3MF route's segment is source-dl, which does not contain "/dl/", so with auth enabled the middleware rejected the slicer's header-less request before the route's token check ran. Open source 3MF in slicer could never work on an install with authentication on. |
||
|
maziggy
|
816f073a9e |
fix(auth): decouple media routes from the camera stream token (issue #3025)
Thirteen routes with nothing to do with a camera took the camera stream
token as their credential -- library and archive thumbnails, plate
previews and plate thumbnails, timelapses, print photos, archive QR
codes, project covers, print-log thumbnails, printer covers and
external-link icons. A browser cannot put an Authorization header on an
<img src>, so these need a credential that fits in the URL, and the
camera token was the only one that existed. Minting one costs
camera:view, so a user granted library access to their own files got a
grid of broken images until they were also handed the live camera.
Adds a media token: minted by POST /auth/media-token behind plain
authentication, and identified -- it records the principal the way the
websocket token does rather than being anonymous the way the camera
token is. Each route now gates on the permission and ownership rules of
the resource it serves, through the same _ensure_*_visible helpers its
header-authenticated siblings already use. The three camera routes keep
the camera token, and require_camera_stream_token_if_auth_enabled now
documents that it is for those only.
The media dependencies accept ordinary Authorization / X-API-Key headers
as well as ?token=, delegating that path to the existing checkers, so
API-key scope rules and the per-printer allowlist are unchanged.
Long-lived camera_stream, camwall and overlay tokens are deliberately
not accepted on the media routes -- those are handed to kiosks, walls
and Home Assistant to display video. The cam wall, streaming overlay and
kiosk views use only the three camera routes and are unaffected.
Frontend: withMediaToken alongside withStreamToken, and
useStreamTokenSync fetches a media token for every signed-in user while
asking for a camera token only when the user can mint one, which also
stops the 403 that fired on every page load for everyone else.
Also fixed, same class:
- /printers/{id}/files/plate-thumbnail/{i} is rendered in an <img> but
had a header-only guard, so the file manager's plate thumbnails 401'd
whenever auth was enabled. It now takes a media token too.
- getProjectCoverImageUrl returned a URL ending in ?token=, and the
project edit dialog appended its own ?v= cache-buster after it, so the
second ? landed inside the token value. The version is now a parameter
applied before the token.
Tests: 15 integration tests for the token boundary, permission
enforcement and per-row scoping; 10 frontend tests for the URL split and
the two-query hook. test_cover_image_get_uses_stream_token_gate is
renamed and repointed at the media gate -- what it pins, that the
credential has to fit in a URL, is unchanged.
|
||
|
maziggy
|
09b4584d5f |
fix(queue): say when an unscheduled item runs instead of calling it ASAP (issue #3018)
The print dialog offers ASAP, Queue and Schedule. ASAP and Queue differ only in where the item is inserted, and neither is stored on the item -- scheduleType is a frontend-only concept, and grep finds no "asap" anywhere in the backend. So the queue's time column had nothing to read but scheduled_time, and labelled every unscheduled item "ASAP": the name of the one mode the user may well have chosen against. Someone who picked Queue then watched their row appear as ASAP and start immediately, and concluded Bambuddy had overridden them. Two reporters wrote that same sentence thirteen months apart, and #2557 was closed as A2L-specific after the first of them -- kilrah replied there with an X1C before filing this. The column answers when an item runs, so it now says that. The key is renamed whenFree rather than just retranslated: left called asap, the next translator puts ASAP back. The dispatch is unchanged, because it was right. A print scheduled for later does not reserve the printer until then; an unscheduled item behind it uses the idle printer rather than leaving an X1C dark until 6 AM. Two of the new tests pin that, so it does not get "fixed" later on the strength of a report like this one. What genuinely could not answer the question was the queue's own log. Its per-printer line called every entry in busy_printers "not available" -- but that set holds both printers that cannot take work and printers the pass has just claimed for some, which are opposite facts. It also read printer state at logging time rather than at the decision, so #3018's bundle carries Queue: printer 1 not available — connected=True, state=IDLE, ... Launching 1 upload(s) (pool 0/4 in flight) Starting queue item 18 a printer reported unavailable, evidence that it was available, and a dispatch to it, in three consecutive lines. It is the first line anyone greps for "why did my item not go out". Each of the nine sites that removes a printer from a pass now records why, and the summary reports a claim as a reservation and everything else as an obstruction with its reason. The live fields stay, since a bundle reader wants them next, but are labelled as read now rather than offered as the cause. print_scheduler.py:1210 already documented that these two meanings differ -- the dispatching_printers snapshot exists for it. This carries that distinction into the log. |
||
|
maziggy
|
6564c74071 |
fix(archives): report a refused FTPS handshake as the printer, not the slicer (issue #2780)
The Archives banner picks its wording from a priority list of the causes it knows. REASON_FTPS_COOLOFF was added by #2957 and never put in that list, so an install whose empty archives all came from a printer refusing the TLS handshake matched nothing, got reason: null, and fell to the original wording: the slicer did not leave the .gcode.3mf on the card, switch on "Store sent files on external storage", here is installation step 4. Every clause of that is wrong for this cause. The slicer did write the file -- reason he read the whole thing as Bambuddy being broken. The setting was already on. And there is nothing on his side to change: the printer's file service answered port 990 with something that is not TLS, so no lookup ever ran and where the file went was never tested. It is #2899's mistake -- an error message describing a cause that was ruled out before it was printed -- in a surface that did not get that pass. The slug now leads the list rather than joining the end of it. The other three describe an install working as configured and each ends in something the operator can change; this one reports a fault nobody can yet explain, which is both the more urgent thing to say and the thing that produces a useful report. The banner also dismisses one-shot into localStorage, so a reason ranked below another is not deferred to next time -- it is never shown to that user again. Ranking it first cannot bury a permanent cause in exchange: a successful recovery clears the row's markers (#2957), so a row still carrying this slug is one whose retry failed too, days after the print. New wording in all fourteen languages says the printer refused the connection, that this is not a slicer setting and not something the operator did, that Bambuddy comes back for the file when the five-minute pause clears so a brief episode fills itself in, and that a card still empty means the refusal outlasted the retry. It links to the handshake entry in the troubleshooting guide instead of to the installation guide. The client's getNo3MFWarning type still declared the old three-slug union, which made all three new comparisons provably dead -- caught by tsc, not by any test. Four tests. One pins the slug reaching the banner, one pins it outranking the three settled causes, one pins those three keeping their order behind it, and one asserts the rendered wording carries no slicer advice at all. Also corrects the wiki page these reports are pointed at. It said to power-cycle the printer; the reporter who prompted that advice power-cycled both of his and the failure continued unchanged, and bambu_ftp.py has carried the retraction in a comment since. The page now states what was actually measured -- that a version mismatch reports itself differently, that every printer probed refuses TLS 1.3 and completes on 1.2 so there is no version to fall back from, and that three P2S units failed while three more on the same switch never did -- says plainly that the trigger is unknown, and names the one cleartext-probe line worth collecting. |
||
|
maziggy
|
2e405afcd1 |
Decide whether a 3MF is sliced by looking inside it (issue #2993)
An archive that showed the green GCODE badge could re-import into the File Manager as a source-only project with no Print button, seemingly at random. Nothing was ever lost from the file. The download serves the stored bytes verbatim and the G-code was still in the zip; the two sides simply asked different questions. Archives looked inside the file. The library looked at the filename. So a sliced 3MF stored as Foo.3mf rather than Foo.gcode.3mf earned the badge and lost the Print button, and which one you got depended on how the print had reached the printer -- a slicer's LAN send names it .gcode.3mf, a per-plate export or a cloud-dispatched print does not. Both sides now ask one shared predicate about the zip itself, and every route into the library classifies on content. Only the central directory is read, and only when the name has not already settled it, so ingest costs nothing extra -- the external scan opens each 3MF for its thumbnail regardless. Rows already stored are re-checked once, internal ones only: an external row points at a mount that may be slow or absent, and startup is the worst place to discover that. The Slice action moves with it. Its refusal to slice an output was as name-bound as the Print gate, and without that a file that correctly gained a Print button would have offered to re-slice its own G-code. |
||
|
maziggy
|
7363d5fd33 |
Show the spool that is in the AMS slot, not the one that was
Pull a Bambu ABS Orange out of A1, put a PLA Matte Dark Blue in, and the slot card still read "Bambu ABS" against the new colour until the page was reloaded. Three things stood between the swap and a correct card. The RFID auto-assign rewrites the slot's slot_preset_mappings row and then broadcast an event that refreshed everything except the query that reads it. Only the manual assign path invalidated that one. Those queries then sat behind the 3s cascade debounce, which exists for print completion, where one event fans out across half the app. A swap touches one slot and the user is standing at the printer looking at the card; worse, the timer restarts on every further event, so a busy moment could defer it indefinitely. Slot changes now invalidate immediately. And the card trusted the stored preset over live telemetry outright. That priority is why a hand-picked preset name stays on a slot, but it also let a cached row outrank what the printer was reporting. The row is now skipped when it names a different official Bambu filament than the tray does, so the card is right from the status push alone. User and local presets carry ids that genuinely cannot be compared and are left exactly as they were. Spoolman mode was the worse half of the same bug: its AMS sync writes the same row but announced nothing at all, so there was no event to refresh on. It now reports each slot it changed or cleared. |
||
|
maziggy
|
a70047c75d |
Let sub-project groups be collapsed on the Projects page (issue #2991)
A project with sub-projects drew every one of them expanded, at every level, with nothing to shut. Over a three-level hierarchy and a couple of hundred archives that makes the page one long scroll. Each group's caption is now a chevron that folds that group, and a Collapse pill next to the status filter tabs sets the default for the page and is remembered across reloads. A shut group takes one grid cell rather than a full-width row, so folding a deep tree actually gets the page back. The count on the caption is of the cards nested there, not the parent card's badge: the API counts sub-projects across every status on purpose, so under the Active filter the badge can legitimately say 2 where one card unfolds. A count that disagrees with what unfolds is worse than no count at all. |
||
|
maziggy
|
699fc419fe |
Paint an AMS slot card with the spool's colours, not the tray's (issue #2967)
A Ziro "Colorful Mist" -- yellow, cyan and pink, effect Tri Color -- hovered on the printer card as a single flat pink rectangle. A printer reports exactly one tray_color hex per tray and nothing else, so telemetry cannot describe a gradient or a surface effect and never will. The header now paints the bound spool's own swatch whenever that spool declares extra colour stops or an effect, through buildFilamentBackground -- the builder the Inventory swatches already use, so the two surfaces cannot drift apart. A plain single-colour spool keeps the flat backgroundColor it has always had, and a slot with nothing bound is untouched, so the common case goes nowhere near the gradient path. The gate is "any stop at all", not "more than one". buildColorLayer ignores rgba the moment stops exist, so a one-stop spool renders that stop rather than the slot hex; skipping it would leave this card showing a different colour from the Inventory row for the same spool, which is the class of disagreement the shared builder exists to prevent. isLightColor now tests the colour actually on screen. Once the spool's swatch is painted the base is no longer the slot hex -- a single stop replaces it outright, and an effect-only spool paints the spool's own rgba -- so testing the slot hex would pick the text colour for a background that is not there. Above one band no single hex can decide legibility, and the name sits dead centre where a multi-stop background is likeliest to change under it. So a genuinely multi-band header puts the name on the same scrim the vendor badge already uses. One stop, or an effect over one colour, still vendor badge already uses. One stop, or an effect over one colour, still leaves a real base colour to test and keeps the contrast rule it had. Spoolman mode gains the gradient in the process. Spoolman has held the stops in filament.multi_color_hexes all along and the label renderer has been reading them for releases, but _map_spoolman_spool never returned them -- so the identical roll registered in Spoolman rendered flat while the internally-managed one did not. Both now share one parser rather than reading the same field two ways. What stays asymmetric is Spoolman's own limitation, and it is pinned by a test rather than left to be rediscovered: Spoolman has no field for a surface effect at all. Its only neighbouring field, multi_color_direction, says how the stops are laid out, not that the roll is silk or glitter. effect_type is therefore None for a Spoolman spool instead of guessed at, and silk/sparkle/wood remain internal-only. The other two halves of the report -- the header naming the colour "White" instead of "Colorful Mist", and the print dialog offering "A3: PLA (White)" -- were already fixed on dev by #2875 and by the slot-naming change that landed the day after this was filed. Neither is in 1.2.5.3, which is what the reporter is running. |
||
|
maziggy
|
a7b563334e |
Configure a spool's filament preset and K profile per nozzle
A slicer preset is bound to a printer model: "Bambu PLA Basic @BBL X1C" is not the same preset as "@BBL H2C", and Bambu names a nozzle size in it as well. A spool carried exactly one, which was right until the same spool was used on a second machine -- the AMS slot on the other one was then configured with a preset that machine has no profile for. K profiles had the matching gap from the other side: the tables have always been keyed per hotend, but the picker could not express it. spool_filament_preset and its Spoolman twin store the exceptions, keyed (spool, printer_model, nozzle_diameter). Model rather than printer because the preset is a property of the model -- "@BBL X1C" is the same preset on every X1C, and asking per machine would mean picking the identical value twice. K profiles stay on printer_id, because a K value is measured on one physical hotend and two machines of the same model legitimately differ. Resolution is exact (model, diameter) -> (model, "") -> the spool's own preset, so a spool nobody has configured behaves exactly as it did before. The form writes one row per nozzle size and never the "" row; that level is kept for API clients wanting one value to cover a model. Both halves cover every standard nozzle size rather than the size currently fitted, because a spool is configured once and nozzles get swapped. The PA Profile tab becomes a Printers tab: a model list beside a detail pane holding a preset row per size and a K-profile grid of size by hotend. Each model is offered only the presets that name it, through the same matcher the Configure AMS Slot modal filters with, which moves out of that component into utils/slicerPrinterMatch. Presets whose name identifies no model -- most user-authored and OrcaSlicer ones -- stay offered everywhere, as does whatever is already selected, so a saved override cannot vanish from the control that shows it. Every preset carries an origin badge in the wording and colours that modal already uses. Every path that configures a slot now respects both: manual assign in either inventory mode, RFID auto-assign, the Spoolman tag link, the re-fire when a slot goes empty to loaded, the re-apply after a calibration-table refresh, and the re-selection when a Filament Track Switch moves an AMS to the other nozzle. Which nozzle a slot feeds, and how wide it is, was worked out independently in seven of those places, each reading nozzles[0] for every slot on the machine -- correct on a single-nozzle printer and on a dual-nozzle printer with matching nozzles, wrong the moment two sizes are fitted. That resolution is now services/slot_nozzle. Which array entry belongs to which hotend is no longer inferred. Measured on an H2D fitted with a 0.4 high flow on the left and a 0.6 on the right, nozzles[0] reads the right hotend, so the array is indexed by extruder id and the H2/X2 parser's convention is the one that holds. The legacy parser's opposite convention never governs a real dual-nozzle machine: every model in DUAL_NOZZLE_MODELS reports device.nozzle.info, and left_nozzle_diameter appears in no log or wire capture. Two comments that said otherwise were wrong and are fixed; amsHelpers' code was right all along and only its comment lied. Four defects surfaced while wiring it, all pre-existing except the last. The picker identified a chosen calibration by cali_idx alone, and the printer numbers its calibration table per nozzle -- on a dual-nozzle machine the same index exists on both hotends meaning different things, so saving could persist the other hotend's K value and diameter; SpoolBuddy's write-tag page carried a verbatim copy and gets the same fix. RFID auto-assign chose a K profile with no extruder test at all, so a spool calibrated on both hotends had a coin toss decide which pressure-advance value the slot got, on the path that runs unattended every time a Bambu spool is loaded. The Spoolman tag-link path resolved no preset whatsoever, configuring every linked slot with a generic material id and discarding a preset set in inventory -- the same defect #1713 fixed on the assign path, one function over. And an FTS inlet move re-selected K for nozzle 0 rather than for the nozzle the AMS had just been moved to. The last one is new here: a per-model override can be a cloud USER preset, whose PFUS-prefixed id the slicer rejects, and passing it straight into extrusion_cali_sel would silently lose the K-profile link. Reached the printer only where such an override exists, which is why nothing in the suite caught it. printer_safe_filament_id falls through to the spool's own preset and then the tray's RFID value instead. Reading a printer's calibration table asks for one nozzle size at a time. H2-series firmware answers only the first one or two of a concurrent burst of extrusion_cali_get and silently drops the rest, each dropped request costing a five-second timeout before its retry: measured at 11 and 23 seconds on an H2C and an H2D for four parallel requests, against roughly one second in series. An X1C answers all four at once, which is why this only ever surfaced on dual-diameter printers. Printers themselves are read in parallel -- separate machines are separate connections. The Configure AMS Slot dialog opens on the spool's own configured values, falling back to the slot's last manual configuration and then the tray's RFID data. The spool form is wider for the two-pane layout, colour, weight, cost and location move to their own tab in two columns, and a printer card in expanded view lists every fitted nozzle size rather than the first entry alone. |
||
|
maziggy
|
9500c046c0 |
Ask which nozzle to feed when a Filament Track Switch is fitted
Load and Unload in the AMS slot menu did nothing on an H2C with the switch fitted. The ams_change_filament command carries an optional extruder_id and Bambuddy never sent it. That is correct on every printer without the switch, and is what BambuStudio does there too -- each AMS is wired to one hotend, so the firmware works the target out for itself and an explicit value would only be a guess at something it already knows. Fit the switch and every AMS is bound to one of its two inlets instead, either hotend is reachable from any slot, and a command naming neither leaves the firmware nothing to act on. It was discarded in silence. Load now asks which hotend to feed, on the same terms as Bambu Studio: no preselection, so a stray Enter cannot feed the wrong one, and the hotend already fed from that very slot greyed out. Printers without a switch send a byte-identical command and still load in one click. A switch fitted but not yet set up -- any AMS still unassigned to an inlet -- refuses the load up front rather than publishing one the firmware will drop, mirroring DevFilaSwitch::IsReady, which likewise demands a switcher position on every AMS. Unload was addressed at the same time. It was aimed with tray_now, a single value for the whole printer, so on any dual-nozzle machine with both hotends loaded it unloaded whichever that field happened to name regardless of which slot's menu was used. It now names the slot and resolves the holding hotend from device.extruder.info, previously read for temperatures only. That resolution is gated on the printer having reported two extruders: single-nozzle machines do send the block, but nobody has read a single-nozzle snow value off the wire, and staking every X1C, P1S and A1 unload on an unverified encoding buys nothing where tray_now is already unambiguous. Both new state fields ride the WebSocket and are in the broadcast key, and both are computed in the REST status route as well -- that response is what the page has before any push arrives, and leaving them at their defaults would have told a correctly set-up machine that its switch was not set up. Verified on H2C-1, AMS-A slot 3: loaded and unloaded from each hotend in turn, all four correct. Covered by 18 MQTT unit tests, 4 status-dict tests, 7 integration tests and 6 component tests. Two known stragglers, both deliberately left alone. Load on an AMS-HT slot has never worked -- an HT unit is addressed by its unit id rather than ams*4+slot, which these endpoints do not accept -- so unload there keeps the printer-wide form it always used instead of gaining a slot it cannot name. And a slot's K-profile still follows the AMS's plumbing rather than the nozzle just loaded, so loading to the far hotend leaves the other one's calibration bound; that is the same per-nozzle problem the filament and K-profile redesign is scoped to fix. |
||
|
maziggy
|
196fcaf15b |
Keep the last run a batch order can re-queue a plate from
An order produces what it still owes by cloning an existing queue item for the same plate. That row is the only record of the printer target, AMS mapping and print options the user chose, so deleting the last one left the order reporting work outstanding that nothing could produce, and no way to close it out: Cancel was hidden unless there were pending items to cancel, which by then there were none. Deleting an order's last surviving run for a plate now cancels it instead. A cancelled run does not satisfy a target, so the order still owes the print and can still make it. A completed run is exempt and still deletes outright -- rewriting it as cancelled would falsify what the order produced. Also: the response reports per plate whether anything is left to clone, so the card explains a stranded plate rather than offering a button that can only fail; dispatch skips a stranded plate instead of aborting the whole order; and Cancel is offered for any active order. |
||
|
Kouki Ojima
|
c3677865b6 | Give the AMS temperature alarm its own threshold (issue #2905) (#2943) | ||
|
MagicMelody84
|
54af3146a3 | [Feature]: Bind Home Assistant sensors to storage locations (dryboxes/bins) (#2827) | ||
|
maziggy
|
5dd7bd213f |
Read a print's destination from the report topic, not just the request one (issue #1820)
current_project_url was assigned in exactly one place, _handle_request_message, and _on_message calls that only for the request topic. A print started from the printer's own screen publishes nothing there, so the field stayed None for the one case the storage verdict exists for: the file is already in the printer's model library under /userdata/model/history/, which port 990 does not serve. The verdict then fell through to the sdcard flag, and @ojimpo's H2S reports that flag true -- its "card" is the internal eMMC -- so every such print ran the full sweep before giving up. He measured one: 16 filename-and-directory attempts over 22 FTPS connections, 18 of them refused, 6.4 seconds, then a fallback archive holding a name and nothing else. The printer does announce where the file lives, as an unsolicited project_file *response* on the report topic about two seconds before gcode_state reaches PREPARE. _process_message now reads the url off it, gated on result SUCCESS and a non-empty value so a refused dispatch cannot name a file that was never written. Reading it there rather than only at the request topic also covers an install neither of us had in view: some brokers refuse the request-topic subscription, and on those no print of any kind had ever populated the field. The new branch captures state and nothing else. The "External project_file payload" diagnostic stays with the request-topic handler: our own dispatch is echoed on both topics, the request-topic echo lands first and clears _own_project_file_key, so reusing the diagnostic here would have logged every Bambuddy-started print as somebody else's. A test pins that. What the print names is now what gets tried -- the five directories a copy could be in, rather than the ~110 connections that cannot succeed. The probe is still worth running: an H2S keeps recently used jobs under /cache and archives them in full while they last, which is why the reporter's two prints on the same day behaved differently. Slicer-sent prints are unchanged. The banner no longer describes a step that never happened. With no reason recorded, a blank archive fell back to the original wording -- "Store sent files on external storage" is off in your slicer -- which on that printer is on, and which the internal-storage wording from #2780 already explains would not help on an H2. The archive that most needed that explanation was the only one that could not be given it. So file:///userdata/ now earns its own reason, internal_history, separate from the brtc://emmc dispatch case. A dispatch chose internal storage and can be aimed elsewhere; a print of a file that was already there had no dispatch at all, and telling that operator to pick External in Send names a dialog they never opened. The banner and the connection diagnostic both read the verdict's reason rather than a fixed one, so the two surfaces cannot give the same printer different advice. Thirteen locales, and a wiki section the banner links to. ----- Read the K-profile selection when the mutation runs, not when it is captured Configure Slot sends cali_idx from selectedKProfile, and the mutation read it through its own closure. React Query hands a mutation its options from an effect, so a click landing between a commit and that effect flushing runs the previous render's mutationFn -- one that captured the selection as it was before the K-profile query resolved. The payload then carries cali_idx -1 and the printer binds the default 0.020 instead of the calibrated K, while the dialog shows the right profile selected throughout. It surfaced as an intermittent failure of the per-nozzle K-profile test, about one full-suite run in six. Reproducing it with staggered query resolution showed the divergence directly: the select element held the correct profile immediately before and after the click, and the payload still carried -1. That test's slot is the most exposed case in the file -- a right-hotend slot carrying the left hotend's index, where the "keep showing the active profile" safety net cannot repair an empty recompute. The selection now goes through a ref written during render, so the mutation resolves it at execute time. An effect would have inherited the same flush ordering this exists to escape. The K value and the profile's ids travel in the same payload and had the same exposure, so they move with it. Measured over a staggered-resolution grid: 2 failures in 15 runs before, 0 in 12 after. api.getSlicerPrinterModels was also missing from the test file's mock, so that query ran with no query function and rejected in all 37 tests -- mocked now, though on its own it changed nothing, which is how the ref was confirmed as the fix rather than assumed. |
||
|
maziggy
|
06e5114a03 |
Do not report a printer as Safe when nothing is checking it (issue #2952)
The printer card's AI badge collapsed every class that was not Warning or Failure into green Safe, and the service reported `safe` whenever it had no verdict. The state entry is created when a monitored print is first seen -- before the first snapshot, let alone the first inference -- so a rejected ML API token, an unreachable ML API, a failed capture and an unset External URL all rendered as a healthy watched print: green Safe at score 0.000. For a safety feature that is the worst failure mode available: it asserts the print is being watched exactly when it is not. The reporter read that badge and concluded the loop had never started. It had been calling the ML API every ten seconds and being turned away with a 401 -- invisible because Obico's auth layer rejects a bad token before its request log sees it, and because successful checks log nothing there either. Add two honest states. Not checking (amber) when the last poll produced no result, carrying the reason; Starting while a monitored print waits for its first result. Score and frame count are withheld while not checking, since 0.000 beside "Not checking" reads as a measurement rather than its absence. The reason is per printer, so a card names its own problem rather than whichever printer failed most recently, and stays behind settings:read because it can quote configured URLs -- the badge state does not, because whether a print is watched is not configuration. An unrecognised class now falls back to Starting, not Safe. Test Connection saves the form before probing, so a green result describes the configuration the loop actually runs with rather than what is typed in the boxes. |
||
|
maziggy
|
87e0a4c3b6 |
Name a spool by its subtype on the slot it is assigned to
A spool's subtype is half of what it is called: "PLA" and "PLA Wood" are
different filaments. The AMS slot's hover card built the assigned-spool
line out of brand, material and colour name and left the subtype out, so
a roll of Bambu PLA Wood Classic Birch in an H2C's A4 was announced as
"Bambu Lab PLA - Classic Birch".
Everything else named it correctly at the same moment -- the RFID read,
the inventory row, the slot's own profile line, which is built from the
spool's slicer preset rather than reassembled, and Bambu Studio -- so the
one wrong line read like a bad tag read rather than a display fault.
It was not only the render. The card's assignedSpool prop had no subtype
field at all, and the six places the printer card fills it in -- regular
AMS, AMS-HT and external spool, each in both Spoolman and internal-
inventory mode -- never passed one, so the value could not reach the
component. The field is required rather than optional, which is what
stops the next call site from quietly omitting it; that omission is the
whole of this bug.
Three more surfaces rebuilt the name the same way and are fixed with it:
the SpoolBuddy AMS slot panel in both inventory modes, and the write-tag
confirmation. Every other place a spool is named -- the assign dialogs,
the inventory cards, the forecast rows, the label picker -- already
included the subtype, so these four were the outliers.
This is the display-side half of #2902, which stopped the backend
reducing a filled or foamed filament onto its base material. The card was
doing the same thing to the same spools, one layer further out.
|
||
|
maziggy
|
68140747f2 | Post work PR #2853 | ||
|
Sean K
|
55cc64c87d | Add printer video downloads and range selection (#2853) | ||
|
sgiffhorn
|
937440f956 | Report the selected plate on the archives API (#2796) (#2871) | ||
|
maziggy
|
e4aab7b44b |
Leave archived projects out of the pickers that file work (issue #2888)
The reporter opens a project per job and archives it when the job is done, so the Project dropdown in Edit Archive listed five live projects behind thirty-odd finished ones, in one unscrolled run with nothing to tell them apart. Archived is the state that means "put this away", so that is what the pickers now drop: the Edit Archive dropdown, the pending-uploads panel, the bulk Add to Project dialog and the File Manager's folder link. Completed stays. It says the work is finished, not that it should be hidden, and filing a reprint under a finished project is ordinary. The Archives right-click submenu had the opposite bug and offered active projects only, so a completed project was reachable from the edit dialog and not from the menu next to it. All five surfaces share one rule now. Whatever a thing is already filed under survives the filter whatever its status. A select holding a value that matches none of its options is reset by the browser to the first one, and here that reads "No project" -- an archive sitting in an archived project would have said in as many words that it was filed nowhere. The stored id does survive an untouched save; it is the field that lies. The parent-project picker is deliberately untouched. A finished or archived project is still a legal parent, and its own comment says so. Fixed alongside it, and reported separately: the status tabs counted only the projects the selected filter had already let through, so every tab but the current one counted zero and dropped its badge. Switching tabs moved the number rather than showing four of them. They are counted from the unfiltered list the page already fetches for the sub-project captions -- same query key, no extra request. The new rule is one function with its own unit tests, since five callers now depend on it reading the same way. Each half is pinned separately: dropping the filter, dropping the kept id, restoring active-only, and counting from the filtered list each fail their own tests and nothing else. |
||
|
maziggy
|
3916db822c |
Stop the G-code preview from sizing the box that sizes it (issue #2887)
Opening a 3D Preview from Archives left an empty white pane with the legend and the layer slider drawn over it, and the page's scrollbar shrank for as long as it stayed open -- about 190px of page height a second, with no limit. The viewer appends its canvas into the very element it measures with clientWidth/clientHeight and watches with a ResizeObserver. setSize writes each new size onto the canvas as inline style, and three.js leaves the canvas display:inline, so the line box adds descender space on top of the height just set. Where that element takes its height from its contents, the canvas sizes the box that sizes the canvas and gains a fixed 33px every round -- the reporter measured container = canvas + 33 on every sample. The page gave it no height to take instead. The viewer pane is flex-1 min-h-0, which divides nothing unless the column above it is a definite height, and h-full is a percentage resolved against a main area whose own height comes from a min-height -- a floor, not a size. So it fell through to the content, and the content was the canvas. Nothing was ever drawn because of the same loop, not a second fault: every observer callback reallocated and cleared the frame buffer, and an antialiased render of what had grown to roughly 18 megapixels never finished before the next one arrived. The data path was fine throughout, which the legend and the 1..57 layer slider both prove -- they are built from the parsed toolpath. The canvas is now positioned out of flow, so it cannot contribute to the height of the element that measures it on any page, and that element takes a definite height from the pane around it rather than a percentage. display:block goes on too, for the case where something overrides the positioning. The page is sized from the viewport the way the File Manager page already was. Either change alone stops the growth, but the structural one alone would trade it for a collapsed pane: an out-of-flow canvas contributes nothing to content height, so with no definite height above it the pane becomes clientHeight || 1. They belong together. The same viewer in the File Manager dialog was never affected -- a dialog gives it a fixed height, so neither fault could arise there. jsdom does no layout, so the loop cannot be reproduced in a test. The structure that forbids it can: the new cases assert the canvas is out of flow, that the measured element is definite-height rather than h-full, and that the pane stays positioned so inset-0 resolves against it. Reverting either change fails exactly those. |
||
|
gyrene2083
|
8d1daab23a | Show K-profile value on AMS slot card (#2854) | ||
|
maziggy
|
3901043238 |
Name an AMS slot's colour by its material, not its hex alone (issue #2875)
A hex is not one colour in Bambu's range. #FFFFFF is Jade White in PLA Basic, Ivory White in PLA Matte and plain White in six other materials; popover resolved its title from the hex alone, against a map that keeps one name per hex, so an ivory Matte spool read "Jade White" while the profile line beside it correctly read Matte Ivory. /inventory/colors/map now carries the names collapsing loses, keyed "<material>|<hex>". An entry is emitted only when it recovers a name the same manufacturer's own range lost -- 11 of them against the 608 colours in the shipped catalog. Both halves matter: a name equal to the flat answer is weight, and a name from another brand is not a recovery, it would put Prusament's "Pristine White" on every generic white PLA slot. A slot with a spool assigned from Inventory is titled with that spool's own colour name: it is the roll the user said is in there. Bambu internal codes are still rejected as non-names (#857). |
||
|
maziggy
|
28781ea558 |
Keep the printer's name on statistics after it is deleted (issue #2873)
Every per-printer breakdown resolved the name against the printers that exist now, so deleting a printer and choosing to keep its prints turned "Ultron" into "Printer 1" in Prints by Printer, the success-rate and time-accuracy lists, and Failures by Printer. Archives lose their printer on that delete as well, so nothing was left to read a name from. The runs themselves recorded the name they printed on. /archives/stats now reports the last name each id was known by - taken from the newest run that has one, so a later name-less row cannot blank it - and failure analysis falls back to the same thing for ids with no printer left. The client keeps preferring a live printer's own record, so a rename still shows up straight away rather than after the next print. |
||
|
maziggy
|
cfecfa360e |
Restore the skip-objects list after a restart mid-print
The object list lives in PrinterState and is filled by the print-start path, which bambu_mqtt suppresses on the first RUNNING push after startup so a running print is not archived twice (#1304). Everything else that moment restores came back - the archive into _active_prints, the filament attribution session, the timelapse baseline - and the object list did not. So the card saw zero objects and greyed out its Skip button for the rest of the print. Measured on the maintainer's H2C: 8 objects loaded at 09:02, a restart at 09:17, Skip dead for the remaining hour. Nothing could bring it back either. GET /print/objects rebuilds the list whenever it is empty, but its only caller is the modal that the greyed-out button opens. on_print_running_observed now reloads the objects from the archive of the print that is still running, anchored on subtask_id - the firmware mints one per print, so a leftover status="printing" row from a completion that was never seen cannot lend its objects to another job. Without an id nothing is loaded rather than guessed; the endpoint's own reload covers that on demand. That endpoint now reads the archived 3MF from disk before it asks the printer. The archive of a running print normally holds the very file the printer is executing, so the fan-out was fetching back 15 MB Bambuddy already had, over the printer's single FTP socket, while it was printing - and on a printer that kept the file on internal storage it cannot succeed at all. FTP stays as the fallback. skipped_objects is left alone: a reload is not a new print, and what the user has already skipped only lives there. The plate image had the same fault one layer down. Opening the modal asks for the cover, the top view and the object-ID mask, and the in-memory 3MF cache those share dies with the process - so after a restart all three went back to the printer at once: three fan-outs, thirteen seconds, and a 0-byte read from socket contention, which is the storm #972 was about. The cover flow takes the running print's archived file too, resolved in the caller's short-lived session and passed in so _produce_cover_image still does no DB work, and marked as a shared file so the cleanup cannot delete the archive. Finally the card: a running print always has at least one object, so a count of zero means "not loaded", not "nothing to skip". Exactly one object is the real nothing-to-skip case and still disables the button. --- Stop a test's printer client leaking into the next test POST /api/v1/printers really connects, so a test that creates a printer through the API leaves a live client in the printer_manager singleton. The singleton outlives the per-test in-memory database, so the next test on that xdist worker - whose own first printer is handed the same primary key - reads that leftover client as its own live status. test_scheduled_drying_routes was the visible victim: an "online" printer with no firmware version fails the drying preflight, so scheduling came back 400 instead of 200. It only bites when --dist load happens to put victim and leaker on one worker, which is why it passes on its own and flakes under -n. Registrations made during a test are now undone after it, ids the test did not add are left alone, and disconnect_printer is what also drops the model and printer-info caches and stops the paho thread the leaked client was keeping alive against an unreachable address for the rest of the run. |
||
|
maziggy
|
90fac7b529 |
Keep card and row actions reachable without a hover-capable pointer (issue #2865)
Tailwind v4 compiles group-hover: inside @media (hover: hover) - the shipped CSS has .group-hover\:opacity-100 sitting in exactly that block. On a touch-only device the media query never matches, so the rule that reveals the control is not merely never triggered: it is never applied. A control written as opacity-0 group-hover:opacity-100 is invisible for good. The reporter's iPhone screenshot shows the project card with nothing where the "..." belongs, and Edit and Delete live only there. So the hiding half is what has to depend on the pointer, not the revealing half. A can-hover variant carries the query - the same one the history thumbnail preview has used since it was written - and the six controls behind it become can-hover:opacity-0 group-hover:opacity-100. Without a hover-capable pointer no rule hides them and they simply render; with one, nothing changes. Every reveal selector is specificity (0,2,0) against the hider's (0,1,0), so which one wins does not depend on where they land in the stylesheet. Six controls were affected: the project card menu, the File Manager's folder actions (reachable by accident today - the "wrap names" toggle drops the hover class), duplicate preset, rename and delete tag, delete print photo, delete plate reference. Six more already tried to handle this, by viewport width under 768px on the Archives cards and the File Manager's file cards. That covers a phone and misses an iPad in landscape, which is touch-only at 1024px. They move to the capability check and useIsMobile goes with them, along with the isMobile prop threaded into FileCard. opacity-0 also leaves a button focusable while invisible, so tabbing through a card stopped on a control nobody could see. Focus now reveals them, through group-focus-within on the wrappers and focus-visible on the standalone buttons - neither is hover-gated. jsdom does not evaluate media queries, so the tests pin the class contract instead: a bare opacity-0 is the defect, because it applies unconditionally while everything that undoes it does not. The decorative hover reveals are left alone - the archive hash badge, the project name overlay, the thumbnail preview, the swatch tooltips. Nothing is unreachable there, only unseen. |
||
|
maziggy
|
05d87a9740 |
Release the plate-clear gate on a powered-down printer (issue #2864)
POST /printers/{id}/clear-plate answered 400 "Printer not connected" for
anything without a live MQTT client, and the printer card hid the button
under the same condition. With Auto Power Off that is the ordinary end of
every print: the reporter's log has printer 1 marked offline at 12:00:55
by the plug and the clear-plate POST rejected at 12:03:12, with the plate
already cleared by hand. Nothing could release the gate short of powering
each printer back on, clearing, and switching it off again.
Nothing in the clear path talks to the printer. set_awaiting_plate_clear
writes an in-memory set and the printers.awaiting_plate_clear column, and
that column exists precisely so the gate survives an Auto Off cycle
(#961). The guard came in with the endpoint in
|
||
|
maziggy
|
5a05e03c8e |
Use the printer's own plug for energy when several are linked (issue #2859)
Per-print energy is one plug's meter read at the start of a print and again at the end. Both readings asked for "the plug on this printer" with scalar_one_or_none(), which raises on two rows. Linking a second plug to a printer - a dry box, a filter fan, a lights script - therefore stopped energy tracking on that printer outright, and did it silently: the print-start handler logged the exception as an ordinary failure and the print-end handler then reported "no start kWh recorded", which is also what it says for a printer with nothing linked to it. The assumption was never enforced anywhere else. The plug API rejects a second Tasmota plug and deliberately allows any number of Home Assistant entities, the UNIQUE constraint on smart_plugs.printer_id was dropped on purpose, and every other consumer reads a list. These two call sites were the last ones left from before that. Energy now ranks a printer's plugs - the one that powers it first, then by id so the start and end readings agree - and takes the first that actually reports a counter, so accessories drop out with nothing configured. Ranking rather than filtering: a printer whose only linked row is disabled, or a script, used it before and still does. When none of them measures anything the log names the ones it tried, so that stops reading like "no plug configured". Also: the plug page counted an online plug as offline unless it reported energy, so a switch with no power sensor showed as offline for as long as it stayed linked. Existing archives cannot be backfilled - the starting reading was never taken, so there is nothing to compute a delta from. |
||
|
maziggy
|
c5e0055864 |
Track which nozzle each AMS feeds through the Filament Track Switch
With a switch fitted, an AMS is not wired to a nozzle any more. It is plumbed into one of the switch's two inlets and reaches both nozzles through it, so every unit reports its extruder as "not fixed" (0xE) and ams_extruder_map comes back empty. Bambuddy had nothing to fall back on but the AMS unit number, so AMS-A was badged R and AMS-B was badged L purely because their unit ids are 0 and 1, a third unit got no badge at all, and every one of those labels was wrong. The binding needed no new telemetry. BambuStudio reads it out of bits 24-27 of the same AMS info string we already parse for the type and the extruder id -- 0 is In-B, 1 is In-A -- and it only means anything when a switch is installed, because without one 0xE really does mean an uninitialised unit. That gates the read, which forced the switch block to be parsed before the AMS block: _handle_ams_data runs early in _process_message and _update_state only much later, so the binding was lost on every frame that carried both. The badge letters stay L and R, In-A reading as L, with the inlet named in full in the tooltip -- the letter is the inlet's position and not a claim about which nozzle that AMS feeds, since the switch can route either inlet to either outlet. Both views update live now. The switch fields were missing from the WebSocket payload, and the frontend shallow-merges each push over its cached status, so an absent field kept whatever the last full fetch left behind. The broadcast dedup key had no term for them either, so "Join IN-B" on the printer screen moved nothing: the binding is not in the tray component of that key, and not in the AMS change-hash, which covers tray fields only and must stay that way because it drives Spoolman sync. The rest of this is the calibration half, which is where it actually bites. K-profiles are calibrated per nozzle and the printer numbers its calibration table per nozzle too, so entry 16 exists on both hotends and means a different profile on each. A tray holds exactly one index. Move an AMS to the other inlet and every configured slot in it silently keeps pointing at the old hotend's table -- measured on the maintainer's H2C, a black PLA calibrated 0.018 left and 0.020 right stayed on the left profile after the move, and a manual RFID re-read only re-asserted the same wrong one. Bambu has not solved this either; their AMS dialog carries "TODO: fila_switcher broken the connection of ams->extruder" above the line that decides which nozzle's profiles to offer. Three copies of "which extruder is this slot on" each ended in else 0, which on a switch machine filed every profile under the right-hand nozzle. They now share one resolver that returns None for "unknown", because unknown and extruder 0 are very different answers on a dual-nozzle machine and conflating them is what bound a left-nozzle profile to a slot sitting on the right. The per-slot K value on the printer card had the same confusion from the other direction: its lookup was keyed on cali_idx alone, so one nozzle's K silently overwrote the other's. Moving an AMS now re-selects each configured slot's counterpart profile for the nozzle it has arrived on. Only the calibration binding moves, and only for slots whose spool already has a profile for that nozzle: configuring a slot is a deliberate preparation step, so a slot we know nothing about, or a spool calibrated on one hotend only, is left exactly as the operator set it. Nothing fires on the first sighting of a binding either, since every reconnect learns them afresh and re-applying there would overwrite a choice made by hand. Configure Slot resolves against the slot's own nozzle throughout. Option identity carries the extruder, so a filament calibrated on both hotends gives two distinguishable entries instead of two that collapse into whichever the printer listed first; options name the hotend; matches are scoped to the nozzle the slot feeds, with the other hotend's profiles still reachable under Other K profiles; and the slot's active index is resolved as a pair rather than followed into the wrong table. Inlet to nozzle is one table, In-A to the left hotend and In-B to the right, measured rather than assumed -- fila_switch.out cannot be used for it, reporting [1, 1] unchanged across a 90-second capture, both outlets claiming the same extruder. The print dialog picks up the same inlet labelling in its slot dropdown, replacing a left/right hint that never rendered because it matched snow-encoded values against global tray ids; decoding it correctly would not have saved it, since the firmware never reports which inlet is currently paired with which outlet. The dialog also notes when every filament a print needs sits behind one inlet, which is legal but slow -- a change between two filaments on the same inlet retracts the outgoing spool all the way back to its AMS, where a change across the two only retracts as far as the switch. Assigning an AMS to an inlet remains printer-side. BambuStudio can read that binding and has no command to write it, so there is no wire format to copy. |
||
|
maziggy
|
7a42e0a7e5 |
Show which Filament Track Switch inlet each AMS feeds
With a switch fitted, an AMS is not wired to a nozzle any more. It is plumbed into one of the switch's two inlets and reaches both nozzles through it, so every unit reports its extruder as "not fixed" (0xE) and ams_extruder_map comes back empty on these machines. The printer card had nothing to fall back on but the AMS unit number, so AMS-A was badged R and AMS-B was badged L purely because their unit ids are 0 and 1, a third unit got no badge at all, and every one of those labels was wrong. The SpoolBuddy assign modal had the same fallback in a worse form, mapping anything that was not extruder 1 to R. The binding turned out to need no new telemetry. BambuStudio reads it out of bits 24-27 of the same AMS info string we already parse for the AMS type and the extruder id -- 0 is In-B, 1 is In-A -- and it is only meaningful when a switch is installed, because without one 0xE really does mean an uninitialised unit and those bits carry nothing. That gates the read, which in turn forced the switch block to be parsed before the AMS block: _handle_ams_data runs early in _process_message and _update_state only much later, so the binding was lost on every frame that carried both. _parse_fila_switch is split out and called first, and left in _update_state as well so that stays a complete absorb step. The badge keeps L and R rather than A and B, because the lettering is familiar and matches the physical layout. It is a different colour from the plain nozzle badge, and its tooltip names the inlet in full, since the letter is the inlet's position and not a claim about which nozzle that AMS feeds -- the switch can route either inlet to either outlet. An AMS still reporting a real extruder id keeps its ordinary badge, which BambuStudio also treats as authoritative over any switch binding, and a switch that has been fitted but not yet set up on the printer shows nothing rather than a guess. The print dialog's slot dropdown gets the same label. It replaces a left/right hint that never once rendered: ftsExtruderForSlot compared snow-encoded in[] values against global tray ids and could not match. Decoding it correctly would not have saved it -- the firmware reports which slot sits in each inlet and which nozzle each outlet feeds, but never which inlet is currently paired with which outlet, so no per-slot nozzle can be derived. That function is gone rather than fixed. The dialog also points out when every filament a print needs sits behind one inlet. Bambu's own guidance is that this is legal but slow: a change between two filaments on the same inlet retracts the outgoing spool all the way back to its AMS before the next can be fed up the shared tube, where a change across the two inlets only retracts as far as the switch. All on one inlet means every change in the job takes the slow path, and moving a single spool fixes it. So it advises, it does not block. Both views update live. Two things were stopping that. fila_switch and ams_switch_inlet were absent from printer_state_to_dict, and the frontend shallow-merges each WebSocket push over its cached status, so a field the push omits keeps whatever the last full fetch left behind. And the broadcast dedup key had no term for either, so "Join IN-B" on the printer screen moved nothing: the binding is not in the tray component of that key, and it is not in the AMS change-hash either, which covers tray fields only and must stay that way because it drives Spoolman sync. Assigning an AMS to an inlet remains printer-side. BambuStudio can read the binding and has no command to write it -- its switch class is parse and getters only, and the recommended-arrangement popup draws and publishes nothing -- so there is no wire format for us to copy. Adding the two fields to PrinterState broke four test modules whose SimpleNamespace stubs predate them. The stubs are fixed rather than the production reads made defensive: the real dataclass always carries both, and a getattr in the dedup key would silently stop tracking the field if it were ever renamed. |
||
|
maziggy
|
61a6ed1f20 |
Move Camera View Mode from Settings onto the camera button
Whether a camera opened in its own browser window or as a floating overlay was one dropdown in Settings > General > Camera, applied to every camera on the install. Deciding per printer meant leaving the Printers page, changing the setting, coming back, opening the camera, and going back again to undo it -- five steps for a choice you make while looking at the printer you want to watch. The camera button on the printer card is now a split control. The icon opens the camera whichever way you opened the last one; the caret beside it offers both modes, and picking one opens the camera that way as well as making it the mode the icon uses from then on. A menu that only changed a preference would have left the user a second click to do the thing they had already asked for. The mode in effect is ticked. The choice lives in the user's own browser, so two people watching the same farm can each have the view they want. camera_view_mode survives as the default a browser that has never chosen starts from, and is written back when the user holds settings:update. The local value wins on read: someone below that permission cannot write theirs back, and a preference that silently reverted on the next render would be worse than none. Two things were consolidated on the way through. The popup-opening code -- saved geometry, and deliberately no noopener so the browser copies sessionStorage and its auth token into the new window -- was duplicated between the printer card and the Cam Wall tile handler; it is now utils/camera, with the geometry parse wrapped so a corrupt cameraWindowState falls back to defaults instead of throwing, which neither copy did. The Cam Wall follows the same remembered mode, since a tile has no room for a split button of its own. The effect that force-closed every open overlay when the setting flipped to window is gone. It made sense for a global switch; with the choice made per click, closing viewers someone deliberately opened does not. No new locale strings: the four the settings control used are reused as the menu's labels and tooltips and the caret's own label, so all 13 locales stay in parity untouched. |
||
|
maziggy
|
47a37618a0 |
Let a busy or offline printer take a dropped file (#2849)
Dragging a sliced file onto a printer card refused the drop unless the
printer was connected and neither RUNNING nor PAUSE. The overlay went red
with "Printer busy", handleCardDrop returned early, and the file was
discarded with no toast and nothing uploaded. The card's Print button was
hidden by the same condition, so both routes into "Print from Printer
Card" closed at once and the way through was the File Manager, uploading
and queueing by hand.
The gate never described a real constraint. Every print Bambuddy sends
becomes a queue item; dropping onto an idle printer only looks instant
because the scheduler dispatches it on the next pass. Busy is a timing
difference, not a different path. The modal has always passed
disableBusy={false} to PrinterSelector, and asapToastShouldPromiseLaterStart
exists precisely to say "this will start later" when the target cannot
take it now. cleanup_library_after_dispatch is a print_queue column
consumed at dispatch, not on close, so the transient upload survives
however long the item waits.
Offline is included for the same reason: the queue dispatches when the
printer comes back, so a machine that is powered down can be given work.
The overlay now says which one is happening -- "Drop to print" when the
job would start immediately, "Drop to queue" when it would wait, covering
a print in progress, a paused job, an AMS mid-cycle, a plate not yet
cleared, and a printer that is offline. The predicate behind that wording
is the one the modal already used for its own later-start notice, lifted
out of PrintModal into utils/printer as isPrinterCurrentlyDispatchable so
the card cannot promise something the modal contradicts a second later.
The drop is also gated on the permissions the flow actually exercises. It
uploads to the library and creates a queue item, so library:upload and
queue:create -- the pair the Print button beside it has always checked.
printers:control, which it checked before and never uses, meant someone
holding that alone got the file uploaded and then rejected by the queue,
leaving a library row behind with nothing pointing at it. The refusal now
names whichever of the two is missing instead of claiming the printer is
busy.
printers.cannotPrint is dropped in favour of printers.dropToQueue across
all 13 locales; its text was both unused and, after this, wrong.
The Print button stays inside the expanded-card block, so S-size cards
still show the drop zone and no button, exactly as before.
|
||
|
maziggy
|
a72f49be02 |
Stop the File Manager card menu from clipping its own top entry (#2846)
A grid card drew its action menu inside itself and clipped its own overflow, so a card shorter than its menu lost whichever entry sat at the top. An STL card is the shortest in the library -- a square thumbnail plus a name and a size, around 270px against a seven-entry menu needing closer to 310px -- and the entry it lost was Slice, since Print is only offered for an already-sliced file. A 3MF carries a target model and a print count, two more rows, so its card was tall enough and the button appeared, which made this read as a rule about file types. It was not: the shortest card lost its first item, whatever that item was. The menu is now the shared ContextMenu, anchored to the kebab in viewport coordinates the way the archive card has always opened its own. Being fixed, it escapes both clipping ancestors -- the card and the grid's scroll container, which would have cropped the top row of cards even without the card's own overflow. The card drops overflow-hidden anyway and the thumbnail rounds its own corners instead, so nothing a child positions outside the card can be cut off again. While rewriting the block, 3D Preview and its permission tooltip stop being hardcoded English; fileManager.preview3d and fileManager.noPermissionPreview are added to all 13 locales. List view was never affected: it has no menu, only inline buttons. |