UDP-Geräte-Discovery
Damit ein neues Endgerät den lokalen Standort-Server findet, ohne manuell eine IP eintippen zu müssen, läuft auf jedem Server ein UDP-Broadcast- Responder. Endgeräte schicken einen Discovery-Broadcast, der Server antwortet mit seiner Endpoint-Info.
Parameter
| Parameter | Wert | Bemerkung |
|---|---|---|
| Port | 34567/UDP | für Anfrage + Antwort |
| Magic (Welle 1C, neuere Clients) | PROFIPOS-DISCOVER-V6 | Server + Kasse + goapp |
| Magic (Kundendisplay, Welle 2B) | PROFIPOS-DISCOVER-V1 | aktuell noch eigene Konstante |
| Broadcast-Ziel | 255.255.255.255 | LAN-weit |
| Antwort-Latenz | < 100 ms | server-seitig handler-sync |
Magic-String-Inkonsistenz
Der Kundendisplay-Client (PairingCoordinator.cs) verwendet aktuell
PROFIPOS-DISCOVER-V1, während Kasse und goapp PROFIPOS-DISCOVER-V6
schicken. Der Server antwortet auf beide. Sollte beim nächsten
Pair-Test-Sprint vereinheitlicht werden (Ziel: …-V6).
Ablauf
Antwort-Payload (JSON)
{
"magic": "PROFIPOS-DISCOVER-V6",
"server_uuid": "…",
"server_name": "Cafe Lanz - Server 1",
"endpoint": "http://10.1.1.20:8080",
"mqtt_host": "10.1.1.20",
"mqtt_port": 1883,
"version": "6.0.22"
}
Sicherheits-Hinweis
Der Discovery-Layer authentisiert sich nicht — er liefert nur
Erreichbarkeits-Infos. Die eigentliche Auth erfolgt erst beim
Geräte-Pairing und danach per
pp_*-Bearer-Token.
Stille Fail-States
| Symptom | Wahrscheinliche Ursache |
|---|---|
| Discovery findet nichts | UDP-Broadcast vom AP blockiert (Client-Isolation) |
| Discovery findet, Server-Verbindung schlägt fehl | Firewall blockiert TCP/8080 oder TCP/1883 |
| Discovery findet, Antwort kommt aber doppelt | mehrere Standort-Server im selben LAN — bei Mehrstandort-Setups MUSS jeder Server in eigenem VLAN sitzen |