Warunki w SUPLA Scripts - pomysły

[Arghatell]

To w warunku, zamiast ">50" wstaw "50". Wtedy będziesz miał tylko jedno powiadomienie.

Przecież tak się nie da, jest błąd parsowania warunku wtedy.

{{state(16140).temperature 20}} (ERROR: Unexpected token "number" of value "20" ("end of print statement" expected) in "__string_template__02390d395cb3604098a3e73b8b4a579934a1d772cb9085ebea01924b2383afa1" at line 1.)

Grrr, to wpisz tak:

{{not state(16140).temperature %20}}

[Arghatell]

Gdy mam jeden kanał w warunku wyzwalacza - to dostanę jedno powiadomienie. Gdy mam więcej kanałów, to dostaję więcej najczęściej tyle ile jest wpisanych kanałów. Jestem na 99% przekonany, że jest to błąd po stronie SUPLA SCRIPTS lub innego skryptu który przetwarza wyzwalacz w oparciu o dane pozyskiwane z urządzeń nadawczych z suplą (choć scripts chyba sięga za pomocą webhooków do danych supla cloud?).

Nie i jeszcze raz NIE. Pole wyzwalacza nie traktuj jako pola warunku stricte. Jeśli wciąż kombinujesz niewłaściwie/nielogicznie, czyli w polu wyzwalacza wstawiasz kilka wyzwalaczy, licząc że wykona się to wtedy kiedy sobie "wymyślisz" to właśnie po to masz osobne pole warunku aby tam wpisać warunek, który tylko w pełnej i jedynej "koniunkcji" zadziała jak "zatrzask" dając tylko jedno, właściwe powiadomienie. Gdyby było inaczej (czyli jak cały czas błędnie kombinujesz) osobne pole warunku nie byłoby potrzebne Tak generalnie to nie wiem jak zabezpieczyć skrypty aby były (sorry za wyrażenie) idiotoodporne...ale można dać analogię, że wiertarką nie wbijamy gwoździ i nie piszemy do producenta że coś jest "niehalo" bo się psuje Wiertarka nie służy do tego

[mabakay]

A jesteś pewien że temperatura nie "plywa" I scena wykonuje się np. 14:53:10 i 14:53:50 ??

Ha! Wstawię czas do "odpowiedź" i zobaczę!

Dodałem timestamp - daje sekundową rozdzielczość.

Grrr, to wpisz tak:

{{not state(16140).temperature %20}}

Że co? Zwracamy modulo z temperatury, a potem odwracamy wartość logiczną? Czyli jak temperatura będzie 42, to modulo zwróci 2, not dla "0" zwraca "1", a dla każdej innej wartości większej od zera zwróci pustą wartość "". Jeżeli to wkleję w warunek wyzwolenia, to dopóki temperatura nie będzie wielokrotnością 20, to nigdy się scena nie wyzwoli. O to Ci chodziło?

[Arghatell]

Grrr, to wpisz tak:

{{not state(16140).temperature %20}}

Że co? Zwracamy modulo z temperatury, a potem odwracamy wartość logiczną? Czyli jak temperatura będzie 42, to modulo zwróci 2, not dla "0" zwraca "1", a dla każdej innej wartości większej od zera zwróci pustą wartość "". Jeżeli to wkleję w warunek wyzwolenia, to dopóki temperatura nie będzie wielokrotnością 20, to nigdy się scena nie wyzwoli. O to Ci chodziło?

Matko boska, rence opadajo :/
Masz to wpisać w pole warunku a nie w pole wyzwalacza. Jeszcze nie ogarnąłeś do czego służy pole wyzwalacza? Sens jest taki, że jeśli cokolwiek wpiszesz w pole wyzwalacza to TEN wpis w pole WARUNKU, który podałem, zadziała TYLKO w przypadku, jeśli temperatura będzie 20, obojętnie od tego, ile wyzwalaczy innych z innych kanałów masz wpisane w pole wyzwalacza. Poprzednio wpisując "<20" logiką było, że od 20 do nieskończoności masz wyzwalanie akcji i każdy inny wyzwalacz to uruchamia. Teraz, po wpisie {{not state(16140).temperature %20}} będziesz miał TYLKO przy 20 jeden raz wyzwoloną akcję

[Arghatell]

Grrr, to wpisz tak:

{{not state(16140).temperature %20}}

Że co? Zwracamy modulo z temperatury, a potem odwracamy wartość logiczną? Czyli jak temperatura będzie 42, to modulo zwróci 2, not dla "0" zwraca "1", a dla każdej innej wartości większej od zera zwróci pustą wartość "". Jeżeli to wkleję w warunek wyzwolenia, to dopóki temperatura nie będzie wielokrotnością 20, to nigdy się scena nie wyzwoli. O to Ci chodziło?

Matko boska, rence opadajo :/
Masz to wpisać w pole warunku a nie w pole wyzwalacza. Jeszcze nie ogarnąłeś do czego służy pole wyzwalacza? Sens jest taki, że jeśli cokolwiek wpiszesz w pole wyzwalacza to TEN wpis w pole WARUNKU, który podałem, zadziała TYLKO w przypadku, jeśli temperatura będzie 20, obojętnie od tego, ile wyzwalaczy innych z innych kanałów masz wpisane w pole wyzwalacza. Poprzednio wpisując "<20" logiką było, że od 20 do nieskończoności masz wyzwalanie akcji i każdy inny wyzwalacz to uruchamia. Teraz, po wpisie {{not state(16140).temperature %20}} będziesz miał TYLKO przy 20 jeden raz wyzwoloną akcję

Miałem chwilę i sprawdziłem u siebie. Niestety nie mam teraz pod ręką wielu wyzwalaczy, więc skorzystałem z wielu wyzwoleń jednego kanału termometru od CO stosując "or".

POLE WYZWALCZ:

{{state(12345).temperature > 47 or state(12345).temperature > 52 or state(12345).temperature > 53}}

POLE WARUNEK
{{state(12345).connected and not state(12345).temperature % 47 }}

Po takim zapisie sceny, miałem...2 wyzwolenia. Jedno wyzwolenie kiedy temperatura osiągnęła 47 i drugie, kiedy spadając osiągnęła 47.

Zmieniłem POLE WARUNEK na takie:

{{state(12345).connected and not state(12345).temperature % 47 and state(12345).temperature > 47}}

...i mam tylko JEDNO wyzwolenie sceny, kiedy temperatura wzrastając osiągnie 47 pomimo kilku wyzwalaczy, które działają.

[mabakay]

Nie i jeszcze raz NIE. Pole wyzwalacza nie traktuj jako pola warunku stricte.

Wielokrotnie podnosisz kwestię, do której ja nie zgłaszam zastrzeżeń. Ale muszę Cię poprawić.

Kiedy urządzenie nadawcze (urządzenie z zainstalowaną suplą) wysyła odczytaną z czujnika wartość, trafia ona do supla cloud. Tam wywoływane jest zapytanie (webhook) do supla scripts do metody postAction (https://github.com/fracz/supla-scripts/ ... er.php#L21).

W zapytaniu przesłane są m.in. takie dane jak identyfikator użytkownika, powiązany z nim kanał i nowa zarejestrowana wartość.

Code: Select all

//        $parsedBody = ['userShortUniqueId' => 'dc85740d-cb27-405b-9da3-e8be5c71ae5b', 'channelId' => 123,
//            'state' => ['on' => true, 'connected' => true], 'timestamp' => time(),
//            'channelFunction' => 'LIGHTSWITCH', 'accessToken' => 'XXX'];
//        $parsedBody = ['userShortUniqueId' => 'dc85740d-cb27-405b-9da3-e8be5c71ae5b', 'channelId' => 123,
//            'triggered_actions' => ['HOLD'], 'timestamp' => time(),
//            'channelFunction' => 'ACTION_TRIGGER', 'accessToken' => 'XXX'];

Odczytane dane (w postaci użytkownika i kanału) po walidacji przekazywane są do metody triggerScenesExecution (https://github.com/fracz/supla-scripts/ ... er.php#L64).



Tam zostają pobrane wszystkie sceny które należą do użytkownika oraz w wyzwalaczu zawierają podany kanał => $scenes.
Następnie iterator wykonuje sekwencyjnie operacje na każdej z tych scene, czyli:

Tworzy FeedbackInterpolator który służy do parsowania wyrażeń. Przeprowadza ewaluacje wyrażenia zapisanego w wyzwalaczu
$feedback = $feedbackInterpolator->interpolate($scene->trigger);.

Wynik interpretuje jako wartość logiczną i zapisuje do zmiennej $triggerState = boolval($feedback);.

Porównuje z ostatnim zapisanym logicznym stanem wyzwala sceny
if ($triggerState != $scene->lastTriggerState) {

I jeżeli się różni, to wykonuje scenę (teraz dopiero sprawdza opcjonalny warunek wykonania), przypisuje nowy stan logiczny wyzwalacza i zapisuje scenę do bazy.
$scene->log('Wykryto zmianę warunku wyzwolenia sceny - wykonuję.');
$scene->lastTriggerState = $triggerState;
$sceneExecutor->executeWithFeedback($scene);
$scene->save();

Powyżej pokazałem, że pole wyzwalacza przeprowadza ewaluacje złożenia warunków jako całość i działa analogicznie do termostatu (wyzwala raz gdy wartość logiczna zmieni wartość).

A teraz dlaczego nie tylko można dostać (nieprawidłowo) wiele notyfikacji, jak po prostu wielokrotnie wykonać każdą akcję przypisaną do sceny.

Webhook wywoływany przez supla cloud działa asynchronicznie, dlatego metoda postAction może zostać wywołana wielokrotnie "w tym samym czasie". Nie posiada ona żadnego zabezpieczenia gwarantującego jakąś kolejność przetwarzania np. po czasie nadejścia aktualizacji z urządzenia nadawczego. Analogicznie przekłada się to na wywoływaną dalej metodę triggerScenesExecution.

Gdy użyjemy w wyzwalaczu sceny więcej niż jednego kanału, a aktualizacje z tych kanałów nadejdą "w tym samym czasie", oba zapytania rozpoczną proces obsłużenia. Dla obu zostanie pobrany z bazy ten sam rekord sceny, który będzie zawierał ten sam stan logiczny wyzwolenia lastTriggerState. Jeżeli zmiana wartości dowolnego z tych kanałów spowodowała by zmianę tego stanu, to w tym momencie nie ma znaczenia który zostanie obsłużony pierwszy. Zapisze on stan w bazie z nowym stanem logicznym wyzwalacza sceny, ale w tym czasie pozostałe kanały mają już w pamięci poprzedni stan i one również wywołają reakcje przypisane do sceny, co objawi się np. wielokrotną notyfikacją.

Zgłosiłem zagadnienie na githubie - https://github.com/fracz/supla-scripts/issues/77.

[Arghatell]

Nie i jeszcze raz NIE. Pole wyzwalacza nie traktuj jako pola warunku stricte.

Wielokrotnie podnosisz kwestię, do której ja nie zgłaszam zastrzeżeń. Ale muszę Cię poprawić.


Powyżej pokazałem, że pole wyzwalacza przeprowadza ewaluacje złożenia warunków jako całość i działa analogicznie do termostatu (wyzwala raz gdy wartość logiczna zmieni wartość).

A teraz dlaczego nie tylko można dostać (nieprawidłowo) wiele notyfikacji, jak po prostu wielokrotnie wykonać każdą akcję przypisaną do sceny.

Webhook wywoływany przez supla cloud działa asynchronicznie, dlatego metoda postAction może zostać wywołana wielokrotnie "w tym samym czasie". Nie posiada ona żadnego zabezpieczenia gwarantującego jakąś kolejność przetwarzania np. po czasie nadejścia aktualizacji z urządzenia nadawczego. Analogicznie przekłada się to na wywoływaną dalej metodę triggerScenesExecution.

Gdy użyjemy w wyzwalaczu sceny więcej niż jednego kanału, a aktualizacje z tych kanałów nadejdą "w tym samym czasie", oba zapytania rozpoczną proces obsłużenia. Dla obu zostanie pobrany z bazy ten sam rekord sceny, który będzie zawierał ten sam stan logiczny wyzwolenia lastTriggerState. Jeżeli zmiana wartości dowolnego z tych kanałów spowodowała by zmianę tego stanu, to w tym momencie nie ma znaczenia który zostanie obsłużony pierwszy. Zapisze on stan w bazie z nowym stanem logicznym wyzwalacza sceny, ale w tym czasie pozostałe kanały mają już w pamięci poprzedni stan i one również wywołają reakcje przypisane do sceny, co objawi się np. wielokrotną notyfikacją.

To może z innej beczki, żeby było jaśniej. Osobiście nie uznaję tego za błąd a wręcz odwrotnie za "future" dlaczego?
Posłużę się analogią:

Z prostej przyczyny, jak próba wciśnięcia do małego Fiata 10 osób. Przeznaczenie było na 4 osoby. Są tacy co próbują i mają zastrzeżenia do producenta, że ciężko i nie mogą sobie poradzić i jest to błąd konstrukcyjny. Wszystko ok do momentu, kiedy producent Fiata nie da im żadnej możliwości przewiezienia 10 osób za "jednym razem" jeśli jednak za free, udostępni więcej samochodów to już OK...ale zwyczajnie nie o to chodzi. W założeniu kierowcy, kiedy chce przewieźć 10 osób to bierze autobus...i nawet odpowiedź, że nie do tego służy mały fiat, nie zadowala użytkownika i drąży temat. Tutaj jest inaczej. Nie ma żadnego problemu z utworzeniem wielu scen i wielu zależności, żeby osiągnąć efekt bez żadnych opóźnień i konfliktów. Generalnie jest to dla mnie "czepianiem się" z nutą narcyzmu, bo jeśli ktoś inny będzie chciał skorzystać z podanego narzędzia inaczej niż Ty, to on będzie miał problem bo nie będzie mógł w "wersji" poprawionej. Jak dotąd nie podałeś żadnego argumentu dlaczego uparcie chcesz tworzyć kilka wyzwalaczy w jednym ciągu, nawet wtedy, jeśli warunkowane działają w tym samym czasie. Tak się po prostu nie robi, czyli nie jest to właściwe Nie twierdzę, że miałem kiedyś podobny problem, bo miałem ale już dawno "przebudowałem" sobie łeb, że to ja jestem dziwnie uparty, zupełnie bez sensu i rozpisałem sobie wiele założeń na dwie lub wiecej scen i co ciekawe, odkryłem jeszcze więcej niż w próbie zapisania sobie wszystkiego w jednej scenie.

Zgłosiłem zagadnienie na githubie - https://github.com/fracz/supla-scripts/issues/77.

Jak dla mnie, nadal jest wszystko OK. Po prostu, nie używam skryptów w taki sposób, żeby mieć z nimi problem i kombinować, że ktoś mi ten problem rozwiąże lub jest to błędem. Robię co chcę bez żadnego problemu a ilość scen mnie nie przeraża, tym bardziej, że jeśli napiszę dość złożony ciąg logiczny scen i uzależnień, to w zasadzie go nie modyfikuję, jeśli działa poprawnie, chyba że stwierdzę potrzebę innych wartości ale nie ma to żadnego wpływu na wykonany poprawnie schemat.

[klew]

Obawiam się, że ciężko będzie o jakieś poprawki w skryptach, bo to projekt powoli zastępowany przez rozwiązania, które są dostępne bezpośrednio w Supla Cloud.

Oczywiście, takich warunków aktualnie nie zbudujesz w Supli bez skryptów.

Także lepiej poszukać jakiegoś rozwiązania, które objedzie ten problem. Przykładowo - jeśli ta scena odpala jakiś przekaźnik, to można ustawić powiadomienie na zmianę stanu przekaźnika - wtedy nawet 10x "włącznie" tego samego przekaźnika, wygeneruję tylko jedno powiadomienie, bo stan 10x włączanego przekaźnika zmienia się tylko raz.

Pewnie można to jeszcze jakoś inaczje rozwiązać, ale musiałbyś napisać coś więcej o problemie, który próbujesz tutaj zautomatyzować.

[YoMan]

Pomimo tego że u mnie problemu nie da się zduplikowac to taka wskazówka dla @makabay i innych (już kiedyś pisałem): skrypty nie są idealne ... ba ... daleko im do tego ale nie ma już nad nimi pracy, autor dołączył do teamu supli I tam powoli pojawiają się te same lub podobne rozwiązania. Więc korzystamy z tego co jest. A jest tak:
Wyzwalanie w oparciu o stan kanału: podajemy proste zdarzenie, w przytoczonym przypadku przekroczenie założonej różnicy temperatur. Inne rzeczy dodajemy w warunku i tak to śmiga.

Gdy użyjemy w wyzwalaczu sceny więcej niż jednego kanału, a aktualizacje z tych kanałów nadejdą "w tym samym czasie", oba zapytania rozpoczną proces obsłużenia. Dla obu zostanie pobrany z bazy ten sam rekord sceny, który będzie zawierał ten sam stan logiczny wyzwolenia lastTriggerState. Jeżeli zmiana wartości dowolnego z tych kanałów spowodowała by zmianę tego stanu, to w tym momencie nie ma znaczenia który zostanie obsłużony pierwszy. Zapisze on stan w bazie z nowym stanem logicznym wyzwalacza sceny, ale w tym czasie pozostałe kanały mają już w pamięci poprzedni stan i one również wywołają reakcje przypisane do sceny, co objawi się np. wielokrotną notyfikacją.

Z całym szacunkiem dla Twojej wiedzy ... ale to się nie spina w sensie mojego user experience. Musiałbym mieć inna wersje skryptów skoro u mnie tak się nie zachowuję a mam tą samą (publiczna).
Juz kilka razy mnie skrypty zaskoczyły dziwna reakcja na np. dodatkowy nawias lub jego brak ... może tu problem?

[Arghatell]

Z całym szacunkiem dla Twojej wiedzy ... ale to się nie spina w sensie mojego user experience. Musiałbym mieć inna wersje skryptów skoro u mnie tak się nie zachowuję a mam tą samą (publiczna).
Juz kilka razy mnie skrypty zaskoczyły dziwna reakcja na np. dodatkowy nawias lub jego brak ... może tu problem?

Bo u Ciebie w wyzwalaczu jest jeden wyzwalacz a "mabakay" wprowadził drugi wyzwalacz. Na koniec skopiował całe wyrażenie do pola warunku. U Ciebie jest inaczej, bo w polu warunku podajesz dwa warunki a w polu wyzwalacza masz jeden wyzwalacz. Nie wiem tylko, który z wyzwalaczy u "mabakay" robi problem. Zapewne da się dopisać dodatkowy stan do pola z dodatkowym warunkiem, żeby "nie klikało" Jak słusznie napisał "klew", w polu warunku należy wstawić stan odpowiedzialny w sposób przeciwny. U siebie mam kilka takich scen, żeby właśnie coś się nie wykonało, jeśli stan jest "właściwy" tym bardziej, jeśli wyzwalaczem jest timer. Chyba bym zwariował od powiadomień