Controller, GlobalDatastore und Dateien

Diese Seite beschreibt, was aus dem Schema „Module → Properties → Elemente“ der vorherigen Seiten herausfällt: die Controller-Daten, das zentrale Modul GlobalDatastore und das Dateisystem des Servers. Ein Client, der sich darauf beschränkt, Module anzuzeigen, braucht sie nicht; ein Client, der das anbieten will, was eine Seite mit globalen Einstellungen bietet (Konfigurationen, INDI-Treiber, Serverlast, Ausrüstung, Bilder), muss sie verarbeiten.

Die Controller-Daten (`controllerdata`)

Der Controller ist die Komponente des Servers, die die Module lädt und den eingebetteten INDI-Server steuert. Er stellt seine eigenen Daten im Dump unter dem Schlüssel controllerdata bereit (siehe d) und hält sie anschließend mit uc-Nachrichten aktuell.

Schlüssel	Inhalt
`availableconfs`	Gespeicherte Modulkonfigurationen: Objekt `Konfigurationsname → Liste von {modulelabel, moduletype, profilename}`
`currentconf`	Name der aktuellen Konfiguration
`banner`	Banner des Servers (Freitext, Option `--banner`)
`git`	Version des Servers: `Gitdate`, `Githash`, `Gitmessage`, `Gittag`
`libraries`	Verfügbare Modulbibliotheken, ein Metadatenobjekt pro Bibliothek
`profiles`	Verfügbare Profile: Objekt `Klassenname des Moduls → Liste von Profilnamen`
`indiserver`	`"Y"`, wenn der eingebettete INDI-Server aktiviert ist, sonst `"N"`
`indidrivers`	Katalog der installierten INDI-Treiber: Liste von `{binary, family, label, mdpd}`
`indiactivedrivers`	Aktuell gestartete INDI-Treiber
`systemwatcher`	Serverlast, siehe unten
`files`, `folders`	Kopie von `d.files.files` und `d.files.folders`, siehe Dateisystem

uc: ein Schlüssel pro Nachricht, Wert wird komplett ersetzt

Eine uc-Nachricht trägt einen einzigen Schlüssel von controllerdata, und ihr Wert ersetzt den alten vollständig (keine Zusammenführung). Ein Client, der nur den ersten Schlüssel des Payloads liest (wie es Rooster tut), ist daher korrekt, solange der Server nur einen Schlüssel pro Nachricht sendet — was heute der Fall ist.

`systemwatcher`: Serverlast

Der Server misst seine eigene Last in regelmäßigen Abständen und sendet sie an alle Clients. Das Intervall wird mit der Option --systemwatchinterval eingestellt (Sekunden, Standard 10, 0 deaktiviert). Die Nachricht ist ein gewöhnliches uc, und der letzte Wert steht auch in controllerdata.systemwatcher des Dumps.

{
  "uc-update controller data": {
    "systemwatcher": {
      "cpu": { "load_1m": 10.42, "load_5m": 9.79, "load_15m": 4.51 },
      "ram": { "used_mb": 12194, "total_mb": 31941 },
      "disks": [
        { "device": "/dev/nvme0n1p2", "mountpoint": "/", "used_gb": 789.4, "total_gb": 915.3 }
      ],
      "network": [
        { "iface": "enp4s0", "rx_kbps": 16.27, "tx_kbps": 448.8 }
      ],
      "temperatures": [
        { "type": "Tctl", "temp_c": 75.375 }
      ]
    }
  }
}

Feld	Bedeutung
`cpu.load_1m` / `load_5m` / `load_15m`	Durchschnittliche Systemlast (wie `/proc/loadavg`), kein Auslastungsprozentsatz: 1.0 = im Mittel ein ausgelasteter Kern
`ram.used_mb` / `total_mb`	Belegter Speicher (gesamt − verfügbar) und Gesamtspeicher, in MB
`disks[]`	Ein Element pro eingehängtem Speichergerät (`/dev/*`, ohne `loop`): `device`, `mountpoint`, `used_gb`, `total_gb`
`network[]`	Ein Element pro Schnittstelle (ohne `lo`): Raten `rx_kbps` / `tx_kbps`, gemessen zwischen zwei Nachrichten; der erste Messwert einer Schnittstelle ist 0
`temperatures[]`	Hardware-Sensoren des Prozessors: `type`, `temp_c`. Die Liste kann je nach Rechner leer sein (nur Sensoren vom Typ Intel `coretemp` und AMD `k10temp` werden gelesen)

Nicht davon ausgehen, dass die Arrays gefüllt sind

disks, network und vor allem temperatures können leer sein. Ein Client sollte den entsprechenden Abschnitt ausblenden, statt ein leeres Array anzuzeigen. Das Protokoll liefert nicht die Kernzahl des Servers: eine CPU-Anzeige kann daher kein echter Prozentwert sein, der Wert muss als Last dargestellt werden.

Konfigurationen und Modul-Lebenszyklus

Eine Konfiguration ist eine benannte Menge von Modulen (Bibliothek, Label, Profil), die der Server auf einmal neu laden kann. Die Liste steht in controllerdata.availableconfs, die aktive Konfiguration in controllerdata.currentconf.

Aktion	Befehl	Detail
Konfiguration laden	`CL`	Lädt alle Module der Konfiguration
Aktuelle Konfiguration speichern	`CS`	Unter dem angegebenen Namen
Modul laden	`ML`	Bibliothek, Label, optionales Profil
Modul entladen	`MK`	Nach Modulname

Die tatsächlich geladenen Module sind die des Dumps (d.m); sie erscheinen und verschwinden über aa und dm. Die Konfiguration enthält niemals GlobalDatastore (siehe unten), das immer vorhanden ist.

INDI-Server und Treiber

Wenn controllerdata.indiserver den Wert "Y" hat, steuert der Server eine eingebettete INDI-Instanz. Die Befehle YA/YZ/YL/YR/YS starten und stoppen sie und verwalten die Treiber; controllerdata.indidrivers liefert den verfügbaren Katalog und controllerdata.indiactivedrivers das, was läuft. binary ist der Wert, der als driver in YL, YR und YS übergeben wird.

Das Modul `GlobalDatastore`

GlobalDatastore ist im Dump ein Modul wie jedes andere (d.m.GlobalDatastore, mit Properties, Elementen, Grids, Profilen), spielt aber eine zentrale Rolle:

es wird vom Server vor allen anderen Modulen erstellt und ist immer vorhanden: MK darauf wird abgelehnt, und es ist nie Teil einer Konfiguration;
es trägt das gemeinsame Ausrüstungsverzeichnis, das alle anderen Module nutzen: Optiken, Standorte, Ausrüstungen (Gerätesätze) und INDI-Server.

Seine Grids dienen als Quelle für Auswahllisten (LOV) gleichen Namens, die in d.lovs stehen (optics, locations, equipments, servers) und bei jeder Änderung des Grids neu aufgebaut werden. Die anderen Module nutzen sie so: Die Wahl einer Optik füllt Brennweite und Durchmesser, die Wahl eines Standorts füllt Breite, Länge und Höhe, die Wahl eines Ausrüstungssatzes löst die Geräte auf (Kamera, Montierung, Fokussierer, Filterrad, Guiding-Kamera, GPS, Kuppel, Wetter) sowie den zu kontaktierenden INDI-Server.

Bereitgestellte Properties:

Property	Rolle
`devices`	Ausgewählter Ausrüstungssatz und GPS (`equipments`, `gps`)
`devicesactions`	Schaltflächen: Geräte verbinden/trennen, Konfigurationen laden (`condevs`, `discondevs`, `loadconfs`)
`server`	Host und Port des INDI-Servers (`host`, `port`)
`serveractions`	Schaltflächen: INDI-Server verbinden/trennen (`conserv`, `disconserv`)
`startup`	Kontrollkästchen für den automatischen Start (`indiatstart`, `devatstart`, `confsatstart`)
`equipments`	Grid der Ausrüstungssätze
`locations`	Grid der Standorte (Icons `refresh` = GPS lesen, `add` = aktuelle Zeile hinzufügen)
`optics`	Grid der Optiken
`servers`	Grid der INDI-Server

Alle Properties werden mit den Standardnachrichten bedient (SV, SA, GC …, I3/I4 auf locations); ein generischer Client zeigt sie wie jedes andere Modul an. Rooster stellt sie in einem eigenen Tab seiner Einstellungsseite dar, wobei es die Properties mit Profil (hasprofile) auswählt und nach level1/level2 gruppiert.

Dateisystem

Der Server veröffentlicht die Liste der erzeugten Dateien (Bilder, Sequenzen, Archive) im Ordner --webroot, ohne dass der Client danach fragen muss. Dieser Mechanismus ist unabhängig von den Modulen.

Im Dump: `d.files`

"files": {
  "folders": ["", "/Allsky", "/Sequencer/gam Cyg/LIGHT/Luminance"],
  "files": ["/image1.jpeg", "/rapport.txt"],
  "selectedfolder": "/home/gilles/ostmedia"
}

Feld	Inhalt
`folders`	Alle Unterordner des Webroots, rekursiv, Pfade relativ zum Webroot und mit führendem `/`. Das Wurzelverzeichnis ist die leere Zeichenkette `""`. Nicht sortiert.
`files`	Die Dateien nur des ausgewählten Ordners (nicht rekursiv), Pfade relativ zum Webroot und mit führendem `/`. Alle Dateien, ohne Erweiterungsfilter.
`selectedfolder`	Der ausgewählte Ordner als absoluter Pfad im Dateisystem des Servers (nicht relativ).

Es gibt weder Paginierung noch Größenbegrenzung: bei einem sehr gefüllten Webroot kann die Liste lang sein.

Den Ordner wählen: `FS`

FS bestimmt den Ordner, dessen Dateiliste man haben möchte. Der Server überwacht immer nur einen einzigen Ordner.

Der ausgewählte Ordner gilt global für den Server

Es gibt keinen Ordner pro Client: ein FS ändert die Dateiliste, die alle verbundenen Clients sehen (die untenstehenden Ereignisse werden an alle gesendet). Ein Client sollte es nicht für eine rein „lokale“ Navigation verwenden, wenn andere Clients verbunden sein können.

Der Server validiert den Pfad nicht: ein nicht existierender Ordner liefert einfach eine leere Liste, ohne Fehler.

Aktualisierungen: `evt`

Wenn sich der Inhalt des ausgewählten Ordners ändert (Datei erstellt, gelöscht oder umbenannt) oder nach einem FS, sendet der Server evt-Ereignisse auf oberster Ebene:

{ "evt": "fileadd", "fileevent": ["/Sequencer/gam Cyg/LIGHT/Luminance/img_001.FITS"] }
{ "evt": "filedel", "fileevent": ["/rapport.txt"] }

Wert von `evt`	Bedeutung
`fileadd`	Datei(en) im ausgewählten Ordner hinzugekommen
`filedel`	Datei(en) aus dem ausgewählten Ordner verschwunden
`folderadd` / `folderdel`	Unterordner im Webroot erstellt / gelöscht (gleiche Form, `fileevent` enthält die Ordnerpfade)

fileevent ist immer ein Array; heute enthält es einen einzigen Pfad pro Nachricht (N Dateien = N Nachrichten). Nach einem FS erhält der Client für jede Datei des alten Ordners ein filedel und dann für jede Datei des neuen ein fileadd: es gibt keine Nachricht, die den neuen selectedfolder ankündigt, der nur im Dump existiert.

Zusätzlich sendet der Server bei jedem Durchlauf uc-Nachrichten files und folders mit den vollständigen Listen: ein Client kann also entweder die evt-Ereignisse einzeln anwenden oder seine Listen einfach mit diesen uc ersetzen.

Falle: evt beginnt mit ev

Die übliche Regel ist, die ersten 1 oder 2 Zeichen des Schlüssels zu vergleichen. evt beginnt jedoch mit ev, dem Typ der Element-Updates mit Metadaten, deren Payload ein Objekt und keine Zeichenkette ist. Ein Client, der über das Präfix verzweigt, muss vor dem Test auf ev auf exakte Gleichheit mit evt prüfen, sonst hält er ein Dateiereignis für ein Element-Update.

Die URL einer Datei bilden

Die Pfade in files sind relativ zum Webroot und beginnen mit /. Die URL einer Datei ist die Basis-URL der Medien des Servers (http(s)://hostname/ostmedia/, siehe den Hinweis „URLs media“ im Datenmodell) gefolgt vom Pfad. Vorsicht beim führenden /: an eine Basis angehängt, die schon mit / endet, ergibt es ein doppeltes //.

Was das Ereignis nicht leistet

Der Server erkennt das Hinzufügen, Löschen und Umbenennen von Dateien, nicht die Änderung des Inhalts einer bestehenden Datei: ein unter demselben Namen neu geschriebenes Bild löst kein Ereignis aus. Das gilt für die Vorschaubilder der Module, deren URL bei jeder Aufnahme identisch bleibt: ein Client muss einen Cache-Busting-Parameter (?t= + Zeitstempel) anhängen, wenn er ein Bild nach einer Aktualisierung seiner Property neu lädt.