Nowa funkcjonalność - lokalne akcje i warunkowanie [bramka ZigBee]

[mmiikk]

Nie jestem pewny, czy do końca rozumiem ten pomysł - obecnie możesz skopiować stan jednego kanału na drugi przy użyciu zdarzeń ON_TURN_ON/ON_TURN_OFF i akcji TURN_ON/TURN_OFF (SET/CLEAR). Na czym miałoby polegać to kopiowanie, o którym piszesz?

Identycznie jak w reakcjach cloud,

przykład
mamy 3 kanały


[1] ma stan akurat ON lub OFF nieważne ważne ze w tej chwili jest załóżmy ON i nie zmienia się na razie bo żaden sposób nie zalezy od [2] ani [3], po prostu taki stan w nim obecnie jest

[2] ma zdarzenie on_turn_on
robi na [3] KOPIUJ FROM [1]

tym samym trójka dostaje taki stan jaki ma w tej chwili jedynka bez żadnej zmiany na jedynce

W bramce jest już namiastka takiej funkcjonalności:
- jeżeli jedynka jest przekaźnikiem (ZigBee, RR albo VR), to możesz ustawić następujące reakcje:

[1] ON_TURN_ON -> [3] TURN_ON,
[1] ON_TURN_OFF -> [3] TURN_OFF,

wtedy dla [2] ustawiasz akcję:
[2] ON_TURN_ON -> [1] RESEND_RELAY_STATE

i stan [3] robi się identyczny z [1].

Dopisałem za późno do tamtego posta
Od akcji z bramkami różni to:
"Ponadto, teraz jakakolwiek zmiana na [1] nie jest propagowana na [3] chyba ze znów odpali się akcja z [2] powyżej z kopiowaniem, więc [1] ,moze sie w miedzyczasie zmieniac i nie wplywa to na stan [3]

[vajera]

Dopisałem za późno do tamtego posta
Od akcji z bramkami różni to:
"Ponadto, teraz jakakolwiek zmiana na [1] nie jest propagowana na [3] chyba ze znów odpali się akcja z [2] powyżej z kopiowaniem, więc [1] ,moze sie w miedzyczasie zmieniac i nie wplywa to na stan [3]

W wersji 1.5.14-16/04/26 doszły dwa nowe zdarzenia i dwie nowe akcje - aktualnie działają one tylko z przekaźnikami (ZigBee, RR i VR), ale nic nie stoi na przeszkodzie, żeby dodać je np. do VirtualBinary:

- akcja COPY RELAY ON STATE - w odpowiedzi na tę akcję kanał docelowy wygeneruje zdarzenie ON COPY ON STATE wtedy i tylko wtedy gdy jest stan = ON, w przeciwnym wypadku nie wygeneruje żadnego zdarzenia,

- akcja COPY RELAY OFF STATE - w odpowiedzi na tę akcję kanał docelowy wygenruje zdarzenie ON COPY OFF STATE wtedy i tylko wtedy gdy jest stan = OFF, w przeciwnym wypadku nie wygeneruje żadnego zdarzenia,
- zdarzenie ON COPY ON STATE,
- zdarzenie ON COPY OFF STATE.

Pozwolę sobie wyjaśnić ich działanie na przykładzie:

- dodajemy 3 wirtualne przekaźniki SOURCE, DESTINATION, COPY,
- tworzymy następujące akcje:

Event: {ON COPY ON STATE}
from source channel: [SOURCE]

Action: {TURN ON}
on destination channel: [DESTINATION]


Event: {ON COPY OFF STATE}
from source channel: [SOURCE]

Action: {TURN OFF}
on destination channel: [DESTINATION]


Event: {ON TURN ON}
from source channel: [COPY]

Action: {COPY RELAY ON STATE}
on destination channel: [SOURCE]

Event: {ON TURN ON}
from source channel: [COPY]

Action: {COPY RELAY OFF STATE}
on destination channel: [SOURCE]

Kanały SOURCE i DESTINATION mogą być włączane i wyłączane niezależnie od siebie i stan jednego nie wpływa na drugi kanał.
Włączenie przekaźnika COPY (zdarzenie ON_TURN_ON) generuje dwie akcje, który efektem jest skopiowanie aktualnego stanu przekaźnika SOURCE na DESTINATION.

Odpowiem z góry na pytanie, dlaczego zrobiłem oddzielną akcję dla kopiowania stanu ON i OFF - bo założyłem, że jeżeli zrobię wspólną to prędzej czy później ktoś zapyta o możliwość kopiowania tylko jednego stanu

[zzrr]

@vajera... no to teraz pojechałeś grubo Przeczytałem objaśnienie trzy razy i nie mogę odnaleźć różnicy z dotychczasową akcją turn on, turn Off. Chyba muszę do tego podejść czwarty raz ale już w ciszy i spokoju. Na razie przeczytałem na telefonie w ferworze panującym w pracy

[vajera]

@vajera... no to teraz pojechałeś grubo Przeczytałem objaśnienie trzy razy i nie mogę odnaleźć różnicy z dotychczasową akcją turn on, turn Off. Chyba muszę do tego podejść czwarty raz ale już w ciszy i spokoju. Na razie przeczytałem na telefonie w ferworze panującym w pracy

Jeżeli powiążesz kanał SOURCE i DESTINATION zdarzeniami ON_TURN_ON/ON_TURN_OFF i akcjami TURN_ON/TURN_OFF, to każda zmiana stanu SOURCE zmieni DESTINATION - czyli nie będzie możliwa sytuacja, w której SOURCE == OFF a DESTINATION == ON.
W przypadku tych akcji SOURCE i DESTINATION mogą przyjmować różne stany i dopiero, gdy na SOURCE zadziałają akcje COPY ON STATE i COPY OFF STATE, to ten kanał skopiuje swój stan na DESTINATION.

[zzrr]

@vajera... no to teraz pojechałeś grubo Przeczytałem objaśnienie trzy razy i nie mogę odnaleźć różnicy z dotychczasową akcją turn on, turn Off. Chyba muszę do tego podejść czwarty raz ale już w ciszy i spokoju. Na razie przeczytałem na telefonie w ferworze panującym w pracy

Jeżeli powiążesz kanał SOURCE i DESTINATION zdarzeniami ON_TURN_ON/ON_TURN_OFF i akcjami TURN_ON/TURN_OFF, to każda zmiana stanu SOURCE zmieni DESTINATION - czyli nie będzie możliwa sytuacja, w której SOURCE == OFF a DESTINATION == ON.
W przypadku tych akcji SOURCE i DESTINATION mogą przyjmować różne stany i dopiero, gdy na SOURCE zadziałają akcje COPY ON STATE i COPY OFF STATE, to ten kanał skopiuje swój stan na DESTINATION.

Ok.Przeanalizowałem dodatkowo czwarty raz Wcześniej z opisu jakoś nie wybił mi się ważny element dotyczący tego że to kopiowanie wyzwala trzeci element w logice. O to chodzi. Tak?

[vajera]

Ok.Przeanalizowałem dodatkowo czwarty raz Wcześniej z opisu jakoś nie wybił mi się ważny element dotyczący tego że to kopiowanie wyzwala trzeci element w logice. O to chodzi. Tak?

Mniej więcej - kopiowanie ma miejsce jedynie w odpowiedzi na akcję z innego źródła (przekaźnika, bramki logicznej, czujnika itp.).

[mmiikk]

Dopisałem za późno do tamtego posta
Od akcji z bramkami różni to:
"Ponadto, teraz jakakolwiek zmiana na [1] nie jest propagowana na [3] chyba ze znów odpali się akcja z [2] powyżej z kopiowaniem, więc [1] ,moze sie w miedzyczasie zmieniac i nie wplywa to na stan [3]

W wersji 1.5.14-16/04/26 doszły dwa nowe zdarzenia i dwie nowe akcje - aktualnie działają one tylko z przekaźnikami (ZigBee, RR i VR), ale nic nie stoi na przeszkodzie, żeby dodać je np. do VirtualBinary:

- akcja COPY RELAY ON STATE - w odpowiedzi na tę akcję kanał docelowy wygeneruje zdarzenie ON COPY ON STATE wtedy i tylko wtedy gdy jest stan = ON, w przeciwnym wypadku nie wygeneruje żadnego zdarzenia,

- akcja COPY RELAY OFF STATE - w odpowiedzi na tę akcję kanał docelowy wygenruje zdarzenie ON COPY OFF STATE wtedy i tylko wtedy gdy jest stan = OFF, w przeciwnym wypadku nie wygeneruje żadnego zdarzenia,
- zdarzenie ON COPY ON STATE,
- zdarzenie ON COPY OFF STATE.

Pozwolę sobie wyjaśnić ich działanie na przykładzie:

- dodajemy 3 wirtualne przekaźniki SOURCE, DESTINATION, COPY,
- tworzymy następujące akcje:

Event: {ON COPY ON STATE}
from source channel: [SOURCE]

Action: {TURN ON}
on destination channel: [DESTINATION]


Event: {ON COPY OFF STATE}
from source channel: [SOURCE]

Action: {TURN OFF}
on destination channel: [DESTINATION]


Event: {ON TURN ON}
from source channel: [COPY]

Action: {COPY RELAY ON STATE}
on destination channel: [SOURCE]

Event: {ON TURN ON}
from source channel: [COPY]

Action: {COPY RELAY OFF STATE}
on destination channel: [SOURCE]

Kanały SOURCE i DESTINATION mogą być włączane i wyłączane niezależnie od siebie i stan jednego nie wpływa na drugi kanał.
Włączenie przekaźnika COPY (zdarzenie ON_TURN_ON) generuje dwie akcje, który efektem jest skopiowanie aktualnego stanu przekaźnika SOURCE na DESTINATION.

Odpowiem z góry na pytanie, dlaczego zrobiłem oddzielną akcję dla kopiowania stanu ON i OFF - bo założyłem, że jeżeli zrobię wspólną to prędzej czy później ktoś zapyta o możliwość kopiowania tylko jednego stanu

WOW, szybki jesteś, w weekend będę testował

[mmiikk]

Ok.Przeanalizowałem dodatkowo czwarty raz Wcześniej z opisu jakoś nie wybił mi się ważny element dotyczący tego że to kopiowanie wyzwala trzeci element w logice. O to chodzi. Tak?

Mniej więcej - kopiowanie ma miejsce jedynie w odpowiedzi na akcję z innego źródła (przekaźnika, bramki logicznej, czujnika itp.).

Nie wytrzymałem do weekendu napisałem akcje do światła WC w notatniku i chyba jeśli dobrze to rozumiem ilosc akcji bedzie mniejsza o połowe aby osiagnac ten sam cel, w dodatku całkowicie niewrażliwe na szybkość zamykania drzwi po zgaszeniu światła

scena wc na bramkach (ta obecna) CO czujnik otwarcia - Stan zamkniety to 1; VB ustawiany przez wylaczenie swiatla przez 6 sek na 1;
1. SW on t_off -> VB set
2. VB on t_on -> AND t_off
3. VB on t_off -> AND t_on
4. CO on t_on -> AND T_OFF
5. CO on t_off -> AND t_on
6. AND on t_ON SW t_on

scena wc oparta na akcji kopiowania stanów (nie jestem pewnie czy to dobrze zrobilem)
1. SW on t_off -> VB set (ma ustawiony autoset na 6 sek czyli po 6 sek będzie 0)
2. VB on ON COPY OFF STATE-> turn_on on SW
3. CO on t_OFF -> COPY RELAY OFF STATE on VB

Czyli ja to rozumiem tak otwarcie drzwi CO -> off wywołuja zdarzenie COPY RELAY OFF STATE na VB i jełśi akurat wtedy VB ma stan OFF czyli 0 to wykona ackje TURN ON SW, a jesli VB ma wtedy stan 1 (ON) To zdarzenie nie wykona tej akcji bo sie stany COPY OFF STATE i bieżący VB (1) OFF<>ON nie zgadzają?
Zdarzenie odfajkowane idzie w niepamięć więc i jednocześnie kiedy VB w końcu wróci do 0 to nic się nie stanie bo zdarzenie ON COPY OFF STATE było wykonane wczesniej bez skutku (właczenia) na SW

[EDIT] ale chyab źle rozumiem bo mi takei akcje nie chcą działać

[mmiikk]

Przy okazji, znów mam konflikt w supli z bramką na praktycznie każdym kanale z bramki, a w samej bramce ZIgbee channels mam tylko gateway events.
Co zrobiłem:
1. upgrade firmware do wczorajszej wersji i restart (przez OTA) wziąlam wersje update no logs
2, wyłaczyłem wszystkie akcje opricz wlaczenia lampy SW przyciskiem zigbee BUTTON i restart
3. w bramce dodalem virtual relay i restart
4. ustawilem autoset dla virtual relay i dopisałem 3 powyzsze nowe akcje (nie uzywalem w nich virtual relay) i restart
5. tutaj jeszcze bramka dzialalo prawidlowo i przycisk robil toggle na lampie, ale poniewaz testowana scena mi nie dzialala zrobilem ostatni reastart bez żadnuch wcześniejszych zmian w bramce w tym kroku
6. i tutaj juz przycisk BUTTON nie robil toggle na SW, w supli konflikt na bramce a w samej bramce ZIgbee channels mam tylko gateway events.

W supli cloud nic nie wlaczalem, żadnej rejestracji nowych urzadzeń.

[vajera]

Ok.Przeanalizowałem dodatkowo czwarty raz Wcześniej z opisu jakoś nie wybił mi się ważny element dotyczący tego że to kopiowanie wyzwala trzeci element w logice. O to chodzi. Tak?

Mniej więcej - kopiowanie ma miejsce jedynie w odpowiedzi na akcję z innego źródła (przekaźnika, bramki logicznej, czujnika itp.).

Nie wytrzymałem do weekendu napisałem akcje do światła WC w notatniku i chyba jeśli dobrze to rozumiem ilosc akcji bedzie mniejsza o połowe aby osiagnac ten sam cel, w dodatku całkowicie niewrażliwe na szybkość zamykania drzwi po zgaszeniu światła

scena wc na bramkach (ta obecna) CO czujnik otwarcia - Stan zamkniety to 1; VB ustawiany przez wylaczenie swiatla przez 6 sek na 1;
1. SW on t_off -> VB set
2. VB on t_on -> AND t_off
3. VB on t_off -> AND t_on
4. CO on t_on -> AND T_OFF
5. CO on t_off -> AND t_on
6. AND on t_ON SW t_on

scena wc oparta na akcji kopiowania stanów (nie jestem pewnie czy to dobrze zrobilem)
1. SW on t_off -> VB set (ma ustawiony autoset na 6 sek czyli po 6 sek będzie 0)
2. VB on ON COPY OFF STATE-> turn_on on SW
3. CO on t_OFF -> COPY RELAY OFF STATE on VB

Czyli ja to rozumiem tak otwarcie drzwi CO -> off wywołuja zdarzenie COPY RELAY OFF STATE na VB i jełśi akurat wtedy VB ma stan OFF czyli 0 to wykona ackje TURN ON SW, a jesli VB ma wtedy stan 1 (ON) To zdarzenie nie wykona tej akcji bo sie stany COPY OFF STATE i bieżący VB (1) OFF<>ON nie zgadzają?
Zdarzenie odfajkowane idzie w niepamięć więc i jednocześnie kiedy VB w końcu wróci do 0 to nic się nie stanie bo zdarzenie ON COPY OFF STATE było wykonane wczesniej bez skutku (właczenia) na SW

[EDIT] ale chyab źle rozumiem bo mi takei akcje nie chcą działać

Dobrze to rozumiesz, ale, tak jak wcześniej napisałem, póki co dodałem te akcje do przekaźników (ZigBee, remote relay, virtual relay) - robiłem testy na VR i wszystko działało. W najbliższym czasie postaram się dodać te akcje również do czujników binarnych (ZigBee, virtual binary).