Bugtracker DMXControl 3

  • Status Unbestätigt
  • Prozent erledigt
    0%
  • Aufgabentyp Wunsch / Idee
  • Kategorie GUI & Server → Server → DMX Plugin
  • zuständig niemand
  • Betriebssystem All
  • Schweregrad niedrig
  • betrifft Version unbestimmt
  • fällig in Version unbestimmt
  • fällig am unbestimmt
  • Stimmen
  • versteckt
gehört zu Projekt: DMXControl 3
angelegt von Souko - 19.02.2019

FS#3383 - Firmware fuer DMXControl-HW mit Lumos ausliefern

Da wir immer mehr eigene Hardware anbieten und auch hin und wieder neue Funktionen in die Devices kommen, welche z.T. eng mit DMXC verknüpft sind (Nodle U1, Sync ausgabe, heartbeat), wäre es vielleicht sinnvoll die jeweils aktuellste Firmware für z.B. das Nodle U1 und dann auch das R4S und zukünftige mit DMXC 3 auszuliefern und eventuell beim Start den User darauf hinzuweisen, das eine neue FW verfügbar ist.

DMXC3 müsste dafür nur eine Datei pro HW haben, in welcher die aktuellen FWs stehen und diese beim Verbinden mit dem Interface abgleichen.
Wurde eine ältere Firmware im Device erkannt, kann wird beim Start der Software und verbinden der HW eine MessageBox geworfen und die Verbindung abgebrochen mit Hinweis auf die neue FW.

Der User kann nun entscheiden ob er die Hardware mit der alten FW verbinden will oder zunächst ein Update machen will.
Bei Update-Entscheidung muss DMXC nur ein kleines von uns mitgeliefertes Programm/Tool/exe starten, welches in einem definierten Pfad im Kernel oder GUI liegt.

z.B. beim U1: kernel/hardware/nodle_u1/update.exe –Serialnumber
oder beim R4S: kernel/hardware/nodle_r4s/update.exe –Serialnumber

Das Programm “update.exe” ruft dann die nötigen subprogramme/Funktionen/etc aus dem Ordner auf, um den User durch den Flashvorgang zu leiten.
Wenn erfolgreich, meldet das Programm “exit 0” oder so zurück und DMXC3 kann mit dem Verbindungsaufbau zur HW fortfahren.
Die Seriennummer oder eine andere Geraetekennung (je nach Device) dient dazu mehrere angeschlossene Geräte zu unterscheiden.

Je nach Gerät passiert das alles nach dem druck auf “Ja Update Jetzt” automatisch, weil der User keine Interaktion mit der HW benötigt.
Die spezifischen Unterschiede für jede Hardware sind von DMXC3 komplett entkoppelt und nur in der update.exe pro Hardware zu warten.
Damit ist das jederzeit austauschbar/anpassbar ohne DMXC und dessen Hardware-Treiber zu beeinflussen.

Als Luxus-Variante könnte in dem “neue FW-Fenster” noch der Changelog bzw. die neuen Funktionen des Firmware drin stehen, die sich DMXC aus besagter Versionsdatei in dem jeweiligen Verzeichnis ziehen kann.

Project Manager
Soon5 schrieb am 19.02.2019 11:49

An der Stelle würde ich sagen, macht das so wenig Sinn. Hier brauchen wir einen "Online Dienst" ähnlich der DDFLib in welchem wir:
1. Die Firmwarestände verwalten können
2. Die Firmware zum zugehörigen DMXControl Plugin mappen können
3. Beides direkt aus der Software downloaden.

Wir haben ja schon darüber gesprochen, dass ein solches System auf Grundlage der DDFLib Super wäre, aber Moritz hat halt auch nur ein begrenztes Zeitbudget und meiner Ansicht nach geht da Beamy (oder wie es auch heißen mag) vor.

LightningBrothers schrieb am 19.02.2019 20:34

Ich denke aus Usersicht sollte das durchaus sinnig sein, hier eine nahezu automatisierte Updatemöglichkeit anzubieten, für die man insbesondere nur ein Tool benötigt. Zudem dürfte das Tool auch gerade für die Bastler interessant sein, die häufiger die Firmware tauschen wollen.

Grundsätzlich sollte aber ganzheitlich betrachtet darüber nachgedacht werden, dieses Tool mit dem Installationsmanager für Plugins (siehe FS#3136) zusammenführen, um den Nutzern nicht erklären zu müssen: Firmware-Update hier, Plugin-Installation und Update dort.

Admin
Souko schrieb am 20.02.2019 11:47

zum Thema Online sehe ich das hier anders wenn es um Devices-Firmware geht.

So können wir immer genau die Firmware ausliefern, welche die nötigen Funktionen in der Hardware beinhalten, die für genau die DMXControl-Version benötigt werden, mit welcher sie geliefert wurden.

Angenommen jemand hat an seinem Disco-Rechner kein Internet und sein Nodle 1.05 mit Heartbeat und Sync-Ausgabe (die er unbedingt wegen der Matrix an der Bar braucht) daran geht hops. Er hat aber als Reserve irgendwo noch ein Nodle von vor 4 Jahren mit FW 1.03 in der Kiste. Dann kann er es anstecken und fix die Firmware aktualisieren um alle besagten Features der aktuellen Version zu nutzen.

Wenn das wieder Online verbunden ist, geht das so einfach nicht. Dann muesste man wieder alle FW-Images einmal downloaden und zwischenspeichern oder manuell in das programm schieben. → Dann kann man die gleich mit ausliefern.

Und da wir neue Features in die Hardware meistens nur einbauen, wenn wir das Gegenstueck in der neuen DMXControl-Version einbauen, macht es mMn wenig Sinn, hier über eine online-Funktion die neue FW in einer älteren DMXC-Version anzubieten, wenn sowieso auch DMXC herunter geladen werden muss zum aktualisieren.

Ausserdem braucht der Online-App-Kram auch wieder Wartung. So könnte man einfach immer den letzten Build aus den HW-Jobs bei Jenkins mit in den Installer packen.

Und sooo viel HW werden wir auch in den nächsten Jahren nicht entwickeln, als dass und der Installer hier um zig MB groesser wird.

Momentan denke ich da an:

R4S, U1 (wobei da nicht mehr viel kommen wird), Nodle_U2_Plattform, DUED-nodes

Admin
Souko schrieb am 20.02.2019 11:49

Fuer Stefans vorschlag was die Plugins angeht macht sowas wie ein Online-Repo durchaus sinn ! - Daher wuerde ich diese beiden Dinge ganz klar trennen wollen !

Plugins können auch von Drittanbietern kommen und asynchron zur DMXControl-Version veröffentlicht werden. Bei der Firmware fuer unsere HW sehe ich das nicht.

LightningBrothers schrieb am 20.02.2019 13:18

Die Trennung Offline für Firmware-Updates und Online für Plugins könnte ja intern "unter der Oberfläche" laufen, wovon der Nutzer ja nur bedingt etwas mitbekommen muss.

Die Aussage "Firmware-Update nur mit Installer ausliefern" fände ich durchaus valide, sodass man sich hier in der Tat eine Online-Anbindung sparen kann.

Bei den Plugins kann es übrigens ähnlich laufen. Der Installationsmanager sollte im ersten Wurf die User bei der korrekten Installation unterstützen, sodass sie dann nur ein passendes zip-Archiv auswählen müssen, dessen Inhalt der Installationsmanager dann in die richtigen Verzeichnisse schiebt.

Admin
Souko schrieb am 21.02.2019 05:38

Ich würde sagen Plugins und Firmware für Geräte sind zwei völlig verschiedene Anwendungsgebiete. Daher sollte man das auch trennen.

Ich denke das einfachste dürfte sein, beim verbinden von Interface XYZ in einem definierten Ordner zu schauen, ob dort ein Verzeichnis mit dem Namen XYZ vorhanden ist und in diesem Ordner eine "Version.xml" oder so. Darin steht die aktuell vorhandene Firmware, welche dann natürlich auch in dem Ordner liegt.

Vorteil daran: man braucht in DMXC keine riesen aufwand zu pflegen welche Interfaces wo liegen, etc.

im Anhang mal ein Kurzes Diagramm, wie ich mir den Ablauf beim verbinden der HW vorgestellt haette.

Lade...

verfügbare Tastenkürzel

Aufgabenliste

Aufgabendetails

Aufgabenbearbeitung