Skrypt w domoticz do NR , Jakiego noda użyć?

Witam , staram się przeflancować soją bazę skryptów w domoticz na przepływyw NR i mam pytanie czego, jakiego noda użyć do uzyskania takiej funkcjonalności : Jeśli otwieram drzwi i lampa jest OFF włącz lampę , Jeśli lampa ON i czas od załączenia tej lampy krótszy niż 15 sek , to po zamknięciu drzwi zostaw lampę na ON . Jeśli lampa ON i czas od załączenia lampy dłuższy niż 20 sek i zamknięcie drzwi wyłącza lampę .

   if lamp.state == 'Off' and czujnik.state == 'Open' then
        lamp.switchOn()
        
    elseif czujnik.state == 'Closed' and lamp.state == 'On' 
          and lamp.lastUpdate.secondsAgo <= 15 then
              lamp.switchOn()
        
    elseif czujnik.state == 'Closed' and lamp.state == 'On'
        and lamp.lastUpdate.secondsAgo > 20 then
       lamp.switchOff()
    

Chodzi mi tylko o zależnosć czasową , jak to ugryźć ?

If mozesz zastąpić nodem switch.
And - połączeniem szeregowym nodów.
Or - równoległym.
Do zależności czasowych są nody delay i trygger.
Stan encji odczytasz curent_state.
Spróbuj na początek coś sam połączyć to się później poprawi.
Pooglądaj dowolne przykłady to sam zaskoczysz.

edit… Domyślam się, że głównie nasz problem z pomiarem czasu?
Przykładowy testowy proces - prawdopodobnie znalazł byś w palecie node-red-contrib coś do dogrania i spełniające Twoje oczekiwania. Ja jestem jednak zwolennikiem działania na natywnych nodach.


flows (30).json (2,5 KB)

Pierwszy sposób to zastosowanie noda delay jako filtra wiadomości.
Drugi to porównywanie czasu zdarzeń.


Jeśli stan encji odczytujesz z HA do każdej msg dołączana jest informacja o czasie ostatniej aktualizacji msg.payload.old_state.last_changed lub msg.payload.old_state.last_update.
Jednak operacje na taki formacie są dość uciążliwe - nie polecam.

Ja preferuje timestamp, do każdego zdarzenia (msg) dołączam “zmienną” timestamp, którą zapamiętuje po skończonej robocie w procesie jako czas odniesienia dla kolejnych zdarzeń ( w przykładzie to lasttime

funkcja “różnica” liczy odstęp pomiędzy zdarzeniami i dołącza do msg.roznica w celu np. dalszej analizy.

Dzięki za naprowadzenie będę walczył, trochę to bardziej wykonalne się wydaje :slight_smile:

Był edit patrz wyżej.
Ostatecznie mógłby Ci to zrobić ale chyba nie o to chodzi :wink:
Jeśli zaczynasz z NR to staraj się opanować operowanie na zmiennych aby Twoje procesy nie były przeciążone transferami NR<>HA ( najmniej niebieski nodów :wink: )
np. Funkcja sprawdzająca stan różnych encji - #17 przez RobinI30

To bardzo duża pomoc, dzięki wielkie . Nie chcę żebyś cokolowiek robił na gotowo , nie tędy droga . Przy okazji mam prośbę , skoro jak najmniej niebieskiego , to co można zoptymalizować w poniższym flow ?
Jest to na bazie filmu Artura tylko zagnieżdziłem dwie zmienne w jednym flow i nie wiem czy to nie będzie jakiś problem
flows oświet.+ruch.json (12,0 KB)

Tak szczegółowo nie analizowałem, kierunek jest dobry. Spróbuj się jeszcze pozbyć tych dwóch nodów current state node.
Zastąp delay triggerem. Nody delay mają tą dziwną właściwość, że każde jego wywołanie tworzy kolejny nowy obiekt. Robi się z tego sterta i po upływie czasu kolejno kończą zadanie, zaburzając zamysł działania algorytmu (częsty błąd gdy uruchamia się je częściej niż ustawiony czas). Naucz się żyć bez delay :wink:

O ile wymiana delay na trigger , nie była problemem , ustawiłem nie wysyłaj nic poczekaj (czas) i wyślij wiadomość , to już current state nie bardzo wiem jak zastąpić . Ten node przekażuje stan lampy i na podstawie tego stanu aktualizowana jest zmienna , z tym że wcześniej użyty jest przycisk chwilowy , który nie określa jednoznacznie stanu tej lampy.

…obecnie nieważne, za bardzo musiałbym się do tego przyłożyć (nie chce mi się) :wink:
Zawsze można zapamiętać rzeczywisty stan, pochodzący z event_state w zmiennej, dzieje się to tylko raz podczas zmiany. Później można korzystać ze zmiennej nieskończoną ilość razy bez potrzeby ponownego odczytu przez current.

To chyba nie na tym etapie , mam jeszcze sporo do konwersji z dzVents , więc może za jakiś czas samo wpadnie , jak to ogarnąć . Dzięki za wskazówki

Już to częściowo robisz.
Wrzucaj skrypty i jak to przerobiłeś na NR.

edit… trochę uprościłem to co wrzuciłeś wcześniej.


flows (39).json (16,9 KB)

Dokładnie jeszcze nie rozumiem celu tych przycisków ale wydaje mi się, że to przekreślone jest już niepotrzebne.

Nie mogę się pozbyć tych przycisków , jednak opiszę co robi ten flow , może wtedy będzie łatwiej. Wykryty ruch włącza lampę na określony czas w moim przypadku już o tym decyduje trigger a nie delay .
Załaczenie z przycisku manualnego na ścianie włącza lampę na stałe , aż do wyłaczenia z interfejsu , lub z tego samego przycisku . To co skreśliłeś odpowiada za : użycie przycisku i następnie status oświetlenia , odpowiednio zmienia stan zmiennej , która to “blokuje” górną część przepływu z czujnikiem ruchu.
Wrzucę to co działa już dwa dni , muszę tylko uzupełnić nody time range o czujnik lux , ale najpierw muszę go dodać do HA .
flows.json (6,6 KB)

Ale nic nie robi w procesie. Gdy lampa się włączy (od przycisku) powiadomi o tym NR przez event_state (od przełącznika) i przepisze obecny stan do zmiennej.

Wyleciało 50%. Importuj i sprawdź czy działa.
Jeśli działa to porównaj co zmieniło się w ustawieniach nodów i postaraj się zrozumieć.
flows (32).json (4,3 KB)
Funkcje z flow.set są niepotrzebne, zmienne można ustawić bezpośrednio w event_state również przy starcie flow.

Kolego @RobinI30 , naprawdę staram się zrozumieć to co robię i doceniam Twoją pomoc , jednak to co uprościłeś w całym procesie powoduje nieprawidłowe działanie już przy starcie. Dodałeś ustawienie zmiennej w events state , czyli załączenie oświetlenia wywołane ruchem z PIR , ustawia zmienną na ON , a to powoduje że polecenie wyłącz lampę nie dotrze do noda “Wyłącz” bez względu czy włączę przyciskiem na ścianie , czy naruszę PIR. Jeżeli już to musiałoby to aktualizować zmienną tylko po użyciu przycisku fizycznego, a to na moim poziomie wiedzy nie jest możliwe , jeśli nie wiemy o zmianie stanu przycisku

:+1: :smile: Ja też już zrozumiałem cóż to jest ten magiczny przycisk, Faktycznie jeśli jest to przycisk wyłącznika to w ten sposób nie będzie działać… a jednak się pobawię.

edit… odwróciłem trochę logikę. Teraz POWINNO być tak, że funkcja od PIR uruchamia się tylko gdy światło jest wcześniej wyłączone. Plus jest jeszcze taki, że polecenie wł/wył leci tylko raz. Brakuje tylko time range nie chciało mi się instalować tego czego nie używam,
flows (34).json (4,4 KB)

Ten przepływ po jest ok , nie wiem czym różni się użycie dwóch zmiennych użytych w tym przepływie, od node function , której używam w pierwotnym , ale każde uproszczenie automatyzacji to plus , więc sprawdzę jak to się zachowa po przeładowaniu systemu itd. Jeśli będzie ok to wdrażam. Dzięki kolego , to kolejna lekcja , jak można kombinować na różne sposoby :slight_smile:

Jedna jest po to aby znać faktyczny stan włącznika i nie odpytywać go bez potrzeby ( w razie zmiany sam powiadomi), druga jest po to aby “zaznaczyć”, że włączenie nastąpiło od PIR.
Może się zdarzyć, że w stanach granicznych - np. gdy odliczany jest czas ktoś “popstryka” włącznikiem może to działać dziwnie. :wink: ale nie jestem tego w stanie w głowie rozpracować.

W działaniu niczym, po prostu jeden nod mniej. Wyznaję zasadę, że proces tak działa jak wygląda i im mniej nodów zastosujesz tym łatwiej go zrozumieć i zmodyfikować.
Jest też (podobno !) ograniczenie co do ich ilości.

Za co odpowiadają te zmienne to wiem , natomiast ciekawy jestem czym się różnią od użycia funkcji ? Chodzi mi o róznicę powodującą np jakieś niepożądane użycie procka czy temu podobne. Jedno jest pewne , ten przepływ można zastoswać tylko z przyciskiem , który fizycznie jest włącznikiem lampy, mając przycisk nie zintegrowany z przekaźnikiem , już to nie zadziała. Zobaczę jeszcze jak to rozbudować o nocne oświetlenie uruchamiane z tego samego PIR ale w innym przedziale czasowym, tyle , że to wieczorem. Tym czasem jeszcze raz Dzięki
PS
Nie widziałem edycji Twojego postu .

Dodam jeszcze, że jeśli stan zapamiętasz w jednym miejscu jako global to możesz go używać we wszystkich procesach NR bez potrzeby ciągłego odczytywania.
Każdy dodatkowy nod zużywa zasoby i czas procka, na słabym sprzęcie prędzej lub później zacznie kuleć.

To napisz mi jak takie globalne zmienne “katalogujesz” , tzn skąd wiesz po pół roku, że masz taką zmienną globalną i możesz jej użyć w danym przepływie ? Tu jak narazie używamy zmiennych dotyczących konkretnego flow i to dla mnie nie stanowi problemu , natomiast jak przypadkowo nazwę sobie zmienną identycznie w jednym przepływie jak nazwana jest zmienna globalna to , sam mogę zgłupieć , jak coś zacznie dziwnie działać.
Wiem , że pokutuje przyzwyczajenie z domoticz , gdzie masz np zmienną pora dnia i można jej użyć w dowolnym skrypcie , ale tam wiem gdzie ją mam

W HA zmienne wszystkich trzech typów wraz z ich wartościami są z zakładce context (przydatne przy debugowaniu).


Polecam rozwinąć zmienną homeassistant i zobaczyś ile jest tam cennych informacji :slight_smile: