bambuddy

mirror of https://github.com/maziggy/bambuddy.git synced 2026-10-04 05:01:37 +02:00

Author	SHA1	Message	Date
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	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	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
Kouki Ojima	c3677865b6	Give the AMS temperature alarm its own threshold (issue #2905 ) (#2943 )	2026-08-25 15:03:34 +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	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
Sean K	55cc64c87d	Add printer video downloads and range selection (#2853 )	2026-08-22 13:22:56 +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	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	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	7a42e0a7e5	Show which Filament Track Switch inlet each AMS feeds With a switch fitted, an AMS is not wired to a nozzle any more. It is plumbed into one of the switch's two inlets and reaches both nozzles through it, so every unit reports its extruder as "not fixed" (0xE) and ams_extruder_map comes back empty on these machines. The printer card had nothing to fall back on but the AMS unit number, so AMS-A was badged R and AMS-B was badged L purely because their unit ids are 0 and 1, a third unit got no badge at all, and every one of those labels was wrong. The SpoolBuddy assign modal had the same fallback in a worse form, mapping anything that was not extruder 1 to R. The binding turned out to need no new telemetry. BambuStudio reads it out of bits 24-27 of the same AMS info string we already parse for the AMS type and the extruder id -- 0 is In-B, 1 is In-A -- and it is only meaningful when a switch is installed, because without one 0xE really does mean an uninitialised unit and those bits carry nothing. That gates the read, which in turn forced the switch block to be parsed before the AMS block: _handle_ams_data runs early in _process_message and _update_state only much later, so the binding was lost on every frame that carried both. _parse_fila_switch is split out and called first, and left in _update_state as well so that stays a complete absorb step. The badge keeps L and R rather than A and B, because the lettering is familiar and matches the physical layout. It is a different colour from the plain nozzle badge, and its tooltip names the inlet in full, since the letter is the inlet's position and not a claim about which nozzle that AMS feeds -- the switch can route either inlet to either outlet. An AMS still reporting a real extruder id keeps its ordinary badge, which BambuStudio also treats as authoritative over any switch binding, and a switch that has been fitted but not yet set up on the printer shows nothing rather than a guess. The print dialog's slot dropdown gets the same label. It replaces a left/right hint that never once rendered: ftsExtruderForSlot compared snow-encoded in[] values against global tray ids and could not match. Decoding it correctly would not have saved it -- the firmware reports which slot sits in each inlet and which nozzle each outlet feeds, but never which inlet is currently paired with which outlet, so no per-slot nozzle can be derived. That function is gone rather than fixed. The dialog also points out when every filament a print needs sits behind one inlet. Bambu's own guidance is that this is legal but slow: a change between two filaments on the same inlet retracts the outgoing spool all the way back to its AMS before the next can be fed up the shared tube, where a change across the two inlets only retracts as far as the switch. All on one inlet means every change in the job takes the slow path, and moving a single spool fixes it. So it advises, it does not block. Both views update live. Two things were stopping that. fila_switch and ams_switch_inlet were absent from printer_state_to_dict, and the frontend shallow-merges each WebSocket push over its cached status, so a field the push omits keeps whatever the last full fetch left behind. And the broadcast dedup key had no term for either, so "Join IN-B" on the printer screen moved nothing: the binding is not in the tray component of that key, and it is not in the AMS change-hash either, which covers tray fields only and must stay that way because it drives Spoolman sync. Assigning an AMS to an inlet remains printer-side. BambuStudio can read the binding and has no command to write it -- its switch class is parse and getters only, and the recommended-arrangement popup draws and publishes nothing -- so there is no wire format for us to copy. Adding the two fields to PrinterState broke four test modules whose SimpleNamespace stubs predate them. The stubs are fixed rather than the production reads made defensive: the real dataclass always carries both, and a getattr in the dedup key would silently stop tracking the field if it were ever renamed.	2026-08-16 15:09:00 +02:00
Ben Hamilton (Ben Gertzfield)MartinNYHC maziggy	d37ce94f81	Feature: Scheduled drying (#2703 ) * feat: add ScheduledDrying model for delayed drying runs (#2638) * Release the printer when a scheduled dry ends (#2638) _check_scheduled_dryings marks a printer as drying in _drying_in_progress, which is shared with auto-drying. Auto-drying prunes that map in _sync_drying_state(), but that call sits behind its enabled check, and this is the first writer that runs whether auto-drying is on or not. With it off -- the default -- nothing dropped the entry short of a print being dispatched to the same printer, so the next scheduled run parked on "already_drying" forever and queue_drying_block held that printer's prints too. A nightly off-peak dry with no printing in between is exactly the workflow this feature is for: night one worked, every night after it silently did not. The check now releases what it acquired, covering both a run that ends mid-pass and one cancelled through the route between passes. The retention prune ran on every pass. Issuing the DELETE is what opens a write transaction, this method is called every 3s while the queue dispatches, and rows only become prunable a week after they finish, so it is now gated to hourly on a monotonic stamp -- with the first pass after a restart still reaping whatever the dead process left behind. Both drying paths now pick the blocking dry_sf_reason through one rule. The immediate endpoint quoted whichever code the firmware listed first while the scheduler prioritised power over retract, so one blocked AMS read two ways depending on which button you pressed. drying_preflight.primary_reason_code holds the order and both call it, including the flame button's tooltip, which had no wording for filament at the outlet at all and sent those users to the generic "can't start drying right now". scheduled_drying joins the model list in init_db. The table was already created -- importing the package registers it -- but it was the only model relying on that indirection. Tests: the release (completion and route-cancel), the prune throttle, the shared reason rule, the tooltip priority, and four driving the real check_queue, which nothing covered before -- a pass with no rows still dispatching prints, a due row dispatching, and a failed row not stalling the queue behind it. Each one fails against the code it guards. --------- Co-authored-by: MartinNYHC <martin@bambuddy.cool> Co-authored-by: maziggy <mz@v8w.de>	2026-08-15 13:40:21 +02:00
maziggy	fffa68ec55	Explain a print that never reached the printer's card, instead of sweeping for it (#2780 ) Bambuddy reads a print's 3MF, cover and timelapse over FTPS on port 990, which on every Bambu model serves external storage only. Under some configurations H2-series and P2S firmware keeps the sliced file on internal storage, where Bambu Studio put it over the port-6000 service, and then no path on 990 can find it. The print command has always said which of the two it used -- `url` reads ftp://<name> or brtc://emmc/<name>. We discarded it and swept anyway: ~110 connections per print, all certain to fail, ending in an archive card with nothing on it and no stated reason. In the reporter's bundle all 35 dispatches to their H2C and P2S said internal storage, all 25 to their X1C said external, and all 44 empty cards belonged to the first two. Read the field, skip the sweep when it cannot succeed, and record which reason applied. A printer that uses the card is unaffected, and so is one we have no answer for -- silence is not evidence, and reading it as bad news would break archives that work today. The answer is held per print and dropped when that print ends, rather than kept as a standing fact about the printer. Plenty of prints never announce themselves: 14 of the 79 print starts in that bundle arrived with nothing on the request topic, started from the printer's own screen or picked up after a restart. Left standing, one slicer print to internal storage would suppress the lookup for every screen-started print after it, on a printer whose files really are on the card. The sticky reading is kept for the connection diagnostic alone, which is run after the print that prompted it and would otherwise have nothing to report. Two things that pointed the wrong way go with it. The archives banner told everyone to enable "Store sent files on external storage"; the reporter had it on for the whole three weeks and it would not have helped. The diagnostic passed a printer whose slot was empty, because it read only the toggle -- an empty slot is now a failure naming the slot, and a printer that has storage and still used its own is a warning. On P1-series that empty-slot failure yields to the existing unsupported-model skip: the toggle cannot be switched on there at all, so telling the operator to insert a card would promise a fix inserting a card does not deliver (#2524). Also close FTP sockets on the failure paths, which dropped them for the garbage collector -- 1813 in a day in that bundle -- and drop the advice to restart the printer, which the reporter tried twice while a single manual connection to the same printer handshook cleanly. This does not make the affected prints archive in full; that needs the port-6000 protocol tracked in #2762.	2026-08-14 13:40:12 +02:00
maziggy	3954d3a7e6	Choose which rack nozzle each filament prints from on an H2C (#1784 ) The Vortek rack holds six hotends, and a multi-colour plate is sliced to use a different one per colour so it can skip the purge. Which of the six each colour takes is not in the 3MF. The same plate, sliced and sent twice from Bambu Studio with a different choice each time, produces two files that differ only in rounding in the last digit of a few extrusion figures -- the filament grouping, the toolchange stream, the 120 nozzle-change markers and project_settings.config are all identical. The choice travels only in the dispatched nozzle_mapping. Bambuddy had no way to state it, so those plates went out with no nozzle assignment at all and the printer chose for itself. That is what levelled on one hotend and printed with another, millimetres above the plate. Every rack-bound filament now carries a position picker beside its AMS slot dropdown, listing all six with the nozzle each holds. An empty position, or one holding the wrong diameter or flow type, is shown greyed out with the reason rather than hidden, so someone looking for position 4 finds it. The choice is per filament group rather than per slot, because a group is one hotend: two filaments the slicer grouped together share it and cannot point at different positions. Nothing has to be picked. Positions are assigned automatically, preferring one already loaded with that colour, which on the plate this was built against reproduces Bambu Studio's own pick exactly. A nozzle currently picked up onto the carriage is offered too. The firmware drops its rack position from the report entirely rather than sending a placeholder (#943), and refusing it would rule out the position most likely to be wanted -- the one the last print left mounted. Only recoverable when exactly one position is missing; two gaps are genuinely ambiguous and stay unavailable. Positions are re-checked at dispatch, not just when queued, because the rack can be re-loaded in between. The two failure modes differ on purpose: an explicitly chosen position that no longer fits stops the print, names what the position now holds, and deletes the uploaded file from the SD card so it cannot be started by hand either -- an operator who named a hotend must not silently get a different one. An automatic assignment that cannot be made instead falls back to letting the firmware choose, which is what happened before any of this existed. The pick is stored as {group: position} rather than as the expanded nozzle_mapping, though that is what goes on the wire. That column means "Bambu Studio decided, forward verbatim", and only the group-and-position form can be re-checked against what is actually mounted at dispatch. The existing multi-rack refusal in extract_nozzle_mapping_from_3mf stays. It still guards the #2800 fallback, which can only ever name one rack id. Measured on the maintainer's H2C: rack position n is physical nozzle id 15 + n, confirmed by cross-referencing two captured dispatches against Bambu Studio's own dialog. extruder_max_nozzle_count names which carriage is the rack straight from the file, and is read rather than assumed -- a fourth independent confirmation of the carriage indices fixed in `45dc139`. The print dialog is also wider, on every printer. Its filament rows carry the most horizontal content in it and adding a picker truncated names to "Bamb...". The column widths themselves only change on a rack machine. Tests: 44 unit covering the plan, the resolver, the mounted-nozzle recovery and every refusal; 9 dispatch integration asserting the two real captures end to end; 7 API round-trip; 33 frontend. The API ones exist because two integration bugs got through a green suite that tested the pieces and not the seams -- the group data reached only one of the three filament-requirements routes, and the field was declared on every schema except the create one, where Pydantic dropped it in silence.	2026-08-14 11:27:50 +02:00
maziggy	df5aa04df1	Pool AMS backup spools in the print dialog's filament check The dialog weighed each plate against the spool in the slot it mapped to and knew nothing about AMS Filament Backup, so a two-plate job needing 1441 g of ABS was refused against a 1000 g spool while the identical full spool in the next slot went uncounted. The dispatcher has pooled matching spools since #1762 and would have run the print -- "Print anyway" was always the right answer to this warning. The rule for which spools back each other up now lives in one place: build_slot_materials() in filament_deficit, which the dispatcher's pool and the new slot_materials half of GET /printers/{id}/inventory-remain both draw on. The dialog groups on the keys it is handed rather than resolving spools a second time, which is what let the two answers drift apart, and which also gives the check to Spoolman users -- it read the internal inventory only, so in Spoolman mode it approved everything. Where a pool really is short the warning quotes the pooled totals, since the per-slot figure reads as a contradiction next to a full peer spool.	2026-08-11 11:32:17 +02:00
maziggy	3dc681d9f1	fix(slicer): write slice output to the source's external folder (#2810 ) slice_and_persist always wrote to get_library_files_dir() while giving the new row the source folder's id, so slicing a file on a NAS mount produced a .gcode.3mf that showed up in the right folder in the UI and never reached the share -- invisible from the web UI, which is why it did not reproduce. Resolve the destination from the target folder like uploads (#1112) and moves already do, set is_external and store the absolute path. Collisions uniquify to "Model (2).gcode.3mf": a 409 would throw away minutes of CPU on a routine re-slice, and overwriting a file on someone's NAS is worse. An external folder that cannot take the file (read-only, unreachable, not writable) falls back to managed storage rather than discarding the slice, and reports why on SliceResponse.external_write_fallback -- surfaced as a warning toast. Silent fallback is what made this bug invisible.	2026-08-11 09:02:52 +02:00
MartinNYHC	37b0e25a2b	Merge branch 'dev' into feature/queue-keep-warm-chamber-history	2026-08-10 13:31:28 +02:00
maziggy	7c117dc6bc	Let API clients resolve user ids to names (#1894 ) Archives, the queue and statistics report ownership as a numeric created_by_id, and statistics accept it as a filter, but nothing let an API key discover whose id was whose -- the only user listing returns emails, roles, group membership and full permission sets, so it is administrative and rejects keys. Add GET /users/slim returning id + username only, gated on a new users:read_slim permission mapped to can_read_status. That grants no data a key could not already reach: for API-keyed requests the permission deps return None as current_user, so the stats:filter_by_user guard short-circuits and ?created_by_id=N is already honoured for every N. What was missing was the ability to address the filter, not permission to use it. The full listing stays unmapped = admin-only. Also fix /auth/me, which answered an API key with a synthetic administrator: id 0, role admin, is_admin true and every permission in the enum. A key cannot reach an administrative route at all, so clients building their UI from that response rendered actions that 403 on use. It now reports the key owner's identity, is_admin false, and the permissions the key's scopes actually admit. Ownerless legacy keys keep id 0 but no longer claim admin. --- Source user names from the slim listing where only names are needed (#1894) Stats filter-by-user, the Archives print log filter, the File Manager username autocomplete, the camera-token owner column and the Finance member picker all render nothing but a username, but all of them read the full user listing, which is gated on the admin-level users:read. An operator granted stats:filter_by_user but not users:read got an empty filter with no indication why. Point them at /users/slim under a separate react-query key, since the full listing shares the 'users' key and the two shapes would clobber each other in the cache.	2026-08-10 11:43:23 +02:00
Thomas Scott Williams	f86f5a7c34	feat(queue): keep the chamber warm between prints and skip redundant soak Back-to-back prints in chamber-heated materials (ASA, ABS, PA, PC) each paid a full heat-soak from cold, even when the print that just finished had left the chamber at temperature. Two changes remove that cost. Keep bed warm between prints While a printer sits in FINISH awaiting plate-clear and the next queued item needs chamber heat, hold the bed hot so the chamber does not cool during the bed-clearing window. The bed is the chamber's heating element here, not a print surface, so the hold runs at the new `queue_keep_warm_bed_temp` (default 90C, which also satisfies bed-threshold-linked aftermarket chamber heaters), raised to the item's own bed temperature when that is higher. Gated on `queue_keep_bed_warm` AND `require_plate_clear` AND `preheat_enabled`, all re-checked in the backend so a stale UI cannot leave the feature running. `queue_keep_warm_max_minutes` (default 120) bounds the hold: when it elapses the bed is switched off and the hold latches until the printer is next a candidate, so a plate nobody clears cannot leave the bed hot indefinitely. The hold is also released when the item is deleted, the queue empties, or a gate is toggled off mid-hold, and never when firmware reports a target other than the one it set — a temperature the user or a print changed is left alone. Publishing is idempotent. Smart soak reduction from chamber history The scheduler samples each connected printer's chamber temperature every tick into a 2h rolling history. Preheat credits time the chamber has already spent at temperature against the configured soak, shortening or skipping it. Credit starts no earlier than the newest sample, the most recent unbroken run of samples, or the end of the last real dip below target. A dip only counts once it outlasts a grace period: an enclosed chamber cannot lose and regain several degrees quickly (measured on an X1C, cooling from 55C to below 48C takes 23-73 minutes, ~0.2 C/min), so a brief low reading is a door opening or sensor noise rather than lost soak — and a plate swap, which is exactly when keep-warm runs, produces one. A stale history credits nothing: at that cooling rate the chamber can cross the threshold unobserved, so the full soak runs instead. Three supporting changes to preheat itself: * Cancelling or deleting a queued item now stops a preheat already running for it. Those routes only write `status` to the database, which a dispatch coroutine parked in `asyncio.sleep` cannot observe, so the heaters ran for the rest of max_wait + soak — 45 minutes at the default settings — and the printer stayed in `busy_printers`, blocking every other queued item behind a print that was not happening. The routes now signal the scheduler directly, and the stage sleeps in slices so it notices promptly and abandons the dispatch, letting the existing rollback shut the heaters off. * A chamber-heated print whose slicer metadata carries no bed temperature (common for Orca-exported 3MFs) used to skip preheat entirely and start with a cold chamber. It now heats the bed to `queue_keep_warm_bed_temp`. A parsed bed temperature still wins, and a print with no chamber requirement still skips — no bed temperature is invented for the print itself. Preheat's bed target is transient regardless: the print's own gcode issues its M140/M190 at start. * Preheat records which commands it sent (bed, chamber, airduct) and unwinds them if the dispatch aborts before the print starts — a failed upload, a cancelled item, an exception — instead of leaving the printer heating for a job that is not happening.	2026-08-09 17:07:34 -04:00
maziggy	b6027b7138	Say why a preset's values are unavailable, not just that they are The settings panel collapsed four causes into one message -- "the picked preset's own values could not be read" -- with no indication of what to do about it. The overwhelmingly common cause has an obvious fix, and it isn't an edge case: an install pulls its sidecar as SIDECAR_TAG:-latest regardless of which Bambuddy channel it is on, so a current Bambuddy talking to a sidecar that predates POST /profiles/resolve is the normal state, not a misconfiguration. Those users would have seen an amber warning on every slice with nothing pointing at the sidecar image. resolve_profile now returns ResolvedProfile(values, reason) instead of None for everything, the route passes the reason through, and the panel picks its message from it: sidecar_outdated -> name the fix: update the sidecar image sidecar_unavailable -> the sidecar did not answer not_configured -> no sidecar is configured preset_unresolved -> the previous generic wording A request that fails outright maps to sidecar_unavailable, since a backend we cannot reach and a sidecar that will not answer are the same thing from the dialog. Every variant still ends with "anything you don't change still uses the preset" -- that reassurance is the point of the notice, and it is true whichever way the lookup failed. Tests pin the distinction rather than just the happy path: a 404 and a 500 must produce different reasons, and each panel case asserts both that its own message appears and that the "update the sidecar image" line does not leak into the others.	2026-08-09 11:25:09 +02:00
maziggy	f421bb8160	Show the picked preset's real values in the process-settings panel The panel baselined every field on the option schema's compiled-in defaults, so a preset setting a 0.42mm line width displayed 0 -- the C++ default meaning "derive from the nozzle". Every field was affected; the Line width group just made it obvious. Bambuddy cannot answer this itself. A standard-tier pick is only an {inherits: ...} stub on our side, and local/cloud presets are deltas whose remainder lives in the profile tree bundled inside the running sidecar. The values now come from the sidecar's POST /profiles/resolve, which runs the same resolver /slice does against the same profiles, so what the panel shows cannot disagree with what a slice produces. Deliberately not the local orca_profiles resolver: it walks OrcaSlicer's published tree, which can differ from the image actually installed. An untouched field shows the preset's value and reverting returns to it. isModified compares against that baseline too, so fields the preset moved off the C++ default are no longer flagged as user edits, and values nobody typed are no longer sent. When the values can't be read -- sidecar offline or older than the endpoint -- the panel falls back to schema defaults and says so rather than presenting them as the preset's. Row layout, from screenshots: - The control column is anchored to the right edge at a fixed width. It had been packed left after a fixed label column, leaving the values stranded mid-container with dead space beside them. - Units are no longer truncated to "mm o...". The cap fitted the common "mm" but not "mm or %" or "mm/s² or %". - The "from file" tick moved ahead of the control it qualifies; it used to sit past the unit at the row's right edge, reading as unrelated. Both the unit and the control keep fixed widths, and the tick's slot is reserved on rows without one -- sizing any of them to content makes each row's input land at a different x and the column comes out ragged. Also fixes a field that could not be cleared: emptying a free-text input dropped the key, so it snapped back to the baseline and retyping appended to it ("0.42" + "0.5" = "0.420.5"). The number branch was fixed earlier; the text branch -- coFloatOrPercent, coString, the vector types -- was not, and the regression test used a number input so it never caught it. Requires a sidecar built from orca-slicer-api 4b664b7 or later. Older images 404 the endpoint, which is handled as the fallback above.	2026-08-09 11:02:03 +02:00
maziggy	f0500578bd	Edit the full print-parameter set from the slice dialog Slicing from Bambuddy meant taking a process preset as-is; any change meant a round trip through Bambu Studio. The slice dialog now carries OrcaSlicer's full process tree -- pages, groups, labels, tooltips, ranges and defaults extracted from the slicer's own sources. Enable/disable rules are evaluated from the slicer's own enable_if expressions via a recursive-descent interpreter (no eval, CSP), with enum comparisons validated against each option's declared values. Anything undecidable leaves the field editable rather than greyed. Overrides apply after the source's support config (#1881) and the designer's carried tweaks (#2622), so an explicit choice always wins; an untouched panel sends the same request as before. Adds slice_engine as a separate setting from preferred_slicer -- where slicing runs is a different axis from which binary the sidecar drives. Only the sidecar engine is registered, so no picker renders yet.	2026-08-08 16:33:41 +02:00
maziggy	328bac450a	Stop auto-drying re-arming into a threshold it can never reach (#2770 ) An H2D armed five 12-hour drying cycles inside four hours, one of them six seconds after the previous one ended, and none ran more than a couple of hours. Two things combine. The firmware ends a cycle when it decides the filament is dry rather than when the clock runs out, and reports no fault doing it -- across this printer's history the run length tracks how wet the spools were, from nearly the full 12 hours starting at 32% down to minutes once the unit sat at 10-13%. That part is the AMS doing its job. The loop is ours. An AMS reports higher relative humidity while it is warm than once it has cooled: the same unit read 10-13% cold and 15-20% through every cycle. With the threshold at 14% the reading at the moment a cycle ended was always still above it, so the next 30-second pass armed another 12-hour cycle. Nothing counted, nothing waited, and it only stopped when the box finally cooled enough to read 13%. Auto-drying now waits 30 minutes after a cycle ends before arming another on the same unit, and gives up on a unit after two consecutive cycles that bring the reading no lower -- logging why and sending a new notification, on by default because it reports that Bambuddy has stopped acting. Progress is judged against the lowest reading any cycle on that unit has ended at, not against the threshold, so a genuinely wet spool in a humid room coming down 40-37-35 keeps drying however far it still is from the target; comparing against the best so far rather than the previous end stops a sensor wobbling by one point reading as progress every other cycle. The suspension lifts by itself once the reading falls below the threshold. Neither guard can stop a running cycle, and a cycle Bambuddy cut short for a print, or that the user stopped by hand, is not counted against the unit -- so a farm that dries between queue jobs is unaffected. The threshold field now warns below 20%, and every cycle end logs the unit's temperature and humidity, which is what made this diagnosable. The same bundle showed unrelated tasks failing with "database is locked", each inside a 30.000-second Discord connect timeout. Alarms are raised from inside the loop that records sensor history, at a point where the new rows are added but not committed; the first read in the notification path flushed them to satisfy itself, opening a write transaction, and the provider was then contacted over the network with that transaction still open. SQLite allows one writer and 30 seconds outlives the 15-second busy timeout, so every other write in that window failed. The two reads that run before a provider is contacted no longer flush the caller's pending work, and the connect timeout is 5 seconds rather than 30 -- the body keeps the full 30, so image uploads on a slow uplink are unaffected. SQLite only; Postgres has no single-writer limit.	2026-08-08 12:40:17 +02:00
MartinNYHC	406cf71149	Merge branch 'dev' into feature/billing	2026-08-08 10:56:09 +02:00
maziggy	604fa44593	Explain Bambu Cloud's CAPTCHA challenge instead of repeating it (#2790 ) A reporter tried to connect to Bambu Cloud and got "We need you to confirm you are not a robot" as an error toast, with no CAPTCHA anywhere to answer and nothing to click. That sentence is Bambu's, not ours. Their anti-abuse layer had flagged the network and was answering the sign-in with HTTP 418 and a challenge body: {"captchaId": "...", "error": "We need you to confirm you are not a robot"}. Bambuddy had no idea what that was. The reply is well-formed JSON, so _detect_cloudflare_challenge -- which triggers on an unparseable body, CF markers, 403+cf-mitigated or 503+cf-ray -- never fired on it, and login_request fell through to its generic error path, which lifts data["message"] or data["error"] out and hands it to the UI verbatim. The user was left to conclude their password was wrong or that Bambuddy was broken. Four sign-in attempts inside eighteen seconds appear in their log, each one more evidence for the thing that had flagged them. is_captcha_challenge matches on the 418 status plus a challenge marker in the body -- captchaId is the reliable one, the wording is matched too because Bambu has shipped it under more than one phrasing. A bare 418 with no marker is has shipped it under more than one phrasing. A bare 418 with no marker is deliberately NOT reported as a CAPTCHA: telling someone to solve a challenge that was never offered is the exact confusion this issue is about. login_request, verify_code and verify_totp now return reason="captcha" with an explanation covering the three things the reporter had no way to find out: the credentials are not the problem, the block is keyed to the public IP address rather than the account, and it clears by itself within a few hours. Sign-in requests are then held back for 300s so Bambuddy stops deepening the block. Keyed per origin, not per service: TOTP verification posts to bambulab.com while everything else posts to api.bambulab.com, and a challenge seen on one must not strand somebody halfway through a two-factor sign-in on the other. Entries expire on read, so the map cannot grow past one per region. The token endpoint is deliberately left ungated -- it is the way out. The UI shows a persistent panel rather than a toast. A toast names a problem the user cannot act on and then vanishes; this one stays put and carries a one-click route to "Use access token instead", which is the only thing that works while the challenge lasts, since that path does not touch the challenged endpoint. MakerWorld meets the same challenge from the same edge and now shares the detection. It used to require the literal word "robot" in the error text and reported any other wording as an unexplained block. The System Health scanner gets a bambu-cloud-captcha signature. The reporter's bundle came back with zero findings while their log was full of the failure. Its advice for a failed FTPS handshake was corrected at the same time: it still blamed firewalls and outdated firmware, which the #2780 investigation ruled out last release -- it is the printer's own file service wedging, and the fix is to restart the printer. The wiki said so already; the health panel did not.	2026-08-08 10:04:55 +02:00
behrinml	a9e23910fc	Merge branch 'dev' into feature/billing	2026-08-06 20:32:59 +02:00
behrinml	2e5d36d680	implemented pr (minor) feedback	2026-08-06 20:28:16 +02:00
behrinml	dd1d40b0d4	implemented pr (worth fixing) feedback update commit	2026-08-06 20:27:25 +02:00
maziggy	afa0ba0dc0	Nest projects under a master project and roll their figures up (#1264 ) Projects were flat. The parent_id column and the sub-project list existed but nothing could set a parent outside the API, and a master project's stats only ever covered its own prints. The project dialog gets a parent picker, and a project with sub-projects gets a second card covering the whole tree -- jobs, parts, time, filament, cost, and progress against every target in the tree added together. That card is separate from the project's own stats, which keep their existing meaning; widening them would have restated the figures of anyone who had already nested projects over the API. Each listed sub-project carries its own branch's roll-up, so the rows add up to the card above them. On the Projects page a sub-project is drawn inside its parent's group rather than as another card in the grid -- two cards columns apart cannot show that they belong together, whatever the caption says. A sub-project whose parent the status filter has hidden stays put and names its parent instead. compute_project_stats now goes through the same grouped aggregation as the roll-up rather than its own copy of the SQL, since the two must agree. Three things the interface made reachable: - PATCH refused only a project as its own direct parent, so A -> B -> A was two calls away. A cycle has no root to roll up to, and the walk keeps its seen-set for databases that already contain one. - A sub-project's percentage was completed quantities against the plate target, disagreeing with the page it linked to. - Deleting a mid-tree project orphaned its children at top level; they now move up to its own parent.	2026-08-06 10:00:45 +02:00
jmoore-skild	bb25e36510	Merge branch 'dev' into feature/2656-restore-from-github	2026-08-05 16:47:49 -04:00
behrinml	43bf854bd5	Merge remote-tracking branch 'upstream/dev' into feature/billing	2026-08-05 20:19:32 +02:00
maziggy	cd004df817	Show Home Assistant sensors on the printer card (#1148 , #448 ) Binds binary_sensor and reading-carrying sensor entities to a printer and renders their state on its card, worded by Home Assistant's device_class. Optional per-sensor alert condition drives a notification on the transition into the alert state and an opt-in interlock that holds queued prints while alerting -- a hold with a readable waiting_reason, never a failure, and only ever on a sensor that was read successfully. Sensors get their own table rather than a wider entity pattern on SmartPlug: get_smart_plug_by_printer would otherwise hand the card's power button a door contact to switch. The hold is passed to the model matcher directly rather than merged into busy_printers: _check_auto_drying reads that set as "is currently printing" and would put an idle-but-held printer down the mid-print drying path. The notification_providers migration spells its default FALSE, not 0 -- Postgres rejects an integer default for a boolean and _safe_execute swallows the error.	2026-08-05 14:26:38 +02:00
jmoore-skild	af8d14d796	i18n(backup): make the restore notes and preview details translatable (#2656 ) A German user got a translated modal with "Not present in this backup commit" in the middle of it. Every tally note and preview caveat was a server-built English sentence rendered verbatim. Follows the backup.pathCheck contract already in use one card down in the same component, deliberately rather than inventing a second convention: the server sends a `code` plus typed `params` and carries the English along as the fallback, and the client renders `t(`...${code}`, { ...params, defaultValue: message })`. The defaultValue arm is what keeps a newer backend's unfamiliar code readable instead of printing the raw key — covered by its own test. Shapes: - notes: list[str] -> list[GitHubRestoreNote] {code, params, message}. Breaking, but the field is unreleased in this same PR. - GitHubRestorePreviewCategory gains detail_code / detail_params; `detail` stays as the English fallback. - _CategoryTally.note(code, message, *params), deduped on (code, params) rather than on the rendered text, so two offline printers both keep their names. The 20-note cap is unchanged. 28 new leaves across 13 locales: 20 notes. and 8 details.*. `noData` collapses the four per-category "No X data in this backup" strings into one, since the category heading already renders beside it. Counts use single-form {{count}} in the existing "N record(s)" style rather than i18next plural suffixes — nothing in this block uses _one/_other and the parity script has extra rules for them. Parity holds at 5737 leaves in all 13 locales. Deliberately out of scope, and worth saying so rather than leaving it to look like an oversight: result.message, the commit-picker subject lines and the HTTP error strings stay English. Those also originate in the provider backends, so code-ifying them widens the diff well past the restore service. spoolTagKept is added here with the rest of the locale churn but is not emitted until the next commit, so the 13-locale change lands once.	2026-08-04 08:57:33 -04:00
jmoore-skild	6a239314dc	feat(backup): restore selected categories from a Git backup commit (#2656 ) The Git backup feature was push-only: there was no equivalent of the local backup's Restore button, so recovering meant hand-downloading JSON files from the repository. This adds the read side. Providers gain list_commits / list_tree / fetch_files on the GitProviderBackend ABC. GitHub implements them against the Git Data API and Gitea/Forgejo inherit that unchanged; GitLab overrides for its own REST shape, including tree pagination and subgroup path encoding. fetch_files is batched so the path -> blob SHA lookup happens once per restore rather than once per file, and uses the blobs API rather than contents because contents silently inlines only the first 1 MB. The new GitHubRestoreService resolves HEAD to a concrete SHA up front, so a preview and the restore that follows act on the same commit even if a scheduled backup lands in between. Categories are applied archives -> spools -> settings -> kprofiles: archives first because spool usage history references archive_id, K-profiles last because they leave the database and publish over MQTT. Restores never reuse the backup's primary keys. spool.id and print_archives.id are bare autoincrement columns, so ids from an old backup very likely belong to unrelated rows today; rows are matched on natural keys (tag_uid, then tray_uuid, then a descriptive composite for spools; content_hash or filename plus started_at for archives), inserted without an explicit id, and an old_id -> new_id map rewrites the foreign keys in spool usage history. created_at is carried across on insert so restoring the same backup twice matches instead of duplicating. Dangling printer/project links are cleared and reported rather than failing the row. Settings restore re-applies the collector's credential denylist on the read side, plus a pattern guard, because a backup taken before that denylist existed can still contain secrets. Restored archives are metadata-only: the 3MF and thumbnail bytes are not in a Git backup and print_archives.file_path is NOT NULL, so inserted rows get an empty path and the UI says so. Backup and restore take a mutex against each other; both write the same tables and talk to the same printers. Restores are logged as GitHubBackupLog rows with trigger="restore", which needs no migration and surfaces them in the existing History card. Cloud profiles are deliberately not a restore category. The collector never actually writes cloud_profiles/*.json - it reads a "setting" list key the Bambu Cloud API does not return - and the preset list it would write carries no setting payload. Filed separately. Permission github:restore already existed and is granted to Administrators, so no permission changes were needed. Tests: 125 new backend tests (provider reads across all four providers, the per-category appliers, the API endpoints) and 13 frontend tests. Full suites pass with no regressions; the 35 backend failures on Windows are byte-identical with and without this branch.	2026-08-04 08:22:57 -04:00
maziggy	33ab5f1ead	Add temperatures to the streaming overlay and a URL builder (#1422 ) The overlay at /overlay/{printer} draws live print data over a full-screen camera view for OBS, a wall display or any browser source. It has been tunable since it shipped -- which fields, what size, what frame rate -- but only through query parameters documented in the wiki, and temperatures were not among the fields on offer. The request asked for temperatures first and for the field set to be selectable in the web UI; this addresses both. Nozzle, bed and chamber readings join the list. The target is drawn only while the heater is still climbing, so a settled hotend reads "220°C" for the rest of the print instead of the noisier "220 / 220°C" -- 219.6 against a target of 220 rounds to the same number, and repeating it says nothing. Both nozzles appear on a dual-nozzle machine. They are drawn whether or not a print is running, because a preheating printer is exactly when they are worth watching, and each reading appears only when the printer genuinely reports one: chamber temperature stays absent on P1 and A1 models, which publish a chamber_temper with no sensor behind it, so the overlay never puts a measurement on screen that does not exist. Labels reuse the heater chart's strings rather than inventing a second vocabulary for the same three things. The feed sends an allow-list rather than the temperatures dict. That dict doubles as the MQTT client's working memory -- derived heater flags and private target-set timestamps live alongside the readings -- and an overlay token is a narrower grant than a login, so it gets exactly what the overlay draws and does not pick up fields as the dict grows. The same chamber-sensor gate the full status payload already applies is applied here. The integration test that asserts the payload's exact key set, which exists to catch that surface widening silently, is updated deliberately. Temperatures are not in the default field set, so an overlay URL already pasted into a scene renders identically after upgrading. Settings -> API Keys -> Streaming Overlay now builds the URL: printer, field checkboxes, size, frame rate, camera toggle, an optional token, and a copy button. It persists nothing and calls nothing new -- the URL is the configuration, which keeps a scene reproducible by copy-paste and lets two displays show different fields off one token. Fields are emitted in the overlay's own top-to-bottom order rather than click order, and parameters left at their default are omitted, so the same selection always produces the same URL. The preview alongside it stays off until asked for: an always-live iframe would hold a subscriber on the printer's single camera connection for as long as the settings tab stayed open. The preview needed one narrow security-header change. Every SPA route sent frame-ancestors 'none', which is stricter than the SAMEORIGIN in X-Frame-Options beside it and refuses even a same-origin frame, so the preview showed Firefox's "another site has embedded it" page instead of the overlay. The overlay path now sends 'self', mirroring /gcode-viewer, which admits a framer only on this origin -- Bambuddy's own UI. Every other path keeps 'none', and embedding the overlay from another host still requires TRUSTED_FRAME_ORIGINS.	2026-08-04 12:38:36 +02:00
maziggy	71a06f3638	Add batch orders with a quantity per plate (#342 ) Printing a multi-plate file in different quantities per plate meant queueing each plate separately and tracking the counts by hand: one shared Quantity field cannot say "plate 1 once, plate 2 twice, plate 3 three times". Each selected plate now carries its own quantity, and the submission becomes an order on a new Batches tab. The point is the distinction the old flat batch could not express. print_batch_plates stores how many runs of each plate were wanted, separately from what was queued, so a run that fails, is cancelled or is skipped does not satisfy a target -- the order goes on saying it owes a print instead of quietly under-delivering. Queue remaining re-queues exactly what is missing, for the whole order or one plate, by cloning the most recent item for that plate: that inherits the printer or model target, AMS mapping, filament overrides and print options along with the validation they already passed, rather than re-serialising twenty fields through a template that would drift from the model the first time someone adds a column. Clones append to the end of the relevant printer's queue and take the same advisory lock the add-to-queue route does; positions are per-printer sequences, not global. Cost is measured, not estimated. print_log_entries gains queue_item_id, set where the queue item is already in scope, so each run's material and energy are attributed through the item that produced them -- an unrelated reprint of the same archive never lands in an order's total, and a multi-plate order gets each plate's own cost rather than the whole file's via the plate-scoped estimate from #2614. Before any run has completed there is no honest figure, so cost reads as unknown instead of a fabricated 0.00. The Batches tab wires up GET /queue/batches, which has been unreferenced since the batch MVP shipped, along with six locale keys that were translated and never used. It is a separate tab because an order outlives the queue that produced it: once its runs finish they leave the active queue, so Queue and History each hold half the picture. completed was not a reachable status before now, so every batch created since April is still marked active however long ago its last print finished -- 73 of them on the development install. A startup pass closes out the finished ones: those whose runs all completed become completed, and groupings whose items were all cancelled become cancelled, which is what they are. Not applied to orders, which state their intent independently of their runs and still owe the work. Only batches with nothing queued or printing are considered, and repeating the pass also catches an order whose last run landed while the process was down. Batches with neither items nor targets are no longer listed at all -- empty shells left when a grouping's items went with their source archive. Dispatch applies the same source-file gates as POST /queue/. It creates queue items, so without them it would be a weaker door to the same outcome; the archive and library-file checks move into shared helpers so a third route cannot drift from them.	2026-08-04 11:11:36 +02:00
maziggy	689f5276e4	Show the compose directory in the Docker update command (#2664 ) The printed command only works from the directory holding the compose file, which is the thing the user came to the page not knowing. Adds a copy button, a saved Compose directory setting, BAMBUDDY_COMPOSE_DIR, and best-effort detection from a bind mount's host path. Compose records the directory on every container it creates, but reading that label needs the Docker socket mounted in — root-equivalent access for a convenience string. The mountinfo guess is a prefill only: its root field is relative to the mounted device, so a compose dir on its own mount loses that prefix, and nothing in the container can detect it. The field is restricted to path characters. It is the one setting whose purpose is to be pasted into a root shell, so "/opt/bambuddy; rm -rf /" would otherwise render as a plausible update command.	2026-08-03 15:12:02 +02:00
maziggy	a08d3e62f3	Show the Print Log's per-run cost and energy, and let users pick columns (#2636 ) The list and update endpoints serialised field by field and never named cost / energy_kwh / energy_cost, so values Bambuddy had been recording all along went out as nulls. Both now validate from the ORM row, which removes the chance to omit a field rather than patching the three that were missing. Adds a Filament Used column plus a Columns picker for Cost, Energy, Energy Cost and Finished, persisted per browser. Also fixes the log view being unreachable with zero archives: the empty state ran before the view check, hiding a log that outlives the archives it refers to. --- Sort the Print Log by any column (#2636) Adds sort_by / sort_dir to the print-log endpoint, driven by clickable column headers. Server-side because paging is: ordering the rows the client holds would sort one page rather than the log. Empty values are held last in both directions — Postgres sorts NULLs high and SQLite low, so the same click would otherwise open on blanks on one backend and values on the other. id DESC breaks ties so paging through a low-cardinality sort can't repeat or skip a row.	2026-08-03 14:53:21 +02:00
maziggy	e95c42c021	Add auto-orient and auto-arrange to server-side slicing (#2548 ) Both are per-slice checkboxes, off by default, forwarded as the sidecar's orient / arrange form fields. An unticked box is sent by omission: the sidecar treats any present value as truthy, so a literal "false" would have arranged every slice. Arrange unions with the #1493 cross-class decision rather than replacing it, and the per-plate slice-all loop is now keyed on the arrange flag itself — the project-wide collapse belongs to --arrange, not to the cross-class case. The loop also covers the embedded-settings path, whose crash-retry is suppressed there since a single --slice 0 retry would return one consolidated plate.	2026-08-03 14:10:02 +02:00
maziggy	ef7c1b21f1	Add cross-model print alternatives to the File Manager and print modal (#671 , #2570 ) Selecting several sliced files and pressing Print now creates one queue item carrying all of them, instead of hiding the Print button the moment a second file is selected. The printer picker is replaced by the ordered candidate list, since choosing these files is already the answer to "which printer" and the only question left is which is preferred. Per-candidate configuration is the plate only. Model-based assignment sends no AMS mapping — the printer is unknown until dispatch, where the scheduler derives it — so a per-candidate mapping editor would collect choices it then discards. Filament overrides stay shared: "this job needs PETG" holds for every slice of the same job. Adds Group as versions for durable grouping, a versions badge counting the whole group rather than the rows on screen, and a queue card label naming every model a pending item is waiting on.	2026-08-03 11:33:39 +02:00
MartinNYHC	8b46006644	Merge branch 'dev' into feature/oidc-env-config	2026-08-01 11:22:58 +02:00
maziggy	18938a10ee	fix(kprofiles): stop reporting rejected K-profile writes as saved Saving a K-profile was fire-and-forget. set_kprofiles_batch published and returned True, and the printer's extrusion_cali_set answer was logged at DEBUG and dropped, so a write the printer refused was reported to the user as saved (#2718, reporter @jmoore-skild). The reason it could not simply be gated on: the answer itself was wrong. Single-nozzle firmware returned result:"fail" with reason:"invalid tray_id" on writes that demonstrably applied. Measured against an X1C and an H2D over MQTT, the cause is the tray_id:-1 Bambuddy itself put in the payload. Sending three otherwise identical writes isolated it: tray_id:-1 fails, tray_id:0 succeeds, and cali_idx:-1 is accepted either way, so only that one field is at fault. The H2D ignores the value entirely; the X1C validates it, complains, and applies the write anyway. BambuStudio always sends a real tray_id and defaults it to 0 for a manually entered profile. With tray_id:0 the acknowledgement is honest, and the printer echoes back the sequence_id we sent -- confirmed for extrusion_cali_get, _set and _del on both printer classes -- so it can be matched to the write that caused it. Writes now return their sequence_id and the routes await the verdict, turning a real failure into an error that carries the printer's own reason. A printer that stays silent is still treated as success: no answer is not evidence of refusal, and firmware that never answers must not turn every save into an error. Raises the ack to INFO. It sat at DEBUG, so the one line that explains a failed save was absent from every support bundle -- the same reasoning that put ams_filament_drying at INFO for #1447. Also fixes extrusion_cali_set building its payload from str(self._sequence_id) without incrementing first, reusing the previous command's id. Harmless while nothing correlated on it, fatal now that the write path does. Adds supports_nozzle_flow_type() for the Standard / High Flow choice, which the K-Profiles UI previously showed as "Not reported by printer" -- not a value anyone can save. Most printers omit the nozzle identity from their calibration table entirely, and the slicer treats that as Standard rather than unknown; Bambuddy now does the same and keeps the choice editable. The field is hidden only where the model ships a single nozzle variant, using the slicer's own rule (len(nozzle_volume) // len(nozzle_diameter) > 1 over the machine preset) evaluated across every bundled Bambu profile. That puts only A1, A1 Mini and A2L on the hidden side -- it is not the single- versus-dual-nozzle split, since P1P, P1S, P2S, X1, X1C, X1E and H2S are all single-nozzle and all carry two variants. Editing a profile also no longer writes back an empty nozzle_id. Wiki records that on printers which omit the field the chosen flow type is discarded by the firmware and reads back as Standard, in Bambu Studio as well, so it does not get filed as a bug again.	2026-08-01 10:35:22 +02:00
MartinNYHC	21d61c3535	Merge branch 'dev' into feature/oidc-env-config	2026-07-31 17:05:24 +02:00
maziggy	455a9e4ba7	fix(backup): collect cloud profiles from every connected account (#2717 ) Enabling Cloud Profiles for a Git backup produced nothing, and said it had worked. Two independent faults, either one sufficient. The collector looked for a "setting" list. The Bambu Cloud listing endpoint is keyed by preset type instead, each key holding private and public arrays, so the loop body never executed once — and the entries carry no type of their own either, which routes/cloud.py already knew: it takes the type from the outer key and maps Bambu's "print" to process. Two bugs on one line. It also asked build_authenticated_cloud for the credential store used when authentication is disabled. With auth on, tokens live on User rows, so the collector returned at "Cloud not authenticated" before ever reaching the bad key. Every multi-user install was collecting from zero accounts. Neither failure surfaced. backup_metadata.json recorded the configured flag rather than the outcome, so it claimed cloud_profiles: true on runs that wrote nothing, and the log read "Collected cloud profiles: 0 filament, 0 printer, 0 process" at INFO — which is exactly what a successful backup of an empty account looks like. Cloud profiles now come from every connected account across both clouds. The toggle predates Orca Cloud entirely, and Orca has the same three preset types, so both are collected and grouped the same way: cloud_profiles/bambu/user-3/{filament,printer,process}.json cloud_profiles/orca/user-3/{filament,printer,process}.json Accounts are keyed by Bambuddy user id, "global" when auth is off. Never by email: a backup repository can be public, and the Bambu listing's user_id is dropped for the same reason. Both credential stores are read on every run, because a Settings row survives someone enabling auth later and dropping it would silently stop backing that account up. Bambu costs one get_setting_detail per private preset. The listing is metadata only, and without base_id and setting the backup is a list of names that create_setting cannot rebuild from. Public presets are skipped — Bambu's bundled catalogue is the same hundreds of entries for everyone, always re-downloadable, not recreatable under your account, and would rewrite the repository on every run. Orca needs no second call; its sync-pull carries each profile's content inline. Where the Orca route drops a profile whose content.type it cannot map, the backup writes it to other.json instead: silently omitting a profile because Orca added a type is the same class of bug as this one. Failures are contained per account and per preset, and counted rather than swallowed. A partial backup that looks complete is how this stayed invisible. The metadata now reports what was collected, per cloud and per account, and a run that collects nothing while the category is enabled warns with the reason instead of an INFO line that reads like success. The checkbox gated on the viewer's own Bambu sign-in, which is not the same question as whether there is anything to back up — with auth enabled the accounts belong to individual users, and an administrator who never signed in personally saw the category disabled with plenty in scope. It now gates on the total across both clouds and shows the counts. That comes from its own endpoint rather than a field on /config, since /config answers null until the first save and would disable the toggle during the very setup it belongs to. Counts only, never identities. One deliberate restraint. _build_authenticated_service clears stored credentials when a refresh is rejected, which is right for a route — the user is on the page and can pair again — and wrong for a scheduled job. Orca reports every rejection with one composite reason ("unknown, expired, revoked, or already used"), so a genuine revocation cannot be told apart from a lost token-rotation race, and acting destructively on a signal that cannot be disambiguated is the #2562 mistake in a different cloud. It also gains nothing: the Profiles route hits the same failure and clears it then, with the user present. Background callers now pass clear_on_auth_failure= False and skip the account. A successful refresh is still persisted either way — by that point the old token is consumed, so dropping the new pair would break a working pairing for real. Restore is not part of this. Nothing reads cloud_profiles/* yet; the format carries base_id/setting for Bambu and content for Orca so that it can.	2026-07-31 16:59:33 +02:00
behrinml	037688514a	Merge remote-tracking branch 'upstream/dev' into feature/billing	2026-07-31 15:52:40 +02:00

1 2 3 4 5 ...