Support- und Sicherheitsupdate-Richtlinie

1. Geltungsbereich

Diese Richtlinie gilt für den AirNode-Lüftungsregler. Der Regler besteht aus zwei getrennten Baugruppen mit sehr unterschiedlichen technischen Voraussetzungen: dem Controller — er trägt die Firmware, die Regelung, die lokale Weboberfläche und die gesamte Netzwerkanbindung —, und dem externen Sensor-Satelliten — er misst Temperatur und Feuchte außen und meldet sie über eine verdrahtete Verbindung an den Controller.

AirNode sagt für jedes einzelne Gerät Sicherheitsupdates für die Controller-Firmware für fünf Jahre ab dem Kaufdatum dieses Geräts zu. Die Frist läuft pro Gerät und beginnt mit dem Kaufdatum des jeweiligen Geräts, wie es sich aus dem Kaufbeleg ergibt — nicht mit einem gemeinsamen Enddatum für die gesamte Produktlinie. Ein später gekauftes Gerät ist damit auch länger unterstützt. Noch nicht geregelt ist, wie der Beginn der Frist bestimmt wird, wenn sich kein Kaufdatum nachweisen lässt; diese Ergänzung steht aus.

Diese Zusage ist eine garantierte Mindestunterstützung, keine Obergrenze. Sie sagt, wie lange wir Sicherheitsupdates mindestens liefern. Sie sagt nicht, dass mit ihrem Ablauf Ihre gesetzlichen Rechte enden: Ihre Mängelrechte beim Kauf einer Ware mit digitalen Elementen — insbesondere der gesetzlich geschuldete Aktualisierungszeitraum nach § 475b Abs. 4 BGB — richten sich nach dem Gesetz und nicht nach dieser Richtlinie. Der gesetzliche Zeitraum bemisst sich nach Art und Zweck des Produkts sowie den Umständen des Einzelfalls und kann im Einzelfall länger sein als der hier zugesagte. Diese Richtlinie verkürzt ihn nicht und kann ihn nicht verkürzen.

Erfasst ist die Firmware des Controllers einschließlich der in sie eingebetteten lokalen Weboberfläche. Der kostenlose Cloud-Dienst ist kein Gegenstand dieser Update-Zusage; für ihn gilt gesondert Abschnitt 6.

1.1 Der externe Sensor-Satellit — kein Feld-Update-Pfad

Der Sensor-Satellit lässt sich nicht aus der Ferne aktualisieren. Das ist keine Betriebsentscheidung, sondern eine Eigenschaft der Baugruppe, und wir benennen sie hier ausdrücklich statt sie an anderer Stelle zu vermerken: Der Satellit lässt sich nur mit physischem Zugang zum geöffneten Gerät programmieren; es gibt keinen Bootloader und damit keinen Mechanismus, über den der Satellit eine neue Firmware entgegennehmen könnte. Der Satellit hat zudem keine Netzwerkschnittstelle; er ist über eine verdrahtete Verbindung innerhalb der Kundeninstallation angebunden und spricht ausschließlich mit dem Controller.

Was das für Sie bedeutet: Sollte im Satelliten je ein Fehler auftreten, der eine Firmware-Änderung erfordert, kann er nur durch physischen Service vor Ort behoben werden — am geöffneten Gerät oder durch Tausch der Baugruppe. Eine Aktualisierung über das Netz, über die Weboberfläche oder über die Cloud ist technisch ausgeschlossen. Wie ein solcher Servicefall im Einzelnen abgewickelt und abgerechnet wird, regelt diese Richtlinie nicht; sie sagt an dieser Stelle bewusst keine Fernaktualisierung zu.

Ihre gesetzlichen Ansprüche bleiben davon unberührt. Dass diese Richtlinie den Servicefall nicht regelt, heißt nicht, dass Sie ihn tragen: Wer die Kosten einer solchen Abhilfe trägt, richtet sich im Einzelfall nach dem Gesetz — insbesondere nach dem Kaufvertrag über die Hardware und den Mängelrechten aus §§ 434 ff. BGB. Bei einem sicherheitsrelevanten Mangel kann sich bereits daraus ein Anspruch auf kostenlose Abhilfe ergeben. Der vorstehende Absatz beschreibt allein, was technisch möglich ist, und trifft keine Aussage darüber, wer zahlt.

Warum die Angriffsfläche eine andere ist: Der Controller ist mit dem WLAN und — sofern Sie das aktivieren — mit dem Internet verbunden; er nimmt Anfragen aus dem Netz entgegen und baut Verbindungen nach außen auf. Er ist damit aus dem Netz erreichbar und braucht regelmäßige Sicherheitsupdates. Der Satellit ist es nicht: Er hat keine Netzwerkanbindung und keinen Dienst, der aus einem Netz angesprochen werden könnte. Wer ihn angreifen wollte, müsste sich physischen Zugang zur Installation verschaffen — dieselbe Voraussetzung, unter der er auch legitim programmiert wird. Aus diesem Grund benennt diese Richtlinie die Position des Satelliten offen, statt für ihn eine Fern-Update-Fähigkeit zu behaupten, die es nicht gibt.

Zwei Punkte gehören zu einer Support-Zusage in dieser Form — Controller vollständig erfasst, Satellit ausdrücklich mit benannter Einschränkung: Die Einschränkung nennen wir bereits vor dem Kauf und nicht nur in dieser Richtlinie (Abschnitt 7), und wir treffen keine pauschale Aussage, alle Firmware-Bestandteile würden für den erklärten Zeitraum aktualisiert. Neu zu bewerten wäre diese Einordnung, wenn der Satellit künftig eine sicherheitskritische Funktion übernähme; heute misst er ausschließlich Temperatur und Feuchte und meldet diese Werte an den Controller.

2. Was ein Sicherheitsupdate ist

Ein Sicherheitsupdate im Sinne dieser Richtlinie ist eine Änderung der Controller-Firmware, die eine Schwachstelle beseitigt — in unserem eigenen Code oder in einer der von uns eingebundenen Fremdkomponenten —, durch die die Vertraulichkeit, die Integrität oder die Verfügbarkeit des Geräts, seiner Konfiguration oder seiner Messdaten beeinträchtigt werden kann. Dazu zählen insbesondere Schwachstellen in der Netzwerk- und TLS-Verarbeitung, in der Authentifizierung der lokalen Weboberfläche, im Update-Pfad selbst und in den eingebundenen Bibliotheken.

Davon zu unterscheiden sind Funktionsupdates — neue Funktionen, Bedienverbesserungen oder Anpassungen der Regelung. Solche Updates kann es geben, sie sind aber nicht Gegenstand dieser Zusage. Wir behalten uns vor, Sicherheitskorrekturen und Funktionsänderungen in einem gemeinsamen Firmware-Release auszuliefern; das ist bei einem eingebetteten Gerät der Regelfall.

Diese Richtlinie nennt keine feste Veröffentlichungsfrequenz und keine zugesicherte Reaktionsfrist. Ein Sicherheitsupdate wird erstellt, wenn eine Schwachstelle bekannt wird, die das Gerät betrifft; die Dringlichkeit richtet sich nach der Schwere und der tatsächlichen Ausnutzbarkeit in der ausgelieferten Konfiguration.

Hinweise auf mögliche Schwachstellen nehmen wir unter contact@air-node.net entgegen.

3.1 Lokal über das eigene Netz

Es gibt zwei voneinander unabhängige Wege, ein Firmware-Update auf den Controller zu bringen, hier in der Reihenfolge ihrer Erreichbarkeit aufgeführt — beginnend mit dem Weg, der die wenigsten Voraussetzungen hat.

Ein Firmware-Image kann direkt an das Gerät übergeben werden: über die Bedienoberfläche des Geräts im selben lokalen Netz, angemeldet mit dem Administrator-Zugang des Geräts. Das Gerät schreibt das Abbild unmittelbar in den gerade nicht laufenden Firmwarestand und startet neu. Dieser Weg benötigt weder den AirNode-Cloud-Dienst noch Dienste Dritter noch eine Internetverbindung — nur eine Netzwerkverbindung zum Gerät im eigenen Netz und eine vorliegende Firmware-Datei. Er ist damit der Weg, auf den sich eine mehrjährige Update-Zusage auch dann noch stützen kann, wenn Dienste Dritter oder unser eigener Cloud-Dienst nicht zur Verfügung stehen.

Einschränkung, die wir offen benennen: Beim lokalen Upload vergleicht das Gerät keine vom Aufrufenden mitgelieferte Prüfsumme. Der lokale Weg ist deshalb ausdrücklich als Administrator-Vorgang zu behandeln. Die Integrität stützt sich auf den vollständigen Abschluss des Schreibvorgangs und auf die Signaturprüfung beim Start (Abschnitt 3.3). Laden Sie gleichwohl nur Firmware-Dateien hoch, deren Herkunft Sie kennen.

3.2 Über den Cloud-Dienst

Ist das Gerät mit dem Cloud-Dienst verbunden, kann ein Update aus der Ferne angestoßen werden. Dieser Weg setzt voraus, dass die gesamte Kette erreichbar ist: das signierte Release, seine Übernahme in unseren Plattformdienst, die Freigabe für das Gerät, eine Internetverbindung des Geräts und der Download. Fällt eine dieser Stationen aus, erhält das Gerät den Auslöser nicht oder kann das Image nicht laden — das laufende Image bleibt in diesem Fall unverändert.

Beim Fernupdate prüft das Gerät die Unverletztheit des heruntergeladenen Abbilds und bricht bei einer Abweichung ab, bevor der Startzustand verändert wird.

Zur Verfügbarkeit des Cloud-Dienstes trifft diese Richtlinie keine Aussage; eine Verfügbarkeitszusage ist mit ihr nicht verbunden. Was ohne den Cloud-Dienst weiterläuft, steht in Abschnitt 4; was bei seiner Einstellung gilt, in Abschnitt 6.

3.3 Signierung, zwei Firmwarestände, automatische Rückkehr zur vorherigen Version

Beide Wege teilen sich denselben Schutzmechanismus auf dem Gerät. Das Gerät hält zwei gleich große Firmwarestände (A/B) vor. Ein Update wird immer in den gerade nicht laufenden Stand geschrieben; die laufende Firmware bleibt bis zum Neustart vollständig erhalten.

Firmware-Abbilder sind signiert; das Gerät startet nur eine mit unserem Produktionsschlüssel gültig signierte Firmware, und der ausgelieferte Firmwarestand ist gegen Auslesen und Veränderung geschützt.

Nach einem Update muss sich die neue Firmware zeitnah als funktionsfähig erweisen; eine fehlende Verbindung ins Heimnetz gilt dabei ausdrücklich nicht als Fehlstart. Bleibt der Funktionsnachweis aus, startet das Gerät neu und kehrt zum vorherigen Firmwarestand zurück. Ein fehlgeschlagenes Update hinterlässt so kein unbrauchbares Gerät.

4.1 Läuft vollständig auf dem Gerät

Der AirNode ist so gebaut, dass seine eigentliche Aufgabe — lüften, wenn Lüften sinnvoll ist — ohne unseren Cloud-Dienst und ohne Internetverbindung weiterläuft.

Vollständig auf dem Gerät laufen: die Messwerte des Innen- und des Außensensors; die Differenzregelung — die Entscheidung, ob der Lüfter laufen soll, aus dem Vergleich der absoluten Feuchte innen und außen, mit Hysterese, Frostschutzgrenze und einer Mindestverweildauer im aktuellen Schaltzustand; der Wochenzeitplan, der eine gültige, von einem einstellbaren Zeitserver bezogene Uhrzeit voraussetzt — nicht vom AirNode-Cloud-Dienst — und ohne die der Zeitplan ruht, während die Regelung weiterläuft; die manuelle Lüftersteuerung, jederzeit lokal auf „aus", „automatisch" oder „ein" umschaltbar; und die lokale Weboberfläche auf dem Gerät, die im Firmware-Image eingebettet ist, nichts aus dem Internet nachlädt und bei fehlender WLAN-Verbindung — sofern der Access-Point-Betrieb nicht abgeschaltet ist — über einen eigenen Access-Point erreichbar bleibt.

Keine der oben genannten Funktionen hängt am Cloud-Client des Geräts.

4.2 Läuft ohne den Cloud-Dienst nicht

Ohne den Cloud-Dienst funktionieren nicht: der Zugriff von außerhalb des eigenen Netzes — ohne Cloud-Dienst ist das Gerät nur im lokalen Netz erreichbar; die geräteübergreifende Übersicht mehrerer Geräte in einer gemeinsamen, kontogebundenen Ansicht; die Langzeit-Historie — auf dem Gerät liegt nur ein begrenztes Messwertarchiv über die letzten Stunden und Tage, alles darüber hinaus findet ausschließlich im Cloud-Dienst statt; und Alarme und Benachrichtigungen per E-Mail oder Push, die ein Dienst der Plattform sind — das Gerät selbst versendet keinerlei Benachrichtigungen.

5. Ende des Supportzeitraums

Mit dem Ablauf des Supportzeitraums für ein bestimmtes Gerät enden für dieses Gerät die Sicherheitsupdates. Was das nicht bedeutet: Das Gerät hört nicht auf zu arbeiten. Es gibt in der Firmware keinen Ablaufmechanismus, keine Zeitsperre und keine Lizenzprüfung — nichts, was die Funktion des Geräts nach einem Stichtag oder mangels Freischaltung beendet. Die zuletzt installierte Firmware läuft weiter, und mit ihr alle in Abschnitt 4.1 genannten Funktionen.

Der Vollständigkeit halber: Solange ein Gerät mit dem Cloud-Dienst verbunden ist, kann die Plattform ihm Befehle senden — Neustart, Setzen des Lüftermodus (einschließlich „dauerhaft aus"), Ändern der Regelparameter und des Zeitplans. Das ist die normale Fernbedienung, die Sie mit der Kopplung an den Cloud-Dienst einschalten, und sie endet, sobald das Gerät nicht mehr gekoppelt oder nicht mehr mit dem Internet verbunden ist. Einen Befehl, der ein Gerät dauerhaft unbrauchbar macht, gibt es nicht. Der lokale Update-Weg bleibt zudem offen: Der Weg nach Abschnitt 3.1 funktioniert unabhängig davon, ob wir noch Updates veröffentlichen (Abschnitt 3.1).

Was es bedeutet: Ab diesem Zeitpunkt schließen wir für dieses Gerät keine neu bekannt werdenden Schwachstellen mehr. Wir empfehlen dann, das Gerät entweder zu ersetzen oder es so zu betreiben, dass es aus dem Internet nicht erreichbar ist.

Was der Ablauf ebenfalls nicht bedeutet: Ihre gesetzlichen Rechte enden damit nicht. Der Supportzeitraum beschreibt, wie lange wir Sicherheitsupdates liefern. Er ist keine Frist für Ihre Mängelrechte und begrenzt sie nicht. Ob im Einzelfall Aktualisierungen über diesen Zeitraum hinaus geschuldet waren, richtet sich nach dem Gesetz (Abschnitt 1) und kann anders ausfallen als die hier zugesagte Dauer.

Wir werden das Ende des Supportzeitraums nicht stillschweigend eintreten lassen, sondern es ankündigen — über alle drei der folgenden Wege, damit die Ankündigung auch diejenigen erreicht, die das Gerät ohne Benutzerkonto rein lokal betreiben: auf der Website unter dem Punkt Support, mit Angabe der betroffenen Kaufzeiträume; in der lokalen Weboberfläche des Geräts — dem Weg, der ohne Konto und ohne Cloud-Anbindung funktioniert; und per E-Mail, soweit ein Benutzerkonto besteht und dort eine Adresse hinterlegt ist. Eine E-Mail allein genügt ausdrücklich nicht: Der AirNode ist nach Abschnitt 4.1 vollständig ohne Konto nutzbar, und wer nie eines angelegt hat, hat uns auch keine Adresse gegeben. Der Hinweis in der lokalen Weboberfläche setzt voraus, dass Sie diese aufrufen; darauf, dass jede Ankündigung jede Nutzerin tatsächlich erreicht, können wir nicht zusagen.

Das Ende des Supportzeitraums ist nicht gleichbedeutend mit einer Einstellung des Cloud-Dienstes. Der Cloud-Dienst kann darüber hinaus weiterlaufen; wird er eingestellt, gilt Abschnitt 6.

6. Einstellung des kostenlosen Cloud-Dienstes

Der Cloud-Dienst ist für den in dieser Richtlinie genannten Supportzeitraum vorgesehen. Sollte eine Einstellung erforderlich werden, erfolgt diese nach den nachfolgenden Übergangsregelungen.

Kommt es zu einer Einstellung, gilt: Ankündigung mindestens sechs Monate im Voraus, per E-Mail an die im Konto hinterlegte Adresse — und, weil ein Gerät auch ganz ohne Benutzerkonto betrieben werden kann, zusätzlich über die beiden kontounabhängigen Wege aus Abschnitt 5 (Website und lokale Weboberfläche des Geräts); Datenexport während der gesamten Vorlauffrist — Ihre in der Cloud gespeicherten Daten bleiben bis zum Abschaltzeitpunkt exportierbar; und ein abschließendes Firmware-Release, das den lokalen Betrieb des Geräts intakt lässt. Das Gerät soll nach der Abschaltung genau das weiter tun, was in Abschnitt 4.1 beschrieben ist. Dieses abschließende Firmware-Release ist eine technische Absicherung für den Ausnahmefall; es gilt eigenständig, unabhängig davon, ob der Cloud-Dienst wie im ersten Satz dieses Abschnitts vorgesehen fortgeführt wird.

7. Kommunikation zum Verkaufszeitpunkt

Damit die Zusage aus Abschnitt 1 vor dem Kauf erkennbar ist und nicht erst danach, gilt: Der zugesagte Supportzeitraum wird vor Abschluss des Kaufs genannt — in der Produktbeschreibung und durch einen Verweis auf diese Richtlinie in ihrer veröffentlichten Fassung. Die Einschränkung zum Sensor-Satelliten aus Abschnitt 1.1 wird an derselben Stelle und in derselben Deutlichkeit genannt wie die Zusage selbst; sie erscheint nicht ausschließlich in dieser Richtlinie. Das Enddatum ergibt sich aus dem Kaufdatum des einzelnen Geräts, wie es der Kaufbeleg ausweist; der Kaufbeleg ist damit der maßgebliche Nachweis für den Beginn der Frist. Maßgeblich für ein Gerät ist die Fassung dieser Richtlinie, die zum Zeitpunkt seines Kaufs veröffentlicht war. Spätere Fassungen können die Zusage für bereits verkaufte Geräte nicht verschlechtern. Frühere Fassungen bleiben über das Versionsprotokoll nachvollziehbar.

8. Versionsprotokoll

Version 1.0, 2026-07-27: Erste verbindliche Fassung.

Version 1.1, 2026-08-08: Abschnitt 6 — Fortführung des Cloud-Dienstes als Absicht statt als Zusage; Abschnitt 1.1 — Hinweis, dass die gesetzlichen Ansprüche unberührt bleiben.