The Protocol
The OpenPiste Protocol
Communication is the backbone of any fencing electronics ecosystem. Every component — scoring device, remote control, display, weapon tester, video referee tool — needs to exchange data reliably, in real time, in a format that any device can consume.
OpenPiste defines an open communication standard for this purpose: the OpenPiste Protocol.
Why a new protocol?
Most commercial fencing equipment uses Cyrano (technically EFP1.1), a UDP-based protocol designed in 2008. It works, but it was built for a different era:
- UDP provides no delivery guarantee — messages can be lost silently
- The format is positional CSV — adding new fields without breaking existing parsers is difficult
- Every device needs to know the IP address of every other device — a practical headache at any competition
- There is no timestamp — making video synchronisation impossible without additional infrastructure
- It carries only scoring data — there is no standard for remote control, tablet scoresheets, or other use cases
The OpenPiste Protocol replaces this with MQTT and JSON:
- MQTT runs over TCP — messages are delivered or the failure is known
- JSON is self-describing and forward-compatible — new fields are ignored by older receivers
- Every device only needs to know the address of the broker — no fixed IP management
- Millisecond-precision timestamps are built in — enabling accurate video referee synchronisation
- The topic structure is extensible — new use cases (remote control, tablet scoresheets, analytics) are added as new topics, not new protocols
Two levels
The protocol is structured in two levels, reflecting the reality of a large installed base of existing equipment.
Level 1 — EFP1.1 over MQTT
A bridge relays existing Cyrano UDP messages to an MQTT broker, unchanged. Existing scoring apparatus and competition management software require no modification. MQTT-native subscribers — displays, piste monitors, video tools — can immediately consume live data from existing infrastructure.
Level 1 is a migration bridge. It is not the destination.
Level 2 — Native JSON over MQTT
A clean, typed JSON protocol designed from the ground up for MQTT. Purpose-specific message topics, proper data types, retained state, and millisecond timestamps. Implementable on an ESP32 with standard open source libraries. Designed to cover the full fencing electronics ecosystem as it grows.
Level 2 is the destination.
Why not a middle step?
A middle step was considered — parsing EFP1.1 into JSON using the same field names as keys and publishing the result over MQTT. It was discarded for four reasons:
It adds no meaningful value over Level 1, since consumers must still understand EFP1.1 field semantics. It requires two parsing steps — CSV at the bridge, JSON at every consumer — making the bridge more complex than necessary. It inherits EFP1.1’s structural limitations — string-encoded integers, awkward field names, flat structure — in a format where developers would reasonably expect clean typed data. And it creates a false impression of a modern protocol while delivering the constraints of a legacy one.
Level 1 is honest about what it is. Level 2 makes a clean break. The middle step is neither.
Extensibility
Level 2 is designed to grow. New use cases are added as new MQTT topics without changing the protocol version or breaking existing receivers. Planned and possible additions include:
- Tablet-based scoresheet replacement
- Standardised remote control commands
- Analytics and AI tools
- Integration with competition management software
Open standard
The protocol specification is developed openly on GitHub. It is currently in draft. Feedback is actively sought from everyone in the fencing electronics community — developers, armourers, referees, competition organisers, and federation officials.