Aktualizacje oprogramowania [bramka ZigBee]

[vajera]

@vajera Rewelacja!!!. Przy "RESEND RELAY STATE" przekaźnik(żródło ciepła") robi RESEND tak jak by został przełączony i wcześniejsza akcja wykrywa np ON TURN ON na nim. Tak?
Ustawiłem tak jak niżej i działa. Nie da się oszukać już wskaźnika VB
Event: {ON SUPLA REGISTERED AND READY}
from source channel: [GATEWAY EVENTS]
Action: {RESEND RELAY STATE}
on destination channel: [SW_KOCIOL]
Rozumiem że w moim przypadku to tak ma wyglądać bo widzę w tym UPDATE wiele innych możliwości.

Dokładnie tak, ale możesz też wykorzystać te e eventy czasowe, np. ON_EVERY_60_SECONDS.

I one właśnie były w tej chwili na moim celowniku Upewnię się... EVERY czyli cały czas co 5,30 lub 60s. tak?

Tak, aczkolwiek zegarka bym nimi nie regulował
Tych zdarzeń czasowych może być w sumie dowolnie wiele - tak teraz do mnie dotarło, że mogę zrobić akcję RESTART_GATEWAY i zdarzenie EVERY_24H - ktoś o to pytał ostatnio.

[zzrr]

Tak, aczkolwiek zegarka bym nimi nie regulował
Tych zdarzeń czasowych może być w sumie dowolnie wiele - tak teraz do mnie dotarło, że mogę zrobić akcję RESTART_GATEWAY i zdarzenie EVERY_24H - ktoś o to pytał ostatnio.

Oj... daje ten UPDATE widzę pole do popisu żeby sobie pozabezpieczać w przyszłości niektóre akcje żeby się zaktualizowały po jakimś ewentualnym resecie bramki.
EDIT:
... nie tylko pozabezpieczać w sumie. Bo można akce zrobić które potrzebne tylko przy starcie

[zzrr]

@vajera a jak się odpali tą akcję EVERY to da się ją zatrzymać?

[vajera]

@vajera a jak się odpali tą akcję EVERY to da się ją zatrzymać?

To działa trochę inaczej - ten moduł GatewayEvents genruje te akcje od momentu uruchomienia - wyobraź sobie to w ten sposób, że co 5 sekund strzela ta akcja, Supla sprawdza, kto jest do niej zarejestrowany i każdy taki element dostaje zdarzenie. Mogę oczywiście dodać akcje STOP_TIMER i START_TIMER, ale one będą globalne. Niemniej możesz wtedy np. włączać i wyłączać je przekaźnikiem.

[vajera]

Niestety w SuplaDevice akcje nie mają swojego unikalnego ID i dlatego trudno jest włączać je lub wyłączać w trakcie pracy.

[zzrr]

Niestety w SuplaDevice akcje nie mają swojego unikalnego ID i dlatego trudno jest włączać je lub wyłączać w trakcie pracy.

Jasne... nic więcej nie trzeba.
Ciągłe EVERY przy starcie bramki jest idealne. W szczególności do zabezpieczenia jakiegoś stanu przekaźnika czy VB czy czegoś innego. To jest SUPER.
Zapytałem bo przed chwilą tak dla treningu i zapoznawczo zrobiłem dodatkowo akcję żeby mi cyklicznie przełączało przekaźnik. No i cyka jak złoto i tak mi w głowie zaświtała ta myśl o wyłączeniu zależnym od innej akcji. Ale to nie była potrzeba. To było takie pytanie wynikające m.in. z braku takiej wiedzy jaką Ty posiadasz. Można było pomyśleć że jak jest START to zrobić do tego STOP to moment Ale nie nie, to nie jest przynajmniej w moim przypadku uzasadniona potrzeba tego. Moją i pewnie nie tylko moją z której warto będzie korzystać to właśnie różne akcje po ewentualnym restarcie.

[vajera]

Niestety w SuplaDevice akcje nie mają swojego unikalnego ID i dlatego trudno jest włączać je lub wyłączać w trakcie pracy.

Jasne... nic więcej nie trzeba.
Ciągłe EVERY przy starcie bramki jest idealne. W szczególności do zabezpieczenia jakiegoś stanu przekaźnika czy VB czy czegoś innego. To jest SUPER.
Zapytałem bo przed chwilą tak dla treningu i zapoznawczo zrobiłem dodatkowo akcję żeby mi cyklicznie przełączało przekaźnik. No i cyka jak złoto i tak mi w głowie zaświtała ta myśl o wyłączeniu zależnym od innej akcji. Ale to nie była potrzeba. To było takie pytanie wynikające m.in. z braku takiej wiedzy jaką Ty posiadasz. Można było pomyśleć że jak jest START to zrobić do tego STOP to moment Ale nie nie, to nie jest przynajmniej w moim przypadku uzasadniona potrzeba tego. Moją i pewnie nie tylko moją z której warto będzie korzystać to właśnie różne akcje po ewentualnym restarcie.

Począwszy od wersji 1.2.1-15/01/26 zdarzenia cykliczne (EVERY_) są domyślnie wyłączone. Podjąłem taką decyzję ponieważ:

- będzie ich używać kilka procent użytkowników bramki Z2S (a może kilka promili ),

- każde dodatkowe obciążenie procesora może wpływać na stabilność pracy bramki - te 3 zdarzenia uruchamiają się w sumie 15x/minutę.

Oczywiście nie rezygnuję z tej funkcjonalności, ale użytkownik musi ją włączyć dodając np. następującą akcję:

Event: {ON SUPLA REGISTERED AND READY}
from source channel: [GATEWAY EVENTS]

Action: {START TIMER}
on destination channel: [GATEWAY EVENTS]

[Zibi_007]

Niestety w SuplaDevice akcje nie mają swojego unikalnego ID i dlatego trudno jest włączać je lub wyłączać w trakcie pracy.

Jasne... nic więcej nie trzeba.
Ciągłe EVERY przy starcie bramki jest idealne. W szczególności do zabezpieczenia jakiegoś stanu przekaźnika czy VB czy czegoś innego. To jest SUPER.
Zapytałem bo przed chwilą tak dla treningu i zapoznawczo zrobiłem dodatkowo akcję żeby mi cyklicznie przełączało przekaźnik. No i cyka jak złoto i tak mi w głowie zaświtała ta myśl o wyłączeniu zależnym od innej akcji. Ale to nie była potrzeba. To było takie pytanie wynikające m.in. z braku takiej wiedzy jaką Ty posiadasz. Można było pomyśleć że jak jest START to zrobić do tego STOP to moment Ale nie nie, to nie jest przynajmniej w moim przypadku uzasadniona potrzeba tego. Moją i pewnie nie tylko moją z której warto będzie korzystać to właśnie różne akcje po ewentualnym restarcie.

Począwszy od wersji 1.2.1-15/01/26 zdarzenia cykliczne (EVERY_) są domyślnie wyłączone. Podjąłem taką decyzję ponieważ:

- będzie ich używać kilka procent użytkowników bramki Z2S (a może kilka promili ),

- każde dodatkowe obciążenie procesora może wpływać na stabilność pracy bramki - te 3 zdarzenia uruchamiają się w sumie 15x/minutę.

Oczywiście nie rezygnuję z tej funkcjonalności, ale użytkownik musi ją włączyć dodając np. następującą akcję:

Event: {ON SUPLA REGISTERED AND READY}
from source channel: [GATEWAY EVENTS]

Action: {START TIMER}
on destination channel: [GATEWAY EVENTS]

Bardzo mądra decyzja. Użytkowników tej funkcji musielibyśmy już liczyć w ppm

[vajera]

Wersja 1.2.2-15/01/26:

- usunąłem uruchamianie parowania po restarcie bramki

- dodałem kolejne zdarzenie systemowe Z2S_SUPLA_EVENT_ON_SUPLA_INITIALIZED - można je użyć np. do włączenia zdarzeń cyklicznych jeszcze wcześniej niż w przypadku Z2S_SUPLA_EVENT_ON_SUPLA_REGISTERED_AND_READY;

- dodałem też zdarzenie Z2S_SUPLA_EVENT_ON_EVERY_24_HOURS oraz obsługę akcji SOFT_RESTART - można je wykorzystać na przykład w taki sposób:

Event: {Z2S_SUPLA_EVENT_ON_EVERY_24_HOURS}
from source channel: [GATEWAY EVENTS]

Action: {SOFT_RESTART}
on destination channel: [GATEWAY EVENTS]

[zzrr]

Począwszy od wersji 1.2.1-15/01/26 zdarzenia cykliczne (EVERY_) są domyślnie wyłączone. Podjąłem taką decyzję ponieważ:
.....
- będzie ich używać kilka procent użytkowników bramki Z2S (a może kilka promili ),
.....

......
Bardzo mądra decyzja. Użytkowników tej funkcji musielibyśmy już liczyć w ppm

Zdecydowanie również popieram Ale klub w klubie? Niee