1779 Commits

Include renames

Author	SHA1	Message	Date
maziggy	73e0787bfd	Name an unnamed print stage "Preparing" on the card ... New printers report stage numbers before Bambuddy learns their names, and the H2C still has several. Those reached the printer card verbatim, as "Unknown stage (72)" -- a number that means nothing to the person reading it, on the one line that otherwise says what the printer is doing. Every stage that has turned out to be unnamed so far has been part of the run-up to printing, so an unnamed one now reads as "Preparing". That is the same literal stage 74 already carries rather than a second spelling of the same idea, so a card cannot show two different words for the same situation depending on which number the firmware picked. Display only, and deliberately not pushed down into get_stage_name. That function also feeds the stage-transition log line and the once-per-session warning added to capture unnamed stages so they can be named in a later release; there the number is the entire diagnostic value, and replacing it with "Preparing" would hide the only thing that reports these. Both paths are pinned by tests asserting they disagree for an unnamed stage and agree for a named one, so a later tidy-up cannot quietly collapse them. The idle sentinels are untouched: 255 on A1/P1 and -1 on X1 mean "no stage", not an unnamed one, and still resolve to nothing rather than being swept up by the fallback. Nothing keys logic off stg_cur_name -- it is display-only in the printer card, the print dialog's printer selector and the stream overlay -- so all three improve and none change behaviour. No i18n either way: the whole stage table has always been English.	2026-08-28 09:51:14 +02:00
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.	2026-08-28 09:46:37 +02:00
maziggy	4f10d15584	Record the colour a slice is actually printed in (issue #2977) ... Every file the internal slicer produced came back with filament_colour = #00AE42 whatever filament was picked: a green plate thumbnail, green metadata, and a "Color mismatch" in the Print dialog against the AMS slot the job had just been correctly mapped to. A colour is not a property of a filament preset in either slicer. It belongs to the project, and Bambu Studio and OrcaSlicer set it from the plate in their GUIs -- so nothing was attached to the preset Bambuddy sends by name, and the CLI fell back to its own compiled-in default, which is Bambu green. None of the shipped BBL filament profiles define filament_colour; the whole tree has zero occurrences. default_filament_colour is not the answer on its own. Measured against a 02.08.02.61 sidecar, a profile carrying only that still slices to filament_colour ["#00AE42"] -- Bambu Studio consumes it in the GUI when a project is created, not in --load-filaments. So it is read and rewritten as filament_colour, which the same sidecar does honour: the reporter's exact triplet returns ["#E8B00C"] when patched this way, and the colour lands in both project_settings.config and slice_info.config, which is what the thumbnail and the AMS mapping actually read. Each filament row in the slice dialog gets a colour control, and the resolved value flows through a chain: the user's pick, then the preset's own default_filament_colour, then the colour that slot was designed with in the source 3MF. A slot with none of the three is left untouched rather than given a guess. The designed colour is read from project_settings.config, not slice_info.config. The latter records what the file was last sliced with, which for a source that never carried a colour is #00AE42 itself -- measured -- so using it would have been circular. The control is offered on single-filament sources too, because an STL, and equally a mesh-only 3MF exported from CAD, has no colour anywhere else to inherit. That is the case this exists for, and it took three shapes to make it visible: a swatch in the label row was identical to the read-only dot multi-colour rows have carried for releases, and adding the hex beside it only made it look like a caption. It now sits beside the dropdown, styled like it and the same height, with the swatch and hex wrapped in one label bound to the input so a click anywhere on it opens the picker. An untouched slot with no designed colour submits an empty string rather than the control's displayed default. A sent colour outranks the preset's own, so pinning the placeholder would silently discard the real colour of an imported OrcaSlicer profile that carries one. Slicer Pipelines pick up the same chain without carrying a colour of their own. Also adds a warning for a defect found while investigating this: a filament preset whose name the sidecar's bundle cannot resolve is not rejected. The CLI inherits nothing, falls back to its defaults for every field, and returns a well-formed success -- measured, an unresolvable name slices as filament_type ["PLA"] at nozzle_temperature ["200"] with filament_ids [""] and filament_vendor ["(Undefined)"], so a PETG preset a sidecar image predates prints at PLA temperatures with no diagnostic anywhere. Both signals are required together, which keeps it off the two legitimate lookalikes: a hand-written profile that never named a vendor still carries a real filament id, and a user's own cloud preset carries a vendor while legitimately having no bundled id. The file is kept rather than refused, unlike the missing start G-code of whoever can see the temperatures.	2026-08-28 09:23:30 +02:00
maziggy	5211fd4575	Store a failure reason in one vocabulary, not three (issue #2974) ... failure_reason was written three different ways and nothing reconciled them. derive_failure_reason wrote English display labels ("Layer shift"), older builds of the archive editor wrote the translated label in whatever locale that user was running, and the two stale-archive paths wrote English prose sentences. All three reach one column -- the archive PATCH has mirrored the field onto the latest print-log entry since #1444 -- and the Failure Analysis widget groups on the raw value, so one real cause occupied several buckets. On a live install before this landed: print_log_entries held 91 rows reading "User cancelled" beside 1 reading "userCancelled". In an English UI those two render as the same words twice with different counts, which is why nobody spotted it. In any other locale one of them stays English, because a stored label has no key for t() to resolve. The editor was worse than cosmetic about it: its reverse lookup compared the stored value against t() in the current locale, so for a non-English user nothing matched and the dropdown opened empty over an archive that plainly showed a reason. The keys were already canonical and already enforced. _FAILURE_REASON_KEYS in api/routes/print_log.py rejects anything else with a 400 and explains why in its own comment -- the widget renders values back through t(), so an unrecognised one surfaces as a raw string. derive_failure_reason had simply never been held to that rule. It now produces keys, and the cancel branch returns userCancelled. The two "Stale - ..." sentences become one new noStatusUpdate key. Both describe the same observation, that no end-of-print status ever arrived; which of the two situations occurred is already carried by status -- cancelled at the stale-cleanup site, the reconciled outcome at the reconnect site -- so collapsing them loses nothing and gives Statistics one bucket instead of two sentences that could never be translated. It had to enter the vocabulary rather than merely be tolerated, because the editor discards any value it does not recognise. Existing rows are converted by a startup migration folding 168 historical labels onto the 12 keys across both columns. It is exact rather than a guess: every label across all 14 locales resolves to exactly one key, with no collisions. The map is a frozen snapshot rather than something read from the locale files at run time -- it maps what was written historically, so regenerating it from the current translations would silently stop recognising the very rows it exists to convert. A value outside the map is left alone; guessing would be worse than leaving one honest string in its own bucket. There is no one-shot settings flag, on purpose: the statement only matches values in the map and a key is never a label, so it is self-terminating, and a flag would permanently skip anyone who restores an older database. The last part is a data-loss bug that was not in the report. The editor's fallback to '' was not merely a wrong-looking dropdown -- the empty selection was then saved over the stored text, so opening the editor on an archive whose reason was free text and pressing Save destroyed the classification. An unrecognised value now keeps its own option and survives a save.	2026-08-28 08:28:27 +02:00
maziggy	d5c7047765	Name an AMS slot after the spool assigned to it ... The print dialog described every slot from the printer's own telemetry, and a printer cannot describe a spool it did not sell: a tray record carries no brand field, tray_sub_brands is left empty for anything that is not a Bambu spool, and the colour arrives as a bare hex the client resolves against Bambu's own colour catalogue. A Devil Design PLA Basic Orange assigned in Bambuddy therefore read as "PLA (Sunflower Yellow)" -- Bambu sell a Sunflower Yellow at the same FEC600 -- while the printer card, which reads the assignment, named it correctly. Two views of one slot, disagreeing. GET /printers/{id}/inventory-remain now carries each bound slot's brand, material, subtype, colour name and hex alongside the pooling key it already sent, and the dialog prefers that over telemetry. The fallback is per field, not all or nothing, so a spool with no stored colour name still gets the catalogue lookup it had before while its brand and subtype come from the binding. Resolved server-side because the identity rule differs per inventory mode -- brand is a column in internal mode and a nested vendor in Spoolman's, where the subtype is the filament name with its material prefix stripped and the colour name has a three-step read order Spoolman has no field for. Spoolman's synthesised colour name, which falls back to the subtype, is withheld rather than rendered as "PLA Basic (Basic)". Matching is deliberately untouched and still runs on the printer's telemetry. The auto-assignment, the colour-mismatch test and the mapping that actually gets dispatched all read type, colour hex and tray_info_idx, so renaming a slot cannot make the panel and the dispatcher draw different conclusions from it. The payload is re-read on every open of the dialog: it names the slots now, and a spool assigned moments earlier would otherwise keep its old name for the rest of the thirty-second stale window. Done at the two readers rather than by invalidating the key from each of the eighteen places a binding or a spool can change, half of which are internal paths and half Spoolman ones -- covering some would make freshness depend on which mode you run. Two hardening fixes fall out of putting a mapper on this path. build_slot_materials runs before every queue start through compute_deficit_for_queue_item, and _map_spoolman_spool walks a dozen nested fields off the wire, any of which arriving as the wrong type raises AttributeError rather than ValueError. Naming a slot must never cost a dispatch, so that call fails soft to no name. The same inputs also reached _material_identity_spoolman and _normalize_color_for_id, which have always been on this path and would fail a queue start on a Spoolman record whose filament is not a dict or whose color_hex is a number; both now read those as "nothing to pool with". Behaviour for well-formed input is unchanged -- the guards only intercept types that previously raised -- so no pooling key moves and AMS Filament Backup is untouched.	2026-08-27 16:04:41 +02:00
maziggy	e5a18bf58b	Key a K profile on its nozzle's flow type ... A printer files each calibration under a nozzle id of the form HH00-0.4 (high flow) or HS00-0.4 (standard) and can hold both for one diameter -- a maintainer's H2D carries 102 high-flow entries against 6 standard -- because the same filament reads a different K through each. Nothing read that, so a standard-flow profile could be selected for a high-flow nozzle and vice versa. The flow is now stored with the profile, shown against each option in the picker, and checked before a stored profile is applied. Two spellings have to agree for that: a calibration entry says HH00-0.4 while the fitted nozzle reports HH01, so the comparison is two characters rather than four -- the trailing digits are a hardware variant the calibration table normalises to 00. Unknown flow on either side matches anything, which is what it has to do. Every profile stored before this has none. And an X1C declares none on any profile at all -- probed live, all eight come back with an empty nozzle id, against a four-digit cali_idx and a populated setting_id -- even though the machine really does take either nozzle. supports_nozzle_flow_type is therefore the wrong thing to gate on: it returns True for an X1C, and treating that silence as Standard would have dropped every X1C profile the moment a high-flow nozzle was fitted. What the printer's own table declares per profile is the test. NozzleInfo.nozzle_type carries two vocabularies by printer generation -- the nozzle material on legacy printers, the flow code on H2 -- and the comment claiming only the former is corrected. Anything that is not HH or HS reads as unknown, which is what makes the material spelling harmless. Storing both flows for one hotend and diameter is deliberately not done: spoolman_k_profile is UNIQUE on (spool, printer, extruder, diameter) with no flow column, and allowing a second row in internal mode alone would break inventory-mode parity. The picker marks a profile whose flow does not match what is fitted instead of letting it look configured while doing nothing.	2026-08-27 13:42:55 +02:00
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.	2026-08-27 13:03:15 +02:00
maziggy	59d2713acf	Give a no-3MF archive the timelapse baseline it never took (issue #2957) ... _capture_timelapse_baseline_at_start says in its own docstring that it must be called from every on_print_start path that proceeds to a real print, and what breaks otherwise: the completion scan falls back to snapshotting the card after the printer has written the video, so the new file lands inside the baseline and no diff can ever match. There are three such paths. The fallback branch was not calling it, and nothing else covered the gap -- on_print_running_observed is restart-recovery only and is suppressed whenever on_print_start fires. Every no-3MF archive therefore reached completion with no baseline in memory and none on the row, and kept its timelapse only by accident. Not confined to the reported cool-off. The same branch serves the internal-storage verdict, so every H2C/H2D/P2S print that Bambu Studio's Print button sends to eMMC lost its timelapse the same way, off a card that was holding it the whole time. Measured on a live install: 0 of 9 fallback archives had a baseline, against 73 of 275 normal ones. The branch now takes one like the other two, and last like they are: it lists the printer's timelapse directory, so a slow card must not delay the active-print registration, the energy reading, the archive-created event or the start notification ahead of it. The other half is a print shorter than the five-minute cool-off, where the card is still unreadable at the one moment a baseline has to be taken. list_files_async answers [] when its connect fails rather than raising, so that is indistinguishable from a card holding no videos. When the cool-off expired inside the 900-second poll window every video on the card read as new, the first in listing order won, and a stale unclaimed video was attached to the print and then deleted off the printer. The empty baseline is still recorded rather than refused. Bambuddy deletes each video once it is attached, so the usual card holds exactly one at completion and an empty baseline resolves it correctly; refusing outright would lose that common case to protect a rare one, and persisting NULL instead would send completion to snapshot a card that by then has this print's video on it. Instead the scan marks such a baseline untrusted and the attach step declines to choose between several candidates, leaving them for the manual Scan for Timelapse button. require_unambiguous defaults to off, so the only caller whose behaviour changes is that scan.	2026-08-27 08:37:35 +02:00
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.	2026-08-26 12:04:42 +02:00
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.	2026-08-26 10:11:55 +02:00
Whitigol	a68933cb2f	Allow Avery label sheets to start at an unused position (#2879) (#2918)	2026-08-26 08:57:44 +02:00
maziggy	14f46510ba	File the printer's calibration table under the nozzle it belongs to (issue #2854) ... The K value on an AMS slot card went blank after a while and came back after a backend restart. It is not the MQTT merge: that preserves a tray's k correctly. H2-series trays have no k to preserve. Verified against the H2 wire capture in logs/vp_wire -- every tray reports cali_idx and nothing else -- so the number on the card is resolved from that index against the printer's calibration table in state.kprofiles, and that table was a single global list. An extrusion_cali_get response is the complete table for one nozzle diameter, and the printer answers whoever asks; BambuStudio's queries arrive on the same report topic we subscribe to. Every response was assigned straight to state.kprofiles, so any one answer stood for the whole printer. The nightly GitHub backup asks for 0.2, 0.4, 0.6 and 0.8 in turn and finishes on 0.8, which holds nothing on a 0.4+0.6 machine: logs/bambuddy.log records exactly that at 17:15 on 2026-08-25, and the table was empty from then until something refilled it. Responses are now bucketed by the diameter they describe, so an empty answer for a size the printer does not have clears only that size. The three assign paths that look an index up by nozzle_diameter get the same fix for free -- they were quietly finding nothing whenever the last response was for another nozzle, which is what spoolman_inventory has been logging as a stale kp. Bucketing makes state.kprofiles a union, and cali_idx is numbered per nozzle, so the index alone no longer identifies a profile. The REST serializer has keyed on (extruder, cali_idx) since c5e005586; the WebSocket one still keyed on the index alone, which meant the first render of a card could be right and every update after it wrong. Both now share one resolver. It goes through the extruder the slot feeds, and where that does not single out one profile -- a single-nozzle printer that has been swapped, so both its tables sit under extruder 0 -- it falls back to which diameters are actually fitted. Where neither settles it the card shows nothing, because a blank space is a smaller error than confidently printing the other nozzle's number. Deliberately no loosening to a bare cali_idx lookup on a miss: that is the cross-nozzle bleed the extruder keying was added to stop. Nothing read the table on connect, which is the other half of the report. It arrived by luck -- a visit to Profiles or Configure Slot, a backup, or the printer answering someone else -- so a Bambuddy nobody had opened showed a card with no K values at all, and "restart and they come back" was the printer happening to broadcast rather than anything we did. It is now read once per connection, on the same latch the stale-print reconcile uses. Only the fitted diameters are asked for, one request on a single-nozzle printer and two on a dual; probing the four sizes blind is what the backup does and what blanked the table. The edge is gated on a nozzle diameter being known as well as on the state being known, because the first push_status is what makes the state known and does not always carry the nozzle fields -- latching there would spend the connection's one attempt on a printer that could not yet say what was fitted. Adopting an unsolicited table now logs at debug. It was the quietest way for the card to change underneath us and there was no way to see it in a support bundle. Three test files gained nozzles=[] on their PrinterState stubs. The field has always been on the dataclass; the connect edge is simply the first thing on that path to read it.	2026-08-25 17:52:02 +02:00
maziggy	08a58b1ef4	Keep both modes' slot assignments across an inventory mode switch (issue #2812) ... Turning Spoolman mode on ran an unfiltered delete(SpoolAssignment) across every printer. Turning it straight back off cleared the other table instead, so the two directions were symmetric in code and one-way in effect, and the setting auto-saves on a 500 ms debounce with no save button and no confirmation. Opening the settings page to see what the option did was enough to destroy the configuration: the reporter's log shows four toggles in 85 seconds, which is someone looking and reverting, and the assignments never came back. The deletion was not careless. Checks that read both assignment tables would otherwise let a row in the mode you are not using answer for the mode you are, which is how #1473 was fixed, and emptying the inactive table made that impossible by construction. The cost was that the guarantee was bought with the user's data. That decision belongs to the readers -- the mode is a property of the install, not of the rows -- so spoolman_owns_assignments now answers it and nothing is deleted on a toggle. Each mode keeps its own assignments and switching is reversible. Existing installs need no migration: their inactive table is already empty, because it was being emptied. Six sites had to be told which mode they meant, and only two of them are the reads you would guess at, the missing-assignment notification and the queue cost estimate. The per-slot K-profile lookup consults the built-in table first and, on a hit with no matching profile, deliberately stops rather than falling through to Spoolman, so a leftover row would have shadowed the Spoolman binding for that slot -- the symptom #1556 reported from the other direction. configure_ams_slot *writes* a K-profile against whichever table answers first, so the same leftover would have filed a calibration against a spool the printer is not drawing on and never written the local one, leaving a calibration that appeared to succeed and then did not apply. The auto-unlink pass in on_ams_change is the one that would have made this change worthless. It drops any assignment whose tray no longer matches the fingerprint it recorded, and it ends in db.delete. Ungated, it would have removed the preserved rows one slot at a time as the AMS contents changed under the other mode -- the same loss, arriving slowly enough not to be connected to the toggle that caused it. The sixth is the built-in remaining-weight fallback inside the Spoolman AMS sync, and it is deliberately left inert rather than woken up. It could never fire while the table it reads was being emptied, it is keyed by slot rather than by spool, and create_spool writes remaining_weight unconditionally where the update path does not -- so preserving the rows would have seeded a stale figure into a brand new Spoolman spool the first time a tray reported an unusable remain%. The query stays, gated off, so the intent survives for whoever revisits the cross-mode fallback. Separately, a print that could not debit a spool said nothing about it, and that is what turned a mis-click into lost filament. The reporter's print was already running when they toggled. At completion it resolved its 3MF, read its per-filament grams, resolved its tray, and then skipped the debit because the assignment row no longer existed -- logged at INFO, invisible under the default log level, while the completion notification fired as usual. 65.49 g was never deducted and they only noticed because a spool's remaining weight looked wrong. _resolve_spool_id_for_tray has no tag or fingerprint fallback, so there was nothing else to catch it. The skip is now a warning naming the grams, and a completed print that failed to charge a tray it drew from raises the missing-spool-assignment notification. The print-start check cannot cover this and was right to stay quiet: the assignments existed when it ran. The two are different statements -- the first says the weight may not be tracked, the second says it was not -- so a print warned at start will notify twice, which is the right trade. Collected across the print rather than fired per slot, and given the caller's session, because this runs inside on_print_complete's transaction and opening a second one to read the printer's name would deadlock against it on SQLite. This is independent of the toggle and catches any other cause of an assignment disappearing mid-print.	2026-08-25 17:17:26 +02:00
maziggy	39835437a3	Price a print from the spool that fed it, not the default rate (issue #2591) ... Spoolman holds per-spool pricing, and #261 gave that as the reason for integrating with it. Nothing ever read it. A print's cost is set once, at archive time, from the built-in Filament catalogue matched on the primary type and falling back to a global default rate -- and in Spoolman mode nothing revisited that figure afterwards. The per-spool recompute that would have fixed it, in usage_tracker.on_print_complete, runs only over rows the built-in inventory writes, and Spoolman mode hands the usage tracker spoolman_owns_usage at print start so it writes none. The reporter's catalogue was empty, which is the ordinary state of one in Spoolman mode, so every print came out at the default no matter what the linked spool cost. Multi-material was wrong twice over there: the primary type's rate applied to the whole print's weight, so a slot of expensive PA was billed at the price of the PLA beside it. Each slot is now priced from the spool it was actually charged to, at the moment of the charge, and the per-slot costs are summed -- which is what fixes the multi-material case, rather than a separate change. All three charge paths feed it: per-slot, tray-split, and the remain%-delta fallback. The rate is the spool's own price when set, else the filament's, over filament.weight. That is net grams excluding the core, and the same field the remain-delta path already divides by to turn a percentage into weight, so a spool that can be charged by percentage can always be priced. The price comes out of the get_spool call the colour and material rewrites already pay for, so the tagged path costs no extra round trip. Grams no spool could price are covered at the global default in one subtraction against the archive's own total. A spool with no price, a tray with no Spoolman row, and filament the sliced file never attributed are the same case from here, and without the top-up a print with one priced slot out of four would report a quarter of its cost -- #1344 in the other inventory mode. Only the first run writes the archive, matching the built-in writer (#1378); reprint actuals live in PrintLogEntry. If no slot could be priced at all, whatever archive.py recorded is left alone, so an install with prices in neither place stays where it was. Applied even when the slot-to-tray mapping was a positional guess, unlike the colour and material rewrites beside it. Those overwrite what the slicer recorded, which is why a guess must not touch them. The cost has no such original -- archive.py's figure is itself derived from a default rate -- and the grams have already been deducted from these spools, so the archive should say what that deduction was worth. Both cost recalculations would have undone it on the next run. /rescan and /recalculate-costs rebuild an archive's cost from SpoolUsageHistory and fall back to the catalogue or the default when there are no rows, which in Spoolman mode is always, so the fallback was not a recalculation but a downgrade. The spool-to-slot resolution a price is derived from exists only while a print is completing and cannot be rebuilt from the archive row, so both now leave a cost alone rather than replacing it with a worse one, and the bulk endpoint reports how many it kept. An archive with no cost yet is still priced, and with Spoolman off both behave exactly as before. The rate parser refuses more than it looks like it needs to, because everything it refuses was reachable. A non-dict filament raised through a call that sits after a successful use_spool, which would have abandoned the remaining slots of a multi-material print with the charges already made. NaN compares False against every bound, including the applier's own total <= 0, so a NaN price would have been written to the archive with nothing downstream able to clear it; two finite operands can produce it by overflow, so the quotient is checked as well as the inputs. A bool is an int in Python, and float(True) is 1.0 -- a weight of 1 g prices a spool per-gram at its whole cost. And a spool-level price of 0 now falls through to the catalogue rather than reading as free: Spoolman leaves the override null when unset, but importers write 0 often enough that treating it literally would price a whole print at the default with a good catalogue price one level down.	2026-08-25 16:45:50 +02:00
maziggy	935d4b5bbf	Charge the tray the printer said it used, not the first one loaded (issue #2953) ... A sliced file numbers its filaments 1..4; which AMS tray each came from is decided when the job is sent. #2768 gave the Spoolman writer two ways to recover that decision when the print did not come through Bambuddy: the printer's own mapping field, and a colour match of the 3MF's slots against the loaded trays. An A1 satisfies neither. It publishes no mapping field, and it drops the MQTT connection when we subscribe to its request topic, so the slicer's instruction never arrives either. That leaves the colour match, and it compares hex strings exactly. The reporter sliced with a generic black profile against a tray they had set to charged slot 1 to whatever sat in the first tray -- 2.17 g onto a grey PLA+ spool, while the print was fed from tray 3. Their bundle carries the printer's own answer: "Tray change during print: tray=3 at layer=0", recorded 90 seconds in, and read further down the same completion pass by _print_used_tray_keys to decide which slots the print had touched. The same pass then charged tray 0 on a guess, and logged "AMS0-T3: remain% did not fall over the print" about the tray that had actually done the work. _single_slot_tray_from_state adds the third rung. For a print with exactly one slot carrying usage, the one slot came from the one tray, so the printer's tray reporting answers the question directly: the mid-print tray-change log, then the tray loaded at print start, then the current one, then the last real tray seen. That is the ladder usage_tracker.on_print_complete has consulted since it started resolving mappings at completion -- Spoolman users were the only ones not getting it, which is why an install running the built-in inventory has never shown this. On this printer only the first and last rungs can fire: tray_now_at_start is 255 because print start runs before the filament is loaded, and the A1 parks tray_now back at 255 the moment a print ends. Gated on exactly one slot with usage, like the internal writer: a multi-colour print moves tray_now on every change, so one reading cannot then be attributed to one slot. It also declines when the log holds more than one switch, because an AMS-backup runout is split per segment (#1793) and a single-tray mapping would land the whole print on one spool. That gate needed the guess warning to exclude the split path too. The split never reads slot_to_tray at all -- it charges each segment to the tray the printer announced switching to, which is the same evidence this fallback is built on -- so a declined mapping there is not a guess, and calling it one suppressed the archive rewrite for exactly the prints whose attribution is best supported. Nothing covered that combination; a test does now. Where nothing names a tray the positional default still stands, because it is right for an AMS loaded in slicer order. It now says so at warning level so a support bundle carries the reason, and it no longer restamps the archive's filament colour and material from a spool it picked by position. That restamp is what made the fault read as data loss: the grams can be put back, whereas overwriting what the slicer recorded leaves nothing to compare against, and the reporter's archive had already been rewritten from #000000 to the wrong spool's grey. A slot that consumed nothing also stops claiming a tray in the handled set -- it was never charged, so the remain-delta path should stay free to cover it rather than be suppressed by an estimate of zero. The request-topic probe is the same failure reached from the other side. A printer that refuses kills the TCP connection instead of returning a SUBACK failure, so the only signal is "we subscribed, then got disconnected", and that was believed the first time it happened. Every other reason a connection drops inside the same window looks identical -- a network blip, the printer rebooting, the container stopped mid-probe -- and the verdict was cached per serial with no re-probe anywhere, so on a printer that supports the topic one unlucky drop cost mapping capture for the rest of the process and every slicer print after it was charged by tray position. It now takes two consecutive drops, and a disconnect we asked for is not counted. A printer that genuinely refuses answers the same way every time and pays one extra reconnect; one already known to refuse still skips the subscription outright rather than reopening a reconnect loop.	2026-08-25 16:22:43 +02:00
Kouki Ojima	c3677865b6	Give the AMS temperature alarm its own threshold (issue #2905) (#2943)	2026-08-25 15:03:34 +02:00
Kouki Ojima	73912d4f05	Let a clear spool stay clear on the way to Spoolman (issue #2912) (#2924)	2026-08-25 13:45:57 +02:00
maziggy	d9bc7ae47a	Read a NULL notification flag as off instead of dropping every provider (issue #2827) ... Adding on_stock_reorder_alert and on_stock_break_alert to the provider schema made them required on the way out as well as in: the response model inherits the write model. Every on_* column on notification_providers is nullable with no server default, and where the table was created from Base.metadata before run_migrations, the ALTER ... DEFAULT false that introduced those columns was swallowed as a duplicate and never backfilled existing rows. Those NULLs were harmless until the flags were read, at which point the row failed validation -- and a list is validated as a whole, so one row took every provider with it. The route returned 500 and the UI rendered an empty list, so configured providers looked deleted. Backfill them to off, which is what the sender already assumed: it selects providers with IS TRUE, so a NULL flag never sent anything. A NULL flag now also reads as off rather than failing the response, across all of them, so the next flag added to this schema cannot repeat it. Writes are unchanged.	2026-08-25 13:09:24 +02:00
MagicMelody84	54af3146a3	[Feature]: Bind Home Assistant sensors to storage locations (dryboxes/bins) (#2827)	2026-08-25 12:17:23 +02:00
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.	2026-08-25 11:19:46 +02:00
maziggy	4e79f9c2f7	Fill in a fallback archive when the 3MF finally arrives (issue #2957) ... A failed TLS handshake pauses a printer's file service for five minutes, and the archive flow checks that pause at the top of its path loop and gives up before opening a connection. A print that starts inside one gets an empty fallback archive 13 milliseconds later, having never touched the network. Four minutes on, the pause clears and the cover endpoint downloads the same file, parses it, takes a thumbnail out of it, and publishes it to the shared 3MF cache under the exact key the archive flow looks up. Nothing ever looks: all three readers of that cache run before or during the print-start handler that already gave up, and print completion drops the cache as its first act, deleting the file. No path existed by which a fallback archive could become a real one. Offer a later 3MF to the running print's archive, filling the existing row rather than adding a second -- the row id carries the energy reading, the timelapse session and the start notification. That covers the reported case at no network cost, since opening the printer card already downloads the file. Schedule a bounded retry when the pause is what caused the fallback, spending the cache first and the printer only if that misses. Not scheduled for the other cause: a print kept on internal eMMC has no FTPS copy to come back for, and retrying it is the sweep removed in #2780. The two reasons are now recorded separately instead of both landing as "no 3MF". Recovery refuses anything that is not a readable 3MF -- a truncated download would replace an honest empty archive with wrong metadata -- and leaves an archive alone once it has a real file. Three things the recovery path has to get right, each with a test: Reduce every retry candidate to a bare name. MQTT hands `filename` over as "/data/Metadata/plate_1.gcode" on some firmware, and joining that onto the temp directory yields the absolute path itself, so the retry is fed the flow's own sanitised candidate list and strips the path again on its own account. Serialise recovery per printer. The cover endpoint's single-flight coalesces by view, so two views race each other, and the retry task and print completion can land on top of either -- each reads file_path == "" and runs a full copy, leaving the row on one timestamped directory and the rest orphaned. Keep looking for photos in the pre-recovery directory. `archive_dir` derives from `file_path`, so filling the row moves the archive's directory, and a photo uploaded to the empty card while the print ran stays where it was put.	2026-08-25 09:33:52 +02:00
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.	2026-08-25 08:49:24 +02:00
maziggy	ea898141f0	Decide migration idempotency by SQLSTATE, not by English error text (issue #2949) ... PostgreSQL renders its messages in the server's lc_messages locale. _safe_execute recognised an already-applied statement by searching the error text for "already exists", so a Russian-locale server -- which says "уже существует" -- re-raised it and aborted startup. The column already existing is the expected outcome: create_all() builds the tables from the models before the migration list runs, so on a fresh database essentially every ADD COLUMN in that list is a duplicate by design, and all 382 of them relied on that recognition. No PostgreSQL server outside an English locale could start Bambuddy at all, fresh install or upgrade. Classify on SQLSTATE instead -- 42701, 42P07, 42710, 23505 -- which PostgreSQL never translates. The existing narrowing is kept and now rests on a code rather than a phrase: a missing column counts as already-applied only for RENAME COLUMN, so a missing column during ADD COLUMN or CREATE INDEX still aborts rather than hiding a corrupt schema. SQLite keeps the text match; its driver publishes no SQLSTATE and it does not localise. The OIDC auto-link constraint read message text the same way and gets the same treatment. Verified against PostgreSQL 15 under ru_RU, en_US and C: init_db() completes on a fresh database and on a re-run in all three, and the schema the Russian server ends up with is byte-identical to the English one.	2026-08-25 07:55:49 +02:00
Kouki Ojima	f95c81e6cd	Take an RFID spool's core weight from the row that names it (issue #2909) (#2923)	2026-08-24 11:51:22 +02:00
maziggy	b1f5ec9642	Let one checkbox say where a slice's settings come from (issue #2942) ... Two features in the slice dialog read as one. "Use the file's built-in settings" slices a 3MF the way its designer set it up, ignoring the picked profiles. The per-option "from file" ticks beside each setting carry the designer's individual deviations onto the profile you picked, and those arrived pre-ticked whatever the checkbox said. So a slice run deliberately without the file's settings still took sixteen values out of it -- the reporter's log names them, enable_support and support_type among them, landing on a process preset they had chosen on purpose. The ticks now follow the checkbox. Off, nothing comes out of the file until it is asked for by name; on, every setting the file changed shows ticked, because on that path the file really does drive the whole slice. Taking the designer's work in bulk is still one click, from a line at the top of the panel that says how many settings the file changed -- it is the only way left to reach them without hunting for chips across six pages of 348 options -- and it still leaves the machine-tuned keys and the two that are the picked preset for a per-key decision. The panel greys out options the slicer's own rules switch off, and it was evaluating those rules against what the user had typed alone, falling back to the compiled-in schema defaults for the rest. A preset with supports on therefore read as enable_support: false and greyed out the whole Support page while the slice ran supports. A greyed row greyed its tick too, which is how the reporter's screenshot shows a support type marked "from file", applied to the slice, and impossible to clear. The rules now see what the slice will actually run with: the preset's values, the file's values for the keys that are on, and anything typed on top. The tick is no longer gated on those rules at all -- it answers a different question, not whether an option is in play but where its value comes from. Underneath both, the support carry-over ran outside the ticks entirely, lifting four keys out of any 3MF that had supports on with nothing on screen able to decline. It now stands down for the keys that were offered and turned down, which the request can say for the first time: an empty design_overrides list means the caller was shown the file's settings and took none, where no list at all is a caller that predates the choice. That distinction is what keeps the carry whole for sources with no deviations to tick, an OrcaSlicer export among them, rather than trading one silent default for another. Worth knowing: a Bambu Studio file with supports enabled no longer switches supports on for you. Tick Enable support, or the checkbox above the panel. Measured against the reporter's own sixteen keys, and covered by backend and frontend tests -- reverting any one of the three changes fails tests.	2026-08-24 11:04:33 +02:00
maziggy	6988a30eae	Carry a fault's description in the status response (issue #2926) ... The HMS catalogue has been in the backend all along and the status response never carried it, so every consumer that wanted to tell a user why a print halted resolved the same 853 codes from its own duplicate of the same sentences -- this repo's Python table, the frontend modal's, and at least one third-party client whose catalogue exists purely because the server would not say. Each ages separately, and a relay watching a printer could only manage "your printer needs attention" while the server already knew it was "Filament ran out. Please load new filament." hms_errors[] entries now carry a description, defaulting to null so a client that has never seen the field is unaffected. It is resolved where the fault is parsed rather than at the boundary that prompted the request, because there are three serializers of a fault, not one: the status response, the WebSocket broadcast, and the completion payload the queue's failure reason is built from. Adding it to only the first would have handed half the feature to a relay watching the stream, which is the likelier consumer of the three. The queue's failure reason now quotes the resolved sentence instead of looking the code up a fourth time, and the notification path reads it rather than re-deriving. That they cannot report different text for one fault is the point, and a test asserts they agree. describe_fault is the single mapping from either code shape onto the table. An 8-char print_error is the catalogue's MMMM_EEEE key with the separator removed -- the parser derives full_code and that key from the same 32-bit value -- so it resolves exactly. A 16-char hms[] identifier is tried whole and then collapsed to its first and last groups. That collapse is lossy, and keeping it was the decision worth making carefully. #2728 counts 65 documented faults falling onto 0300_0001 alone, so a hit can attribute a neighbour's sentence to this fault, and refusing it looks like the stricter reading. It is not: the notification path, the queue's failure-reason helper and the frontend modal have all resolved hms[] faults this way for as long as they have existed, and it resolves real ones -- a 0500_4038 nozzle mismatch arrives in that shape. Declining to collapse would have stopped describing faults that are described today, silently suppressed the notifications they raise, and left this field null while the UI showed text for the same fault. Narrowing it belongs with #2728, where both key spaces can move together. So the lookup is exactly what it was, verified rather than asserted: a test walks every catalogue code in both fault shapes across all three alert levels and checks the result against the derivation this replaces. A future change to the lookup cannot quietly stop notifications firing. The catalogue ships one language, so the field is English and unlocalized, which the schema and the API reference both say next to it. The camwall feed is deliberately left alone -- it is code-only because its token travels in a URL on a screen, and a readable sentence discloses more than the camera picture already does. The frontend keeps resolving its own text: switching it would change what filterKnownHMSErrors counts across eight call sites, which is #1840 and #2728's argument to have. HMSError.message goes with this -- a text field that was never set or read anywhere, and an invitation to populate the wrong one now that a live description sits beside it. ----- Record a failure code the user can actually look up The queue's failure reason formats a fault's module and error into MMMM_EEEE, and that one derivation never masked the error to 16 bits. A fault arriving from the printer's hms[] array carries its alert level in the code's high half, so the label came out as 0500_24038 -- five digits in a group that has four. It is not a code anyone can find on Bambu's HMS index, and because it matches no catalogue key the sentence explaining the failure was dropped along with it, leaving the bare number alone. The nozzle-size mismatch behind #1111 is exactly such a fault. Reported one way it read "[0500_4038] The nozzle diameter in sliced file is not consistent with the current nozzle setting"; reported the other, the same physical fault read "[0500_24038]" and nothing else. There is already a helper that gets this right, used by the archive's own failure-reason lookup, so this calls it instead of keeping a fourth copy of the derivation. It also takes the raw integer code the MQTT payload carries, which the local version only handled as a string.	2026-08-24 09:47:39 +02:00
maziggy	c094102614	Let a virtual printer be told which address to advertise ... BambuStudio reads its FTP upload destination out of net.info[].ip in the MQTT status, and the bridge fills that field from the VP's bind address. On Docker bridge networking the two are different machines' worth of address: slicers reach Bambuddy on the host's LAN IP, the container binds something like 172.24.0.2, and that private address is what the slicer was handed -- so it opened an FTP connection to an address that does not exist on its network and the send stalled around 10%. VIRTUAL_PRINTER_ADVERTISE_ADDRESS supplies the address slicers actually use, taking precedence over the bind address and over the same-subnet host interface the bridge falls back to. The armed log line names its source, so (VIRTUAL_PRINTER_ADVERTISE_ADDRESS) against (bind_address) tells an operator whether the variable reached the container at all, and the not-armed diagnostic now names it as the remedy -- a bridge-network install that has not set it is exactly the one that cannot auto-resolve either, and until now saw only that nothing worked. An environment variable rather than a change to how the advertised address is resolved, which is the decision worth recording. The VP already has a "Network Interface Override" field, and reading it here is the smaller patch, but it feeds SSDP and the certificate SANs only: honouring it would silently move the upload destination on every install that has one set -- the multi-NIC, VLAN and Tailscale setups, which are the ones most likely to have been arrived at by hand and least likely to survive being second-guessed. Unset, this changes nothing, and a test pins that. A value that is not a dotted-quad IPv4 is refused with one warning naming it and the previous address is used instead. That direction is deliberate: declining to rewrite would put the real printer's IP back in front of the slicer, which is the leak the rewrite exists to close, so a typo must not be able to reopen it. 0.0.0.0 counts as unset and whitespace is stripped, for values pasted into a compose file. Host and macvlan networking need none of this and stay what Virtual Printer is developed against. The variable removes one blocker; it does not make bridge mode equivalent. The wiki said in three places that the host address could not be discovered at all, which is no longer true, so those now describe the variable and keep the recommendation.	2026-08-24 08:58:41 +02:00
maziggy	537b4d2509	Stop offering AMS slots as places to store a spool ... The Storage Location dropdown listed entries like "H2D-1 - AMS A1" next to real locations, and they could not be got rid of. They were never locations. Bambuddy used to record which slot a spool was loaded into by writing that string into Spoolman's location field, and the writer went away when Storage Location became something the user picks -- but the strings stayed on people's Spoolman spools, and the location sync imports every distinct one it finds, so they have been coming back in through the front door ever since. A printer slot is where a spool is loaded, not where it is put away, and slot assignments already track the first. Deleting one by hand did not work either, which is what made this a dead end rather than an annoyance: the delete route refuses a location that has spools, and in Spoolman mode it counts them by matching that same string, so every marker still sitting on a loaded spool answered 409 -- and the two that were empty were back on the next sync a minute later. The import now skips them and a one-shot migration clears the ones already in the catalogue. The shape is defined once and used by both: an optional printer-name prefix followed by AMS A1, AMS-HT A1 or External Spool, which is exactly what convert_ams_slot_to_location produced. It stays narrow on purpose -- "AMS Drybox" and "Spare AMS trays" are somebody's shelf, and anything the filter swallowed would be a place they could no longer file a spool under -- so both directions are pinned by tests. A row is only removed when no spool in this database points at it, by id or by legacy free-text name, so an internal-mode user who has deliberately filed spools under such a name keeps it. Spools in Spoolman are neither consulted nor touched: their location strings are the user's data on the user's server, and one that still reads "H2D-1 - AMS A1" in the inventory list is telling the truth about what Spoolman holds. It simply stops being offered as a destination. Verified on a live Postgres instance carrying the reported symptom: 13 locations down to 3, all ten markers removed, the two real shelves and one hand-typed Spoolman name left alone.	2026-08-23 15:17:09 +02:00
maziggy	b38022ec5c	Draw a spool the way the AMS described it, and correct the tare it was added with ... Two faults in the same auto-add path, both found while tracing why an H2C slot named a wood roll as plain PLA. A spool's swatch is composed from effect_type and extra_colors, and the RFID auto-add set neither. It reads the colour catalogue to name the colour and took the name alone, even though the row it had in hand also carries those two columns -- the spool form's own colour picker hands both to a spool a user adds by hand, so the same roll rendered one way when you typed it in and another when the printer identified it for you. Both columns now travel with the name. That alone changes nothing on a stock install, because the shipped catalogue carries an effect on none of its 600-odd rows, so the subtype is read where the catalogue has none: it is already derived from what the printer reports, and the two vocabularies line up -- Wood, Silk, Sparkle, Marble, Glow, Galaxy, Metal, Rainbow, Translucent, Matte, and the Gradient, Dual Color and Tri Color that the M*/T* colour codes upgrade a subtype to. "Silk+" reads as Silk, since the plus is on the product name rather than the finish. A subtype that names no effect -- Basic, Tough, CF -- leaves the column empty rather than inventing an overlay, and a value already set is never overwritten, so the column stays what it is documented to be: a rendering hint the user can override without touching Bambu's categorical label. ------ Correct the spool tare an RFID roll was added with (#2909) The lookup that gave an auto-added spool its core_weight asked for the first catalogue row whose name starts "Bambu Lab" and took whatever came back. There are three, and which is first is the database's business: SQLite returns insertion order in practice, Postgres promises nothing once a table has seen an update. The same roll was therefore recorded with the 216 g High Temp tare on one install and correctly with the 250 g Low Temp one on another. @ojimpo's forward fix picks the row by name; this repairs the rows already written, which the forward fix cannot reach -- 22 of 26 RFID-added spools on the instance this was traced on. The tare is not cosmetic. A spool weighed on SpoolBuddy has its remaining filament worked out as the scale reading minus the tare, so a 34 g low tare credits the roll with 34 g that is not there and writes a used weight 34 g short. That error is a constant -- every later print adds to the used weight on top of it -- so adding the difference back is exact however much has been printed since. It is applied only to spools that have been on the scale; one that never was has a used weight derived from the AMS remaining percentage, which the tare never entered into. Rows are identified by the signature of the broken lookup: added by RFID, carrying the weight of one of the other Bambu catalogue rows, with the weights read out of the catalogue rather than hardcoded so an install whose rows have been re-measured is repaired to its own numbers. Keying on whether a catalogue row had been recorded would not have worked -- the weight picker auto-selects the only row matching the weight and writes its id on the next save, so that column says only whether the form was ever opened. The one case that cannot be told apart is stated rather than hidden: someone who moved an RFID roll onto a genuine High Temp spool and set 216 g by hand is normalised with the rest. Runs exactly once, so a tare set afterwards is kept.	2026-08-23 14:25:45 +02:00
maziggy	7b181b84f0	Let a filled or foamed filament keep its own name (issue #2902) ... The reduction that gave an AMS slot a material type read PLA-AERO, PLA-GF, ASA-GF and PPS-GF as their base material, so a slot loaded with foaming or glass-filled filament went out saying plain PLA or ASA. That is worse than the bug it replaced. "PLA-AERO" matched nothing before, which was useless but honest; "PLA" matches every PLA plate in the queue, so the dispatcher would have sent one to filament that will not print it -- and the contract the first fix claimed, that it could only ever repair a slot, no longer held. @doncaruana caught PLA Aero on the issue. All four are values Bambuddy itself offers: filament_fields.json is the material list the Profiles editor puts in a dropdown, and the reduction table was assembled from the cloud filament names and the frontend preset parser without ever being checked against it. It is checked now, so the next type added to one and not the other fails a test rather than a print. ASA-AERO joins them from the cloud catalogue (GFB02). The table hyphenates because the slicers do, while a spool says "PLA Aero" and every Bambu preset name says "Bambu PLA Aero". Adjacent words are joined and taken when the join is a type exactly -- exactly, because letting the prefix and suffix rules reach across a space would make "Support for PLA" a type by its tail. Also from @doncaruana, and the better half of his point: a preset is chosen from a list the slicer defines, so it already knows its own type and nothing has to be read out of a product name. The resolver now hands that answer back and both assign routes prefer it. It cannot be the only source -- material is required on a spool and slicer_filament is not, and the spool this issue was reported for had no preset at all -- so the reduction stays as the fallback for spools without one. Two things had to move with it. The auto-unlink guard compared the slot's reported type against the reduced material, so a spool whose preset outranked its material column would have been unlinked from the slot it had just been assigned to; it now accepts any type the assign path could have written. And two lookups keyed by material took the catch-all for a type they had no row for, which sent an ASA-GF spool out at 200/240 -- too cold to extrude -- and preheated its chamber to nothing. Both fall back to the base material last, so PLA-CF, PETG-CF and PA-CF keep the rows they are listed with, and ASA-CF and ABS-GF pick up ranges they had been missing all along. What counts as a material name is decided by the base for the same reason: saying yes throws the value away and rescues the slot from the generic-material fallback, so the answer has to be no when that fallback has nothing to offer. ABS-GF reduces to a generic ABS the printer can resolve; PPS-CF reduces to nothing and is left as it stands. Adding a type to the table therefore cannot quietly change that answer, which is how these five slipped through in the first place. ------ Hand the bundled chamber-preheat table back the way it is read Every lookup of the per-filament chamber map happens after the keys are upper-cased, and the parser documents exactly that: keys uppercased, DEFAULT always present so the resolution loop can index it unconditionally. The three fallback paths returned the bundled constant as declared, with the lowercase "default" row the Settings editor writes and displays, so an install that had never opened the setting got a dict the loop could not read its fallback out of and used a hardcoded 0 for any filament without a row of its own. It reported the right number only because that bundled default is 0. Raising it would have changed nothing for everyone who had not customised the map, with the map in Settings still showing the value that was not being used. The test that should have caught this asserted the fallback under either spelling, and its docstring contradicted itself between title and comment. It pins the contract now, over all four ways the parser can fall back.	2026-08-23 10:36:50 +02:00
Maksim Sadontsev	ed85677913	Light the generated thumbnails so one model differs from another (#2816) (#2861)	2026-08-22 14:16:56 +02:00
Sean K	55cc64c87d	Add printer video downloads and range selection (#2853)	2026-08-22 13:22:56 +02:00
sgiffhorn	937440f956	Report the selected plate on the archives API (#2796) (#2871)	2026-08-22 12:44:47 +02:00
maziggy	4e40a5022c	Register a Spoolman extra field with its own write (issue #2903) ... Spoolman rejects a spool whose extra dict carries a key it has not been told about, answering 400 "Unknown extra field tag.". Bambuddy keeps the tray UUID in extra.tag, so that key has to exist before the first spool is created. Registration ran from three hand-maintained lists that fire when the integration is set up -- the connect route, startup, and two inline blocks in the inventory routes. Enabling Spoolman from the Settings page reaches none of them, so the first AMS sync on a fresh Spoolman failed on every slot while vendor and filament creation succeeded. Neither fix suggested on the issue is quite the right shape. Adding the block to PUT /settings/spoolman fixes this path and makes a third copy of a list that has already drifted -- it would still omit bambu_color_name. Ensuring at the sync entry point leaves the other four tag writers alone: linking and unlinking a tag, and both inventory edit paths. So the registration moved to the write. create_spool, update_spool and update_spool_full each register the keys of the extra dict they are about to send, once per client, before sending. Every tag writer funnels through one of the three, merge_spool_extra included. This closes the class rather than the instance: a write that carries a key is a write that registers it, and bambu_color_name shows why that matters -- it never made it into the connect or startup lists at all, and works today only because two call sites remembered it by hand. Best-effort, deliberately. ensure_extra_field already logs and returns False rather than raising, so a registration that fails leaves the write to be attempted and to report exactly what it reported before. Failures are not memoised either, so a Spoolman that was merely restarting gets another try on the next write. The older blocks stay. They are redundant now, but the inventory routes' inline calls are pinned by tests that assert them against a mocked client, where the funnel cannot run. The status endpoint is the other half. The Connect button would have registered the fields, and the reason nobody reaches it is that GET /spoolman/status reported "connected" whenever an earlier request had left a client object behind. Roughly twenty call sites build one lazily, and saving the Settings page builds one as a side effect of syncing locations, so the flag turned on which page had been opened rather than on anything about Spoolman. The UI reads it twice -- Connect only while disconnected, the sync section only while connected -- so those two controls landed in states the user cannot explain. It now asks the Spoolman that is configured, including the stale-URL check every other route already does, and does not probe at all when the integration is switched off, which used to let a leftover client report a disabled Spoolman as connected. That leaves nothing for Disconnect to do, so it is gone. Spoolman is a stateless HTTP API with no session to close; the button dropped the client object, the next request rebuilt it lazily, and the status flipped back on its own within the 30s poll -- an action that looked like it worked and then quietly undid itself. The enable toggle owns turning the integration off. Connect stays as what it always was in practice, a way to re-check a Spoolman that is not answering, and is shown only then. Its translation keys are left in place; only the control is removed. Resolving the client there means the status poll can now fail in ways a read-only check could not, so it no longer reports failure by failing. Replacing a client closes the previous one and httpx's aclose() is not guaranteed not to raise; a poll that runs every 30 seconds answering 500 is worse than one answering what is true either way, which is that Spoolman could not be reached. The SSRF rejection keeps its own message rather than folding into the general one -- a URL the guard refuses is the admin's to correct, and that is only actionable if the log says so. Tests drive the real client against a fake Spoolman that enforces the unknown-extra-field rule rather than mocking it away, so each one fails against the old code for the reason the reporter's install did. The concurrency test needed the fake to be async: MockTransport answers without suspending, so the first version ran each request to completion in turn and passed just as happily with the lock removed.	2026-08-22 12:26:18 +02:00
maziggy	88e8ca81c3	Give an AMS slot a material type, not a product name (issue #2902) ... Assigning a spool wrote its material straight into the slot's tray_type. A slot that says "PLA+" satisfies nothing that asks for PLA: not OrcaSlicer, not Bambu Studio, and not Bambuddy's own dispatch matcher, which compares the type the printer reports to the one the 3MF declares as plain equality. The reporter's slot was unusable for every PLA plate he had. Not only a label, either. The same string went into the generic-filament lookup, which missed, so the slot went out with no tray_info_idx at all -- the half-configured state #2604 documents the printer as reverting from -- and took the 200/240 catch-all nozzle range instead of PLA's 190/230. PLA+ is not a special case. Bambuddy's own colour catalogue supplies the material dropdown, and around forty of its values are vendor product lines rather than filament types: HTPLA, PolyTerra PLA, PLA Matte, ASA Extrafill, Flexfill TPU 98A. So the four routes that configure a slot reduce the material to a name the printer knows before sending it, and the product name moves to tray_sub_brands -- which is where Bambu Lab puts it too: their catalogue carries a preset named "eSUN PLA+" whose type is PLA. A name the reduction cannot place is sent exactly as before rather than guessed at, so this can only repair a slot, never break a working one. The spool's own wording still leads the id and temperature lookups with the reduced type appended behind it, so "PETG HF" keeps its own generic preset (GFG96) rather than being traded down to plain PETG's. Two guards decide whether a candidate filament id is really a material name -- the resolver's, which discards one, and slot reuse, which will not carry one forward. Both saw only bare types, so "PLA+" passed as a filament id. They share one answer now, which also refuses to read an id-shaped value: "GFPLA" ends in a material name, and reducing it would throw away the calibrated preset in the slot. One thing had to move with it. on_ams_change auto-unlinks an assignment whose slot stopped looking the way it did when the spool was assigned, and the check that spares a slot Bambuddy itself reconfigured compared the printer's reported type against the spool's raw material. With the slot now carrying the reduced type, every spool this issue is about would have been unlinked from the slot it had just been assigned to. Both sides are reduced there -- the printer's too, so slots configured by an older version, still reporting "PLA+", keep matching. Something starts working as a result: a slot holding a calibrated preset is reused when a same-material spool is assigned to it, which could not happen for these spools while "PLA" and "PLA+" compared unequal. Reverting any one of the behaviours above fails a distinct test -- the reduction's four matching rules and its pass-through contract included, since that contract is what makes the rest of it safe.	2026-08-22 11:41:28 +02:00
maziggy	cc39acfc74	Ask a printer that refuses FTPS what it actually said (issue #2780) ... @grolmus measured a 9-printer farm and the numbers settle what this failure is not. Reproduced here, three results: cleartext "421" banner on the TLS port -> [SSL: WRONG_VERSION_NUMBER] wrong version number (_ssl.c:1032) 1.2-only server, client forced to 1.3 -> [SSL: TLSV1_ALERT_PROTOCOL_VERSION] 1.2-only server, an uncapped client -> negotiates 1.2 and connects The first is byte-for-byte what the farm logs. So WRONG_VERSION_NUMBER means the printer's first bytes were not a TLS record, a version mismatch cannot produce it, and reaching a 1.2-only peer needs no cap. What it still does not say is WHICH cleartext message, and that is the part that would name the fault. OpenSSL has eaten those bytes by the time the exception surfaces, so on this error the client now opens one plain connection and reads them. The log then carries the printer's own words -- an FTP refusal such as "421 Too many connections" would settle it outright -- marked as the line to quote in a report. This gets the answer from every affected install rather than from the one farm able to take a packet capture. Three things keep it from making the suspected fault worse: - The failed socket is closed BEFORE the probe opens its connection. Holding a dead handshake open across a second connect to a printer that may be out of connection slots is the leak #2780's own cleanup was added to stop. - It asks once per cool-off window, not once per attempt. Checked before the new deadline is written, so a live entry means an earlier failure already asked -- which matters because a dispatch ignores the cool-off (#2898) and reaches this branch four times. - Connect and read share one timeout budget rather than getting one each. Only WRONG_VERSION_NUMBER is probed. A protocol-version alert means the peer did speak TLS, so there is nothing in the clear to read and the probe would only sit out its timeout. A vsFTPd answering its connection limit by accepting and staying silent -- the other half of the standing theory -- arrives as a handshake timeout and lands on that branch instead; there is a test saying so, because widening the trigger later would look like an improvement. The profile registry is corrected to what was measured. Its docstring claimed "the P2S evidently does offer 1.3"; six P2S units refuse it. Worse, the X2D (#1638) and H2C (#2582) entries were capped on the reading that WRONG_VERSION_NUMBER came from a TLS-1.3 ClientHello, which cannot happen -- so the cap is not what changed those outcomes and both are now marked RE-TEST WANTED. They are kept rather than removed: their reporters saw the symptom clear, nobody here has that hardware, and the entry costs nothing on a printer that does not offer 1.3 anyway. The P2S entry (#1401) is a different symptom -- a 426 truncation mid-transfer -- and is the only one a session-ticket problem could explain, though grolmus's firmware refuses 1.3 there too. Both measurements are pinned by tests, so the explanation stays falsifiable instead of becoming the next set of confident wrong comments. Two existing cool-off tests now count two connections where they counted one; the promise they exist for -- contacted twice, not ~110 -- is unchanged, and they say why rather than carrying a new number.	2026-08-22 10:50:22 +02:00
maziggy	70ee53464d	Say why an upload failed instead of blaming the SD card (issue #2899) ... Every dispatch upload that failed carried one sentence: "Failed to upload file to printer. Check if SD card is inserted and properly formatted (FAT32/exFAT)." The reporter got it after a TLS handshake failure and restarted the printer on the strength of it. That could not have helped. The handshake never reached the printer's filesystem, and the cool-off that made the next dispatch fail the same way lives in Bambuddy's own memory, where power-cycling a printer does not reach. because the advice was known not to work. It survived in the string people actually read, so the failure mode that fix closed was still reachable through the UI. reachable through the UI. The information was never missing. connect() separates five failure classes and upload_file() separates 553/552/550, each with its own log line -- 553 even logs a spelled-out list of storage causes -- and then both returned a bare False. The dispatch had nothing left to work with and guessed storage for all of them. So the reason now travels with the result. The client records an FtpFailure (kind, detail, and the reply code where the server gave one) on every failure branch, and upload_file_async fills in a report object the CALLER owns. Not a per-IP dict beside _mode_cache: those describe a printer and are right to share, while this describes one operation, and a background timelapse fetch running beside a dispatch would overwrite the dispatch's reason with its own -- reporting the wrong cause with total confidence, which is this bug again rather than a fix for it. describe_upload_failure() picks the wording, and lives next to the kinds so the two cannot drift. A 553 or 552 keeps the card advice, which is the case it was written for, and quotes the reply code so a queue entry and a support bundle line up. A handshake failure says the file service answered without TLS and that the card is not involved. A refusal points at the access code, a timeout at the network, and anything unclassified says so and points at the log rather than picking a plausible cause. A wrong instruction costs more than a vague one: it sends someone to work on hardware that is fine. Nothing prescribes a power cycle. The failure notification now carries the same sentence the queue shows, instead of its own fixed "Failed to upload file to printer", so a push and the screen cannot disagree about what happened. Tests cover the classification, the report reaching the caller through the retry loop, two callers not crossing, the queue entry itself, and one line per message branch -- without that last one, deleting the access-code or timeout branch left every other assertion passing, since they only check that the card is not named and the generic message satisfies that too. The card-advice test keys on the instruction rather than the words "SD card", because the handshake message names the card in order to rule it out.	2026-08-22 10:26:12 +02:00
maziggy	7c8f1f9435	Keep a dispatch's retries out of the FTPS cool-off (issue #2898) ... A failed TLS handshake arms a 300s per-IP cool-off, and connect() consulted it for every caller. A print dispatch retries after 2s, so once the cool-off was armed all four attempts were answered from the gate rather than the network, and every further job queued for that printer failed the same way for the rest of the window. The reporter's farm lost three jobs to one handshake error, with the retry budget contributing nothing to any of them. The gate was serving two callers that want opposite things from it. The background sweeps -- the post-print 3MF, cover and timelapse fetches -- walk ~110 candidate paths against one wedged printer with nobody waiting, and backing off for minutes is right for them. A dispatch is one delete plus at most four upload attempts with someone watching a progress bar. So the split is by caller: a client built with respect_handshake_cooloff=False goes to the printer regardless, and the dispatch's delete and upload -- and a firmware upload, same shape -- opt out. Everything else keeps #2780's behaviour untouched. In the reported trace it is the pre-upload delete that takes the SSL error and arms the cool-off, 8ms before the upload's first attempt, so exempting the upload alone would have left one dispatch's worth of the problem in place. Callers that do respect the cool-off no longer sleep out a retry loop against it: with_ftp_retry takes the printer's IP and stops at the attempt that armed the gate, instead of spending three more attempts and six seconds on connections that cannot happen. It also reports the attempts it really made -- "failed after 4 attempts" for one attempt is part of how this read as a network problem. Two diagnosis fixes go with it. The cool-off skip was the one connect() failure path that reported without naming its cause, and at DEBUG, so four identical reason-free warnings were all the operator saw. It now says at WARNING that nothing was sent and how long the printer has left, once per cool-off rather than once per attempt -- not every caller is gated, and a download-zip of 200 files would otherwise repeat the sentence 200 times, which is the flood #2780 set out to stop. And a dispatch that fails this way no longer tells anyone to check whether the SD card is inserted and formatted -- nothing reached the printer's filesystem, so the card is the one part of the machine that was working. The message names the file service and rules the card out. It is used only when a handshake failed during the dispatch itself, read from the cool-off deadline MOVING rather than merely being armed: the dispatch ignores the gate, so it can be running underneath one an unrelated background fetch left behind, and blaming TLS for an upload that really hit a full disk would repeat the mistake in the other direction. Tests count sockets rather than return values, since "returned False" looks identical whether or not anything was attempted -- which is what made the original report a log dive. Reverting any one of the five behaviours above fails a distinct test.	2026-08-22 10:05:05 +02:00
maziggy	4961990a7a	Let a print start on a nozzle the printer can fetch (issue #2885) ... The nozzle-diameter guard compared the sliced diameter against the mounted hotends alone. On an H2C both hotends commonly read the same size, so a job sliced for anything else was failed before upload with "install the matching nozzle before printing" -- even with that nozzle sitting in the tool-changer rack, which the printer fetches by itself as part of starting a print. The reporter saw it as an asymmetry: going to 0.4mm always worked, going to 0.2mm never did, and only fetching the nozzle by hand on the printer's own screen let the print run. It was never only about 0.2mm -- with a 0.6mm docked and 0.4mm hotends, a 0.6mm slice was refused identically. Placement is what made it fatal rather than merely wrong. The guard runs near the top of _start_print and the rack picker near the bottom, so the item was failed before the code that would have chosen the dock ever ran. Bambuddy had the rack contents the whole time. nozzle_info carries an entry per nozzle -- ids 0/1 for the hotends, 16-21 for the docks -- each with its diameter, so the guard now tests the slice against both sets. It keys off the ids rather than the printer model: only a rack machine reports 16-21, which leaves no registry to keep in sync. An empty dock is absent from the payload entirely, so an id appearing there already means a nozzle is in it. stat is left uninterpreted; it read 0 on every entry, occupied and empty alike. A diameter in neither a hotend nor a dock still stops the print before it uploads, and the message now names both sets so the machine's real stock is visible. The same telemetry showed a second fault, pointing the other way. A hotend with nothing mounted is still reported, keeping the diameter of the nozzle it last held -- measured at idle, where the rack-side hotend read 0.4mm with max_temp 0 and serial "N/A" after parking its nozzle back in the dock. That stale value counted as installed. Presence now comes from the serial and the temperature rating, and emptiness has to be stated rather than merely unstated: the serial must be the firmware's explicit "N/A" and the rating absent. A firmware that reports neither field normalises to exactly that, and reading it as empty would switch the guard off on that machine. Confirmed on an H2C with 0.4mm hotends and a 0.2mm in R6: the job dispatches with nozzle_mapping [21], chosen by Bambuddy rather than left to the firmware.	2026-08-22 08:46:07 +02:00
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).	2026-08-19 09:06:11 +02:00
maziggy	dd50c51c1b	Stop waking printers that cannot print the queued job (issue #2876) ... The queue's smart-plug step chose a printer to switch on by model alone. With a class-targeted job and every matching printer off, it walked the farm in printer-ID order, woke the first machine with an Auto On plug, and only then read the loaded filament -- so a job for a colour loaded at the far end of the farm woke every earlier printer in turn and left each one running until its own auto-power-off timer expired. The colours were known the whole time. A printer keeps its last reported AMS and external-spool trays after the power goes; mark_power_off blanks connected and state and leaves raw_data alone. The wake step now asks the same three questions the matcher asks a live printer -- required types, forced colours, preferred colours -- of that reading, and passes over a printer it rules out. A printer with no reading at all is still woken: never having heard is not the same as nothing being loaded. The matcher reports such a printer as needing filament rather than as offline, so the waiting reason explains why nothing was switched on. The manager now keeps a printer's last tray reading when it drops the client, and the queue falls back to that. _power_on_and_wait calls connect_printer in a retry loop, so an attempt that timed out used to erase the reading the next one depends on. The record is kept beside the clients, not inside one: the AMS merge is additive, so feeding it back into live status would merge an unplugged AMS unit back in for good.	2026-08-19 08:26:43 +02:00
maziggy	7e77bf5833	Take the layer height from the plate that actually printed ... The archive card, the library file details and the slice dialog all read the layer height from a 3MF's project_settings.config. That records the project's settings and can still describe an earlier process or another plate; the plate's own G-code - what the printer executes - was never consulted for it, because the parser read the first 4KB, enough for the layer count in the header block but not for the config block that carries layer_height 14-25KB in. A print running at 0.08 on the H2C archived as 0.2 with the layer count from the same file correct beside it. The plate G-code now wins wherever the two disagree, and the plate that was printed is the one read - the header parse used to take the first gcode entry in the zip regardless of which plate the archive was for. Source 3MFs, which carry no G-code, keep the project value as before. --- Stop carrying a file's layer height over the preset you picked Bambuddy carries a designer's process deviations across a re-slice (#2622) and pre-ticked every one that was not machine-coupled. layer_height is one MakerWorld projects routinely carry, so picking "0.08mm High Quality" for a file whose designer had moved layer height to 0.2 sliced at 0.2 while the dropdown still read 0.08 - the same 0.2 the settings panel showed, tagged "from file". Layer height and first layer height are now classified preset_defining and treated like the machine-coupled keys: offered, never pre-selected. The flag travels on DesignOverride so the modal and the backend agree, and the panel's badge names the conflict and shows the preset's own value next to the file's, so ticking one is a deliberate choice.	2026-08-18 16:23:32 +02:00
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.	2026-08-18 14:04:18 +02:00
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.	2026-08-18 13:43:46 +02:00
maziggy	d227d42272	Let a print with no 3MF be given its filament weight (issue #1820) ... When the sliced file stays somewhere Bambuddy cannot read, the archive is built from the printer's report alone and carries no weight. Nothing could supply one afterwards: rescan reads the figure out of the 3MF, and that archive has no file to read. The reporter's H2S print left 46.16 g on the spool with nothing recording it, and he corrected Spoolman by hand. Edit Archive now has a Filament used (g) field. It is written to the archive's most recent run as well, because the Projects roll-up and the Prometheus counter sum PrintLogEntry rather than the cards - correcting only the archive would fix the display and leave every aggregate reading the old figure, or none at all. But not over a figure the run measured for itself. A run's grams come from the tracked spool delta when there is one and only fall back to copying the archive's estimate when there is not, so mirroring unconditionally would overwrite a measurement with a typed estimate. The mirror now takes a run that has no figure, or one holding exactly what this archive held - which also makes the undo complete, since clearing the archive clears the copy it made and leaves a measured run alone. The field is text rather than a number input. A number input reports an empty string for anything the browser judges malformed, a decimal comma in a locale that does not expect one included, and that reads here as "the user cleared it" - it would have wiped a good figure while the field still showed what was typed. Filtering on the way in keeps what is displayed and what would be sent the same string, and clamps it to the range the API accepts: this modal has no error surface, so a refused save looks like nothing happened at all. Saving also invalidates the archive's runs query. The Print Log this modal renders at its top reads them separately and kept serving the pre-edit row, so a correction looked like it had not taken - true for the status and failure-reason mirrors since #1444 as well. Second half of the same report: the internal-storage probe (#2856) logged which file it found but not where. On a printer that keeps uploads for weeks - the reporter has months of them in /cache - a reprint of a name that was re-sliced but never re-sent can match an older copy, and without the directory that mismatch is invisible rather than merely rare. The download helper returns the path that served the file instead of a bare flag; every caller only ever tested it for truth.	2026-08-18 10:36:42 +02:00
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 aa87e5598, copied from the stop/pause/resume handlers beside it, where reaching the printer is the whole point. The scheduler already reads the flag off a powered-off printer - it refuses to wake one that is still gated - and the wiki recommends the MQTT topic for automations because it does not depend on the printer being powered on. Only the write path disagreed. The card follows: showClearPlateButton drops the connection term, and the expanded-view button - which lived inside the block that renders nothing without a live status - is shared and given its own slot below it. The bulk filter tests clearPlate before the connection filter; every other bulk action still needs to reach the machine. The plate pill stays connected-only, since its only render site is inside that same block. Two things on the same path needed the flag without a client. GET /status returned the schema default for a printer with no cached state - manually disconnected, or not yet reconnected after a restart - reporting a clean plate the database disagreed with, and hiding the control on exactly the printers that needed it. And _emit_plate_clear_change bailed when the printer info cache was empty, which would have left the retained plate_clear topic (#2525) asserting "awaiting" after the gate was released; it now falls back to the row. This does not dispatch to an unreachable printer: _is_printer_idle still requires a connection. Releasing the gate is what lets the queue switch the printer on for the next job instead of passing it over.	2026-08-18 09:34:03 +02:00
maziggy	607b34e94d	Check the card before writing a print off as internal-storage-only (issue #2856) ... A print's dispatch says where the printer put the sliced file: ftp://<name> for external storage, brtc://emmc/<name> for internal. Since that there is then no file to find at any path. That is where the printer chose to put it, which is not the same as where port 990 can read it. The reporter's H2D - firmware 01.03.00.00, card in the slot - reports brtc://emmc and keeps the same file under /cache: his log has every print from 08-12 downloading from there, 19 MB included, until the skip landed and two days of archives came out as a name and nothing else. #2780's P2S and H2C really did 550 on every path, so both are true and the URL alone cannot tell them apart. So ask the printer rather than the model. The dispatch names the exact file, which turns the question into one connection walking five directories - against the sweep's ~110, which is the cost that made skipping worth doing. A hit archives normally and is shared with the cover endpoint; a miss keeps #2780's fallback archive and its reason, so the archives banner still explains itself. Not probed when the printer reports an empty slot, or while its file service is in TLS cool-off: both have already answered the question. The connection diagnostic asked the same question off the URL and warned that the last print was out of reach. On this reporter's printer that warning would have sent him to a setting that was already right, so it now probes too - by directory listing, since the file it is asking about can be tens of megabytes and the answer is a yes or a no. Capped at 6s to stay inside the support bundle's per-printer budget, and "could not check" leaves the warning standing. The probe filename arrives over MQTT and becomes both a remote path and a local temp filename, so names carrying separators, traversal or control characters are declined rather than cleaned.	2026-08-17 14:50:40 +02:00
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.	2026-08-17 12:17:12 +02:00
maziggy	2c7df27d1a	Look for a print's file when the printer says it is on the card ... (#2780 regression) A print of a file already on the printer -- a reprint from the touchscreen, from Handy, or a slicer send-to-storage followed by a print -- reports its location as a path rather than as a fresh upload: file:///media/usb0/<name>. Since #2780 landed on 2026-08-14 Bambuddy read anything that was not ftp:// as "the printer kept this internally", skipped the FTPS sweep, and archived the print with a name and timing only. Measured on an H2D: the file was listable and downloadable over FTPS at the moment Bambuddy declared it unreachable. Before that change those prints archived normally, so this is a regression, and it is not confined to the H2 series the change was about -- an X1C reprint from its own screen loses its thumbnail exactly the same way. That module's own rule is to skip only on positive evidence, and a file:// path is not evidence of internal storage. It now reads the path: the printer's model cache under /userdata is a genuine skip, anything else is unknown and sweeps, which is what it did before. Unknown rather than external on purpose -- the empty-slot check still runs ahead of it, so a file:// print on a printer with nothing in the slot reports the missing card instead of sweeping for something that cannot be there. The user-facing copy shipped this morning is corrected in the same change, because it was written before we understood how Bambu Studio actually chooses. Its Print button always uses internal memory; only Send offers Cache or External, and that defaults to Cache too. So the advice now leads with the two routes that take one step -- start the print from Bambuddy, or slice in OrcaSlicer -- and offers Send-with-External and a separate print start as the way to stay in Bambu Studio. The earlier wording named no remedy at all and blamed the printer's firmware for a choice the slicer makes. Banner and diagnostic, thirteen locales, README, bundle rebuilt.	2026-08-17 11:24:53 +02:00
maziggy	89ea337612	Recognise our own print dispatch instead of guessing at a magic number ... (#2843 follow-up) Bambuddy records the project_file behind every print, because that command names where the sliced file was put and so decides whether the archive can have a thumbnail and slicer metadata at all. Its own dispatches were told apart from a slicer's by testing sequence_id against "20000", on the belief that 20000 was Bambuddy's alone. It never was. 20000 is the slicer convention Bambuddy copied -- virtual_printer/bind_server documents the slicer sending exactly that during detect -- and both slicers count up from it. Measured on the wire: OrcaSlicer dispatched 20000 and then 20001, BambuStudio 20009 and 20010. So whichever dispatch happened to land on the shared value was filed as ours and never recorded, and after a slicer restart that is the first print you send. The test was wrong in the other direction too: it called every value above 20000 external, including ones we had sent ourselves, which only stayed invisible because we always send exactly 20000. Ownership is now established by remembering the job actually dispatched -- sequence id, file, url and subtask name -- and consuming that marker on the echo. One-shot deliberately: a slicer reprint of the same file a moment later is somebody else's print and must not hide behind our last one. Nothing about printing or archiving changes. current_project_url and ams_mapping are both captured before this branch and always were, so the storage verdict that gates the FTPS sweep is untouched; two tests pin that, because it is the part that would actually cost archives if it drifted. What changes is that the diagnostic entry stops lying, and it is the entry that tells an operator whether their printer stores files somewhere Bambuddy can read -- which is the whole subject of #2780 and would have to count, and an undercount there would have been silent.	2026-08-17 10:26:38 +02:00