- Status geschlossen
- Prozent erledigt
- Aufgabentyp Wunsch / Idee
- Kategorie GUI & Server → Server
-
zuständig
Soon5 
Qasi - Betriebssystem All
- Schweregrad hoch
- betrifft Version 3.1
- fällig in Version unbestimmt
-
fällig am
unbestimmt
- Stimmen
- versteckt
gehört zu Projekt: DMXControl 3
angelegt von Souko - 27.05.2017
zuletzt bearbeitet von Soon5 - 12.11.2017
angelegt von Souko - 27.05.2017
zuletzt bearbeitet von Soon5 - 12.11.2017
FS#2831 - Heartbeat fuer DMX-Ausgabeschnittstelle
Wie mit Patrick besprochen sollte an der Pluginschnittstelle fuer die (DMX)-Interfaces ein Heartbeat-Signal implementiert werden, ueber das die Interface-Entwickler die Moeglichkeit haben den OK oder Error-Zustand ihres IF’s zu melden, sodass die GUI dem User melden kann “Irgendwas passt mit deinem IF nicht”
Die Bedingungen fuer ein Error-Flag sollten in den Plugins selbst definiert sein und Sache der IF-Entwickler bleiben.
DMXControl kennt also z.B. nur 2 bit.
1. Bit: 1 - dieses IF unterstuetzt Heartbeat ODER 0 - ich kenne kein Heartbeat
2. Bit: wackelt hin und her - IF alles gut ODER Bit wackelt nicht - IF Aua, tu was !
Es gibt bereits einen Event "InterfaceWorkingChanged" welchen der Interface Entwickler werfen kann, wenn sich der "Working" Status des Interfaces geändert hat, ergo wenn das Interface abgeschaltet hat. Den hab ich jetzt noch um ein "Error" Flag erweitert.
Der Interface Treiber kann also irgendwie die Funktion des IF überprüfen und bei Bedarf dem Kernel zurück melden.
Das einzige was so nicht abgefangen werden kann, ist wenn sich das IF Plugin selber irgendwie aufhängt. Die Frage ist allerdings, was man dann tun kann. In den meisten fällen hilft da nur ein Neustart.
Und genau um den letzten fall ging es, wenn das IF abschmiert und der Treibef das nicht mitkriegt
Also, wir haben 3 Teile in der Kette: (1) DMXControl => (2) Treiber => (3) Interface
Die Kommunikation (2) => (3) ist nicht in unserer Hand. Wenn also das Interface sich verabschiedet, und der Treiber (2) das nicht mitbekommt, können wir da nix machen. Evtl. bekommen wir das beim nächsten Senden mit, evtl. aber auch nicht. Hängt davon ab wie Interface und Treiber gebaut sind. Sollte es funktionieren, gibt es eine Möglichkeit wie der Treiber DMXControl das Problem mitteilen kann, über oben genanntes Event.
Für die Kommunikation (1) => (2) haben wir das Problem, das wir nicht prüfen können, was der Treiber tut. Das liegt auch nicht in unserer Hand. Selbst wenn wir einen "Heartbeat" einbauen, den der Treiber (2) regelmäßig aufrufen muss, wenn er das nicht tut, dann muss der User sowieso DMXC neu starten. Wobei wir vorher versuchen könnten den Treiber durch "Stop", "Init", "Start" wieder auf Spur zu bekommen.
Was du in deinem Kommentar schreibst ist aber die Strecke 2 => 3, auf die wir keinen Einfluss haben, daher nochmal die Klarstellung.
Beim Nodle haben wir aber Einfluss drauf und ich glaube, darum ging es Marcel auch, dass es vor allem beim Nodle eingebaut wird.
DMXControl (1) sollte eben genau dieses Feature anbieten. Wo wir die Hand drauf haben (bei unserer Nodle-Serie) sollten wir das bis zum IF selbst einbauen. (Wieder ein Alleinstellungsmerkmal für unsere Soft- und Hardware)
Der Treiber (2) sollte abgefragt werden, kannst du Heartbeat, wenn ja, dann melde das, wenn nein, dann schalten wir für diesen Treiber die Überwachung ab.
Ob in Zukunft andere IF-Anbieter unserem Aufruf folgen, das zu implementieren, das ist ein anderes Thema. Aber alleine für unsere Interfaces haben wir dann die tolle Aussage:
Wir unterstützen viele gute 3. Interfaces.. Wenn da aber Premium mit Überwachung der Funktion haben willst, nimm unser Nodle !
Dann bitte 2 neue Tickets machen. Das Ticket hier adressiert nur den Teil DMXControl zu Treiber. Wir brauchen dann noch ein Ticket, den Nodle Treiber zu Erweitern (für Stefan) und evtl. ein Ticket für Dirk für die Hardware.