DISAG Opticscore JSON Live - was ist das?

    TLStatus: Zustand der Ampel während des Schusses; Wert = TrafficLightStatus(off, red, green)

    LastTLChange: Zeit in ms seit letzter Ampelschaltung; Wert int >=0

    Duffy Duc

    hat wohl sehr verkürzt die richtige antwort geliefert!

    im datenstrom des jason gibt es 2 meldungen, die dir den status der ampel angeben: das sind

    --> TLStatus: Zustand der Ampel während des Schusses; Wert = TrafficLightStatus(off, red, green)

    --> LastTLChange: Zeit in ms seit letzter Ampelschaltung; Wert int >=0

    wer hier eine externe ampel programmieren will, der muss nach - vor allem dem oberen - ausschau halten.

    der programmierer weiß dann damit auch was anzufangen.

    mfsg daniel

    Zitat von Gere

    Wie bekomme ich dafür über JSON Status bzw wie kann ich das auslesen

    Meine Annahme ist, dass die Ampel während LuPi Standard und vor allem LuPi Mehrkampf damit gemeint sind. Wenn dem nicht so ist bitte korrigieren.

    Die Anzeige der Ampel muss immer an/im dem Gerät erfolgen, dass auch die Steuerung dafür übernimmt. Also entweder im Messrahmen oder im Anzeigegerät, dass die Schüsse empfängt. Weil nur diese beiden Stellen entscheiden können und müssen, ob der Schuss in grün oder rot abgegeben wurden.

    Würde ich die Ampel über Serversoftware->Schnittstelle steuern, hätte ich immer einen zeitlichen Versatz, bedingt durch PC/Laptop und das Netzwerk. Daher ist bei Wettkämpfen entscheidend, dass der Messrahmen die Ampel steuert/anzeigt. Nur damit kann man sicher stellen, dass die korrekte Ampel dargestellt wird.

    Damit hätte ich Messrahmen -> Netzwerk -> Gate/SIZ -> Netzwerk -> Serversoftware -> JSON-Schnittstelle / Netzwerk -> Ampelanzeige. Da würde früher oder später ein deutlicher Versatz passieren und z. B. hätte der Schütze bei Duell noch immer grün, tatsächlich sind die 3 Sekunden (+ Kulanz Langlochregelung) schon um und der Schuss käme als ungültig im Wettkampf an.

    Von daher gibt es auch keine Live-Infos bzgl. der Ampel, sondern nur als Info zum Schuss, ob dieser in grün/rot abgegeben wurde und wie lang die letzte Schaltung der Ampel her ist.

    Danke Lukas für dein Beispiel.

    An sich ist die Json Schnittstelle eine super Sache. Für Programme wie den ShotAnalyzer total geeignet. Allerdings wäre mir eine RestAPI Schnittstelle lieber als ein UDP Broadcast. Weil das ganze hat einen großen Haken. Das externe Programm muss aufjedenfall laufen bevor ein Schuss im OSS fällt. Ansonsten kommt man an den Schuss nicht mehr ran.

    Ich baue mir gerade so einen Ergebnisserver für das Preischießprogramm, damit der Schütze sein Ergebnis abrufen kann. Daher denke ich werde ich eher den lesenden Datenbankzugriff bevorzugen.

    Hallo!

    Super und Danke, dass ihr Lösungen anbietet bzw. daran arbeitet. Ich als Otto-Normalanwender kenn mich zwar mit dem Disag Preisschießen und Opticscore Server leidlich aus. Jedoch weiß ich nicht, wie ich den Vorschlag von DerLolkas technisch verwirklichen soll, damit ich die Ergebnisse auslesen kann?:/

    (Ich hoffe, ich habe mich jetzt nicht als DAU geoutet?)

    Zitat von Mark87

    Danke Lukas für dein Beispiel.

    An sich ist die Json Schnittstelle eine super Sache. Für Programme wie den ShotAnalyzer total geeignet. Allerdings wäre mir eine RestAPI Schnittstelle lieber als ein UDP Broadcast. Weil das ganze hat einen großen Haken. Das externe Programm muss aufjedenfall laufen bevor ein Schuss im OSS fällt. Ansonsten kommt man an den Schuss nicht mehr ran.

    Ich baue mir gerade so einen Ergebnisserver für das Preischießprogramm, damit der Schütze sein Ergebnis abrufen kann. Daher denke ich werde ich eher den lesenden Datenbankzugriff bevorzugen.

    Definitiv wäre eine RestAPI besser. Aber der Broadcast hat eben genau den Vorteil was von dir als "Nachteil" genannt wird. Ich hänge meine UDP Client irgendwo in den IP Adressraum (Ob auf dem Server Rechner o. extra Rechner) und kann jederzeit wenn ein Telegramm kommt reagieren. Also auch wenn die Software später online kommt.

    Wenn man wie du natürlich jeden Schuss loggen will/muss dann ist es wiederum anders und ergibt somit einen Nachteil.

    Zitat von inntaler

    Hallo!

    Super und Danke, dass ihr Lösungen anbietet bzw. daran arbeitet. Ich als Otto-Normalanwender kenn mich zwar mit dem Disag Preisschießen und Opticscore Server leidlich aus. Jedoch weiß ich nicht, wie ich den Vorschlag von DerLolkas technisch verwirklichen soll, damit ich die Ergebnisse auslesen kann?:/

    (Ich hoffe, ich habe mich jetzt nicht als DAU geoutet?)

    Also die Ergebnisse auslesen war in folgendem Sinne gemeint. Der Ambitionierte Programmierer/Programmierneuling kann mein Projekt benutzen und daran anknüpfen. Muss nun also nicht mehr die ganze Schnittstelle selber basteln.

    Sprich wenn du dich heute noch mit C# befasst kannst du dir dein eigenes Progrämmchen basteln und mit den Daten der JSON Schnittstelle arbeiten.

    Eines der Probleme einer REST-API sind, dass dadurch die Kontrolle über die Auslastung der Serversoftware bedingt aufgegeben wird. Der Broadcast geht raus -> fertig. Hängt man sich eine andere Software ins Netz, die die Daten empfängt und speichert, kann man sie jederzeit wieder aufrufen.

    Eine API könnte mit Anfragen bombardiert werden, was dazu führen würde, dass die Serversoftware nur noch damit ausgelastet ist und ggf. andere wichtige Funktionen darunter leiden. Das die möglichen Fehler dann an einer Fremdsoftware liegen interessiert dann keinen mehr, zu sehen und kommuniziert wird nur "die Anlage geht nicht".