octoturge
818f28ea5d
The gateway and backend halves of `discovered_printers` are hand-synced, so every hand-written example in this file agrees with whichever side wrote it - which is exactly how the two ends of /ws/edge/v1 drifted into different protocols before. A capture is the only thing that catches that. This one came off a live LAN with a Bambu P1P and H2C on it, through the gateway's own serde enum, with its fleet file pointed at an empty file so nothing was filtered out. The addresses and the shape are as captured. The two serials are placeholders of the captured shape. They identify someone's physical hardware, no test depends on their value, and no other fixture here carries one - so the real ones are not something to commit on the owner's behalf.
26 lines
1.3 KiB
JSON
26 lines
1.3 KiB
JSON
{
|
|
"_note": "A real `discovered_printers` frame, captured on 2026-10-19 by running `cargo run --example discover_printers -- wire 192.168.0.0/24` against a live LAN with a Bambu P1P and H2C on it, with the gateway's fleet file pointed at an empty file so nothing was filtered out. The addresses and the message shape are exactly as captured. The two `serial` values are PLACEHOLDERS of the captured shape (15 alphanumeric characters) rather than the real ones: the serials identify someone's physical hardware, nothing in this test depends on their value, and no other fixture here carries one. Note what the frame does not contain, which is the point of the format: no access code, no API key. Re-capture with the `wire` subcommand above when the message changes.",
|
|
"frames": [
|
|
{
|
|
"type": "discovered_printers",
|
|
"printers": [
|
|
{
|
|
"vendor": "bambu",
|
|
"address": "192.168.0.20",
|
|
"serial": "01S00A000000000",
|
|
"source": "certificate",
|
|
"driver_ready": true
|
|
},
|
|
{
|
|
"vendor": "bambu",
|
|
"address": "192.168.0.21",
|
|
"serial": "31B0BP0A0000000",
|
|
"source": "certificate",
|
|
"driver_ready": true
|
|
}
|
|
],
|
|
"scanned_at": "2026-10-19T08:20:03Z"
|
|
}
|
|
]
|
|
}
|