Updates und Sicherung

In der Oberfläche

Je Hub, Modul und Anzeige steht die installierte Version da und ob eine neuere vorliegt. Aktualisiert wird einzeln, ausgewählt oder „alle veralteten“. Eine Anzeige (WLAN) hat keinen Hub und holt ihre Firmware selbst über HTTPS vom Server; das dauert etwa eine halbe Minute.

Die Firmware zum System ist mitgeliefert: Sie wird beim Bauen des Backend-Images gebaut und beim Start übernommen. Eigene Versionen lädt der Hauptadmin auf der Systemseite hoch.

Update des Hubs

Über MQTT kommt nur der Hinweis. Die Datei holt der Hub per HTTPS vom Server, mit dem er verbunden ist. Eine Adresse mit http:// lehnt er seit 0.5.0 ab. Die Adresse gilt zwei Stunden und nur für diesen Vorgang.

Update des Hubs im Hub

Datei per HTTPS laden, Größe prüfen.
SHA-256 der Datei prüfen. Stimmt sie nicht, endet das Update, die alte Version läuft weiter.
In die zweite App-Partition schreiben.
Der Bootloader startet die neue Version zur Probe.
60 s

Die neue Firmware muss sich als gesund melden: Verbindung zum Broker steht, Status gemeldet. Sonst startet der Bootloader die alte Version.

Update der Module

Der Hub lädt und prüft die Datei einmal und spielt sie dann nacheinander in jedes Modul ein. Ein Modul nach dem anderen, damit nie mehrere Aufgaben gleichzeitig ausfallen.

Update eines Moduls über den Bus Hub und Modul

Das Modul wartet, bis es an der Reihe ist.
Die Firmware kommt in Blöcken über den CAN-Bus, mit der niedrigsten Priorität. Die Oberfläche zeigt den Fortschritt.
Das Modul prüft die CRC32 der Übertragung und die SHA-256 der ganzen Datei.
Die Ausgänge sind dabei im sicheren Zustand.
30 s

Das Modul meldet sich mit der neuen Version. Meldet es sich nicht innerhalb von 30 Sekunden, kehrt sein Bootloader zur alten Version zurück.

Während ein Modul aktualisiert wird, gelten seine Ausgänge als im sicheren Zustand. Regler, die das Modul brauchen, stehen so lange. Die Erkennung von Störungen ruht für seine Ausgänge.

Schlägt ein Modul fehl, macht der Hub mit dem nächsten weiter.

Ergebnis	Bedeutung
fertig	Das Gerät meldet sich mit der neuen Version.
gescheitert	Übertragung oder Prüfung gescheitert. Die alte Version läuft unverändert weiter.
zurückgefallen	Die neue Version startete, meldete sich aber nicht. Der Bootloader kehrte zur alten zurück.

Im Simulator lassen sich drei Fehler dazu einspielen: Die Übertragung bricht ab, die neue Firmware eines Moduls startet nicht, der Hub startet nach dem Update nicht.

Von 0.2 auf 0.3.0

Mit 0.3.0 sind Kennungen und Topics englisch. Ein Hub mit 0.2 versteht den Server danach nur noch teilweise: Sollwerte und Reglerzustand laufen über andere Topics. Das Update des Hubs selbst geht weiter. Deshalb gilt die Reihenfolge: zuerst den Hub auf 0.3.0 bringen, danach die Module über ihn.

Gespeicherte Daten werden übersetzt, nicht neu angelegt. Alte Adressen der Oberfläche leiten auf die neuen um, Links aus schon verschickten Mails bleiben gültig.

Von 0.3.0 auf 0.4.0

Erst der Hub, dann Module und Anzeigen. Ein Hub mit 0.4.0 arbeitet mit Modulen auf 0.3.0 weiter, nur ohne die neuen Funktionen; ist ein Modul für etwas Eingestelltes zu alt, meldet der Server eine Warnung mit der nötigen Version.

Der Hub puffert Abbilder für Module und Anzeigen jetzt bis 2 MB statt 1 MB. Dafür braucht er eine neue Partitionstabelle: Bestehende Hubs einmal per USB flashen, dabei bleibt alles erhalten. Über die Oberfläche aktualisiert läuft ein Hub auch, verteilt dann aber nur Abbilder bis 1 MB und sagt das in seinen Einstellungen.

Auf 0.5.0: Netzwerk immer verschlüsselt

Hub und Server sprechen seit 0.5.0 nur noch über TLS. Hubs bis 0.4.0 sprechen nur Klartext und erreichen einen neuen Server nicht mehr. Deshalb erst den Server aktualisieren, dann jeden Hub einmal per USB flashen und im Einrichtungs-WLAN den vollständigen Einrichtungscode mit dem Server-Schlüssel eintragen.

Auf 0.8.0

Erst der Server. Eine Anzeige (WLAN) mit Firmware bis 0.7.3 danach einmal per USB flashen. Hubs, Module und Anzeigen am Bus wie gewohnt aus der Oberfläche aktualisieren.

Auf 0.9.0: Motordaten der Antriebe

Vor dem Update alle Klappen schließen, vor dem Flashen des Hubs. Nach dem Update stehen alle Antriebe, bis ihre Motordaten eingetragen sind. Sie schließen so lange auch bei Regen, Wind oder Frost nicht. Die Kalibrierung bleibt erhalten. Reihenfolge: erst der Server, dann der Hub, dann Module und Anzeigen, danach je Antrieb die Motordaten. Mehr unter Antriebe.

Auf 0.10.0: Sensormodule

Reihenfolge: erst der Server, dann der Hub, dann die Module, dann die Anzeigen. Ein Hub vor 0.10.0 sieht Module mit den neuen Typen nicht. Deshalb spielt der Server Modul-Firmware 0.10.0 nur über einen Hub mit 0.10.0 ein. Die Datenbank migriert beim Start, Hubs und Module laufen mit ihrer bisherigen Firmware weiter.

Vorhandene Module behalten Typ, Kanäle und Verlauf; Klima, Boden, Wasser und Außen heißen danach „(alt)“. Ein Klima- oder Außenmodul startet nach seinem Update einmal ohne gesetzten Typ, der Hub setzt ihn aus der Konfiguration wieder, und das Modul startet noch einmal neu. Das Einrichtungs-WLAN des Hubs ist ab 0.10.0 offen, ein Passwort-Aufkleber gilt nicht mehr.

Versionen

Die Versionsnummer steht an einer Stelle. Server und Oberfläche werden gemeinsam mit der Firmware ausgeliefert und tragen dieselbe Nummer. Den Verlauf zeigt der Changelog.

Den Server aktualisieren

./deploy.sh update           # git pull, Images bauen, starten, warten bis es antwortet

Oder von Hand: git pull und docker compose up --build -d. Die Datenbank migriert beim Start von selbst. Mit einem GitHub-Runner auf dem Server geht es auch von allein, siehe Server installieren.

Sicherung

./deploy.sh backup                      # legt backups/smartbeet-<Zeit>.tar.gz an
./deploy.sh restore                     # Auswahl aus backups/, fragt nach
sh infra/scripts/backup.sh              # dasselbe ohne Menü
sh infra/scripts/restore.sh <datei>

Gesichert werden Datenbank, Geheimnisse, die eigene CA mit dem Serverzertifikat, Broker-Benutzer und Firmware. Ohne die CA müssten alle Hubs neu eingerichtet werden. Die Anlage darf beim Sichern laufen.