Firmware releases

All published firmware releases of this stream, with release notes.

Release notes are curated in German; an English translation is planned.

1. v2.22.0

   2026-08-27
   • Die Standortkarte kommt jetzt fertig aus der Konfektionierung. Beim Zurücksetzen des DataStore wurde bisher nur das Maschinen-Dashboard wiederhergestellt — die Standortkarte blieb leer, weil nie eine ausgeliefert wurde. Und das Spindelbild darauf ließ sich gar nicht ausliefern: Der Bildkatalog wird je Anlage gefüllt, seine internen Nummern sind auf jeder Anlage andere. Die Konfektionierung bringt das Bild jetzt selbst mit und benennt es in der Karte über seinen Namen. Auf der Karte steht damit die IDEA-4S-Kachel mit Spindelbild und daneben der Betriebsstundenzähler.
   • Wer sich selbst eine Karte gebaut hat, behält sie. Der Schritt füllt nur eine Karte, auf der noch niemand etwas abgelegt hat.
   • Die Betriebszeit wird in Stunden angezeigt. Das Gerät liefert keinen Stundenwert, sondern einen Rohzähler in Schritten von rund einer Zehntelsekunde; die Kachel muss ihn umrechnen. Der ausgelieferte Faktor ist der Gerätekennwert aus der IODD — derselbe, aus dem die beiden Spindel-Kacheln daneben ihre Stunden bilden. Falls Ihre Anlage die Betriebszeit heute zehnfach zu hoch anzeigt (etwa 8741 statt 875 Stunden), war dort ein von Hand gesetzter Faktor im Spiel; dieses Update setzt ihn richtig.
   • Zwei Verweildauer-Histogramme gehören ab jetzt zum Dashboard, beide mit logarithmischer Achse und beide mit ihrem Namen beschriftet: „Temperatur Lager 1" und „Effektive Schwinggeschwindigkeit Z". Auf der logarithmischen Achse bleiben auch die selten belegten Klassen sichtbar — auf linearer Achse verschwinden sie neben der Stillstandsklasse.
   • Achtung: Das IDEA-4S-Dashboard wird dabei einmalig ersetzt. Eine auf der Anlage selbst umgestellte Kachelanordnung geht damit verloren; danach steht die ausgelieferte Anordnung da. Die Standortkarte ist davon nicht betroffen.
   • Zur Update-Dauer: An der Datenhaltung ändert sich zwischen 5.82.0 und 5.83.0 nichts — für ein Gerät ab 2.16.4 dauert dieses Update so lange wie ein gewöhnliches.

2. v2.21.0

   2026-08-27
   • Das Zurücksetzen des DataStore hinterlässt jetzt wirklich einen Auslieferungszustand. Datenbank und Einstellungen wurden schon bisher geleert — liegen geblieben war aber, was das bisherige Leben der Anlage im Datenverzeichnis hinterlassen hatte: alte Störungsberichte und der gesamte Protokollverlauf. Nach einem „Zurücksetzen" zeigte die Anlage also weiterhin Vorfälle von vor dem Zurücksetzen. Auf der Testanlage gemessen: 2 alte Absturzberichte und 51 Protokolldateien haben ein Zurücksetzen überlebt. Das ist jetzt weg — die Anlage steht danach so da wie nach der Erstinbetriebnahme.
   • Kacheln bekommen eine einstellbare Beschriftung (DataStore 5.82.0). Bei der Maschinen- und der Quellen-Kachel gab es bisher kein Eingabefeld dafür; dort stand der rohe Signalname, etwa idea4s/operatingHours. Zusätzlich lässt sich die Titelzeile ganz ausblenden — die frei werdende Höhe bekommt dann der Messwert, der dadurch größer erscheint.
   • Die Softkey-Leiste ist ab Werk aus. Sie war bisher standardmäßig eingeblendet. Wer sie bewusst eingeschaltet hatte, schaltet sie nach diesem Update einmalig wieder ein: Ein gespeichertes „ein" ließ sich nicht von „nie angefasst" unterscheiden, weil der frühere Standard ebenfalls „ein" war.
   • Zur Update-Dauer: Zwischen 5.81.0 und 5.82.0 ändert sich nichts an der Datenhaltung — für ein Gerät ab 2.16.4 dauert dieses Update so lange wie ein gewöhnliches. Geräte auf 2.16.3 erhalten zusätzlich die Aufbewahrungsgrenzen aus 2.16.4 (siehe dort „Was Sie nach dem Update erwarten dürfen"), Geräte auf 2.16.2 oder älter davor noch den Umbau der Datenhaltung aus 2.16.3 (rund 5 Minuten).

3. v2.20.0

   2026-08-27
   • „Reset DataStore“ stellt jetzt wirklich den Auslieferungszustand her. Bisher setzte der Knopf nur die Einstellungen zurück. Alles, was auf der Anlage angelegt worden war — zusätzliche Maschinen, deren Standorte, Ansichten, Benutzer — blieb stehen; die Anlage war danach also gerade nicht im Auslieferungszustand. Gemeldet aus dem Feld: Ein selbst angelegter Standort war nach dem Drücken unverändert da.
   • Was der Knopf jetzt tut, in genau der Reihenfolge, in der auch eine Erstkonfektionierung abläuft: Er legt die mit der Firmware ausgelieferte Konfektionierung ab, hält den DataStore an, leert dessen Datenbank vollständig, entfernt die Einstellungen und startet ihn wieder — der DataStore richtet die leere Datenbank ein und spielt die Konfektionierung beim Hochlauf ein, wie bei einer frisch aufgesetzten Anlage. Auf der Testanlage nachgemessen: ein Druck, rund 35 Sekunden.
   • Der Knopf ist damit endgültig. Messdaten, Maschinen, Standorte, Benutzer, Ansichten und der Lernstand sind danach weg und lassen sich nur aus einer Sicherung zurückholen. Der Bestätigungstext sagt das jetzt unmissverständlich. Legen Sie vorher eine Sicherung an, wenn irgendetwas davon gebraucht wird.
   • Was bleibt: die Verbindung zur Datenbank, die lokale Anmeldedatei und der Fernwartungspfad — alles, was die Anlage braucht, um überhaupt wiederzukommen und sich zu melden.
   • „Delete Measuring Data“ ist unverändert und bleibt der schonende Weg: Es verwirft nur den aufgezeichneten Bestand und lässt Maschinen, Benutzer, Lernstand und Histogramm-Einstellungen unberührt.

4. v2.19.3

   2026-08-27
   • „Reset DataStore“ gelingt beim ersten Druck. Der Knopf legt zuerst die ausgelieferte Konfektionierung ab; weicht die Datei auf dem Gerät ab — also genau dann, wenn man den Knopf braucht —, startet der DataStore dafür neu. Das Gerät wartete bisher nur darauf, dass der DataStore wieder antwortet. Das genügt nicht: Während er seine Datenhaltung anpasst, antwortet er bereits, ist aber noch nicht benutzbar, und der zweite Schritt lief in genau dieses Fenster. Jetzt wird gewartet, bis der DataStore sich als betriebsbereit meldet. Auf der Testanlage nachgemessen: ein Druck, 34 Sekunden, fertig.

5. v2.19.2

   2026-08-27
   • „Reset DataStore“ gelingt jetzt beim ersten Druck. Der Knopf legt zuerst die ausgelieferte Konfektionierung ab und lässt den DataStore danach seine Einstellungen daraus neu aufbauen. Weicht die Datei auf dem Gerät ab — also genau dann, wenn man den Knopf braucht —, startet der DataStore für die neue Datei neu, und der zweite Schritt lief bisher in diesen Neustart hinein und meldete einen Fehler. Ein zweiter Druck half. Das Gerät wartet jetzt ab, bis der DataStore wieder da ist, und führt den Vorgang in einem Zug zu Ende.

6. v2.19.1

   2026-08-27
   • Die beiden Wartungsknöpfe erscheinen jetzt wirklich. In 2.19.0 waren „Reset DataStore" und „Delete Measuring Data" zwar ausgeliefert, blieben unter Wartung & Reparatur aber unsichtbar: Das Gerät prüft vor dem Anzeigen, ob der DataStore die Knöpfe ausführen kann — und diese Prüfung las die Versionsauskunft falsch aus. Sie schlug damit immer fehl, und ein Knopf, dessen Ausführbarkeit unklar ist, wird bewusst nicht angeboten. Beides ist korrigiert; an den Knöpfen selbst ändert sich nichts.

7. v2.19.0

   2026-08-27
   • Die beiden Wartungsknöpfe gibt es jetzt auch in der Bedienoberfläche. Unter Einstellungen → Wartung & Reparatur stehen neu „Reset DataStore" und „Delete Measuring Data". Im DataStore selbst (unter Backup) bleiben sie unverändert bestehen — es sind dieselben zwei Handlungen, nur an einer zweiten Stelle.
   • Warum an zwei Stellen. Die Knöpfe hier gehören zum Wartungsdienst des Geräts. Das heißt: Sie stehen auch im FleetManager zur Verfügung, die Fernwartung kann sie also auslösen, ohne vor Ort zu sein — und sie funktionieren auch dann noch, wenn ausgerechnet die DataStore-Oberfläche nicht mehr erreichbar ist, also genau in der Lage, in der man zurücksetzen möchte.
   • „Reset DataStore" stellt den ausgelieferten Stand her. Das Gerät legt zuerst die mit der Firmware ausgelieferte Konfektionierung neu ab und lässt den DataStore erst danach seine Einstellungen daraus neu aufbauen. Diese Reihenfolge ist der eigentliche Gewinn: Der DataStore baut immer aus der Datei auf, die er vorfindet — nur weil das Gerät vorher die ausgelieferte Fassung hinlegt, ist das Ergebnis wirklich der Auslieferungsstand und nicht das, was zufällig auf dem Gerät lag. Lässt sich die Datei nicht ablegen, wird nichts zurückgesetzt und das Gerät sagt das, statt auf einer alten Datei zurückzusetzen und Erfolg zu melden.
   • „Delete Measuring Data" verwirft den aufgezeichneten Bestand. Messwerte, Prozesse, Bewertungen, Alarme und Histogramm-Daten. Maschinen und Kanäle, Benutzer, der Lernstand, die Histogramm-Einstellungen und das Änderungsprotokoll bleiben.
   • Beide Knöpfe erscheinen nur, wenn das Gerät sie ausführen kann (DataStore ab 5.81.0). Auf einem älteren Stand sind sie schlicht nicht da — ein Knopf, der beim Drücken fehlschlägt, ist schlechter als keiner.
   • Die Liste unter Wartung & Reparatur wird wieder sauber dargestellt. Bei manchen Einträgen lief die Beschreibung als schmale Spalte um und der „Run"-Knopf zog sich über die ganze Karte.

8. v2.18.0

   2026-08-26
   • Zwei Wartungsknöpfe aus der Vorgängerversion sind zurück. Sie finden beide im DataStore unter Backup. Beide sind unumkehrbar und verlangen deshalb, dass Sie zur Bestätigung etwas eintippen — ein Häkchen wäre für so etwas die falsche Hürde.
   • „Messdaten verwerfen" löscht den aufgezeichneten Bestand: Messwerte, Prozesse, Bewertungen, Alarme und die Histogramm-Daten. Erhalten bleiben Ihre Maschinen, Benutzer, die Histogramm-Einstellungen, der Lernstand mit allen Grenzen und das Änderungsprotokoll. Vorher zeigt Ihnen das Gerät, was verschwände. Die Zeilenzahlen dort sind Schätzungen — ein genaues Zählen liefe auf einer großen Anlage minutenlang. Ein Hinweis, der in der Bestätigung steht und den Sie kennen sollten: Bei einem Import wird die Fremdhistorie anschließend erneut geladen, dauerhaft Platz schafft das Verwerfen dort also nicht.
   • „Einstellungen auf Auslieferungsstand" setzt sämtliche Einstellungen auf den Stand zurück, mit dem die Anlage ausgeliefert wurde. Das Gerät leert dazu die Einstellungen und baut sie beim Neustart aus den Vorgaben und der mitgelieferten Konfektionierung neu auf — deshalb wirkt es auch dann, wenn niemand mehr weiß, was im Laufe der Zeit verstellt wurde. Erhalten bleiben nur drei Verweise auf die Umgebung (Datenbank, lokale Anmeldedatei, Fernwartungspfad). Gespeicherte Passwörter gehen mit — eine ausgelieferte Anlage hat sie auch nicht; Sie tragen sie danach neu ein, und alle Anmeldungen enden. Nicht betroffen sind Messdaten, Maschinen und Benutzer. Vorher sagt Ihnen das Gerät, unter welcher Adresse es danach erreichbar ist und ob sich das ändert.
   • Der Abtasttakt gehört jetzt der Maschine. Bisher galt eine anlagenweite Abfragerate für alle Importe zugleich — auf einer Anlage mit zwei Importen ließ sie sich für keinen von beiden richtig stellen. Das Gerät zieht den heute wirksamen Takt beim ersten Start automatisch zu den einzelnen Maschinen um und arbeitet danach unverändert weiter; Sie müssen nichts eintragen. Ein von Hand gesetzter Takt bleibt dabei stehen.
   • Der DataStore geht auf 5.81.0. Zwischen 5.80.0 und 5.81.0 ändert sich nichts an der Datenhaltung — dieses Update dauert für ein Gerät ab 2.16.4 so lange wie ein gewöhnliches. Geräte auf 2.16.3 erhalten zusätzlich die neuen Aufbewahrungsgrenzen aus 2.16.4 — lesen Sie dort bitte den Abschnitt „Was Sie nach dem Update erwarten dürfen"; auf einem Gerät mit großem Alarmbestand kann das Aufräumen mehrere Stunden dauern. Geräte auf 2.16.2 oder älter holen davor noch den Umbau der Datenhaltung aus 2.16.3 nach (gemessen rund 5 Minuten).

9. v2.17.0

   2026-08-26
   • Grafana verlangt kein eigenes Passwort mehr. Bisher hatte Grafana ein zweites Konto mit einem eigenen Kennwort, das niemand zuverlässig kannte: Es wird genau einmal vergeben, wenn das Gerät zum ersten Mal eingerichtet wird, und ließ sich danach durch kein Update mehr korrigieren — auf Geräten, die seit etwa Juni 2026 neu aufgesetzt wurden, war es gar kein sinnvolles Kennwort. Dieses zweite Konto entfällt: Die Bedienoberfläche meldet Sie an Grafana mit Ihrem eigenen Benutzernamen an, genauso wie sie es beim DataStore schon tut.
   • Was Sie davon merken. Wer als Administrator angemeldet ist, kann Dashboards jetzt bearbeiten und speichern, ohne irgendwo ein Grafana-Kennwort einzugeben. Wer als normaler Benutzer angemeldet ist, sieht die Dashboards wie bisher. Oben rechts steht Ihr eigener Name, und Änderungen werden unter diesem Namen protokolliert — nicht mehr unter einem gemeinsamen „admin".
   • Abmelden gilt auch für Grafana. Grafana führt keine eigene Sitzung mehr. Melden Sie sich an der Bedienoberfläche ab, endet damit auch der Zugriff auf Grafana. Ändert ein Administrator die Rolle eines Benutzers, wirkt das sofort — nachgemessen: eine entzogene Berechtigung war beim nächsten Seitenaufruf weg, nicht erst nach einer Wartezeit.
   • Die Grafana-Anmeldemaske ist geschlossen. Sie wird nicht mehr gebraucht, und das bisher dort hinterlegte Kennwort ist damit kein Zugang mehr. Für den Servicefall bleibt das Konto über die Gerätekonsole erreichbar.
   • Am DataStore ändert sich nichts. Die Anmeldung dort funktionierte bereits so. Beide benutzen jetzt nur noch dieselbe Zuordnung von Rollen, damit sie nicht auseinanderlaufen können.

10. v2.16.6

    2026-08-26
    • Die Kachel „Restlebensdauer (Spindel)" lädt wieder. Auf Geräten mit viel Verlauf brach sie nach einer knappen Minute mit einem Fehler ab, statt einen Wert zu zeigen. Die Abfrage suchte den jüngsten Messwert je Signal so, dass die Datenbank dafür jede gespeicherte Zeile des Signals lesen musste — auf einer großen Anlage gemessen 183.709 gelesene Zeilen und 53,8 Sekunden für acht Signale, obwohl acht Zeilen die Antwort sind. Jetzt sind es acht gelesene Zeilen in 0,512 ms.
    • Einzelwert-Kacheln können umrechnen. Über der Einheit gibt es ein Feld Faktor; der Messwert wird damit vor der Anzeige multipliziert. Die Kachel „Betriebszeit" zeigt so Stunden statt 30.296.741 Sekunden. Leer lassen heißt unverändert. Gilt für Einzelsignal/KPI und Messuhr — bei Kurven bleibt der Rohwert stehen, dort ist er die Zeitreihe. Wichtig für Grenzwerte: Warn- und Kritisch-Schwellen sowie die Zonen der Messuhr tragen Sie danach in derselben Einheit ein, die die Kachel anzeigt — „kritisch ab 1,5 h“ also als 1.5, nicht als 5400.
    • Der DataStore verlangt keine „Ersteinrichtung" mehr, wo keine nötig ist. Auf diesen Geräten meldet Sie die Bedienoberfläche am DataStore an, ein eigenes DataStore-Konto gibt es bewusst nicht. Kam eine Anfrage ohne gültige Anmeldung an — nach einem Neuladen, einem Zurück-Klick oder einem Aufruf aus dem Adressverlauf —, zeigte der DataStore stattdessen „Es existiert noch kein Benutzer — ersten Administrator anlegen". Das war doppelt falsch: Es sah nach einem Einrichtungsfehler aus, und es bot an, ein Konto anzulegen, das niemand braucht. Jetzt erscheint ein Hinweis mit dem Schritt, der tatsächlich hilft — meist schlicht „Seite neu laden"; bei einem Direktaufruf der Verweis auf das Menü der Bedienoberfläche. Der Weg, über den sich jemand ein solches Konto anlegen konnte, ist zugleich geschlossen.
    • Der DataStore geht auf 5.80.0 (das Gerät überspringt dabei 5.79.0). Zwischen 5.78.0 und 5.80.0 ändert sich nichts an der Datenhaltung — für ein Gerät ab 2.16.4 dauert dieses Update daher so lange wie ein gewöhnliches. Geräte auf 2.16.3 erhalten zusätzlich die neuen Aufbewahrungsgrenzen aus 2.16.4 — lesen Sie dort bitte den Abschnitt „Was Sie nach dem Update erwarten dürfen“; auf einem Gerät mit großem Alarmbestand kann das Aufräumen mehrere Stunden dauern. Geräte auf 2.16.2 oder älter holen davor noch den Umbau der Datenhaltung aus 2.16.3 nach (gemessen rund 5 Minuten).

11. v2.16.5

    2026-08-26
    • Die IDEA-4S-Messwerte kommen wieder vollständig an. Das Gerät hat den IO-Link-Master zehnmal je Sekunde einzeln abgefragt, statt seinen laufenden Datenstrom mitzulesen — obwohl der Master diesen Strom die ganze Zeit gesendet hat. Unter der Abfragelast wies der Master Leseanfragen zeitweise zurück, und die Aufzeichnung riss ab: gemessen 239 Aussetzer von mehr als einer Sekunde in einer halben Stunde und 1101 von 1800 Sekunden ganz ohne Messwert, der längste Aussetzer 27 Sekunden. In Grafana sah das nach einer Anlage aus, die zeitweise stillsteht. Nach der Umstellung auf den Datenstrom: kein einziger Aussetzer, größter Abstand zwischen zwei Messwerten 0,7 Sekunden.
    • Ein von Hand eingetragenes MQTT-Ziel bleibt dabei stehen. Das Topic, unter dem ein IO-Link-Master sendet, ist von Anlage zu Anlage verschieden — mal ein am Master vergebener Name, mal der Standardname des Geräts. Das Update trägt ein Ziel deshalb nur dort ein, wo bisher keines steht. Wo eines steht, bleibt es unangetastet, und das Gerät vermerkt das im Protokoll. Ein falsch eingetragener Broker wird dagegen korrigiert: Auf der openXEdge ist es immer der Broker des Geräts selbst, und der trägt dort den Namen mosquitto — eine IP-Adresse, auch die des Geräts, erreicht ihn nicht.
    • Wenn an Ihrer Anlage nach dem Update weiter Messwerte fehlen, trägt der Master ein anderes Topic als das voreingestellte. Sie sehen das eingetragene Ziel in DataStore unter Maschine bearbeiten im Feld MQTT-Topic; das tatsächliche Topic steht in der Weboberfläche des IO-Link-Masters unter den Notification-/IoT-Core-Einstellungen. Der Master führt Broker und Topic dort in einem Feld, etwa 172.16.9.112:1883/teststand/idea-4s — in DataStore gehört nur der Teil hinter dem Port hinein, und zwar ohne den führenden Schrägstrich: teststand/idea-4s, nicht /teststand/idea-4s. Mit Schrägstrich ist es für MQTT ein anderes Topic, es kommen still keine Daten an. Ein Neustart ist nicht nötig.
    • Der DataStore geht auf 5.78.0. Zwischen 5.77.0 und 5.78.0 ändert sich nichts an der Datenhaltung — für ein Gerät ab 2.16.4 dauert dieses Update daher so lange wie ein gewöhnliches. Geräte auf 2.16.3 erhalten zusätzlich die neuen Aufbewahrungsgrenzen aus 2.16.4 — lesen Sie dort bitte den Abschnitt „Was Sie nach dem Update erwarten dürfen“; auf einem Gerät mit großem Alarmbestand kann das Aufräumen mehrere Stunden dauern. Geräte auf 2.16.2 oder älter holen davor noch den Umbau der Datenhaltung aus 2.16.3 nach (gemessen rund 5 Minuten).

12. v2.16.4

    2026-08-26
    • Messwerte bleiben 90 Tage statt 2 Tage erhalten, und jede Datenart hat jetzt ihr eigenes Budget. Bisher galt eine einzige, knapp bemessene Aufbewahrungsregel für alles. Neu gilt je Art: Messwerte 90 Tage / 50 GB, Prozessdaten 90 Tage / 2 GB, Störungs- und Alarmdaten 365 Tage / 2 GB, Archivwerte 10 Jahre / 1 GB, Histogramme 3 Jahre. Damit reicht die Verlaufsansicht deutlich weiter zurück, und Störungsdaten — das Wertvollste im System — rotieren nicht mehr mit dem Normalbetrieb aus.
    • Was Sie nach dem Update erwarten dürfen. Die niedrigeren Budgets für Prozess-, Alarm- und Archivdaten führen dazu, dass beim ersten Aufräumlauf Altbestände gelöscht werden. Liegt eine dieser Datenarten weit über ihrem neuen Budget, hält das Gerät die Aufzeichnung an, bis der Rückstand abgetragen ist, und meldet das als Notstillstand 1522. Danach zeichnet es von selbst weiter auf, die Meldung bleibt aber stehen: Sie soll die entstandene Lücke sichtbar halten und verschwindet erst mit einem „Kleinen Neustart" (DataStore → Einstellungen → Verhaltensparameter).
    • Wie lange das dauern kann. Nachgemessen auf einem absichtlich überfüllten Testgerät: Die Prozessdaten waren nach rund 75 Minuten abgetragen (613 264 → 83 812 Einträge) — der Stillstand hielt danach weiter an, weil die Alarmdaten bei 238 % ihres neuen Budgets standen. Für diese Datenart läuft die Aufräumung höchstens einmal pro Stunde. Der Stillstand dauerte auf diesem Gerät 4 Stunden 38 Minuten; der Füllstand fiel von 238 % auf unter 110 %, die Alarmkurven von 15,6 Mio. auf 4,5 Mio. Einträge. Danach lief die Aufzeichnung von selbst wieder an. Rechnen Sie auf einem Gerät mit großem Alarmbestand also mit mehreren Stunden, nicht mit Minuten — das Gerät arbeitet den Rückstand zuverlässig ab, es tut es nur langsam. Die Aufbewahrungsfrist hilft dabei nicht: Ist der Bestand jünger als die Frist — auf dem Testgerät war er einen Tag alt —, wirkt allein die Größenregel.
    • Wen das betrifft. Auf einer Anlage mit der IDEA-4S als einziger Maschine passiert nichts davon. Nachgemessen auf einer solchen Anlage: 2,7 MB Prozessdaten gegen die neuen 2 GB und 3 Einträge im Störungsprotokoll. Das Testgerät kommt auf 444 116 Einträge und 15,6 Mio. Alarmwerte, alle aus einem einzigen Tag — Folge eines zusätzlichen UTTM-Imports, der einen Alarmsturm erzeugt. Betroffen sind also Geräte, auf denen eine zweite Maschine importiert wird.
    • Der DataStore geht auf 5.77.0. Enthalten unter anderem: Eine Einstellung wird jetzt mit Klartext zurückgewiesen, wenn ihr Name nicht existiert oder ihr Wert vom falschen Typ ist, statt stillschweigend angenommen zu werden und nichts zu tun. Zur Update-Dauer: Zwischen 5.74.0 und 5.77.0 ändert sich nichts an der Datenhaltung, und Geräte vor 2.16.3 holen den dortigen Umbau nach (rund 5 Minuten). Kurz ist dieses Update deswegen aber nicht — der Aufräumlauf aus den neuen Aufbewahrungsgrenzen oben kommt hinzu, siehe „Wie lange das dauern kann“.

13. v2.16.3

    2026-08-24
    • Der DataStore räumt Alarmdaten wieder ab. Auf dem Testgerät bestand der gespeicherte Bestand zuletzt fast nur noch aus Störungsdaten: Ihr Aufbewahrungsbudget war ausgeschöpft, und das Löschen scheiterte an einer Zeitgrenze — sichtbar nur als Meldung im Protokoll, während der Füllstand weiter stieg. Die Aufräumung ist neu gebaut: Sie beantwortet die Schutzfrage einmal je Störungsprozess statt einmal je Messwert und löscht dann in Bereichen. Ein einziger Durchlauf hat den aufgelaufenen Rückstand in rund 26 Minuten abgetragen.
    • Eine verkürzte Aufbewahrungsdauer hält die Aufzeichnung nicht mehr an. Bisher konnte das Herabsetzen einer Aufbewahrungsfrist die Notbremse auslösen: Das Verhältnis „ältester Eintrag zu Frist" springt beim Verkürzen, ohne dass ein einziges Byte hinzugekommen wäre — und die Anlage hörte auf zu erfassen, bis genug gelöscht war. Die Notbremse bewertet jetzt nur noch Größen- und Anzahlgrenzen, also das, was tatsächlich über den Plattenplatz entscheidet. Sie dürfen eine Aufbewahrungsdauer damit gefahrlos herabsetzen, um Platz zu gewinnen; die Anlage zeichnet weiter auf. Dass eine Frist überschritten ist, meldet sie unverändert.
    • Ein Bestand, den die Notbremse nicht schützen kann, wird jetzt genannt. Ist für einen Datenbestand weder eine Größen- noch eine Anzahlgrenze gesetzt, liegt er außerhalb der Notbremse — die Anlage sagt das mit Meldung 1523, statt es stillschweigend hinzunehmen.
    • Der DataStore fragt nicht mehr zweimal am Tag nach dem Passwort. Ein offen gelassenes Fenster fand die DataStore-Ansicht bisher oft mit „Sitzung ist abgelaufen" vor, obwohl die Anmeldung am Gerät weiterhin galt. Die Sitzungsdauer des DataStore lag bei zwölf Stunden und liegt jetzt bei 30 Tagen. Am Gerät ändert sich an der Absicherung nichts: Der DataStore ist ausschließlich über die angemeldete Bedienoberfläche erreichbar.
    • Hinweis zur Update-Dauer: Dieses Update bringt eine Umstellung der Datenhaltung mit (Kennzeichnung der Störungsdaten, zusätzlicher Suchindex). Gemessen wurde sie auf zwei Anlagen: rund 5 Minuten auf dem Testgerät und knapp 4 Minuten auf einer sehr großen Referenzanlage — die Dauer hängt an der Zeilenzahl, nicht an der Dateigröße. Das Gerät zeigt währenddessen einen Wartungshinweis; bitte in dieser Zeit nicht vom Strom trennen. Das Aufräumen der Altbestände läuft danach im Hintergrund weiter, ohne die Aufzeichnung aufzuhalten.

14. v2.16.2

    2026-08-19
    • Die IDEA-4S-Seite findet den Sensor jetzt auch dann, wenn er beim Einschalten noch nicht antwortet. Bisher suchte das Gerät den IDEA-4S genau einmal, kurz nach dem Start. War der IO-Link-Master in diesem Moment noch nicht erreichbar — nach einem Stromausfall braucht er oder der Netzwerkverteiler oft länger als das Gerät selbst —, blieb die Seite dauerhaft bei „Kein IDEA4S-Gerät verfügbar", ebenso der Parameter-Editor. Besonders tückisch: Messwerte liefen weiter in DataStore und Grafana, das Gerät meldete sich als fehlerfrei, und nur ein Neustart des Dienstes half. Das Gerät sucht den Sensor jetzt so lange weiter, bis er antwortet, und nimmt ihn dann von selbst in Betrieb — im Versuch rund 20 Sekunden, nachdem der Master wieder erreichbar war. Solange ein eingerichteter Sensor fehlt, sagt das Gerät das jetzt ausdrücklich in der Diagnose, statt sich als gesund auszugeben.
    • Eine geänderte Adresse des IO-Link-Masters wirkt sofort. Wird die Adresse in den Einstellungen korrigiert — genau das schlägt die Fehlermeldung auf der Seite vor —, wird sie ab sofort auch verwendet; bisher war dafür zusätzlich ein Neustart des Dienstes nötig.
    • Einzelne verlorene Netzwerkpakete führen nicht mehr sofort zu einem Lesefehler am Sensor. Eine nicht beantwortete Abfrage wird jetzt einmal wiederholt.
    • Der Bildschirm am Gerät zeigt beim Hochfahren einen Startbildschirm statt eines schwarzen Bildes. Seit die Startprüfungen des Geräts gründlicher geworden sind, dauert es nach dem Einschalten spürbar länger, bis die Oberfläche erscheint; bis dahin blieb der Bildschirm einfach schwarz, ohne Hinweis, dass überhaupt etwas passiert. Jetzt erscheint sofort ein Hinweis „System startet…", der von selbst auf die Bedienoberfläche wechselt, sobald sie bereit ist.
    • Grafana zeigt keine roten Fehler mehr, wenn im DataStore mehrere IDEA-4S-Maschinen stehen. Beim Umbenennen oder erneuten Importieren einer Maschine entsteht schnell ein zweiter Eintrag; danach schlugen sämtliche Kacheln des Dashboards fehl und zeigten „No data". Die Auswertung nimmt jetzt eindeutig die erste IDEA-4S-Maschine.
    • Der DataStore macht einen größeren Versionssprung (5.63.0 → 5.72.1) — ohne Umbau der Datenhaltung: Zwischen diesen Ständen ändert sich nichts am Datenbankschema. Für ein Gerät, das bereits auf 2.14.0 oder neuer ist, dauert dieses Update daher so lange wie ein gewöhnliches. Geräte, die noch auf einem Stand vor 2.14.0 sind, durchlaufen weiterhin den in 2.14.0 beschriebenen einmaligen Umbau der Datenhaltung (auf einem gewachsenen Gerät etwa 25–30 Minuten, Gerät in dieser Zeit nicht vom Strom trennen). Enthalten sind unter anderem:
      • Die Gerätehistogramme der IDEA-4S zeigen wieder richtige Werte. Die Verweildauer war um den Faktor 9,992 zu groß angegeben, und für denselben Messwert standen zwei verschiedene Einheiten nebeneinander. Zusätzlich lässt sich ein Histogramm jetzt logarithmisch skalieren.
      • Die Suche nach den ältesten löschbaren Messwerten ist drastisch schneller. Auf einer sehr großen Referenzanlage brach sie regelmäßig in eine Zeitgrenze — sichtbar als Statuskachel mit „0 B" und „Gelöscht gesamt: 0", während der Füllstand weiter stieg. Die Abfrage ist neu gefasst; dort gemessen 137 s → 4,2 s. Ob das Aufräumen auf solchen Anlagen nun dauerhaft vollständig durchläuft, wird nach dem Ausrollen nachgemessen; auf GMN-Geräten mit ihrer kurzen Aufbewahrung ist dieser Effekt bisher nicht aufgetreten.
      • Sicherheitskorrektur: Die Einstellungsschnittstelle gab angemeldeten Benutzern den Signaturschlüssel der Anmeldesitzungen heraus; außerdem standen Zugangsdaten im Klartext in der Startzeile des Protokolls und in der Sicherungsdatei. Beides ist behoben — Geheimnisse werden jetzt zentral geschwärzt.
      • Bedienung am Panel: Einheiten stehen jetzt an den Kurven, die Softkey-Leiste und die Kiosk-Anzeige lassen sich als Anlagen-Vorgabe einstellen (und je Bildschirm per Adresszusatz übersteuern), „Zurück" wirkt auch in Status, Selbstdiagnose und Einstellungen, und auf 1280×600-Panels scrollt die Seite nicht mehr weg.
      • Die Störungs-Ampel bleibt nicht mehr auf Rot stehen und fragt die Datenbank deutlich sparsamer ab (bisher fünfmal so teuer wie nötig).
      • Quittieren sagt jetzt, wenn es nicht geht. Bei einer importierten Maschine — bei GMN ist die IDEA-4S genau das — meldete das Quittieren von Alarmen bisher Erfolg, ohne etwas zu quittieren. Es nennt jetzt ausdrücklich den Grund. An der Maschine ändert sich dadurch nichts; die Anzeige sagt nur die Wahrheit.

15. v2.16.1

    2026-08-05
    • Die Update-Anzeige meldet ein laufendes Update nicht mehr fälschlich als Problem. Dauerte ein Update länger als drei Minuten — was völlig normal ist, sobald neue Programmstände geladen werden müssen —, zeigte der Bildschirm „Das Update dauert länger als erwartet. Möglicherweise benötigt das Gerät Aufmerksamkeit", obwohl im Hintergrund alles planmäßig lief. Schlimmer noch: Mit dieser Meldung hörte die Seite auf, den Fortschritt zu verfolgen, und meldete den kurz darauf erfolgreichen Abschluss nicht mehr. Die Anzeige wartet jetzt so lange, wie das Gerät tatsächlich braucht. Ist das Gerät während des Neustarts seiner Dienste länger als fünf Minuten nicht ansprechbar, sagt sie das ausdrücklich und beobachtet weiter, statt aufzugeben. Eine echte Warnung erscheint erst, wenn sich das Gerät sehr lange gar nicht mehr meldet.

16. v2.16.0

    2026-08-05
    • Die Startseite des DataStore ist jetzt frei wählbar. Bisher legte eine „Standardmaschine" fest, womit die Oberfläche aufmacht. Stattdessen lässt sich nun jedes Dashboard als Start-Dashboard markieren — ein Standort-Dashboard ebenso wie ein Maschinen-Dashboard. Der Haken „Start-Dashboard" sitzt in den Eigenschaften des Dashboards und steht ab der Rolle Service zur Verfügung. Ist nichts markiert, öffnet wie bisher das erste Standort-Dashboard. Eine bestehende Standardmaschine wird beim Update automatisch auf ihr Maschinen-Dashboard übertragen; es ist nichts nachzustellen.
    • Neu: Kiosk-Anzeige für Hallenmonitore. Wird die Oberfläche mit dem Zusatz ?kiosk=1 in der Adresse aufgerufen, blendet sie Navigations- und Kopfleiste aus und zeigt nur noch den Inhalt — geeignet für fest montierte Bildschirme in der Halle. Die Einstellung merkt sich der jeweilige Bildschirm; ?kiosk=0 verlässt sie wieder. Sichtbar bleiben bewusst die Selbstdiagnose-Anzeige und die Softkey-Leiste, über die man weiterhin navigieren kann. An den Rechten ändert die Kiosk-Anzeige nichts.
    • Die Menüleiste startet auf Wunsch schmal. Eine neue Einstellung im Bereich „Oberfläche" lässt die Navigationsleiste als schmale Symbolspur beginnen; über das Menü-Symbol lässt sie sich jederzeit für die laufende Sitzung aufklappen. Im Menü steht „Start" jetzt ganz oben, darunter „Standorte"; der eigene Eintrag „Maschine" entfällt — zu einer Maschine führen die Maschinenkacheln der Standorte und der Softkey S1.
    • Der Log-Versand an die Zentrale schickt nicht mehr die gesamte Log-Historie. Bisher enthielt jede Übertragung sämtliche jemals aufgezeichneten Protokolle erneut — auf einem länger laufenden Gerät wuchs das auf mehrere Gigabyte je Übertragung an und belastete Gerät und Netz spürbar. Übertragen werden jetzt nur noch die neu hinzugekommenen Abschnitte. Den bereits angesammelten Altbestand räumt das Gerät beim ersten Start selbsttätig ab (auf einem betroffenen Testgerät rund 14 GB); ein Eingriff ist nicht nötig.
    • Fehlgeschlagene Log-Übertragungen werden richtig benannt. Eine abgewiesene Übertragung meldete pauschal „offline?", auch wenn das Gerät nachweislich online war und die Gegenstelle den Fehler verursacht hat. Die Meldung unterscheidet jetzt zwischen Netzproblem am Gerät und Ablehnung durch die Zentrale. Zusätzlich meldet das Gerät, wenn der Zwischenspeicher für Protokolle voll läuft und ältere Pakete verworfen werden mussten.
    • Der Pflichtlauf der Datenbankprüfung meldet nicht mehr dauerhaft „nicht messbar". Eine interne Marke, an der der DataStore einen unbemerkten Neustart der Datenbank erkennt, ließ sich technisch nie setzen — genau die Lücke, die die Prüfung schließen sollte, blieb also offen. Sie wird jetzt korrekt geführt.

17. v2.15.0

    2026-08-04
    • Das automatische Aufräumen der Messdaten funktioniert wieder zuverlässig. Auf einer gut gefüllten Anlage brach jeder Aufräumlauf nach einer festen Zeitgrenze ab — über hundert Mal am Tag, ohne dass ein einziger Lauf zu Ende kam. Es wurde also faktisch gar nichts mehr gelöscht, während der angezeigte Füllstand weiter stieg. Die Zeitgrenze war zu knapp bemessen; sie ist jetzt so gesetzt, dass sie nur noch bei einem echten Defekt greift, und der Dienst meldet sich auch während langer Datenbankarbeit regelmäßig als lebendig. Betroffene Geräte holen den Rückstand nach dem Update selbsttätig auf.
    • Die Aufbewahrungsdauer wird jetzt in einem Schub pro Tag durchgesetzt. Bisher löschte jeder Durchlauf genau das, was gerade eben zu alt geworden war — ein Dauer-Rinnsal an Löschvorgängen. Der Schnitt fällt nun gebündelt an, höchstens ein Tag auf einmal; an der zugesagten Aufbewahrungsdauer ändert sich dadurch nichts.
    • Neu: „Datenbank verdichten" gibt belegten Plattenplatz wieder frei. Löschen allein gibt in der Datenbank keinen Platz an das Gerät zurück — die Datei bleibt groß, auch wenn der Inhalt längst kleiner ist. In der Statusansicht gibt es dafür jetzt einen Knopf (ab Rolle Service): Er zeigt vorher Platzbedarf, Freigabepotenzial und geschätzte Dauer und fragt nach, bevor er läuft. Während des Laufs zeichnet das Gerät keine Messwerte auf, und es braucht vorübergehend so viel freien Speicher wie die größte Tabelle belegt — bitte nicht unbeaufsichtigt und nicht bei knappem Speicher starten.
    • Neu: das Gerät meldet von selbst, wenn Verdichten sinnvoll wäre (Meldung 1516, Warnung). Sie erscheint, wenn die Datenbank mehr als 120 % der eingestellten Größengrenzen belegt, obwohl der Inhalt diese Grenzen einhält. Genau dieser Zustand ist auf Geräten zu erwarten, auf denen das Aufräumen zuvor blockiert war: Die Messwerte verschwinden nach dem Update, die Datei bleibt zunächst groß. Die Warnung ist also erwartbar und kein Defekt; sie verschwindet von selbst, sobald verdichtet wurde oder der Bestand wieder in die Grenzen wächst.
    • VNC-, SMTP- und Log-Export-Passwort lassen sich jetzt auch löschen, nicht nur ersetzen. Ein leeres Feld hieß bislang „bestehendes Passwort behalten"; für das Löschen gibt es nun eine ausdrückliche Bedienung.
    • Wartungsstände für Datenbank, Dashboards und AppStore. Der Datenbankserver (PostgreSQL 17.10), Grafana (12.4.6) und die AppStore-Verwaltung erhalten die jeweils aktuellen Korrektur- und Sicherheitsstände ihrer Hersteller. Für die Bedienung ändert sich nichts.
    • Hinweis zur Update-Dauer: Geräte, die noch auf einem Stand vor 2.14.0 sind, durchlaufen weiterhin den in 2.14.0 beschriebenen einmaligen Umbau der Datenhaltung (auf einem gewachsenen Gerät etwa 25–30 Minuten, Gerät in dieser Zeit nicht vom Strom trennen). Wer bereits auf 2.14.0 ist, für den ist dieses Update ein gewöhnliches, kurzes Update.

18. v2.14.0

    2026-07-31
    • ⚠ Dieses Update dauert deutlich länger als gewohnt — bitte einplanen. Die Datenhaltung des DataStore wird umgebaut; das Gerät zeigt währenddessen eine Wartungsseite und zeichnet keine Messwerte auf. Auf einem gewachsenen Gerät (rund 26 Millionen Messwerte) hat das etwa 25–30 Minuten gedauert, auf einem frisch eingerichteten Gerät nur Sekunden. Das Gerät darf in dieser Zeit nicht vom Strom getrennt werden. Es meldet sich anschließend von selbst wieder betriebsbereit; ein Eingriff ist nicht nötig.
    • Der DataStore macht einen großen Versionssprung (5.41.1 → 5.57.0). Darin enthalten sind unter anderem: eine überarbeitete Aufbewahrung, die in ruhigen Schüben aufräumt statt dauerhaft zu laufen, korrekt gezeichnete Grenzwerte und Toleranzbänder im Kurven- und Parameter-Editor, ein zuverlässiges Speichern von Grenzwerten an der IDEA-4S (bislang scheiterte das an sieben von zehn Kanälen mit einer irreführenden Meldung), sowie gespeicherte Zugangsdaten, die einen Neustart überstehen.
    • Das Gerät gibt nach dem Update wieder Speicherplatz frei. Ein alter, 3,2 GB großer Datenbank-Index wird durch einen sehr viel kleineren ersetzt. Der angezeigte Füllstand der Datenhaltung sinkt dadurch spürbar, ohne dass ein einziger Messwert gelöscht wird.
    • Eine Aufbewahrungsdauer von 0 Tagen löscht nicht mehr den gesamten Bestand. Bisher wurde der Wert 0 als „alles ist zu alt" ausgelegt und räumte die Messwerte vollständig ab; er bedeutet jetzt einheitlich „unbegrenzt". Die Größenbegrenzung greift weiterhin.
    • „Update-Server nicht erreichbar" ist kein kritischer Fehler mehr, wenn das Gerät gar keine Internetverbindung hat. Ein Gerät ohne Uplink — im Schaltschrank ein völlig normaler Betriebszustand — meldete den nicht erreichbaren Update-Server bisher als kritischen Fehler und färbte damit den Gesamtstatus rot. Die Meldung erscheint jetzt nur noch als Information; kritisch wird sie ausschließlich dann, wenn das Gerät nachweislich online ist und der Update-Server trotzdem nicht antwortet. Die Einstufung wechselt selbsttätig mit der Verbindungslage.

19. v2.13.13

    2026-07-22
    • Das Grafana-Dashboard bricht nicht mehr ab, wenn im DataStore mehrere IDEA-4S-Maschinen hinterlegt sind. Bisher gingen alle Kacheln davon aus, dass es genau eine importierte IDEA-4S-Maschine gibt. Ein Gerät kann aber mehrere haben, und eine zweite entsteht auch leicht versehentlich, wenn eine Maschine im DataStore umbenannt oder neu importiert wird — in diesem Fall zeigte das gesamte Dashboard nur noch rote Fehler und „No data". Die Kacheln verwenden jetzt immer die erste IDEA-4S-Maschine, sodass eine Dublette die Ansicht nicht mehr lahmlegen kann. Bestehende Geräte erhalten den Fix beim Update automatisch.

20. v2.13.12

    2026-07-22
    • IO-Link-Master-Adresse ist jetzt pro Gerät einstellbar. Bisher war die Adresse des IO-Link-Masters fest auf 172.16.9.110 verdrahtet — saß der Master an einer anderen Adresse, blieb die Seite „IOLink Master Configuration" leer bzw. meldete „nicht erreichbar". Die Adresse wird nun aus einer Konfigurationsdatei auf dem Gerät gelesen, die Firmware-Updates übersteht; ist keine hinterlegt, gilt weiterhin der bisherige Standardwert.

21. v2.13.11

    2026-07-22
    • Der „Handbuch"-Eintrag in der oberen Leiste entfällt. Das Handbuch wird ausschließlich online veröffentlicht; auf dem Gerät gibt es dafür keinen Menüpunkt mehr.

22. v2.13.10

    no date
    • Netplan-Konfigurator zeigt jetzt den Gerätenamen. In der Überschrift steht neben „Netplan Configurator" der im Fleet-Management hinterlegte Name des Geräts, sofern gesetzt — so ist auf einen Blick klar, welches Gerät gerade konfiguriert wird.
    • Live-Status zeigt zusätzlich die MAC-Adresse. Der aufklappbare „Live Status" je Netzwerkkarte enthält jetzt auch die Hardware-Adresse (MAC) der Schnittstelle.

23. v2.13.9

    2026-07-21
    • Frisch eingerichtete Geräte melden sich jetzt zuverlässig am Fleet-Management an. Bei einem neu aufgesetzten Gerät konnte der Zugangsschlüssel für das Fleet-Management fehlen, wodurch alle Statusmeldungen an die Zentrale abgewiesen wurden und das Gerät dort inaktiv blieb. Der Schlüssel wird jetzt von der Maintenance-Komponente sicher auf das Gerät gebracht — sowohl bei der Erstinstallation als auch beim Update — und ein einmal fehlerhaft gespeicherter Zustand wird selbsttätig korrigiert.

24. v2.13.8

    2026-07-21
    • Netzwerkeinstellungen: keine falsche Sicherheitsabfrage mehr am Gerät. Die in 2.13.7 eingeführte Aussperr-Warnung erschien fälschlich auch dann, wenn man direkt am Gerät (Kiosk) eine Adresse änderte — mit einer nichtssagenden internen Adresse. Die Prüfung berücksichtigt jetzt nur noch die tatsächlich konfigurierbaren Netzwerkkarten; die Abfrage kommt nur noch, wenn man wirklich das Netz kappt, über das man aus der Ferne verbunden ist.

25. v2.13.7

    2026-07-21
    • Netzwerkeinstellungen: Fehleingaben werden zuverlässiger abgefangen. Zusätzlich zu den bisherigen Prüfungen wird die Konfiguration jetzt von netplan selbst validiert, bevor sie gespeichert wird — ungültige Adressen, Präfixe oder Schlüssel werden mit einer genauen Meldung abgewiesen, statt erst beim Neustart Probleme zu machen.
    • Schutz vor dem versehentlichen Aussperren. Ändert man ausgerechnet die Schnittstelle, über die man gerade mit dem Gerät verbunden ist, so dass das Gerät danach nicht mehr erreichbar wäre, muss das jetzt vor dem Neustart ausdrücklich bestätigt werden. So verhindert ein Fehlgriff nicht mehr unbemerkt den Zugang zum Gerät.

26. v2.13.6

    2026-07-21
    • Der Kiosk-Bildschirm bleibt nach einem Neustart nicht mehr auf „Dienst wird gestartet …" hängen. Auf einem GMN-Gerät zeigte der Kiosk eine Startseite an, deren Dienst es auf diesem Gerät gar nicht gibt — die Seite lud sich endlos neu, ohne je fertig zu werden. Der Kiosk öffnet jetzt eine geräteunabhängige Startadresse, die automatisch zur richtigen Startseite des Geräts weiterleitet (bei GMN: Grafana). Wird über die Maintenance-Komponente ausgerollt (neuer Kiosk-Stand 1.1.3).

27. v2.13.5

    no date
    • Netzwerkeinstellungen: DNS-Server und Gateway jetzt pro Schnittstelle einstellbar. Jede Netzwerkkarte hat ein optionales DNS-Feld (mehrere Server durch Komma getrennt) und – bei statischer Konfiguration – ein Gateway-Feld. Eingaben werden vor dem Übernehmen geprüft.
    • Neue Live-Statusanzeige pro Schnittstelle. Über „Live Status" lässt sich je Netzwerkkarte der aktuelle Ist-Zustand aufklappen: Verbindungsstatus (an/aus), alle zugewiesenen IP-Adressen, Gateway und die aktiven DNS-Server – live vom Gerät und per Knopf aktualisierbar. Besonders nützlich bei DHCP, wo die tatsächlich zugewiesene Adresse bisher nicht sichtbar war.
    • „Speichern" überschreibt keine bestehenden Netzwerkeinstellungen mehr. Bisher verwarf das Speichern der Netzwerkkonfiguration still bereits vorhandene DNS-/Gateway-/Routen-Einträge. Jetzt bleiben alle nicht in der Oberfläche bearbeiteten Einstellungen erhalten.

28. v2.13.4

    2026-07-21
    • „Speichern & Neustart" in den Netzwerkeinstellungen startet das Gerät jetzt wirklich neu. Bisher meldete die Oberfläche einen bevorstehenden Neustart, der aber ausblieb — und damit wurde auch die geänderte Netzwerkkonfiguration nicht wirksam. Der Neustart wird jetzt zuverlässig ausgelöst; schlägt er wider Erwarten fehl, wird das klar als Fehler mit Handlungshinweis angezeigt statt fälschlich als Erfolg.
    • Keine falschen „nicht erreichbar"-/„unhealthy"-Meldungen mehr in der Diagnose. Ein einwandfrei laufendes Gerät wurde durch die Zustandsüberwachung teils dauerhaft als gestört dargestellt (u. a. Grafana und einmalig startende Hilfsdienste). Der Gerätezustand wird jetzt korrekt bewertet und pro Prüfzyklus aktualisiert.

29. v2.13.3

    2026-07-21
    • Diagnose-Übersicht zeigt DataStore nicht mehr fälschlich als "nicht erreichbar" an. Die Statusabfrage nutzte einen Pfad, den nur der Python-Anteil unserer Basis-Bibliothek kennt — DataStore antwortet unter einem anderen, gleichwertigen Pfad. Wird jetzt korrekt erkannt.

30. v2.13.2

    2026-07-21
    • Bedienungshandbuch jetzt direkt am Gerät. Unter „Handbuch“ auf der Startseite (bzw. /handbuch) steht die Dokumentation offline zur Verfügung — auch ohne Internetverbindung im Schaltschrank. Ist kein Handbuch im Firmware-Build enthalten, verweist die Seite auf das Online-Portal (https://edges.brinkhaus-gmbh.de).
    • Intern: Log-Collector → 0.4.1. Behebt ein mögliches Volllaufen des Gerätespeichers durch nicht aufgeräumte Zwischendateien; der Zwischenspeicher wird jetzt beim Start und nach jedem Bündel-Lauf bereinigt.

31. v2.13.1

    2026-07-21
    • Keine falschen "kritisch"-Meldungen mehr, wenn die Flottenverwaltung nicht erreichbar ist. Ein Edge im Schaltschrank ohne oder mit unterbrochener Internetverbindung ist normaler Betrieb, kein Gerätefehler — das wird jetzt korrekt als Hinweis statt als kritischer Fehler angezeigt.
    • Intern: brinkhaustools → 0.20.2 (main-ui, Maintenance Sidecar, DataStore), Maintenance Sidecar → 1.8.1, DataStore → 5.41.1, IOLink-Proxy → 1.1.2, USB-Service → 1.2.2.

32. v2.13.0

    2026-07-20
    • Bildschirmtastatur nur noch, wenn sie gebraucht wird. Sie erscheint jetzt automatisch nur dann, wenn keine physische Tastatur angeschlossen ist — kein Tastatur-Overlay mehr über jedem Textfeld, wenn ein Techniker mit eigener Tastatur am Gerät arbeitet. Umschaltbar auf „immer an" oder „aus" — direkt am Gerät oder aus der Flottenverwaltung, damit ein Edge nie ohne Eingabemöglichkeit dasteht.
    • DataStore-Konfiguration bleibt jetzt zuverlässig erhalten. Einstellungen werden zuverlässig ausgeliefert und bleiben danach in der Hand des Bedieners — eigene Änderungen werden nicht mehr überschrieben, auch nach künftigen Updates nicht.
    • DataStore erholt sich jetzt selbst, wenn die Datenbank beim Start kurz noch nicht bereit ist (z. B. nach einem Stromausfall, wenn mehrere Dienste gleichzeitig hochfahren). Vorher blieb der Dienst in diesem Fall dauerhaft hängen und brauchte einen manuellen Neustart.
    • Intern: DataStore 5.28.0 → 5.37.0, Maintenance Sidecar → 1.8.0.

33. v2.12.4

    2026-07-15
    • Lesbare Signalnamen für den IDEA-4S. Die Messgrößen erscheinen jetzt als Klartext (z. B. „Effektive Schwinggeschwindigkeit X-Richtung") statt als technischer Schlüssel — in allen Ansichten und mehrsprachig.
    • Sensor-Belegung aus der IODD zur Laufzeit. DataStore liest die Bit-Verteilung des Prozessdatenworts direkt aus der Gerätebeschreibung (IODD) und erzeugt die Signale automatisch — geräte-/firmwareunabhängig statt fest verdrahtet.
    • Stiller Datenstrom wird sichtbar. Ein toter oder falsch konfigurierter MQTT-Broker (die Verbindung steht, liefert aber nichts) sowie eine Serie unlesbarer Telegramme werden jetzt als Diagnose gemeldet, statt unbemerkt zu bleiben.
    • Intern: DataStore 5.25.3 → 5.28.0. Keine Datenmigration nötig (Schema unverändert).

34. v2.12.3

    no date
    • DataStore komplett erneuert. Der Messdaten-Dienst wurde von Grund auf neu gebaut. Er bringt eine eigene, moderne Oberfläche mit (Live-Diagramme, Alarme, Maschinen- und Standortübersicht).
    • Der IDEA-4S-Sensor ist jetzt vollständig angebunden. DataStore spricht direkt mit dem IO-Link-Master und liest neben den Messwerten auch die Grenzen aus dem Gerät und leitet daraus Alarme ab — das konnte die bisherige Anbindung nicht. Das Standard-Dashboard zeigt die Schwingungsachsen als Diagramm und die Statuswerte (z. B. „Vibration O.K.", „Fühlerbruch") als Textkacheln.
    • Kein zweites Passwort mehr. Wer in der Bedienoberfläche angemeldet ist, wird im DataStore automatisch mitangemeldet — mit dem eigenen Benutzernamen und den passenden Rechten. Das DataStore-Protokoll zeigt dadurch, wer etwas geändert hat.
    • Die Grafana-Dashboards laufen unverändert weiter. Sie wurden intern auf die neue Datenbankstruktur umgestellt; Aussehen, Schwellwerte und Legenden bleiben gleich.
    • Wichtig — die bisher erfassten Messdaten gehen verloren. Das neue DataStore speichert Messwerte anders. Betroffen sind die Daten der letzten zwei Tage; die Aufzeichnung beginnt nach dem Update sofort neu.
    • Intern: Ein Ausfall des DataStore wird jetzt als kritisch an das Flottenmanagement gemeldet.

35. v2.12.2

    no date
    • DataStore komplett erneuert. Der Messdaten-Dienst wurde von Grund auf neu gebaut. Er bringt eine eigene, moderne Oberfläche mit (Live-Diagramme, Alarme, Maschinen- und Standortübersicht) und ist deutlich schneller.
    • Kein zweites Passwort mehr. Wer in der Bedienoberfläche angemeldet ist, wird im DataStore automatisch mitangemeldet — mit dem eigenen Benutzernamen und den passenden Rechten: Administratoren dürfen alles, normale Benutzer dürfen ansehen und bedienen, aber keine Benutzer verwalten. Das DataStore-Protokoll zeigt dadurch, wer etwas geändert hat, statt eines anonymen Sammelkontos.
    • Die Grafana-Dashboards laufen unverändert weiter. Sie wurden intern auf die neue Datenbankstruktur umgestellt; Aussehen, Schwellwerte und Legenden bleiben gleich.
    • Wichtig — die bisher erfassten Messdaten gehen verloren. Das neue DataStore speichert Messwerte anders. Betroffen sind die Daten der letzten zwei Tage (mehr wurden auch bisher nicht vorgehalten); die Aufzeichnung beginnt nach dem Update sofort neu.
    • Intern: Ein Ausfall des DataStore wird jetzt als kritisch an das Flottenmanagement gemeldet — bisher fiel er dort nur als Warnung auf und konnte unbemerkt bleiben.

36. v2.11.5

    2026-07-14
    • Schnellere Diagramme: Die Datenbank nutzt jetzt 1 GB Arbeitsspeicher zum Zwischenspeichern (vorher 128 MB — ein Standardwert, der für Geräte mit sehr wenig Speicher gedacht ist). Auf einem BOS-Edge ist die Datenbank der einzige größere Speichernutzer, deshalb wurden die Messdaten bisher bei jedem Aufruf neu von der SSD gelesen. Die Grafana-Dashboards laden dadurch spürbar schneller, vor allem beim ersten Aufruf und bei großen Zeiträumen.

37. v2.11.4

    2026-07-01
    • Intern (Zustandsüberwachung): MainUI und Log-Collector melden ihren Zustand jetzt als strukturierte, typisierte Werte („Leaves" der Grand Unified Log Strategy) — z. B. Erreichbarkeit/Container-Gesundheit als Statuslampe, Laufzeiten als Dauer, Zeitstempel als Uhrzeit, Speicherbelegung als Größe. Der FleetManager kann diese Werte dadurch verständlich darstellen statt als Rohtext. Am Gerät selbst ändert sich nichts.

38. v2.11.3

    2026-06-30
    • Intern: Korrektur in der CI-Prüfung (Typprüfung der Tests). Keine funktionalen Änderungen gegenüber 2.11.2; enthält dieselben AppStore-Verbesserungen (Offline-Kacheln nach einmaligem Login, Behebung des Login-Hängers).

39. v2.11.2

    2026-06-30
    • Fix (AppStore): Die Kacheln der installierten Apps werden nach einer einmaligen Anmeldung jetzt zuverlässig in einem Zwischenspeicher auf dem Gerät abgelegt. Dadurch erscheinen sie auch nach einem Neustart ohne Internetverbindung wieder — ohne erneute Anmeldung und ohne dass etwas im Browser gespeichert sein muss.
    • Fix (AppStore): Behebt ein Hängenbleiben beim FLECS-Login („Completing sign in…"). Die zuvor eingebaute automatische Vor-Anmeldung der AppStore-Seite war damit nicht zuverlässig vereinbar und wurde entfernt; die Anmeldung selbst bleibt über die FLECS-eigene Sitzung erhalten.

40. v2.11.1

    2026-06-30
    • Fix (AppStore): Behebt ein Hängenbleiben beim FLECS-Login (Anzeige „Completing sign in…"). Eine zwischengespeicherte, bereits abgelaufene Anmelde-Sitzung wurde fälschlich in den laufenden Login-Vorgang eingespielt und blockierte den Abschluss. Abgelaufene Sitzungen werden jetzt erkannt und nicht mehr eingespielt.

41. v2.11.0

    2026-06-30
    • Neu (AppStore): Per FLECS installierte Apps (z. B. Heartbeat, Pitstop) werden jetzt als Kacheln auf der Startseite angezeigt — auch ohne vorherigen FLECS-Login. MainUI hält die Anmelde-Sitzung serverseitig und speichert die Kachelliste zwischen, sodass die Kacheln bereits direkt nach dem Hochfahren erscheinen, sobald einmalig eine Anmeldung erfolgt ist.
    • Neu (AppStore): Nach einer einmaligen Anmeldung bei FLECS muss man sich weder im lokalen Bildschirm (Kiosk) noch im Browserzugriff erneut anmelden — die AppStore-Seite öffnet sich direkt angemeldet.

42. v2.10.1

    2026-06-23
    • Fix (Offline-Update): USB-Sticks werden beim Öffnen des Offline-Update-Bereichs automatisch eingebunden — kein manuelles Mounten auf dem Gerät erforderlich. Werden mehrere Sticks mit gültigen Paketen erkannt, wird das Paket mit der höchsten Version vorausgewählt.
    • Fix (Offline-Update): Die Datei für den öffentlichen Schlüssel kann beliebig benannt sein (*.pem), nicht mehr nur public-key.pem.
    • Fix (Offline-Update): Die Signaturdatei kann beliebig benannt sein (*.sig), nicht mehr nur docker-compose.yml.sig.

43. v2.10.0

    2026-06-22
    • Neu (Offline-Update): Firmware-Updates können jetzt auch ohne Internetverbindung über einen USB-Stick eingespielt werden. Der neue Bereich „Offline update" am Ende des Update-Tabs öffnet sich per Klick und zeigt erkannte USB-Sticks an, die ein gültiges Firmware-Paket enthalten (docker-compose.yml, Signatur, öffentlicher Schlüssel). Die Ed25519-Signatur wird lokal geprüft; danach läuft die Installation über denselben Mechanismus wie ein Online-Update — mit identischem Fortschrittsbildschirm und automatischem Rollback bei Fehlern.

44. v2.9.1

    2026-06-18
    • Fix (AppStore-Dienst): Der AppStore-Dienst (flecs/filip) war nach dem Recovery-Workaround aus 2.9.0 noch auf :latest referenziert statt auf einen festen Tag. Bei einem Docker-Pull hätte ein neueres Image eingespielt werden können, ohne dass die Version bekannt war. Der Pin ist jetzt auf die verifizierten Version v4.0.2 fixiert.

45. v2.9.0

    2026-06-16
    • Neu (Fernwartung): Firmware-Updates können jetzt direkt aus dem FleetManager ausgelöst werden. Der neue Befehl „Firmware-Version installieren“ zeigt ein Auswahlmenü mit den jeweils aktuellsten Versionen der obersten beiden Versionslinien (innerhalb des aktuellen Hauptversionsstands). Die Edge lädt die gewählte Version signiert vom Update-Server und installiert sie über den bestehenden Update-Dienst — mit automatischem Rollback, falls die neue Version den Health-Check nicht besteht. Die Update-Logik (Signaturprüfung, Staging) bleibt in der Bedienoberfläche; der Wartungsdienst ist nur der FleetManager-Adapter und spricht die Bedienoberfläche über ein gemeinsames Token an.

46. v2.8.11

    2026-06-16
    • Fix (Update-Reparatur, Fortsetzung): Behebt die letzte Ursache der fehlgeschlagenen Updates 2.8.8–2.8.10. Der AppStore-Dienst (flecs) konnte nie „bereit" melden (sein Healthcheck ließ sich im Dienst-Image technisch nicht ausführen), weshalb die Bedienoberfläche nicht startete und das Update zurückgerollt wurde. Die Bedienoberfläche wartet jetzt nur noch auf den Start des AppStore-Dienstes, nicht auf dessen Healthcheck — das Update läuft sauber durch. Inhaltlich entspricht 2.8.11 dem geplanten 2.8.9.

47. v2.8.10

    2026-06-16
    • Fix (Update-Reparatur): Die Updates 2.8.8/2.8.9 schlugen fehl und wurden automatisch zurückgerollt — Ursache war ein Image-Verweis auf eine nicht existierende flecs-Version sowie ein fehlerhafter Healthcheck des MQTT-Brokers, der nie „bereit" meldete. Beides ist behoben; das Update läuft jetzt sauber durch. Inhaltlich entspricht 2.8.10 dem geplanten 2.8.9 (Kiosk-Verbesserung + Auslieferung über den Wartungsdienst).

48. v2.8.9

    2026-06-16
    • Verbessert: Der Kiosk-Bildschirm wartet beim Start jetzt, bis die Bedienoberfläche erreichbar ist, bevor er das Dashboard lädt — kein leerer/Fehler-Bildschirm mehr direkt nach dem Hochfahren.
    • Intern: Diese Kiosk-Verbesserung wird ab jetzt auch per Firmware-Update auf bestehende Edges verteilt (über den Wartungsdienst maintenance-sidecar 1.4.0), nicht mehr nur bei der Erstkonfektionierung. Die Aktualisierung erfolgt nur, wenn sich die Kiosk-Version tatsächlich ändert.

49. v2.8.8

    2026-06-16
    • Fix: Der Kiosk-Bildschirm zeigt nach einem Kaltstart (oder Neustart) keinen „Internal server error" mehr. Bisher lud der Kiosk das Dashboard, bevor Grafana bereit war — die Fehlerseite blieb dann dauerhaft stehen. MainUI (1.4.14) liefert jetzt eine sich selbst aktualisierende Startseite („Dienst wird gestartet …"), bis der Dienst antwortet, und zeigt danach automatisch das Dashboard.
    • Verbessert: DataStore, Grafana und IDEA4S-Bridge starten erst, wenn Datenbank und MQTT-Broker bereit sind (Healthchecks). Das beseitigt die kurzen Verbindungsfehler direkt nach dem Hochfahren (z. B. „DataStore-Verbindung verloren").

50. v2.8.7

    2026-06-03
    • Fleet-Manager: Neue Obergruppe „Data acquisition" — DataStore (4.4.6) und IDEA4S-Bridge (1.4.6) erscheinen jetzt gebündelt unter diesem Knoten statt einzeln unter der Maschine.
    • UpdateService (2.0.2) meldet sich jetzt unter der Obergruppe „Base system" (zuvor ungruppiert).
    • Updater-Linie automatisch korrigiert: MainUI (1.4.13) hebt Edges, die per „Wechsel zu V2" auf einem 1.2.x-Alias-Updater hängen geblieben sind (laufen bereits V2-Code unter altem Tag), einmalig und selbsttätig auf das echte 2.x-Updater-Tag — danach kommen 2.x-Updater-Updates wieder regulär an. Genuine V1-Edges bleiben unangetastet.

51. v2.8.6

    2026-06-03
    • Fleet-Manager: Die beiden Obergruppen „Base system" und „Security audit" werden jetzt angezeigt — der aktualisierte Sicherheits-Agent (0.7.0) meldet seine Module unter „Security audit".
    • Sicherheits-Agent stellt jetzt — wie alle anderen Dienste — eine Diagnose-Schnittstelle bereit und erscheint in der Diagnose nicht mehr als „unreachable".
    • Versionsanzeige korrigiert: IO-Link-Master-Proxy (1.1.1) und USB-Service (1.2.1) zeigen ihre Versionsnummer jetzt korrekt an (zuvor leer).
    • Log-Collector auf 0.3.0.

52. v2.8.5

    2026-06-03
    • Fleet-Manager-Übersicht aufgeräumt: Die Dienste der Edge werden im Fleet-Manager jetzt unter Obergruppen einsortiert. Die Basissystem-Dienste — darunter der IO-Link-Master-Proxy (1.1.0) und der USB-Service (1.2.0) — erscheinen gebündelt unter „Base system", die Sicherheitsmodule unter „Security audit". Das macht Edges mit vielen Diensten deutlich übersichtlicher.
    • Neu: Edge-Neustart direkt aus der Wartungskarte der MainUI (mit Bestätigung).
    • Neu: Wartungsaktion „DataStore-Verlaufstabellen zurücksetzen" — legt die Verlaufstabellen mit den aktuellen Sensor-Signaltypen neu an (z.B. nach einem Sensortausch).
    • Verbessert: Vollbildmodus wird auf jeder Seite bei der ersten Interaktion aktiviert.

53. v2.8.4

    2026-06-02
    • Fix: Der Sicherheits-Agent (fleetmanager-security:0.5.2) meldet jetzt präzise statt mit Falschmeldungen. Bisher wurden die von Docker veröffentlichten Dienst-Ports und die regulären Dienste der Edge (z.B. AppStore-Proxy, Druckdienst) als „unerwartete offene Ports" gemeldet. Offene Ports werden jetzt gegen eine gelernte Baseline geprüft — gemeldet wird nur, was wirklich neu hinzukommt. Zusätzlich entfällt die auf Ubuntu Core unzutreffende Warnung „Auditd nicht aktiv".

54. v2.8.3

    2026-06-02
    • Fix: Der Sicherheits-Agent (fleetmanager-security:0.5.1) meldet sich jetzt zuverlässig beim Fleet-Manager. In 2.8.0–2.8.2 wurden seine Meldungen serverseitig abgewiesen, sobald die Maschinen-ID Großbuchstaben oder Unterstriche enthielt — der Agent wurde dadurch als „nicht laufend" angezeigt. Die Identität wird jetzt korrekt normalisiert, sodass die Sicherheitsbefunde unter derselben Maschinen-ID wie alle anderen Dienste der Edge erscheinen.

55. v2.8.2

    2026-06-02
    • Fix: Der Log-Collector (fleetmanager-logcollector:0.2.2) startet jetzt zuverlässig — auch mit dem Host-Spool-Mount. Eine Berechtigungs-Ursache der Neustartschleife aus 2.8.0/2.8.1 ist behoben.

56. v2.8.1

    2026-06-02
    • Fix: Der Log-Collector (fleetmanager-logcollector:0.2.1) startete in 2.8.0 nicht — der Container lief in eine Endlos-Neustartschleife. (In 2.8.2 vollständig behoben.)

57. v2.8.0

    2026-06-02
    • Log-Collector als eigenständiges Modul. Der Log-Collector ist jetzt ein generisches Fleet-Manager-Add-on mit eigenem Image (fleetmanager-logcollector:0.2.0). Er erfasst zusätzlich zu den Host-Metriken komprimierte Log-Bündel der Container und überträgt sie gechunkt/fortsetzbar an den Fleet-Manager — so liegen bei Störungen auch die Logs von vor einem Ausfall zentral vor. Der Zugriff auf Docker läuft ausschließlich über einen schreibgeschützten docker-socket-proxy (POST=0); der Collector bleibt unprivilegiert.
    • Neuer Sicherheits-Agent auf der Edge. Die Edge überwacht sich jetzt kontinuierlich gegen anerkannte Härtungs-Standards (CIS-Benchmarks, ausgerichtet auf die EU-Vorgaben CRA und NIS2): Anmelde-Versuche und Brute-Force, ausstehende Sicherheitsupdates, offene Ports, Firewall-Status, Benutzerkonten, laufende Dienste, Dateiintegrität und geladene Kernel-Module. Auffälligkeiten erscheinen im Fleet-Manager unter der aktivierten Maschinen-ID der Edge — so ist der Sicherheitszustand jedes Geräts zentral sichtbar.
    • Da Ubuntu Core ein unveränderliches, snap-basiertes System ist, prüft der Agent dort gezielt nur das Zutreffende: ausstehende Aktualisierungen werden über Snap erkannt, und Prüfungen, die auf Ubuntu Core nicht anwendbar sind, werden als Hinweis statt als Fehler gemeldet.
    • Der Agent läuft als zusätzlicher Container (security-agent, fleetmanager-security:0.5.0). Er liest nur — er verändert das System nicht.

58. v2.5.0

    2026-06-02

    No release notes are available for this version yet.

59. v2.4.4

    2026-05-29
    • Einstellungen → IDEA-4S Devices: Die Standard-IO-Link-Identitätsfelder unter „Identification" — Serial Number, Hardware Revision, Firmware Revision, Application Specific Tag sowie Vendor Name/Text und Product Name/ID/Text — werden jetzt direkt vom Gerät gelesen statt als Fehler („No IOLink index") oder als statischer IODD-Default-String dargestellt. Hintergrund: das IODD referenziert diese Variablen über <StdVariableRef> ohne expliziten ISDU-Index — die festen Indizes (16-24) sind in der IO-Link-Spezifikation hinterlegt, die Bridge kannte sie aber nicht und konnte deshalb nie das Gerät fragen. Auf der GMN-Standard-Edge erscheint Serial Number damit als i000115, Hardware Revision als 1.2, Firmware Revision als 1.2.0. Der IODD-Default bleibt als Fallback aktiv.
    • „Loading…"-Anzeige auf leeren StringT-Feldern korrigiert: StringT-Felder, die das Gerät unausgefüllt zurückgibt (Application-Identifier wie Company Name, Installation Site, Machine Number, Date of Installation/Deinstallation) zeigen jetzt einen leeren Editor statt dauerhaft „Loading…". Hintergrund: das Gerät liefert für leere StringT-Felder ein einzelnes Carriage-Return; Browser strippen CR/LF aus <input type="text">, sodass der ursprüngliche „Loading…"-Platzhalter nach dem erfolgreichen Read sichtbar blieb. Der Platzhalter wird jetzt nach jedem erfolgreichen Read geleert (die grüne Ampel signalisierte den erfolgreichen Read schon vorher).
    • idea4sbridge auf 1.4.5 angehoben.
    • bos-mainui auf 1.4.12 angehoben.

60. v2.4.3

    2026-05-28
    • Die Wartungs-Knöpfe in MainUI (Einstellungen → Maintenance) und im FleetManager stammen jetzt aus einer einzigen Quelle und bleiben in Echtzeit synchron. Nach einem „Datendienste notstoppen" im FleetManager verschwindet der Stopp-Knopf dort sofort und wird durch „Datendienste starten" ersetzt — vorher blieb der Stopp-Knopf hängen, weil der FleetManager den Katalog nur einmal beim Sidecar-Start zugesandt bekam und der Knopf sich nicht selbst aktualisieren konnte. Gilt symmetrisch für alle dynamisch ein- und ausblendbaren Aktionen (z. B. ist „DataStore-Messdaten löschen" jetzt auch im FleetManager nur sichtbar, solange DataStore läuft).
    • Der Edge-Neustart-Knopf erscheint jetzt zusätzlich in MainUI (Einstellungen → Maintenance, ganz unten, mit Bestätigung). Bisher war Neustart-aus-MainUI an einer AppArmor- / D-Bus-Hürde gescheitert und nur im FleetManager verfügbar. Der Knopf läuft jetzt über denselben Pfad wie der FleetManager-Befehl im Maintenance-Dienst, sodass beide Wege funktionieren.
    • bos-maintenance-sidecar auf 1.3.0 angehoben.

61. v2.4.2

    2026-05-27
    • Neuer Wartungs-Knopf „DataStore-Messdaten löschen (Schema-Reset)" unter Einstellungen → Maintenance (und im FleetManager). Behebt Fälle, in denen eine Messgröße (z.B. Drehgeschwindigkeit) im Grafana-Dashboard als Text statt als Zahl auftaucht: passiert, wenn der erste Sensor-Wert beim Hochfahren als String beim DataStore ankommt und die Spalte deshalb für immer als Text angelegt wird — alle späteren Zahlen-Inserts brechen dann den ganzen Zeilen-Insert ab. Der Knopf pausiert die Inserts (die Bridge wartet synchron, kein Datenverlust durch verworfene Frames), droppt die Tabellen historicvalues + historicprocess und lässt sie beim nächsten Sensorwert mit dem aktuellen Signaltyp neu anlegen. Alle bisher erfassten Messdaten gehen dabei verloren — der Knopf ist mit einer Bestätigung versehen. Sichtbar nur, wenn DataStore läuft.
    • bos-maintenance-sidecar auf 1.2.0, datastore auf 4.4.5 angehoben.

62. v2.4.1

    2026-05-27
    • Die Wartungs-Liste unter Einstellungen → Maintenance bekommt einen „Refresh"-Knopf rechts oben — damit lässt sich die Liste auf Knopfdruck mit dem aktuellen Edge-Zustand abgleichen.
    • „Datendienste notstoppen" und „Datendienste starten" werden gegenseitig ausgeschlossen: der Stopp-Knopf erscheint nur, wenn tatsächlich noch mindestens einer der Datendienste läuft, der Start-Knopf nur, wenn mindestens einer noch nicht läuft. Beide nach Aktion automatisch neu bewertet; manuell jederzeit über den Refresh-Knopf nachziehbar.
    • bos-maintenance-sidecar auf 1.1.1, bos-mainui auf 1.4.11 angehoben.

63. v2.4.0

    2026-05-27
    • Die Edge kann jetzt aus dem FleetManager neu gestartet werden. Bisher scheiterte der Neustart-Befehl: er lief im MainUI-Container, dessen Standard-Sicherheitsprofil den dafür nötigen Systemzugriff blockiert. Der Neustart läuft jetzt im Maintenance-Dienst, der die passenden Rechte besitzt — der Befehl wird bestätigt, bevor die Edge herunterfährt, sodass die Rückmeldung den Neustart übersteht.
    • Zwei neue Wartungs-Schaltflächen — im Einstellungen-Menü unter „Maintenance" und im FleetManager: „Datendienste notstoppen" stoppt PostgreSQL, DataStore und IDEA4S-Bridge in geordneter Reihenfolge (etwa um eine überlastete Datenbank zu entlasten); „Datendienste starten" fährt sie wieder hoch und meldet erst „erledigt", wenn DataStore und IDEA4S-Bridge wieder erreichbar sind.
    • Alle Wartungs-Schaltflächen des Maintenance-Dienstes werden jetzt auch im FleetManager angeboten, sodass sie sich aus der Ferne auslösen lassen.
    • DataStore lässt Postgres nicht mehr ausbremsen, wenn die historicProcess-Tabelle anwächst: die interne Wiederverwendungs-Logik für monitoringSettings führte bei laufendem Sensor-Datenstrom zu dauerhaft >50 % Postgres-CPU, weil sie auf einer Spalte ohne Index zählte, und schrieb dabei für nahezu alle neuen historicProcess-Einträge einen leeren Verweis auf die monitoringSettings-Tabelle (auf einer Bestands-Edge waren 99,9998 % der Zeilen ohne Verweis). Diese Logik war seit langem ohne tatsächlichen Nutzen — Verweise werden jetzt unbedingt wiederverwendet, ein begleitender Index sichert die Spalte auch für zukünftige Abfragen gegen sie ab. Zusätzlich greift die automatische Bereinigung (Aufbewahrungsdauer) jetzt auch auf der historicProcess-Tabelle — bisher wuchs sie unbegrenzt, während historicvalues sauber rotiert wurde. Und der DataSwitch-Datenstrom filtert den Fehler-Sentinel 1e-22 jetzt zuverlässig, statt einzelne Fehler-Samples in die historicvalues-Tabelle durchsickern zu lassen.
    • bos-maintenance-sidecar auf 1.1.0, bos-mainui auf 1.4.10, datastore auf 4.4.4 angehoben.

64. v2.3.5

    2026-05-22
    • Die mit Firmware 2.3.4 ausgelieferten Grafana-Datenbankeinstellungen werden jetzt zuverlässig auf der gesamten Flotte wirksam. Grafana liest seine Datenquellen-Konfiguration nur beim Start; auf Edges, die seit dem Update nicht neu gestartet wurden, blieb die Anpassung (feinere Zeitauflösung bei kurzen Zeitbereichen, begrenzte Zahl gleichzeitiger Datenbankverbindungen) bisher wirkungslos. Der Maintenance-Dienst startet Grafana nach einer solchen Änderung jetzt einmalig neu, damit sie greift.
    • bos-maintenance-sidecar auf 1.0.3 angehoben.

65. v2.3.4

    2026-05-21
    • Das Grafana-Dashboard lädt jetzt zuverlässig auch für große Zeitbereiche auf Edges mit umfangreicher Messdaten-Historie. Bisher stellte jedes Panel eine eigene Abfrage über den gewählten Zeitbereich — beim Öffnen einer 7-Tage-Ansicht liefen so rund 14 vollständige Tabellen-Scans gleichzeitig, was zur Zeitüberschreitung führte und leere Panels hinterließ. Die sieben Einzelwert-Anzeigen (Lagertemperaturen, Schwingungs-Tachos) lesen jetzt den aktuellen Messwert direkt über den Zeit-Index aus, statt den gesamten gewählten Bereich zu aggregieren; die beiden Diagramm-Panels fassen ihre Messgrößen in je einer Abfrage zusammen, statt pro Messgröße eine eigene Abfrage zu stellen. Zusätzlich ist die Zahl gleichzeitiger PostgreSQL-Verbindungen begrenzt, das Grafana-Zeitlimit auf 120 Sekunden angehoben und PostgreSQL-JIT abgeschaltet (sein Kompilierungs-Aufwand überwog bei diesen Abfragen den Nutzen).
    • MainUI bricht eingebettete Grafana-Abfragen nicht mehr nach 10 Sekunden ab. Eine Dashboard-Abfrage über eine große historicvalues-Tabelle darf jetzt bis zu 120 Sekunden laufen, bevor der MainUI-Proxy abbricht — eingebettete Panels zeigten dadurch bei längeren Abfragen fälschlich „No data".
    • Eingebettete Ansichten (Grafana, DataStore, IDEA4S-Bridge, AppStore) zeigen nach längerer Inaktivität des Browser-Tabs keine weiße „Not Found"-Seite mehr. Lädt die eingebettete Anwendung sich selbst neu (etwa Grafana nach einer Sitzungs-Token-Erneuerung im Leerlauf), findet MainUI jetzt automatisch zurück in die richtige Ansicht.
    • maintenance-sidecar auf 1.0.2 angehoben: eine neue Migration gleicht die korrigierten Grafana-Vorlagen auch auf bereits laufende Edges ab — der Dashboard-Fix erreicht damit die bestehende Flotte über ein normales Firmware-Update statt nur frisch konfektionierte Geräte.
    • bos-mainui auf 1.4.9, bos-maintenance-sidecar auf 1.0.2 angehoben.

66. v2.3.3

    2026-05-21
    • datastore auf 4.4.3 angehoben: Die periodische Retention (das Löschen alter Messdaten) blockiert die MQTT-Datenerfassung nicht mehr. Bisher lief das Löschen als ein einzelnes DELETE mit voller Tabellen-Durchsuchung und hielt dabei die Datenbank-Sperre, die auch jeder Schreibvorgang braucht — auf großen historicvalues-Tabellen fror dadurch die gesamte Datenaufnahme für die Dauer des Löschlaufs (Minuten) ein; das anschließende VACUUM ANALYZE hatte denselben Effekt. Die Retention löscht jetzt in 10.000-Zeilen-Batches über den indizierten time-Filter, und sowohl das Löschen als auch VACUUM ANALYZE laufen über eine eigene, dedizierte Datenbank-Verbindung — die laufende Datenerfassung wird dadurch nie mehr ausgebremst.

67. v2.3.2

    2026-05-20
    • idea4sbridge auf 1.4.4 angehoben: Die Bridge erholt sich jetzt selbst, wenn der IO-Link-Master beim Start noch nicht erreichbar war und erst später online geht. Bisher hat die Bridge das Ergebnis der einmaligen Geräte-Identitätsabfrage auch bei Fehlschlag dauerhaft zwischengespeichert und blieb mit „Could not find correct IODD file" hängen, bis der Container manuell neugestartet wurde. Ein fehlgeschlagener Lesevorgang wird nicht mehr gecacht — die Geräte-Wiederholschleife fragt erneut ab, und die Bridge fängt sich von allein, sobald die IO-Link-Verbindung wieder steht.
    • datastore auf 4.4.2 angehoben:
      • Neues FleetManager-Kommando reset-historic-tables: Operatoren können historicprocess + historicvalues aus der Fleet-Oberfläche verwerfen, um nach einem Sensor-Hardware-Tausch eine Schema-Drift zu beheben — die Tabellen werden anschließend mit den aktuellen Spaltentypen neu angelegt.
      • Postgres-Tuning für lang laufende Edges: schärfere Autovacuum-Einstellungen auf historicvalues/historicprocess, ein Index historicvalues_time_idx für Grafana-Zeitbereichs-Abfragen, und VACUUM ANALYZE direkt nach jedem Retention-DELETE.

68. v2.3.1

    no date
    • Die Wartungsfunktionen sind jetzt im Einstellungen-Menü unter dem Punkt „Maintenance" erreichbar (unter „Diagnosis") — statt als eigener Reiter in der oberen Navigationsleiste.
    • Zwei neue Reparatur-Aktionen: „Reset DataStore settings" und „Reset IDEA4S-Bridge settings" stellen die jeweilige Konfiguration aus der mit der Firmware ausgelieferten Vorlage wieder her. Der betroffene Container wird dafür gestoppt, die Vorlage eingespielt und der Container wieder gestartet; der vorherige Stand wird gesichert. Die Aktion meldet erst „erledigt", wenn der Dienst wieder erreichbar ist.
    • Die Aktionsliste ist jetzt stream-abhängig: angeboten werden nur Aktionen, für die der Stream auch Vorlagen mitbringt.
    • Durchgängig englische Beschriftung in MainUI und im Wartungs-Sidecar, passend zum Rest der Oberfläche.
    • bos-maintenance-sidecar auf 1.0.1, bos-mainui auf 1.4.8 angehoben.

69. v2.3.0

    2026-05-20
    • Neuer Wartungs-Sidecar (maintenance-sidecar): ein eigener Container im Firmware-Stack, der beim Start versionsgesteuerte Wartungs-Migrationen ausführt und eine Wartungs-Aktions-API bereitstellt. Die erste Migration gleicht die mit der Firmware ausgelieferten Grafana-Vorlagen (Dashboard + Datenquelle) auf die Edge ab — eine Repo-Korrektur an diesen Dateien erreicht bestehende Geräte damit über ein normales Firmware-Update statt über einen SSH-Eingriff.
    • Neue Seite „Wartung" in der MainUI: sie zeigt Reparatur-Schaltflächen, die der Sidecar über ein Manifest bereitstellt — eine neue Aktion erfordert künftig nur ein Sidecar-Release, kein MainUI-Release. Erste Aktion „Grafana-Dashboards zurücksetzen" stellt die ausgelieferten Grafana-Vorlagen wieder her; vorherige Stände werden gesichert, mit einer .locked-Datei markierte Dateien bleiben unangetastet.
    • bos-maintenance-sidecar 1.0.0 zum Stack hinzugefügt.

70. v2.2.4

    no date
    • datastore bumped to 4.4.0: der enableAuthentication-Schalter ist wieder verkabelt. Die DataStore-Vue-UI prüft expert.restFullService.enableAuthentication seit längerem als Gate für die Login-Maske, und das gmn-Stream-Template setzt das Feld auf false — beim ersten Container-Start mit Stream-Template wurde das auch korrekt übernommen, aber die DataStore-1.2→1.4-Schema-Migration hat das Feld stillschweigend gelöscht. Folge: Auf jeder Edge, die die 1.4-Migration durchlaufen hatte, sah die UI das Feld als undefined und forderte einen Login, obwohl der Stream-Default explizit „Auth aus" sagte. Mit DataStore 4.4.0 läuft eine 1.4→1.5-Migration, die das Feld nicht-destruktiv (addKey) mit false neu anlegt — Geräte, die explizit true gesetzt haben, behalten ihren Login. Zusätzlich liest der DataStore-RestServer-Wrapper (pythonuiapphelper) das Feld jetzt aus den Settings und reicht es als enable_auth an brinkhaustools weiter, damit Server- und UI-Seite künftig auf demselben Flag operieren.

71. v2.2.3

    2026-05-17
    • Update-Versionsliste in Settings → Firmware-Update zeigt jetzt standardmäßig nur Versionen mit derselben Hauptversion wie das installierte Firmware (z. B. auf einer 2.x-Edge nur 2.x-Releases). Cross-Major-Bridges (1.x → 2.x, 2.x → 3.x ...) werden über den neuen Toggle „Alle Versionen anzeigen" sichtbar gemacht. Schützt davor, eine Edge versehentlich auf eine inkompatible Architektur zu heben — Major-Sprünge sind ab jetzt explizite Operator-Entscheidungen.
    • Der UpdateService-Self-Updater (der den bos-update-service-Container im Hintergrund über Hash-Vergleich aktualisiert) hält sich an dieselbe Regel: er pullt nie still über eine Hauptversions-Grenze. Wechsel von z. B. Updater 2.x → 3.x erfordert ab jetzt ein dediziertes Bridge-Release. Wenn die installierte Major-Version nicht ermittelt werden kann (z. B. Image-Tag :local), wird der Self-Update aus Sicherheitsgründen ausgesetzt.
    • bos-mainui auf 1.4.7 angehoben.

72. v2.2.2

    2026-04-30
    • idea4sbridge bumped to 1.4.3: bridge now survives an unreachable IO-Link master at startup. Previously IODDHelper.getIODDFilename() raised on a missing device ID, which crashed main.py's startup loop, set diagnosis 4001, and put the container in a 60 s restart loop. Because the SettingsServer (port 8050) had not yet started, MainUI's /idea4s-bridge-proxy/ returned the generic 500 JSON instead of the dashboard. The helper now returns None for an unreachable device; the per-device init loop already handles None and skips the device, so SettingsServer comes up and the dashboard loads. Diagnosis codes 403 / 453 / 501 / 502 still surface the actual cause; 4001 is reserved for genuinely unexpected exceptions again. The dashboard's "no devices configured" empty state now points at the gear icon instead of being a dead end.
    • idea4sbridge 1.4.3 also keeps a single, persistent MQTT client open to the DataStore destination broker for the lifetime of the bridge instead of reconnecting on every published message. Removes per-message connect/disconnect overhead and the brief gaps where messages were dropped while the previous client was still tearing down. No configuration change required.
    • datastore bumped to 4.3.13: new Reset Database admin action under Expert Settings. Wipes the four data tables (historicprocess, historicvalues, monitoringSettings, aliasInformation) without taking the service down or losing schema. Inserts are paused for the duration of the reset via a new PausableBackend gate, each backend's bootstrap is re-run defensively (idempotent CREATE TABLE IF NOT EXISTS, so the action self-heals tables removed by older reset.sql / reset_postgres.sql scripts), the four tables are DELETEd, and a non-critical info self-diagnosis (code 5101, 24 h) records the reset timestamp. A read-only Last Reset field shows when the action last ran. DELETE is used rather than DROP TABLE because input source connectors load their schema from bootstrap.sql only at startup and cache it in-memory — dropping a table mid-run would break their lazy ALTER TABLE ADD COLUMN calls until the container restarted.

73. v2.2.1

    2026-04-28
    • idea4sbridge bumped to 1.4.2: dashboard gear icon now navigates the MainUI iframe to the new /idea4s-bridge-settings-proxy/ route instead of opening a new browser tab to https://<host>:8080/. Port 8080 has no host mapping in the gmn compose, so the gear link previously failed to load. The settings panel now renders inside the same iframe as the dashboard, behind MainUI auth, on every NIC. Pairs with MainUI's existing /idea4s-bridge-settings-proxy/ reverse proxy.
    • idea4sbridge continues to publish port 8050 on the host (0.0.0.0:8050) as introduced in 2.2.0 (never released to the production stream). FLECS-installed apps that need to talk to the bridge — first user is the Heart-Beat 0.2.0 dashboard, available now as FLECS app de.gmn.heartbeat in the AppStore — can reach it via http://tech.flecs.core:8050 (the host alias FLECS injects into every installed-app container) or, equivalently, via any of the edge's LAN IPs. Previously idea4sbridge had no host port at all and was only reachable from inside the bos-internal Docker network or through MainUI's authenticated /idea4s-bridge-proxy/ route, which left FLECS-installed siblings (running on the separate flecs bridge network) with no working path. Port 8080 (the legacy settings panel that /idea4s-bridge-settings-proxy/ forwards to) intentionally stays internal-only. Note: idea4sbridge's REST API on 8050 has no authentication of its own — the exposure means any client on the edge's LAN can read device data anonymously. Tracked as issue #72: deliver idea4s-bridge as a FLECS app so the host port can be removed.

74. v2.1.7

    2026-04-28
    • "Use staging" toggle in Settings → Expert Update Settings now actually does what it says. Until 2.1.6 the toggle wrote the flag to config.json but no code read it, so the Available Versions list always queried the production stream path on the update server — staging builds (deployed by CI from <stream>-test-x.y.z tags to the <stream>-staging server path) were never visible. MainUI now appends -staging to the configured stream name in all four update-server URLs (versions list, compose, signature, description, release notes) when the toggle is on. Switch it off to go back to production. The Stream Name field stays unchanged; the toggle handles the path translation.
    • MainUI bumped to 1.4.6.

75. v2.1.6

    2026-04-28
    • Identical user-facing scope to 2.1.5 — re-released with mypy --strict clean. 2.1.5's CI type-check job flagged 11 union-attr errors in iolink-proxy's new retry path (Optional[StreamReader/StreamWriter] not narrowed after the asyncio.open_connection re-assignment) plus two minor MainUI nits (a cast on a Flask send_from_directory whose return is already typed, and a Dict[Any] cache return). Fixed via narrowing asserts where the variables are reassigned, and a typed cast on the cache hit path.
    • MainUI bumped to 1.4.5. iolink-proxy bumped to 1.0.5.

76. v2.1.5

    no date
    • IOLink Master Configuration page now loads correctly through MainUI's authenticated reverse proxy. Previously the iframe rendered only the orange status bar with the firmware version, but the navigation row and device-overview area below stayed empty — the ifm IoT-Core Visualizer SPA's JSON-RPC client constructed its endpoint URL as bare http://host:port without a trailing slash, which the proxy's URL rewriter didn't recognise as same-origin, so xhr.open('POST', _url) landed on MainUI's / (405) instead of /iolink-master-proxy/. The proxy shim now also handles the bare-origin case, and /iolink-master-proxy/ streams long-poll responses (no 10 s timeout cap, body chunk-by-chunk). The IOLink reverse proxy retries once when the IFM AL1330 closes a TCP connection without sending an HTTP response, a behaviour seen during the SPA's initial-page burst of ~20 parallel requests.
    • IDEA4SBridge iframe now shows the new user-facing dashboard introduced with idea4sbridge 1.3.0 (served on port 8050). MainUI was still proxying to port 8080, where the legacy status panel remained reachable, so users were seeing the old UI. idea4sbridge bumped from 1.2.13 to 1.3.0.
    • Home page now lists FLECS-installed apps in a new "Installed Apps" section. Each tile links directly to its UI through MainUI's reverse proxy with icons fetched lazily from the FLECS marketplace; section is empty until the user has logged into FLECS at least once.
    • MainUI bumped to 1.4.4. iolink-proxy bumped to 1.0.4.

77. v2.1.4

    2026-04-28
    • Grafana panels now show data on remote browsers. The previous 2.1.3 attempt (Grafana env vars GF_SECURITY_CSRF_TRUSTED_ORIGINS=*) didn't work because Grafana's CSRF check has no wildcard support and compares hostnames literally — the env var change was a no-op. The real fix lives in MainUI's reverse proxy: it now rewrites the Origin header to match Grafana's internal Host before forwarding, so Grafana's check passes regardless of what host the browser used. No per-device IP configuration needed.
    • MainUI bumped to 1.4.3.

78. v2.1.3

    2026-04-27
    • Grafana panels now show data when accessed inside MainUI. Previously the dashboard rendered the panel layout but every datasource query returned "origin not allowed" (HTTP 403) because Grafana's CSRF check rejected the proxied request's Origin header (browser sends MainUI's host, Grafana defaults to localhost:3000). Configured Grafana to trust any origin for CSRF — appropriate because Grafana is on a private docker network behind MainUI's authenticated reverse proxy.

79. v2.1.2

    2026-04-27
    • Grafana now loads correctly inside MainUI on edges that were upgraded from a pre-1.4.x firmware. Older firmware persisted an absolute Grafana URL (http://...:3000/...) in the device's config.json; on upgraded edges, host port 3000 is no longer published, so that URL would fail. MainUI now detects the legacy absolute form at request time and routes it through /grafana-proxy/... instead — no manual config edit required.
    • USB service self-diagnosis no longer reports "unreachable" on devices that have it healthy. The container has gained a localhost:8084 healthcheck, which MainUI's diagnosis-discovery uses to learn the right port (the USB service was already healthy on 8084; the diagnosis page was probing the wrong default port).
    • MainUI bumped to 1.4.2.

80. v2.1.1

    2026-04-27
    • MainUI now serves on two ports simultaneously: HTTP on 5000 (existing — for the local kiosk and for backward compatibility with previous firmware versions during OTA upgrade) and HTTPS on 5443 (new — for remote browsers from the LAN). The local kiosk continues to use http://127.0.0.1:5000/. From a technician's laptop, use https://<edge-ip>:5443/ for the AppStore (FLECS' OAuth flow needs a secure context, which HTTPS provides). HTTP http://<edge-ip>:5000/ still works for everything except the AppStore page.
    • Fixes the rollback that occurred when upgrading from 2.0.x to 2.1.0: the OTA health-check (which probes HTTP) now succeeds because MainUI continues to answer on HTTP.
    • Kiosk no longer needs --ignore-certificate-errors and goes back to the HTTP loopback URL (cleaner, no cert handling at all on the kiosk side).
    • Chromium-Executer snap version bumped to 1.0.2.

81. v2.1.0

    2026-04-27
    • AppStore page now works on remote browsers (Firefox, Edge, Chrome) — not only on the local kiosk. The login flow that previously looped on remote browsers now completes; you can onboard, log in to FLECS, and use the marketplace from a technician's laptop on the LAN.
    • MainUI now serves HTTPS on port 5000. On first access from a remote browser you will see a one-time self-signed-cert warning per device — accept it once, the browser remembers it.
    • Grafana is now embedded via MainUI (no longer reachable directly at port 3000 on the device). Existing direct bookmarks http://<edge>:3000/... will stop working — use the Grafana entry inside MainUI instead.
    • The kiosk waits for MainUI to be reachable before launching the browser, so the screen no longer briefly shows "site can't be reached" on slow first boots.
    • MainUI bumped to 1.4.0; chromium-executer snap bumped to 1.0.1.

82. v2.0.1

    no date
    • Fixed FleetManager status showing "Not connected" for the datastore even though data was reaching the server. The embedded brinkhaustools fleet client now accepts any 2xx response from the ingest API (previously only HTTP 200 was treated as success, so the 202 returned by /diagnostics was misclassified as a connection error).
    • Datastore bumped to 4.3.11.

83. v2.0.0

    2026-04-27
    • New AppStore page integrating FLECS — accessible via the main navigation as configured in the stream
    • Stream configuration can now declare custom navigation extensions in stream.json (extensions block) with custom icon and label
    • MainUI bumped to 1.3.0; FLECS service filip (image flecspublic.azurecr.io/flecs/filip:latest) added to the stack

84. v1.2.29

    no date
    • Self-diagnosis now shows service versions for IOLink proxy and USB service in addition to MainUI and UpdateService
    • IOLinkMasterProxy and USBService now expose their versions via REST API
    • MainUI bumped to 1.2.11, IOLinkMasterProxy bumped to 1.0.3, USBService bumped to 1.1.1

85. v1.2.28

    no date
    • Fixed spurious rollback when UpdateService receives SIGTERM during health check (e.g. during self-update)
    • UpdateService self-update now pre-pulls the new image before stopping the old service
    • Self-update check runs in background thread with 90s delay to avoid race with health check
    • Changed restart policy from unless-stopped to always for all services (ensures recovery after reboot)
    • CI pipeline parallelized: all jobs start immediately via needs: [], test failures visible in 3-5 min
    • Split compose-validate into syntax-only (always) and build (branches only) to avoid redundant builds on tags
    • Added pip caching to CI test jobs
    • MainUI bumped to 1.2.10, UpdateService bumped to 1.2.11

86. v1.2.27

    no date
    • Self-diagnosis now shows service versions next to each service name
    • UpdateService exposes its version via REST API
    • MainUI bumped to 1.2.9, UpdateService bumped to 1.2.10

87. v1.2.26

    no date
    • Fixed sidebar label "Idea4S Devices" to "IDEA-4S Devices"
    • Fixed German category labels in IDEA-4S device parameters: "Identifikation" → "Identification", "Diagnose" → "Diagnosis"

88. v1.2.25

    no date
    • USBService now automatically restarts when a USB stick is inserted after boot (Docker hotplug fix)
    • Added self-diagnosis messages for USB status: stick detection, CSV export readiness, transfer results
    • USBService bumped to 1.1.0

89. v1.2.24

    no date
    • Phantom versions in the UI (e.g. 1.0.0) now default to dev_mode, preventing accidental downgrades on production devices

90. v1.2.23

    no date
    • Dummy-Update without content for update-tests

91. v1.2.22

    no date
    • Firmwares without an explicit dev_mode: false flag are now treated as development builds and blocked on production devices

92. v1.2.21

    no date
    • Production firmware can now be installed on production devices without enabling dev mode
    • Dev firmware is marked with a "dev" badge and can only be installed on dev-mode devices
    • Device badge now shows "Production" or "Development Device" instead of "Updates Locked"

93. v1.2.20

    no date
    • Production release with dev_mode disabled by default

94. v1.2.19

    no date

    No release notes are available for this version yet.

95. v1.2.18

    no date
    • User settings (e.g. machine name) are now preserved across firmware updates; the config is merged with new defaults instead of reset
    • UpdateService now pulls images before starting services, preventing stale sideloaded images from persisting

96. v1.2.17

    no date
    • Removed all automatic firmware updates; updates are now triggered manually via the Update/Upgrade/Downgrade buttons
    • Added dev_mode flag to description.json: only devices with dev_mode: true can install development firmware
    • Two-flag access control: production firmware (dev_mode: false) can be installed on any device; dev firmware can only be installed on dev-mode devices
    • Firmwares without an explicit dev_mode: false flag are treated as development builds and blocked on production devices
    • Firmware versions are labeled with a "dev" badge in the update list when they are development builds
    • Added scripts/toggle-dev-mode.sh to enable/disable dev mode on edge devices via SSH

97. v1.2.16

    no date
    • Added cyclic health monitor that checks service URL reachability and Docker container status every 30 seconds
    • Health check results are reported to fleet management and available via /api/health
    • Diagnosis codes 1006-1008 notify when services are unreachable or containers are unhealthy
    • IOLink proxy: fixed white screen when accessed from a remote browser (HTTP/1.0-to-1.1 translation, keep-alive handling)
    • IOLink proxy: shows error page with auto-retry when IOLink Master is unreachable or session is locked (406)
    • IOLink proxy: added diagnosis code 3003 for upstream HTTP errors, visible in self-diagnosis and fleet manager
    • IOLink proxy: added 5-second connect timeout (was OS default ~2 min) and Docker HEALTHCHECK

98. v1.2.15

    no date
    • Fixed FleetManager config not being loaded at container startup when config.json didn't exist yet
    • The fleet monitor now retries loading the config file if the initial read fails
    • Updated brinkhaustools to 0.2.2

99. v1.2.14

    no date
    • All container images now use fully pinned version tags to ensure security patches are reliably deployed
    • Each firmware version now includes a service version manifest in description.json
    • The release notes modal now shows a service version comparison table highlighting which containers changed
    • CI now validates that description.json services match docker-compose.yml image tags
    • Release notes are now mandatory for firmware releases
    • Removed GitLab Container Registry mirror layer; dependency images are pulled directly from Docker Hub
    • Updated datastore to 4.3.10 and idea4sbridge to 1.2.13

100. v1.2.3

     no date
     • Support for external host IPs schown in the Brinkhaus fleet manager (if an edge has access to the internet)

101. v1.2.2

     no date
     • You can now view release notes directly on the firmware update page

102. v1.2.1

     no date
     • You can now view release notes directly on the firmware update page
     • The version tree on the update page now uses collapsible sections for better readability
     • Versions are now displayed at the feature level, making it easier to see which updates are available

103. v1.1.1

     no date
     • Fixed a bug where firmware updates could fail because the new configuration file was written to the wrong location

104. v1.1.0

     no date
     • Added fleet management settings to connect the edge device to the Brinkhaus Fleet Manager
     • The UpdateService now automatically rolls back to the previous version if an update fails
     • The UpdateService now validates configuration files before applying them
     • Improved the IDEA4S device editor with role selection, unit display, and tooltips

105. v1.0.2

     no date
     • Added a resource monitor showing CPU and memory usage
     • Added a display of currently assigned DHCP addresses in the network settings
     • The network configurator now validates your inputs before saving
     • Fixed an issue where DHCP addresses were not displayed correctly
     • Docker service versions are now shown on the update page
     • Improved the visual appearance of the IDEA4S settings section
     • You now receive a warning when leaving the IDEA4S settings with unsaved changes
     • Added the ability to read and write individual IDEA4S device parameters
     • Improved stability of the configuration file handling during updates

106. v1.0.1

     no date
     • Stabilized the automatic update process
     • Pinned all service versions to prevent unexpected changes from upstream images

107. v1.0.0

     no date
     • Initial release of the BOS firmware
     • Web-based dashboard for device management
     • Network configuration via the settings page
     • Automatic firmware update system
     • USB device management
     • Grafana integration for data visualization
     • IOLink Master proxy for sensor communication