Mam w głowie zamysł ale nie wiem jak to wykonać.
Chcę aby przy rozłożonej markizie włączało się oświetlenie tarasu ale w określonych godzinach oraz przy złożonej markizie nie uwzględniało w ogóle harmonogramu.
Dodałem encję markizy która wypluwa informacje closing/opening, dodałem węzeł Light Scheduler ale nie działa tak jak chcę, działa tylko scheduler bez uwzględniania otwarcia markizy.
Pomożecie?
flows (3).json (3,5 KB)
Spróbuj za “Stanem markizy” użyć switch i jak open to daj “Harmonogram” a jak close to omiń “Harmonogram”.
Nie wiem jak działa ten harmonogram, nie używam tego noda (skoro miał stan OFF jak na zdjęciu to nie powinien puścic dalej a mimo to wykonało się switch turn on ?), ale jeśli “Stan markizy” daje stan open albo close to dając za nim switch rozdzielasz te stany jak chcesz i dalej budujesz flow bazując na tym co się ma dalej zadziać .
PS. A tak swoją drogą to jeśli stan markizy to close to Gniado ogrodowe ma się wyłączyć ? A skąd wiadomo, że jest zapalone ?
Nie wiem czy widziałeś w ogóle opis w jaki sposób kontrolować ten harmonogram.
https://faulty.cloud/projects/node-red-contrib-light-scheduler
Aby zmienić sposób działania trzeba wysłać w payload odpowiedni wpis sterujący inaczej będzie działał w/g ustawionego czasu niezależnie.
Tak widziałem ale w node red jestem na tyle zielony, że nie wiem jak na wyjściu “stan markizy” spowodować aby podawał odpowiedni wpis sterujący (on/off) zrozumiały dla harmonogramu
To powinno załatwić sprawę
@MariuszAK przetestowałem twój flow i jest prawie ok, ale gdy markiza jest rozłożona za dnia i przyjdzie wieczór to światło się samo nie zapali, trzeba zamknąć i ponownie otworzyć aby światło zaświeciło. W harmonogramie była taka opcja, że odpytywało co minutę o stan harmonogramu a w twojej propozycji nie wiem jak to rozwiązać. Jest na to jakieś wyjście? bo wtedy będzie rozwiązanie kompletne i na bazie czegoś takiego będę mógł zastosować do wielu innych rozwiązań. Z góry dziękuję za pomoc.
"
Przy takim podejściu będzie mały dyskomfort, zależy jak się wstrzelisz w interwał, ale praktycznie zawsze oświetlenie włączy się z opóźnieniem.
Myślę, że lepiej zostawić event_state i równolegle do niego dać inject
Dajcie znać kiedy się poddacie 
Jak narazie idzie Wam dobrze 
Dzięki bardzo za wszelką pomoc. Działa super, dużo się nauczyłem i stworzyłem na podstawie jednej automatyzacji inne .
Mimo, że autor zaznaczył już rozwiązanie, podziel się swoją koncepcją, skoro uważasz, że to nierówna walka z naszej strony 
Może znowu się czegoś od Ciebie nauczę.
,ponieważ myślicie liniowo 
Mamy dwie niezależne zmienne wejściowe (żaluzja i harmonogram),których zmiana powinna natychmiast uruchamiać proces.
Ostatnie stany powinny być zapamiętane aby finalnie w przypadku dowolnej zmiany możliwe było wykonanie prostego if(żaluzja_otwarta && jest właściwy czas)
… bez ciągłego odpytywania i opóźnień.
Rys.poglądowy
Zapamiętywanie stanów masz już przećwiczone. Coś dodać?
Wszystko fajnie, ale wyjaśnij autorowi, który dopiero zaczyna przygodę z NR jak zrobić takiego warunkowego switcha w nodzie funkcji.
Co do ciągłego odpytywania, to lekka przesada, raptem dwie godziny w moim przykładzie, a można to sobie jescze ograniczyć. Jeśli w ogóle można tu mówić o odpytywaniu, Inject robi to samo co ten harmonogram, tylko nie raz, a np 10, ustawiając odpowiedni interwał.
I na koniec, nie korzystam z light-scheduler, wiec nie zaskoczyło mnie Twoje rozwiązanie, ale dzięki.
PS
Skoro korzystasz z lego harmonogramu, to napisz proszę jak zachowa się proces gdy przypadkowo o godzinie wyznaczonej do załączenia zrobisz akurat restart ? Bo skoro nie odpytuje w jakimś interwale, to jak to się stanie że drugi raz wyśle ON ?
Nie korzystam - dostosowałem do autora. Osobiście to użyłbym schedulera z HA (HACS) i “machał” pomocnikiem switch, a w procesie NR sprawdzał stan obu encji (żaluzja i pomocnik).
Ponieważ dla zmiany nastaw nie musiałbym odpalać NR i robił to z poziomu HA.
To już przerabialiśmy … w nodzie evets: state jest taki ptaszek, który powoduje że w momencie połączenia NR z HA generowane jest jednorazowe zdarzenie - właśnie na taki przypadek.
Ostatni wpis był dedykowany “starym wyjadaczom”
Dlatego do końca siedziałem cicho, aby się pomęczył i czegoś nauczył ,
poznał złe i dobre strony różnych rozwiązań.
@isom1266 …mam nadzieję, że nie odbierasz moich uwag jako jakiś atak?
Jestem daleki od takich pomysłów, Facet pomogłeś mi bardzo dużo i mam nadzieję na więcej.
Nie miałem na myśli event_state, myślałem, że wiesz o co pytam. Co zrobi “harmonogram” , ale ok nie korzystasz, to nie było pytania, mogę się domyślać, tylko po co ?
A ja osobiście wcale bym nie użył harmonogramu, status + warunki za oknem - ciemno
Trafię na zaćmienie słońca i będę musiał siedzieć w ciemności
Zrobię imprezę i HA o 23:59 wygoni mi gości, bo zgasi oświetlenie, itd.
Pozdrawiam
Po to mamy Sceny w HA, włączamy Scenę IMPREZA i potrzebne warunki ustawiamy na tak/nie, lub zwykły input_boolean blokujący niepotrzebnie zdarzenia
Jak lubisz sobie klikać, to masz rację , ja nie lubię pamiętać o kliknięciu Impreza w domu , czy na tarasie, czy jeszcze inna okoliczność. Wracam czasem ze znajomymi i kończymy pięknie rozpoczęty dzień u mnie, kto by wtedy pamiętał o klikaniu.
