Jaka jest różnica między czasem zdarzenia a czasem przetwarzania w automatyzacji domowej?

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

What Is the Difference Between Event Time and Processing Time in Home Automations? - Zima Store Online

Czas zdarzenia rejestruje moment wystąpienia zdarzenia w domu, natomiast czas przetwarzania rejestruje moment, w którym silnik automatyzacji ocenia to zdarzenie.

Czujnik drzwi może zarejestrować zdarzenie o 18:00, buforować komunikat podczas awarii sieci mesh i dostarczyć go do serwera domowego o 18:03. Logika czasu przetwarzania traktuje je jako bieżące, a logika czasu zdarzenia umieszcza je we wcześniejszej sekwencji. Wybór wpływa na przynależność do okien czasowych, kolejność, odtwarzanie i opóźnienia, zwłaszcza gdy urządzenia bezprzewodowe ponownie łączą się z siecią lub serwer automatyzacji nadrabia zaległości po przestoju.

Dwa zegary opisują różne części jednej ścieżki zdarzenia

Czas zdarzenia dotyczy samej obserwacji: momentu naciśnięcia przycisku, wykonania odczytu lub rozpoczęcia ruchu. Czas przetwarzania dotyczy środowiska uruchomieniowego automatyzacji: momentu, w którym jego proces roboczy otrzymał i ocenił rekord. Te momenty pokrywają się tylko wtedy, gdy opóźnienia transportu, buforowania i harmonogramowania oraz błędy zegara są pomijalne.

czas zdarzenia i czas przetwarzania różnią się z powodu opóźnień sieciowych, buforowania i przetwarzania. Te składowe zmieniają się, dlatego kolejność nadejścia może różnić się od kolejności wystąpienia, nawet gdy każdy czujnik publikuje dane prawidłowo.

Systemy domowe mają jeszcze jedno utrudnienie: zegary urządzeń mogą wskazywać błędny czas albo nie być dostępne. Pole czasu zdarzenia jest przydatne tylko wtedy, gdy zegar źródłowy i znaczenie sygnatury czasowej są wiarygodne. Czas przetwarzania jest zawsze dostępny na serwerze, ale opisuje sposób dostarczenia danych, a nie fizyczną kolejność zdarzeń w pomieszczeniu.

Czas przetwarzania sprzyja natychmiastowej reakcji

Automatyzacja oparta na czasie przetwarzania ocenia rekord względem zegara serwera natychmiast po jego nadejściu. Jest to proste i szybkie w przypadku reguł takich jak alarmowanie o bieżącym obciążeniu procesora lub włączanie światła po naciśnięciu przycisku. Nie trzeba czekać na wcześniejsze komunikaty, które mogą być jeszcze w drodze.

przetwarzanie strumienia zdarzeń kładzie nacisk na reagowanie na ciągłe zdarzenia w miarę ich nadejścia, przy czym czas i kolejność mają znaczenie dla operacji stanowych. Korzyść w postaci małych opóźnień staje się kosztem poprawności, gdy opóźnione rekordy są interpretowane jako nowe warunki, a nie spóźnione informacje o wcześniejszym stanie.

Odtwarzanie uwidacznia tę różnicę. Jeśli zdarzenia z ubiegłego tygodnia są przetwarzane dzisiaj, okna oparte na czasie przetwarzania umieszczą je wokół dzisiejszego czasu, chyba że specjalna logika przywróci oryginalne sygnatury czasowe. W rezultacie odtworzona historia obecności lub zbiór danych treningowych może się zmieniać zależnie od tego, kiedy uruchomiono odtwarzanie.

Czas zdarzenia zachowuje sekwencję, ale wymaga oczekiwania na spóźnione dane

Logika czasu zdarzenia przypisuje rekordy do okien i sekwencji na podstawie zawartych w nich sygnatur czasowych wystąpienia. Zdarzenie ruchu wygenerowane przed otwarciem drzwi pozostaje wcześniejsze, nawet jeśli nadejdzie później. Dzięki temu ponowne przetwarzanie danych historycznych jest bardziej spójne, a funkcje oparte na czasie trwania lub kolejności są lepiej chronione.

przetwarzanie czasu zdarzenia wykorzystuje sygnatury czasowe, znaczniki postępu i obsługę spóźnionych danych, ponieważ silnik nie może natychmiast wiedzieć, że dotarły już wszystkie wcześniejsze zdarzenia. Dłuższe oczekiwanie zwiększa kompletność danych, ale opóźnia końcowe wyniki i dłużej utrzymuje stan.

Kompromis ten jest widoczny w automatyzacjach. Jednosekundowy limit spóźnienia może zapewnić szybką reakcję świateł, ale pominąć dane z czujnika baterii opóźnione o minutę; długi limit zapewnia dokładną analitykę, ale nie nadaje się do natychmiastowego sterowania. Wiele domów potrzebuje szybkiego działania wstępnego i późniejszej korekty, zamiast jednej polityki czasu dla każdej reguły.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Ponowne połączenia zamieniają stary stan w nowe nadejścia

Urządzenia bezprzewodowe, brokery i integracje mogą kolejkować lub przechowywać komunikaty, gdy subskrybenci są niedostępni. Po ponownym połączeniu serwer może otrzymać serię komunikatów o zbliżonych czasach przetwarzania, mimo że odpowiadające im zdarzenia obejmują minuty lub godziny. Reguły oparte na kolejności nadejścia mogą zareagować tak, jakby cała seria opisywała teraźniejszość.

Wyjaśnia to, dlaczego zachowane komunikaty mogą zmienić stan domu po ponownym uruchomieniu. Zachowany zrzut stanu, polecenie umieszczone w kolejce i nowo wygenerowane zdarzenie mają różne znaczenia, nawet jeśli korzystają z tego samego tematu i nadejdą podczas tego samego ponownego połączenia.

Same sygnatury czasowe nie rozwiązują tej niejednoznaczności. Automatyzacja musi wiedzieć, czy rekord reprezentuje stan, zmianę stanu, polecenie czy odtwarzanie. Aktualizacje stanu mogą bezpiecznie zastępować bieżącą wartość, natomiast stare polecenie „odblokuj” powinno zwykle nie przejść kontroli aktualności, zamiast zostać wykonane z opóźnieniem.

Dobieraj semantykę czasu do rezultatu automatyzacji

Wybierz czas przetwarzania, gdy natychmiastowa reakcja jest ważniejsza niż dokładne odtworzenie przeszłości, a opóźnione rekordy można bezpiecznie zignorować. Wybierz czas zdarzenia w przypadku czasów trwania, sekwencji, historii obecności, okien energetycznych, cech modeli oraz wszystkich obliczeń, które powinny dawać ten sam wynik po odtworzeniu.

kolejność czasowa staje się niewiarygodna, gdy kolejność nadejścia różni się od sygnatury czasowej przenoszonej przez zdarzenie. Testy powinny uwzględniać opóźnienia, duplikaty, serie komunikatów po ponownym uruchomieniu i rozbieżności zegarów, a następnie porównywać zarówno natychmiastowe działania, jak i skorygowaną historię.

Najlepiej często sprawdza się projekt hybrydowy: podejmuj wstępne działania na podstawie nadejścia danych, odrzucaj nieaktualne niebezpieczne polecenia, a stan analityczny aktualizuj według czasu zdarzenia. Granicę wyznaczają oczekiwania użytkownika. Światło nie powinno czekać minutami na idealną kolejność, ale raport o obecności nie powinien przepisywać wczorajszego dnia zgodnie z dzisiejszym zegarem przetwarzania.