Was ist der Unterschied zwischen Ereigniszeit und Verarbeitungszeit bei Heimautomatisierungen?

Die Ereigniszeit erfasst, wann ein Ereignis im Zuhause aufgetreten ist, während die Verarbeitungszeit erfasst, wann die Automatisierungs-Engine dieses Ereignis auswertet.

Ein Türsensor kann um 18:00 Uhr ein Ereignis registrieren, die Nachricht während eines Mesh-Ausfalls zwischenspeichern und um 18:03 Uhr den Heimserver erreichen. Eine Logik auf Basis der Verarbeitungszeit behandelt es als aktuell; eine Logik auf Basis der Ereigniszeit ordnet es an der früheren Stelle in der Sequenz ein. Diese Wahl verändert Fensterzugehörigkeit, Reihenfolge, Replay und Latenz – insbesondere, wenn sich drahtlose Geräte wieder verbinden oder der Automatisierungsserver nach einem Ausfall aufholt.

Die beiden Uhren beschreiben unterschiedliche Teile desselben Ereignispfads

Die Ereigniszeit gehört zur Beobachtung selbst: wann die Taste gedrückt, die Messung vorgenommen oder die Bewegung begonnen wurde. Die Verarbeitungszeit gehört zur Laufzeit der Automatisierung: wann der Worker den Datensatz empfangen und ausgewertet hat. Sie stimmen nur überein, wenn Transport, Zwischenspeicherung, Planung und Uhrabweichung vernachlässigbar sind.

Ereigniszeit und Verarbeitungszeit können durch Netzwerk-, Puffer- und Verarbeitungsverzögerungen auseinanderlaufen. Diese Komponenten schwanken, sodass die Reihenfolge des Eintreffens von der Reihenfolge des Auftretens abweichen kann, selbst wenn jeder einzelne Sensor korrekt sendet.

Heimsysteme bringen eine weitere Komplikation mit sich: Geräteuhren können falsch eingestellt sein oder fehlen. Ein Feld für die Ereigniszeit ist nur dann nützlich, wenn die Quelluhr und die Bedeutung des Zeitstempels vertrauenswürdig sind. Die Verarbeitungszeit ist auf dem Server immer verfügbar, beschreibt jedoch das Zustellverhalten und nicht die physische Abfolge im Raum.

Die Verarbeitungszeit begünstigt sofortige Reaktionen

Eine Automatisierung auf Basis der Verarbeitungszeit wertet einen Datensatz anhand der Serveruhr aus, sobald er eintrifft. Das ist für Regeln wie das Auslösen eines Alarms bei aktueller CPU-Auslastung oder das Einschalten eines Lichts durch einen gerade gedrückten Taster einfach und schnell. Sie muss nicht auf frühere Nachrichten warten, die möglicherweise noch unterwegs sind.

Ereignis-Stream-Verarbeitung legt den Schwerpunkt darauf, kontinuierlich eintreffende Ereignisse zu verarbeiten, wobei Zeit und Reihenfolge für zustandsbehaftete Vorgänge wichtig sind. Der Vorteil der niedrigen Latenz wird zu einem Problem für die Korrektheit, wenn verzögerte Datensätze als neue Bedingungen statt als verspätete Hinweise auf einen früheren Zustand interpretiert werden.

Beim Replay wird der Unterschied deutlich. Wenn die Ereignisse der vergangenen Woche heute verarbeitet werden, ordnen Fenster auf Basis der Verarbeitungszeit sie der heutigen Uhrzeit zu, sofern keine spezielle Logik die ursprünglichen Zeitstempel wiederherstellt. Eine rekonstruierte Belegungshistorie oder ein Trainingsdatensatz kann sich daher je nachdem verändern, wann das Replay ausgeführt wurde.

Die Ereigniszeit bewahrt die Reihenfolge, muss aber auf Verspätungen warten

Eine Logik auf Basis der Ereigniszeit ordnet Datensätze mithilfe ihrer enthaltenen Zeitstempel des Auftretens Fenstern und Sequenzen zu. Ein vor dem Öffnen einer Tür erzeugtes Bewegungsereignis bleibt zeitlich davor, selbst wenn es später eintrifft. Das macht die historische Nachverarbeitung konsistenter und schützt Merkmale, die auf Dauer oder Reihenfolge basieren.

Ereigniszeitverarbeitung verwendet Zeitstempel, Wasserzeichen und die Verarbeitung verspäteter Daten, weil die Engine nicht sofort wissen kann, dass jedes frühere Ereignis eingetroffen ist. Längeres Warten verbessert die Vollständigkeit, verzögert jedoch endgültige Ergebnisse und hält den Zustand länger offen.

Der Zielkonflikt zeigt sich deutlich bei Automatisierungen. Eine Toleranz von einer Sekunde für Verspätungen kann die Reaktionsfähigkeit der Beleuchtung erhalten, aber einen Batteriesensor verpassen, der mit einer Verzögerung von einer Minute eintrifft; eine lange Toleranz liefert präzise Analysen, eignet sich jedoch nicht für sofortige Aktionen. Viele Haushalte benötigen schnelles vorläufiges Handeln und spätere Korrekturen statt einer einzigen Zeitrichtlinie für jede Regel.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Wiederverbindungen machen alten Zustand zu neuen Eingängen

Drahtlose Geräte, Broker und Integrationen können Nachrichten zwischenspeichern oder aufbewahren, während Abonnenten nicht verfügbar sind. Nach der Wiederverbindung kann der Server eine Flut von Nachrichten empfangen, deren Verarbeitungszeiten eng beieinanderliegen, obwohl sich die zugrunde liegenden Ereignisse über Minuten oder Stunden erstrecken. Ankunftsbasierte Regeln können dann reagieren, als beschreibe die gesamte Nachrichtenflut die Gegenwart.

Das erklärt, warum beibehaltene Nachrichten den Zustand eines Zuhauses nach einem Neustart verändern können. Ein beibehaltener Zustands-Snapshot, ein zwischengespeicherter Befehl und ein neu erzeugtes Ereignis haben unterschiedliche Bedeutungen, selbst wenn sie dasselbe Topic verwenden und während derselben Wiederverbindung eintreffen.

Zeitstempel allein lösen diese Mehrdeutigkeit nicht. Die Automatisierung muss wissen, ob ein Datensatz einen Zustand, eine Zustandsänderung, einen Befehl oder ein Replay darstellt. Zustandsaktualisierungen können den aktuellen Wert meist sicher ersetzen, während ein alter Befehl zum „Entsperren“ normalerweise eine Aktualitätsprüfung nicht bestehen und nicht verspätet ausgeführt werden sollte.

Verwenden Sie die Zeitsemantik passend zum jeweiligen Automatisierungsergebnis

Wählen Sie die Verarbeitungszeit, wenn eine sofortige Reaktion wichtiger ist als die exakte Rekonstruktion der Vergangenheit und verspätete Datensätze sicher ignoriert werden können. Wählen Sie die Ereigniszeit für Dauern, Sequenzen, Belegungshistorien, Energiezeiträume, Modellmerkmale und jede Berechnung, die nach einem Replay dasselbe Ergebnis liefern soll.

Die Zeitreihenfolge wird unzuverlässig, wenn die Ankunft vom im Ereignis enthaltenen Zeitstempel abweicht. Tests sollten Verzögerungen, Duplikate, Nachrichtenfluten nach Neustarts und Uhrabweichungen simulieren und anschließend sowohl sofortige Aktionen als auch die korrigierte Historie vergleichen.

Ein hybrides Design funktioniert oft am besten: Reagieren Sie vorläufig bei der Ankunft, lehnen Sie veraltete gefährliche Befehle ab und aktualisieren Sie den analytischen Zustand anhand der Ereigniszeit. Maßgeblich sind die Erwartungen der Nutzer. Ein Licht sollte nicht minutenlang auf eine perfekte Reihenfolge warten, während ein Belegungsbericht nicht den gestrigen Tag anhand der heutigen Verarbeitungsuhr neu schreiben sollte.