maziggy b5a2f56cca fix(notifications): defer first-layer photo until printer is actually printing (#1837) ...

P1S and other Bambu printers tick layer_num during the pre-print calibration
sequence (homing -> auto bed leveling -> bed-surface scan -> nozzle clean ->
purge / wipe), so a bare `2 <= layer_num <= 5` gate fires the first-layer
notification minutes before the first real extrusion. The attached photo
shows a lowered bed, parked toolhead, and a clean plate -- exactly the
state during PREPARE, not after layer 1.

The reporter's log timeline made it explicit:
- 13:54:27  PRINT START detected
- 14:10:13  [SNAPSHOT] Capturing fresh frame  (notification fires here)
- 14:44:28  gcode_state: RUNNING (debug log, only visible because they
            enabled debug logging mid-print)

So the notification went out ~30 minutes before the print actually started.

Fix in main.py:6043 -- the on_layer_change first-layer block now requires
both:

  - state.state == "RUNNING" (gcode_state is RUNNING, not PREPARE)
  - state.mc_print_sub_stage in (None, 0)
    (0 = "Printing" in the canonical STAGE_NAMES at bambu_mqtt.py:376;
    None preserved as a no-opinion fall-through for any firmware that
    doesn't push the sub-stage so unknown-firmware installs keep
    their existing behaviour)

_first_layer_notified is only set after the gate passes, so calibration
ticks are non-consuming -- the next on_layer_change edge fires the
notification once the printer is actually printing.

The trigger window widens from [2, 5] to [2, 10] so that if calibration
consumed several layer_num slots before RUNNING, the deferred edge
still falls inside. The RUNNING + sub-stage gate ensures we don't fire
on a stale layer count.

2026-06-28 11:39:47 +02:00

..

app

fix(notifications): defer first-layer photo until printer is actually printing (#1837)

2026-06-28 11:39:47 +02:00

tests

fix(permissions): self-heal Administrators to ALL_PERMISSIONS on upgrade + Pipelines runs dashboard polish

2026-06-28 11:18:18 +02:00

__init__.py

…