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

[vajera]

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ń.

Pytanie - jak robisz te restarty?

[mmiikk]

Pytanie - jak robisz te restarty?

Klikam w restart gateway na pierwszej karcie gui bramki
[EDIT]
Przywróciłem działanie przez opcje w bramce Rebuild missing Supla channels on next startup
oraz usuniecie virtuanych kanałów z cloud supli czyli virtual ralay i virtual binary co dodałem w bramce,
oczywiscie własne nazwy kanałów na skutek rebuildu znikneły jak poprzednio. Zastanawiam sie czy to moze byc problem w bramce, była kopiowana z innej, moze pownienem wrócić do pierwszej bramki z krórej kopiowałem i poustawiać to tak jak jest teraz od nowa.
Generalnei mogę potestować różne rzeczy, obie bramki są jeszcze eksperymentalne i nic poważnego na nich nie chodzi.

[mmiikk]

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).

Rozumiem, ale nic nie stoi na przeszkodzie zeby zastapic Virtual Binary przez Virtual Relay? W sensie na Virtual relay też działa autoset jako czas wyłączenia?

[vajera]

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).

Rozumiem, ale nic nie stoi na przeszkodzie zeby zastapic Virtual Binary przez Virtual Relay? W sensie na Virtual relay też działa autoset jako czas wyłączenia?

Nie, w VR nie ma autoset. Dodałem obsługę tych akcji dla czujników binarnych (ZigBee, VB) w 1.5.17-17/04/26

[mmiikk]

Pytanie - jak robisz te restarty?

Klikam w restart gateway na pierwszej karcie gui bramki
[EDIT]
Przywróciłem działanie przez opcje w bramce Rebuild missing Supla channels on next startup
oraz usuniecie virtuanych kanałów z cloud supli czyli virtual ralay i virtual binary co dodałem w bramce,
oczywiscie własne nazwy kanałów na skutek rebuildu znikneły jak poprzednio. Zastanawiam sie czy to moze byc problem w bramce, była kopiowana z innej, moze pownienem wrócić do pierwszej bramki z krórej kopiowałem i poustawiać to tak jak jest teraz od nowa.
Generalnei mogę potestować różne rzeczy, obie bramki są jeszcze eksperymentalne i nic poważnego na nich nie chodzi.

Kolejny już 3 raz wyczyściło mi tabelę kanałów w bramce zigbee (GUI bramki) a w cloud jest konflikt na bramce, bo nie ma janałów - rzecz jest powtarzalna w tych krokach (obstawiam zapis VB autoset potem było wpisanie akcji i i restart:

Na działającej bramce z urządzeniami (wersja firmware Z2S-1.5.19-25/04/26) na wczesniejszych było samo
w cloud dodawanie nowych urządzeń tym razem było wyłączne
1.Dodaje local virtual binary i restart bramki z GUI
2. ustawiam autoset VB na 7 sekund
3. dodaje od razu local actions 3 wpisy i restart bramki z GUI

Treść tych wpisów w akcje chyba nie mają znaczenia a teraz sa bledne bo kanały w bramce gui sa puste (zosta tylko kanał gateway events):
SW - wyłącznik VB - local virtual binary, CO czujnik otwarcia (binary sensor)
ale były takie takie:
1. SW GANG1 on turn_off -> VB set
2. VB on ON COPY OFF STATE-> turn_on on SW GANG1
3. CO on turn_OFF -> COPY RELAY OFF STATE on VB

być moze po save autoset pownienem zrestartować bramkę ale ja zawsze przechodziłem do okcji i definiowałem je z tym VB z autosetem.
Mam backup bramki sprzed tego procesu, mogę go powtarzać

[vajera]

Kolejny już 3 raz wyczyściło mi tabelę kanałów w bramce zigbee (GUI bramki) a w cloud jest konflikt na bramce, bo nie ma janałów - rzecz jest powtarzalna w tych krokach (obstawiam zapis VB autoset potem było wpisanie akcji i i restart:

Na działającej bramce z urządzeniami (wersja firmware Z2S-1.5.19-25/04/26) na wczesniejszych było samo
w cloud dodawanie nowych urządzeń tym razem było wyłączne
1.Dodaje local virtual binary i restart bramki z GUI
2. ustawiam autoset VB na 7 sekund
3. dodaje od razu local actions 3 wpisy i restart bramki z GUI

Treść tych wpisów w akcje chyba nie mają znaczenia a teraz sa bledne bo kanały w bramce gui sa puste (zosta tylko kanał gateway events):
SW - wyłącznik VB - local virtual binary, CO czujnik otwarcia (binary sensor)
ale były takie takie:
1. SW GANG1 on turn_off -> VB set
2. VB on ON COPY OFF STATE-> turn_on on SW GANG1
3. CO on turn_OFF -> COPY RELAY OFF STATE on VB

być moze po save autoset pownienem zrestartować bramkę ale ja zawsze przechodziłem do okcji i definiowałem je z tym VB z autosetem.
Mam backup bramki sprzed tego procesu, mogę go powtarzać

Powtórzyłem Twoje kroki, ale nie udało mi się skasować tabeli kanałów. Mam prośbę - jeżeli używasz Windows, to przycisk PrtSc pozwala też nagrywać - może spróbujesz zrobić film?

[mmiikk]

Kolejny już 3 raz wyczyściło mi tabelę kanałów w bramce zigbee (GUI bramki) a w cloud jest konflikt na bramce, bo nie ma janałów - rzecz jest powtarzalna w tych krokach (obstawiam zapis VB autoset potem było wpisanie akcji i i restart:

Na działającej bramce z urządzeniami (wersja firmware Z2S-1.5.19-25/04/26) na wczesniejszych było samo
w cloud dodawanie nowych urządzeń tym razem było wyłączne
1.Dodaje local virtual binary i restart bramki z GUI
2. ustawiam autoset VB na 7 sekund
3. dodaje od razu local actions 3 wpisy i restart bramki z GUI

Treść tych wpisów w akcje chyba nie mają znaczenia a teraz sa bledne bo kanały w bramce gui sa puste (zosta tylko kanał gateway events):
SW - wyłącznik VB - local virtual binary, CO czujnik otwarcia (binary sensor)
ale były takie takie:
1. SW GANG1 on turn_off -> VB set
2. VB on ON COPY OFF STATE-> turn_on on SW GANG1
3. CO on turn_OFF -> COPY RELAY OFF STATE on VB

być moze po save autoset pownienem zrestartować bramkę ale ja zawsze przechodziłem do okcji i definiowałem je z tym VB z autosetem.
Mam backup bramki sprzed tego procesu, mogę go powtarzać

Powtórzyłem Twoje kroki, ale nie udało mi się skasować tabeli kanałów. Mam prośbę - jeżeli używasz Windows, to przycisk PrtSc pozwala też nagrywać - może spróbujesz zrobić film?

Zrobię zapis nawet na telefonie, ale już jutro. Obecnie działam na backupowej bramce z tym samym stanem sprzed dodania tego VB.

Jedna uwaga: wcześniej zgłaszałem dziwne zachowania, kiedy wyciągam gniazdko nr 3. Teraz to wróciło, więc jeszcze dodam, że dodanie VB autoset i dodanie akcji odbywało się przy wyciągniętym gniazdku nr 3. Przed tym wszystkie urządzenia i pozostałe gniazdka działały. Być może to gniazdko nr 3 – nieobecne online w trakcie tych zmian – coś powoduje.

No bo teraz mam ten dwuprzyciskowy przełącznik Bseed glass touch. Jeszcze przed zmianami z VB i akcjami działał poprawnie – tzn. dało się z aplikacji nim przełączać, a przełączenie palcem w urządzeniu pokazywało poprawny stan w aplikacji. To samo z gniazdkiem Sonoff (gniazdko nr 1).

Teraz na backupowej bramce jest tak: gniazdko nr 3 ma zasilanie, przełącznik 2-gang działa poprawnie i z aplikacji, i ręcznie, gniazdko Sonoff również steruje się z aplikacji poprawnie.

Teraz wyciągam gniazdko nr 3 i przełącznik 2-gang ręcznie – oczywiście mogę sterować. O dziwo odwzorowuje się w aplikacji poprawny stan, ale przełączanie w aplikacji nie skutkuje przełączaniem w przełączniku. To samo z gniazdkiem Sonoff. Wszystko jakoś zależy od tego, czy gniazdko nr 3 jest pod zasilaniem, czy nie.

Zaznaczam, że przez cały dzień było ono wyciągnięte. Może raz czy dwa je włożyłem na parę minut, żeby przetestować koło południa i wszystko działało poprawnie – także kiedy było wyciągnięte. Dodawałem VB i akcje przy wyciągniętym gniazdku nr 3 i tuż przed tym także wszystkie urządzenia sterowały się poprawnie bez gniazdka numer 3 podłączonego do prądu.

Nie wiem, czy to ma znaczenie, ale mam 2 takie gniazdka – gniazdko nr 2 jest cały czas podłączone.

No i teraz przy backupowej bramce – bez gniazdka numer 3 – przekaźniki nie dają się sterować z aplikacji, choć ich stan jest poprawnie w tej aplikacji odwzorowywany, kiedy załączam i wyłączam je ręcznie w urządzeniach.

Dziwne to.

Jutro przetestuję ponownie dodawanie i nagram cały proces.

[bokk]

Czy za pomocą nowej akcji COPY można, a jeśli tak to w jaki sposób w poniższych akcjach sterowania załączania kotła CO za pomocą dwóch przekaźników Relay_GORA/DOL wyeliminować jeden przekaźnik

gate GORA:
add virtual relay GORA_LVR, add remote reley GORA_LRR
remote reley GORA_LRR <===> DOL_LRR

GORA_LVR -> ON_TURN_ON -> GORA_LRR -> TURN_ON
GORA_LVR -> ON_TURN_OFF -> GORA_LRR -> TURN_OFF

gate DOL:
add virtual relay DOL_LVR, add remote reley DOL_LRR
remote reley DOL_LRR <===> GORA_LRR
add Relay_GORA, Relay_DOL

DOL_LRR -> ON_TURN_ON -> Relay_GORA-> TURN_ON
DOL_LRR -> ON_TURN_OFF -> Relay_GORA-> TURN_OFF
DOL_LVR -> ON_TURN_ON -> Relay_DOL-> TURN_ON
DOL_LVR -> ON_TURN_OFF -> Relay_DOL-> TURN_OFF

[vajera]

Czy za pomocą nowej akcji COPY można, a jeśli tak to w jaki sposób w poniższych akcjach sterowania załączania kotła CO za pomocą dwóch przekaźników Relay_GORA/DOL wyeliminować jeden przekaźnik

gate GORA:
add virtual relay GORA_LVR, add remote reley GORA_LRR
remote reley GORA_LRR <===> DOL_LRR

GORA_LVR -> ON_TURN_ON -> GORA_LRR -> TURN_ON
GORA_LVR -> ON_TURN_OFF -> GORA_LRR -> TURN_OFF

gate DOL:
add virtual relay DOL_LVR, add remote reley DOL_LRR
remote reley DOL_LRR <===> GORA_LRR
add Relay_GORA, Relay_DOL

DOL_LRR -> ON_TURN_ON -> Relay_GORA-> TURN_ON
DOL_LRR -> ON_TURN_OFF -> Relay_GORA-> TURN_OFF
DOL_LVR -> ON_TURN_ON -> Relay_DOL-> TURN_ON
DOL_LVR -> ON_TURN_OFF -> Relay_DOL-> TURN_OFF

Te akcje COPY służą raczej do uwzględnienia stanu dodatkowego przekaźnika/czujnika w momencie wykonania jakieś akcji, czyli np. bramka AND bierze pod uwagę stan czujnika binarnego, tylko w momencie, gdy użytkownik włączy/wyłączy dany przekaźnik.

Możesz ewentualnie rozrysować całą swoją instalację, ale raczej nie zredukujesz liczby akcji, zresztą...

jak-dziala-to-nie-ruszaj-zakurzony_2021-01-16_02-32-05.jpg

[bokk]

Czy za pomocą nowej akcji COPY można, a jeśli tak to w jaki sposób w poniższych akcjach sterowania załączania kotła CO za pomocą dwóch przekaźników Relay_GORA/DOL wyeliminować jeden przekaźnik

gate GORA:
add virtual relay GORA_LVR, add remote reley GORA_LRR
remote reley GORA_LRR <===> DOL_LRR

GORA_LVR -> ON_TURN_ON -> GORA_LRR -> TURN_ON
GORA_LVR -> ON_TURN_OFF -> GORA_LRR -> TURN_OFF

gate DOL:
add virtual relay DOL_LVR, add remote reley DOL_LRR
remote reley DOL_LRR <===> GORA_LRR
add Relay_GORA, Relay_DOL

DOL_LRR -> ON_TURN_ON -> Relay_GORA-> TURN_ON
DOL_LRR -> ON_TURN_OFF -> Relay_GORA-> TURN_OFF
DOL_LVR -> ON_TURN_ON -> Relay_DOL-> TURN_ON
DOL_LVR -> ON_TURN_OFF -> Relay_DOL-> TURN_OFF

Te akcje COPY służą raczej do uwzględnienia stanu dodatkowego przekaźnika/czujnika w momencie wykonania jakieś akcji, czyli np. bramka AND bierze pod uwagę stan czujnika binarnego, tylko w momencie, gdy użytkownik włączy/wyłączy dany przekaźnik.

Możesz ewentualnie rozrysować całą swoją instalację, ale raczej nie zredukujesz liczby akcji, zresztą...


jak-dziala-to-nie-ruszaj-zakurzony_2021-01-16_02-32-05.jpg

to nie ruszam, bo działa