Włączniki Sonoff TX wpadają w pętlę

Cześć,

od ponad roku korzystam bez większych problemów z włączników Sonoff i Node-RED. Po ostatnich aktualizacjach (ale może to zbieg okoliczności) włączniki z których korzystam jako schodowych zaczęły wpadać w pętlę.

Jeżeli ktoś bardzo szybko naciśnie więcej niż raz na jeden włącznik który znajduje się na piętrze lub na parterze, to światło naprzemiennie włącza się i wyłącza aż do ponownego uruchomienia HA. Może to wynikać z tego, że włącznik będący na parterze ma słabszy zasięg i ze względu na opóźnienie dochodzi do zapętlenia (wcześniej nie zauważyłem tego problemu).

Czy ktoś mierzył się z podobnym problemem? Nie chciałbym wprowadzać na stałe opóźnienia, bo jednak może się zdarzyć sytuacja, że ktoś się pomyli, włączy i zaraz będzie chciał wyłączyć światło tym samym włącznikiem.

Na zrzucie są dwa osobne schematy dla włącznika znajdującego się na piętrze i poniżej dla włącznika znajdującego się na parterze.

Masz kilka możliwości które możesz sprawdzić.

  1. Sprawdzanie stanu czy jest on/off
    Screenshot - 15.04.2023 , 19_31_23

2.Limit wysłania w ciągu /sekund bez kolejkowania

3.Użyć domeny toggle zamiast on/off wywalenie switch.

Sprawa nie do uratowania … zbudowałeś multiwibrator


… przepływ msg łudząca przypomina układ, słaby zasięg robi za kondensatory.
multiwib

Jaki soft masz w tych wyłącznikach?

Dziękuję za odpowiedzi. Nie zmieniałem fabrycznie zainstalowanego softu. W HA korzystam z hacs SonoffLAN. Czy mogę w takim razie coś jeszcze poprawić w samym przepływie?

Spróbowałem opcji z limitem i w większości przypadków jest ok - nie wpada w pętlę, ale co kilka włączenie nie jestem w stanie wyłączyć światła pomimo upłynięcia więcej niż 1 sekundy.

Ja wykorzystuję sprawdzanie stanu obu wlączników. Mam sonoff NSPanel z tasmotą i drugi włącznik z softem Tuya, którego nie mogę zmienić. Stany włączników zapisuję w zmiennych flow i na ich podstawie sprawdzam stan włączników.


Konfiguracja node events state

Dodatkowo żeby to pewnie działało, wartości zmiennych zapisuję do pliku, a nie tak jak jest domyślnie w NR. Dzięki temu po restarcie NR, wartości zmiennych są zachowane.
Tak naprawdę jest to identyczne rozwiazanie jakie zaproponował @artpc

Oraz identyczne jakie zastosował @Michalek :wink:
U Ciebie sytuację ratuje to, że cały proces zdąży się zakończyć (szybka komunikacja) się zanim debouncing włącznika pozwoli na ponowne naciśnięcie. Co byś programowo nie tworzył na masz żadnego wpływy na czynnik losowy, którym jest człowiek naciskający przycisk.

@isom1266 u Ciebie łatwiej wzbudzić układ gdy użyjesz przycisków góra i dół jednocześnie.

Pytałem o soft, bo rozwiązaniem jest wykrywanie zdarzenia naciśnięcia przycisku, które uruchamiałoby przekaźnik na obu włącznikach jednocześnie.
Rozwiązaniem jest wymiana softu w którym można wykryć fakt naciśnięcia przycisku a nie tylko jego skutek.

Nie mam możliwości zrobić tego inaczej, wymiana całego modułu Tuya byłaby zasadna, gdyby od początku wdrożenia tego scenariusza , chociaż raz zawiódł. Przypadek, o którym piszesz to prawdopodobieństwo jak wygrana w lotka.

Czy ta zmiana dotyczy na “sztywno” wszystkich zapisywanych zmiennych w każdym flow, czy też możesz w każdym z nich wybrać zapis do pliku lub nie ?

Jest możliwość częściowego zapisu do pliku i pamięci… o szczegóły nie pytaj, wiem tylko że jest.
https://nodered.org/docs/user-guide/context

1 polubienie

Tak jak w dokumentacji, do której link podał @RobinI30, możesz mieć dwa miejsca do przechowywania wartości zmiennych i wybierać w każdym przypadku indywidualnie. Sam muisz zdecydować kiedy warto zapisać tylko w pamięci, a kiedy ustawić zapis do pliku. Ja wszystkie zmienne globalne zapisuję do pliku, zmienne flow, w zależności od potrzeb, zmienne node tylko do pamięci.