Round-2 cmd.jsonl from shaddowlink proves the bridge forwards both commands and
responses correctly: ams_filament_setting round-trips with result=success on P1S,
the cached push_status carries tray_info_idx=GFA11/tray_type=PLA-AERO/K-n/cali_idx
intact, and the visible "unload" symptom comes from the slicer's choice of
extrusion_cali_set (push K direct, P1S firmware rejects) vs extrusion_cali_sel
(select by id, both H2D and P1S accept). The open question is what makes the
slicer pick _set vs _sel — likely the info.get_version response Bambuddy
synthesises or the first cached pushall reply the slicer reads at connect.
Round 2 captured neither; the JSONL had slicer_to_bridge and printer_to_slicer
but no direction for the bridge's own synthesised replies.
Same BAMBUDDY_VP_DUMP_WIRE=1 flag now also appends a bridge_to_slicer line for
every bridge-synthesised reply (info.get_version answer, project_file ack,
on-demand pushall response). Capture is in _publish_to_report — the single
chokepoint — gated on a new log_event param; the 1Hz periodic push threads
log_event=False so the JSONL isn't flooded (~60 lines/min/VP) because
dump_wire already covers cache shape per tick.
Diagnostic-only, no data-path change. Default param preserves every existing
call site's behaviour.
The shape-of-payload dump shipped earlier rules out cache wipes —
shaddowlink's round-1 captures show AMS data reaches the slicer
byte-identical to what the printer sent. The remaining symptom
(picking a generic filament in archive mode "unloads" the slot) lives
on the command path, which the snapshot dump doesn't see: it writes
only the cached _latest_print_state and the periodic 1Hz push.
Add append_event() in _debug.py — same env flag, separate file at
<log_dir>/vp_wire/<vp>_cmd.jsonl. One JSONL line per event with UTC
iso timestamp, direction (slicer_to_bridge / printer_to_slicer), MQTT
topic, <channel>.<command> grep handle, and parsed payload. Wired at
two points: mqtt_server._handle_publish for slicer publishes (after
JSON decode so the trace matches what the bridge actually parsed) and
mqtt_bridge._on_printer_raw "everything else" branch for printer
responses (after serial rewrite so the trace matches what the slicer
sees on the wire). Pushall / get_version stay out — both are handled
locally and never round-trip through the bridge.
Bytes payloads get the same \x00-tolerance fix from #927 so
OrcaSlicer's C-string-null publishes parse cleanly; un-parseable
bytes fall back to {"raw": "..."} so every line stays valid JSON.
Add a BAMBUDDY_VP_DUMP_WIRE=1 escape hatch that writes the bridge's
cached push_status (in) and the 1Hz slicer-facing copy (out) to
<log_dir>/vp_wire/<vp_name>_<direction>.json, overwritten each tick.
#1622's symptom — empty filament dropdown in slicer's AMS slot details
for P1S/A1 but not H2D in non-proxy VP modes — needs visibility into
the actual wire bytes flowing through the bridge to bisect between
"cache is missing fields" and "_send_status_report strips them on copy."
The existing logs prove the bridge is bound and pushing at 1Hz, but
not what's in the payload.
Off by default, single env flag, single file per VP per direction
(bounded disk footprint), failures swallowed at debug so a broken
dump can never break the 1Hz loop. 21 tests pin the helper contract:
disabled-by-default, atomic writes, sanitized vp_name (no path
escape), per-call env check so toggling without restart works.
