Record a fixture and replay it

A unit on the bench goes back to its owner, and what it did goes with it. A recording keeps every exchange the bench had with it, bytes both ways, and a replay lets that recording answer for the unit afterward: to take its report again, run the behavior check on it, or show a maker exactly what their fixture does, with the unit gone.

Recording

The app keeps the wire log of this connection in memory, and Export… in Fixture → Wire Log… saves it as a .jsonl file. Export before you disconnect: the log is gone after.

On the command line, add --record to any command that connects, such as rdmbench-cli snapshot --record. The log goes to the captures folder’s wire folder, or to --record=FILE. It holds every RDM exchange the run made, late and missing replies included, and the DMX levels sent. rdmbench-cli wire reads the newest one back.

Replaying

--replay takes one or more logs in place of the widget, and the bench answers each request with what the fixture said at the time, lateness and mistakes included: rdmbench-cli snapshot --replay FILE. Give --replay once for each file, in the order they were recorded, and one unit’s separate runs answer as one fixture.

A request is answered only if the recording made the same one: the same parameter, to the same fixture, with the same data. Anything else is silence, and is counted at the end of the run, so a gap in the recording is not read as the fixture ignoring something. A replay answers best for the commands that made it.

A replay does not act on what it is sent. A SET changes nothing in the answers that follow: a later GET plays what it was recorded saying.

A replay is not a visit

A replayed fixture is treated like the simulator: what it saves goes in the captures folder’s simulator folder, and it never adds a visit to the real unit’s history.