supla4linux - problem z CmdRelay i ActionTriggerParsed

[proxxon]

Hej,

Mam Mikrusa na którym bawię się Suplą na Linuxa. Potrzebuję zrobić system logowania do pliku uruchomienia kanałów. Użyłem kanału CmdRelay. Jako że muszę spiąć włączenie tego przekaźnika z prawdziwym hardware'em (brama) to postanowiłem dodać do tego ActionTrigger, który zapoda mi impuls na bramę i otworzy ją. Poniżej plik konfiguracji yaml:

Code: Select all

name: Mikrus
log_level: info
proto_verbose_log: false
state_files_path: "/var/local/supla-device"

supla:
  server: svrXYZ.supla.org
  mail: [email protected]

channels:
  - type: ActionTriggerParsed
    name: at_brama

  - type: CmdRelay
    name: relay
    initial_state: off
    cmd_on: "date +'%d.%m.%Y %T' >> /home/supla_logs/relay.log"
    action_trigger:
      - use: at_brama
      - on_state_change: [0, 1, 0]
  

No i problem jest taki że to nie działa
Po rejestracji widzę "Wyzwalacz akcji" w Cloud, ustawiam mój sterownik SBW-02 jako kanał, który ma zadziałać, klikam zapisz. Następnie po reconnecie w "Wyzwalaczu akcji" jest pusto - znika możliwość ustawienia, który kanał ma się włączyć. Screen poniżej:

no_at_trigger.png

Zapytałem oczywiście ChataGPT, wrzuciłem mu log i on twierdzi że:

ActionTriggerParsed poprawnie rejestruje ActionTriggerCaps=0x1 przy pierwszym starcie, jednak po odebraniu konfiguracji z Cloud i ponownym reconnect zgłasza już ActionTriggerCaps=0x0, mimo niezmienionej konfiguracji YAML. W efekcie Cloud usuwa konfigurację Action Trigger, a wyzwalacz przestaje działać. Log sugeruje, że capabilities kanału są nadpisywane stanem aktywnych akcji otrzymanym z serwera (active actions), zamiast pozostawać stałymi możliwościami urządzenia.

Capabilities zgłaszane przez ActionTriggerParsed powinny wynikać z konfiguracji YAML i nie powinny zmieniać się po reconnect.

W Twoim przypadku po pierwszej rejestracji capability jest zgłaszane poprawnie (0x1), natomiast po reconnect zostaje wyzerowane (0x0), mimo że konfiguracja YAML nie ulega zmianie.

Brzmi legitnie ale oczywiście proszę o pomoc tutaj w głównej mierze @klew jako developer'a supla-device.

Załączam log z SSH. Użyta biblioteka z dzisiaj z commita https://github.com/SUPLA/supla-device/c ... 34c77e98b1

[klew]

@proxxon coś namieszałeś.

ActionTrigger to komponent supla-device, który służy jako intefejs do akcji związanych z przyciskiem.
Przykładowo, jeśli masz przycisk na urządzeniu, to podłączony do niego AT będzie wysyłał do serwera zdarzenia: wciśnięto przycisk, wciśnięto 4x przycisk, przytrzymano przycisk itd.

To nie ma żadneg związku ze sterowaniem przekaźnikiem. Z tego [0, 1, 0] wydaje mi się, że chciałeś, aby ten AT generował impuls na bramę. To tak nie działa .

Ustaw po prostu CmdRelay i ustaw mu polecenia linuxowe jakie ma wykonać na "turn on" i na "turn off".
W Cloud ustaw mu funkcję "brama" i skonfiguruj czas impulsu.
Reszta zadziała automatycznie

[proxxon]

@proxxon coś namieszałeś.

(...)

To nie ma żadneg związku ze sterowaniem przekaźnikiem. Z tego [0, 1, 0] wydaje mi się, że chciałeś, aby ten AT generował impuls na bramę. To tak nie działa .

Niewykluczone stąd próba wyjaśnienia ale przecież sobie tego nie wymyśliłem
Na dowód Twój commit z 20.02.2023 (link):

* Linux: add ActionTriggerParsed for CmdRelay and BinaryParsed. Ability to trigger AT on specific state (on, off, offline), on value (value read from source/parser before converting to "state"), on state transitions, and on value transitions. Intruction to be added to readme.

I dalej w readme:

Parameter action_trigger allows to use ActionTriggerParsed channel to send actions to Supla server depending on channel state (or value).

i jeszcze kolejne:

Action trigger can be configured when channel enters selected state or value, and for specific transition between states or values.
on_state_change: [FROM_STATE, TO_STATE, ACTION]

No to ja chcę:

Code: Select all

- on_state_change: [0, 1, 0]

czyli z wyłączonego (0) na włączony (1) wywołaj akcję 0 czyli SUPLA_ACTION_CAP_TURN_ON (z proto.h). A w Cloud chce to spiąć z fizycznym przekaźnikiem, który steruje bramą. Tyle i aż tyle Wszystko dlatego, że dla kanału "otwórz furtkę/drzwi" nie ma w reakcjach do wyboru "gdy otwarta". Mam nadzieję że dobrze zrozumiałem readme i nie piszę tu jakiś argumentów z czapy.

BTW, kanału jako "brama wjazdowa" też nie mogę użyć bo akurat moja brama jest skonfigurowana tak, że sama się zamyka i użytkownik nie ma możliwości jej zamknąć. Z tą sprawą założę nowy temat.

[klew]

@proxxon chyba nie

Wydaje mi się, że próbujesz to zrobić na odwrót.

AT jest do wysyłania informacji o "zdarzeniu" (takim jak wciśnięcie przycisku) z urządzenia do serwera. W Cloud do tego zdarzenia możeszy przypisać "akcję" - np. włącz światło.
Do AT w Cloud nie przypiszesz przycisku.

Przycisk w Cloud będzie też reprezentowany jako AT. Mu możesz ustawić "otwórz bramę".
Aby "otwórz bramę" było dostępne, potrzebujesz mieć czujnik otwarcia bramy (np. kontaktron) dodany jako czujni binarny i w Cloud powiązany z Relay, ustawionym jako "brama".

--
Ten AT, który konfigurujesz [0, 1, 0] wygneruje "zdarzenie" do serwera, gdy przekaźnik zmieni stan z 0 na 1 - to nie znaczy, że brama się otworzyła. Przekaźnik do bramy powinien generować impuls, czyli zrobić 0->1->0 i po tym brama: zacznie się otwierać, lub się zatrzyma, lub zacznie się zamykać. Także przejście z 0->1 nie oznacza otwarcia. Taką informację dałby Tobie czujnik otwarcia bramy, a nie przekaźnik.

[proxxon]

Po przeczytaniu pierwszego postu muszę trochę więcej wyjaśnić.

Mam bramę, która w napędzie w sterowniku (ROGER B70/1DC) ma ustawione automatyczne zamykanie. Użytkownik może więc ją tylko otworzyć albo z pilota albo z SBW-02. Kanał przekaźnika w SBW-02 jest ustawiony jako funkcja Otwieranie drzwi po to aby w aplikacji była tylko etykietka/przycisk Otwórz a nie Otwórz/Zamknij jak to w funkcji Otwieranie/zamykanie bramy wjazdowej jest zrobione. Kanał przekaźnika ma ustawiony czas załączenia na 0,5s. Jest podpięty również czujnik otwarcia więc stan ikonki się zmienia gdy brama zaczyna się otwierać. To jest i działa super.

// -------------------
W tym miejscu chciałbym zasygnalizować potrzebę powstania kanału bramowego gdzie będzie możliwość ustawienia dwóch przekaźników (sbw-02 ma tylko dwa) pod jeden kanał i akcje typu otwórz całą, otwórz częściowo, otwórz na stałe z predefiniowanymi etykietkami lub na grubo jak w KPOP gdzie byłaby możliwość wpisania swoich labeli. ROGER ma dedykowane wejścia impulsowe do tego i można fajnie to rozdzielić pod dalsze harmonogramy i integracje. Ale to temat na inny post.
// -------------------

Następnie opiszę co chciałbym zrobić aby móc logować w pliku kto i kiedy otworzył bramę z aplikacji.

Mam sd4linux, na którym są wirtualne przekaźniki typu CmdRelay. Ich funkcja też jest ustawiona na Otwieranie drzwi aby user mógł je tylko otworzyć. Tych przekaźników jest tyle ile użytkowników (przyjmijmy, że 10). Jest też 10 lokalizacji i 10 identyfikatorów dostępu. Każdy CmdRelay jest przypisany do jednej lokalizacji i jednego identyfikatora dostępu. Dzięki temu każdy user widzi tylko jeden i tylko swój przekaźnik (mając wrażenie, że u każdego jest tak samo). Włączając go loguje do pliku moment włączenia przez:

Code: Select all

cmd_on: "date +'%d.%m.%Y %T' >> /home/supla_logs/relay_<user_name>.log"

Na chwilę obecną nie mam innego pomysłu skąd wiedzieć kto włączył przekaźnik, próbowałem przez MQTT coś wyciągnąć ale nie ma info od kogo przyszedł request na włączenie (choć w aplikacji widać, że ktoś coś włączył jeżeli w tym samym momencie mamy ją uruchomioną). API jeszcze nie próbowałem. W każdym razie mam teraz pliki z datami i godzinami włączenia tych wirtualnych przekaźników na linux'ie.
Idąc dalej, mając 10 tych przekaźników z opcją cmd w sd4linux mam je i tyle - nie są połączone z fizycznym sprzętem bo przecież są wirtualne. Pierwsze co nasuwa się na myśl jest spięcie ich przez Reakcje w Cloud. Okazuje się jednak, że taki wirtualny przekaźnik o funkcji Otwieranie Drzwi w swoich Reakcjach nie ma nic co można wykorzystać Ma tylko reakcje na status połączenia...

Kolejną opcją jest zatem stworzyć w YAML kanał ActionTriggerParsed, który według dokumentacji na GitHub może być połączony z przekaźnikiem wirtualnym typu CmdRelay i można wywołać akcję na serwerze Supla Cloud w momencie gdy ten wirtualny przekaźnik zmieni stan z 0 na 1. I to chcę zrobić aby w Cloud dla tego kanału o funkcji Wyzwalacz akcji (który jest spięty z CmdRelay w YAML) ustawić w momencie SUPLA_ACTION_CAP_TURN_ON (0) kanał fizycznego przekaźnika z SBW-02. Screen poniżej bo do tego momentu to mam i jest widoczne w Cloud. Otwórz całkowicie to przekaźnik z SBW-02.

at_trigger.png

Teraz po zapisaniu zmian wystarczy się np. wylogować z konta, (sd4linux robi reconnect), zalogować się ponownie i w wyżej wymienionym Wyzwalaczu akcji jest pusto jak na wcześniejszym screenie z postu wyżej. Po prostu znikają opcje które jeszcze przed chwilą mogłem ustawić. Nie mówię już o tym, że włączenie tego CmdRelay nie powoduje żadnej akcji na fizycznym przekaźniku w SBW-02 choć przed chwilą to właśnie spiąłem w Cloud (ale zniknęło).

I tu zaczyna się historia z mojego pierwszego postu, w którym to opisuję, daje log z SSH linuxa oraz odpowiedź z AI co może być nie tak patrząc na log. Według mnie coś tu jest nie tak z procedurą AT Capabilities, że urządzenie zgłasza co może a serwer to ignoruje albo przesyła inne/puste? To jest moja prośba do @klew aby to przeanalizował pod kątem ew. buga. Jestem też oczywiście otwarty na inne propozycje jak spiąć wirtualny przekaźnik z prawdziwym. Wiem, że mogę po prostu w komendzie dać curl'a z linkiem bezpośrednim albo mosquitto_pub aby przez MQTT wysłać polecenie włączenia fizycznego przekaźnika ale nie ukrywam, że ustawianie tego przez Cloud jest najwygodniejsze.

[klew]

Dzięki za opis i zgłoszenie. Problem zlokalizowany i poprawiony. Przy okazji drugi problem, na który byś zaraz trafił też znaleziony i poprawiony .
Zmiany są branchu main, także pobierz aktualne źródła i sprawdź czy działa.

[proxxon]

Sprawdziłem, działa. Dziękuję bardzo