Funkcja sprawdzająca stan różnych encji

ciepło… ciepło - tylko nie cyklicznie a raz (zaznaczając ptaszek inject once), zrób to całkiem obok
To co zrobiłeś dotychczas jest OK tylko zamiast contex. użyj flow.

1 polubienie

Zrobiłem osobną funkcję w obrębie jednego flow do początkowego odczytu stanu z switch. I nie wiem co oznacza informacja wyświetlana pod nim (current_state) i raczej dlatego nie przesyła mi ich stanu.


flows (2).json (9,9 KB)

Funkcja początkowe zmienne

flow.set('kuchnia', msg.kuchnias);
flow.set('salon', msg.salons);
flow.set('pokoj', msg.pokojs);
flow.set('lazienka', msg.lazienkas);
flow.set('garaz', msg.garazs);

Funkcja główna

flow.set('kuchnia', msg.kuchnia);
let kuchnia = flow.get('kuchnia');

flow.set('salon', msg.salon);
let salon = flow.get('salon');

flow.set('pokoj', msg.pokoj);
let pokoj = flow.get('pokoj');

flow.set('lazienka', msg.lazienka);
let lazienka = flow.get('lazienka');

flow.set('garaz', msg.garaz);
let garaz = flow.get('garaz');



if (kuchnia == "on" || salon == "on" || pokoj == "on" || lazienka == "on" || garaz == "on"){
    let msg1 = { payload: "on" };
    return [msg1,null];
}else{
    let msg2 = { payload: "off" };
    return [null,msg2];
}


Raczej chyba sprawa czy poprawnie ustawiłem current_state chyba że coś nie tak z inicjatorem

Debag wypluwa takie informacje:


Wygląda jakby coś nie tak od strony wejścia current_state, inicjator nie tak ustawiony?

Inicjatory rozbij na 5 osobnych funkcji, każda dla jednego właściwego.
Błędy wynikają z zbyt wczesnego inicjowania i nie zdążyła się odbyć “synchronizacja” HA<>NR.
Jeśli klikniesz Start później masz te same błędy? Jeśli jest OK to wydłuż czas 0.1 sek do takiego przy którym nie będzie tego błędu.

1 polubienie

Zastosowałem wszystkie wskazówki i lekcje Robinl30 i wyszło mi coś takiego w NR


Działa automatyzacja zgodnie z oczekiwaniami. Mam jeszcze kilka pytań, bo być może coś jest zrobione nad wyrost i można to zredukować.
Aby zmienne zostały zaczytane wszystkie na samym początku po uruchomieniu flow, musiałem ustawić w każdym injectorze do 7s, current_state uruchamiały się już przy 6s, ale ustawiłem 7s dla bezpieczeństwa.

Zastanawiam się, czy potrzebnie zastosowałem noda change? Czy bez tego noda, osiągnał bym to samo już na poziomie current_state zmieniająć jedynie w opcjach wyjścia zapis na flow.kuchnia=entity state? Obecnie jest msg.kuchnia=entity state i dopiero nod change zamienia to na flow.kuchnia=entity state.

Co do funkcji głównej, kod obecnie wygląda tak:

let kuchnia = flow.get('kuchnia');

let salon = flow.get('salon');

let pokoj = flow.get('pokoj');

let lazienka = flow.get('lazienka');

let garaz = flow.get('garaz');

if (kuchnia == "on" || salon == "on" || pokoj == "on" || lazienka == "on" || garaz == "on"){
    let msg1 = { payload: "on" };
    return [msg1,null];
}else{
    let msg2 = { payload: "off" };
    return [null,msg2];
}

Tak skonstruowany zapis dał dopiero pozytywny efekt ale nie od razu, trochę dziwne, ale zaczął działać. Próbowałem bez dodatkowych zmiennych, czyli od razu w “IF” korzystałem z flow.kuchnia itd. ale nie działało , zwracało cały czas wynik z “ELSE” jaki stan by nie był na termostatach. Myślę, że powinno to zadziałać ale jak testowałem na początku nie działało. Muszę to sprawdzić, chyba, że się mylę co do takiego odwołania?

Ciekawy skrót, trzeba było spróbować (pewnie się nie uda ponieważ na zmiennych operujemy metodami set/get).

…pewnie gdybyś użył flow.get(‘kuchnia’) to by działało z powodu j/w…

To długofalowo nie będzie działać, brakuje zapamiętania do zmiennych po nodach evet_state.
Aktualizujesz zmienne tylko raz podczas startu nie ma aktualizacji od zdarzeń.

Zredukował bym ilość nodów "Start’',
to jest niepotrzebne

....
let msg1 = { payload: "on" };

......
let msg2 = { payload: "off" };

i wystarczy samo

....
return [msg,null];
.....
return [null,msg];

ale czepiać się nie będę :wink:

Gdy już się wystarczająco napracujesz to wrzuć plik

1 polubienie

Zostawiłem taką ilość inicjatorów “Start” z testów do ustawiania wartości początkowych zmiennych dla flow. Domyślnie zostawię jeden, który będzie aktywował current_state i myślę, że ten sam będzie jeszcze początkowo inicjował główną funkcję “Włącz piec”, aby nie czekał na zmianę stanu przez event_state do uruchomienia funkcji głównej.

Używałem flow.kuchnia i może dlatego mi to nie działało, przetestuje w “IF” z flow.get(‘kuchnia’).

Na obecną chwile, automatyzacja działa, wyłączone zostały po osiągnięciu temp dwa termostaty a piec nadal ma status “ON”, zobaczymy jak przejdą wszystkie termostaty na “OFF” czy piec będzie też “OFF”. Przetestowałem to podpinając pod wyjście funkcji noda debag i działało tak jak chciałem, dlatego użyłem od razu noda call_service aby testować na żywym organizmie. Domyślam się, że sugerujesz użycia noda change po nodach event_state, w celu zapamiętanie w zmiennych stanu po jego zmianie?

W wersji ostatecznej return też poprawie.

Oczywiście, że wrzucę plik, jak już to będzie poprawione do odpowiedniego stanu i przetestowane.

No tak… zauważ, że twoja funkcja pracuje na zapamiętanych już stanach. Event_state w chwili obecnej wyzwala tylko proces.

edit …tak się teraz zastanawiam, czy cały proces inicjalizacji nie załatwiłby ptaszek?
even
możesz to sprawdzić ? - wtedy wszystko od “on start” byłoby niepotrzebne, czysto i schludnie.

1 polubienie

Jak zmieni się status Termostatu to zmianę widzę w podglądach zmiennych na poziomie flow, czyli jeżeli tak jest to znaczy że ta zmienna istnieje i zostaje ona zmieniona już na poziomie event_state. Tak wygląda skonfigurowany nod event_state


Więc jakbym to samo zrobił na poziomie nodów inicjujących wartości początkowe zmiennych w current_state to myślę że otrzymam taki sam wynik, sprawdzę to.

Sprawdzę tę opcję “Output on Connect”, został do wyłączenia jeden termostat, jak się wyłączy to sprawdzę, nie chcę teraz ruszać aby piec mi nie świrował, bo proces rozpalania/gaszenia trochę trwa :stuck_out_tongue:

Przed deploy wyłącz on stat i sprawdz czy wszystkie zmienne utworzą się się automatycznie.

1 polubienie

Z bardzo duża pomocą Robinl30, jest raczej ostateczna wersja prostej automatyzacji wł/wył piec na podstawie stanów termostatów.


Oraz plik flow: wlwylheat.json (5,5 KB)
Tak jak doradził Robinl30, zaznaczenie opcji “Output on Connect” w nodzie event_status, wyeliminowało nody current_state oraz injectory. Dzięki temu automatyzacja opiera się na kilku nodach.
Sama funkcja “Wlacz/Wylacz Piec” posiada finalnie taki kod:

if (flow.get('kuchnia') == "on" || flow.get('salon') == "on" || flow.get('pokoj') == "on" || flow.get('lazienka') == "on" || flow.get('garaz') == "on"){
    return [msg,null];
}else{
    return [null,msg];
}

Dla mnie jest to bardzo merytoryczna lekcja na sam początek przygody z Node-RED i zachęta do tworzenia różnych automatyzacji.

:+1: Pora u siebie posprzątać :slight_smile:

Hej,

ja u siebie nie posprzątałem ale próbuję ogarnąć podobny problem :slight_smile: w związku z nakładem na bardziej ekonomiczną pracę kotła chciałbym dodać warunek że dopiero kiedy kila stref jest chłodniejszych to wtedy włącz piec. W tym momencie mam tak, że wystarczy jedno chłodne pomieszczenie aby wymusić włączenie kotła. Czy możecie doradzić jak ogarnąć aby np 3 z 5 stref uruchamiały dopiero grzanie

Utwórz zminną liczącą ilość stref na ON.
Na początku procesu ją zeruj.
Następnie połacz wszystkie encje od tetmostatów szeregowo. Za wyjściami na ON wataw funkcję zwiekszajacą zmienną o 1. Z wyjść o OFF pomijaj funkcje dodające.
Na końcu swich sprawdzającu jej watość i na tej podstawie sterujący kotłem.
Obrazka dodać nie mogę.
Jeśli chcesz zastosowac metodę @djmaly - musisz rozbić warunek na osobne sprawdzenia dla poszczegolnych stref i też zmiena licząca.
Ciekawi mnie co wyjdzie na podstawie opisu :wink:

Nie wiem czy o to dokładnie chodziło ale chyba działa :slight_smile: funkcja zlicza strefy włączone a druga funkcja wyłączone.

ogrzewanie.json (18,2 KB)

Byłoby parę uwag :wink: …trochę przekombinowałeś. Działać… działa ale gdy się uczysz to utrwalasz błędne nawyki.
W opisie celowałem w coś takiego


flows (44).json (6,8 KB)
Jednak po przemyśleniu - w pewnych warunkach nie działałoby to poprawnie (kiedy? :stuck_out_tongue_closed_eyes:) - jako przykład jest OK

Ja bym w tym Twoim procesie dodatkowo sprawdzał stan pieca, tak jak jest teraz, to co 5 min niepotrzebnie idzie polecenie albo on, albo off . Skoro dobre nawyki, to myślę, że warto.

1 polubienie