YAML dla opornych

Walczę z kilkoma zmianami, które chcę wprowadzić w moim HA i umieram na “nierozumieniu” struktury YAML. Niby proste (wg. wiki i kilku art., które wygooglełem i przeczytałem ze zrozumieniem), ale w moim pliku YAML i innych, które tutaj znalazłem są konstrukcje, których nie kumam. Czy na podstawie mojego Case-Study ktoś może mi pomoc zrozumieć, co poszczególne liniki oznaczają. U mnie config.yaml wygląda jak niżej:


# Loads default set of integrations. Do not remove.
default_config:

# Load frontend themes from the themes folder
frontend:
  themes: !include_dir_merge_named themes

# Text-to-speech
tts:
  - platform: google_translate

automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml

# Example configuration.yaml entry
wake_on_lan:

# Example configuration.yaml entry
switch:
  - platform: wake_on_lan
    mac: xx:yy:zz:aa:bb:cc
    name: "jakas nazwa"
    
  - platform: wake_on_lan
    mac: yy:zz:aa:bb:cc:dd
    name: "jakas druga nazwa"


  1. “default_Config:” klucz, który nie ma wartości.
  2. “frontend” ma jedną cechę “themes:” która ma wartość jak wyżej (includuje plik)
  3. “tts” ma listę cech, a na liście jest tylko jedna pozycja “platform”, która ma wartość …
  4. “wake_on_Lan” - nie ma wartości
  5. Switch ma listę dwu elementów, a których każdy ma dwie cechy?

Czy ja to dobrze rozumiem, bo zaraz podam przykłady, których nie rozumiem. :wink:

Mówimy o configuration.yaml?

Rozumiem że chodzi Ci o poszczególne wpisy typu
default config?

W HA jest taka trochę wariacja YAMLa, ale pomijając to - tak, są klucze które mogą nie mieć wartości (co oznacza że przyjmują wartość domyślną, która może naprawdę zawierać sporo treści, mimo, że jest ona niejawna).
Jeśli poszukasz wątek o default_config, to się dowiesz co m.in. jest w nim defaultem (pewnie można to wygrzebać z dokumentacji, bo to co w tamtym wątku jest już mało aktualne).

Czy twoje słownictwo jest prawidłowe, to nie wiem, bo oficjalnie to są klucze, wartości, słowniki i listy, jakkolwiek po prostu klucze najwyższego poziomu trzeba traktować jako początek jakiegoś bloku logicznego.

Na wstępie dziękuję dobrej-duszy-moderatorowi, który poprawił mój wpis dodając “…” przed treścią YAML i na jej zakończenie, co pozwoliło, się jej dobrze zformatować. :wink:

W podanym przykładzie jest dla mnie mniej więcej wszystko jasne. Kłopoty się zaczynają gdy próbuje dodać np. teraz jakiś przycisk monostabilny. Potrzebuję go do dwu celów:

  • sterowanie bramą garażową
  • wysyłanie magic_packet, aby obudziś poprzez LAN inną maszynę w sieci lokalnej.

Konfiguracja, którą zacytowałem działa, ale nie mam pojęcia np po co pusta wartość (klucz bez podanej wartości): wake_on_lan.

Wracając do momentary switch, to na dziś wyczaiłem, że są 3 rozwiązania (żadnego mi się nie udało wdrożyć).

  1. GitHub - twrecked/hass-momentary: Momentary Switch Component for Home Assistant
  2. Rozwiazania skryptowe
  3. Input Button - Home Assistant
  4. Button Card - Home Assistant (szopen wskazał w jednym z wątków o momentary-switch" Przycisk monostabilny - #2 przez szopen)

Opisy dla pkt.1 i 3 są dla mnie czarną magią. Próbuje odszukać jakiegoś tutoriala, jak to rozumieć, ale chyba czegoś takiego nie ma. Weźmy na tapetę pkt.3 jest tam przykład zastosowania:


trigger:
  - platform: state
    entity_id: input_button.my_button
action:
  - service: notify.frenck
    data:
      message: "My button has been pressed!"

Pytanie 1.
Czym jest “trigger” ?
Wg. pliku YAML, to jakiś klucz z listą (na razie na liście jest jedna pozycja). Klucz jest czytany przez HomeAssisnanta i sobie to jakoś interpretuje. Ale nie pasuje mi format tego klucza. Lista zawiera jedną pozycję o nazwie “platform”, która ma jak rozumuję nie tylko cechy wymienione poniżej (jedną cechę) “entity_id”, ale także swoją wartość “state”? Konstrukcja dziwna, bo ani to wartość skalarna/string, ani zmienna typu rekord, tylko taki miks tych dwu rodzajów zmiennych ? Czy tak to należy rozumieć?

Analogicznie klucz “action” ma na swojej liście jedną pozycję, klucz “service”, który ma zarówno wartość “notif.frenck”, jak i cechę “data”, która ma swoją cechę “message”.

Próbuję to zrozumieć, aby rozkminić, jak osiągnąć cel w postaci pola na moim “lovelance”, które jak nacisnę myszką (na komputerze), lub palcem (na telefonie), to mi się otworzy brama, lub wyśle “magic_packet” i uruchomi komputer.

Obecnie przycisk do otwierania bramy wykonałem dodąc (wyklikując) przycisk typu switch na Lovelance i dopisując do niego encję z odpowiedniego urządzenia Shelly-Uni.

Pytanie 2.

  • Czym jest w powyższym przykładzie klucz “trigger” (gdzie znajdę jakiś opis, jakiego rodzaju klucze mogę dodawać do tego YAML’a i co poszczególe klucze oznaczają? Istnieje taki spis?)
  • Czym “platform”
  • Czym “state” (jakie może przyjmować wartośc?)
  • itd…

Przykład jest ogólny, aby zadziałał u mnie muszę go dostosować. Nie ogarnę tego, jeśli nie zrozumie co jest czym. :wink:

Podsumowanie

Ten tekst zostanie ukryty

Mam wrażenie, że źle zaczynasz… to znaczy skaczesz w nieznaną wodę na główkę. Proponuję zanim zaczniesz studiować składnię pliku YAML z konfiguracją, pójść drogą zwykłego użytkownika, który najczęściej nie jest programistą.
Przykład z dokumentacji dla Input Button sugeruje użycie GUI, nie musisz nic wpisywać w pliku konfiguracji. Cały projekt HA skupia się na odejściu, tam gdzie to możliwe, od grzebania w YAML. Dlatego sporo informacji, które znajdziesz w internetach będzie nieaktualne.

Aby to zrozumieć należy zacząć od zapisu default_Config, nie wiesz dlaczego w pliku configuration.yalm przy tym wierszu nie ma kluczy. Sam ten wpis jest kluczem, bez niego wszystko co zwarte w default_Config będzie niedostępne jako domyślnie włączone funkcje konfiguracji, tak jak to jest np z Input Button:
(zgodnie z dokumentacją, opcja włączona domyślnie wraz z default_config)

Inaczej natomiast ma się sprawa w przypadku ‘wake_on_lan’. Po pierwsze nie jest zawarty w domyślnej konfiguracji default_config. Nie ma możliwości dodania tej integracji poprzez GUI. Dlatego wymaga wpisy w pliku configuration.yaml . Sam wpis wake_on_lan daje wówczas możliwość tworzenia następnego bytu jakim jest np. switch, czyli encja przełącznika. Encje możemy tworzyć w oparciu o różne platformy, dlatego przy nich jest ten dopisek platform, który określa źródło integracji dla tego bytu. Nie chcę kontynuować wykładu, bo ilość pojęć i zależności jest zbyt duża i łatwo się w tym pogubić. Dlatego uważam, że najlepiej jak zaczniesz od prostych przykładów praktycznych.

Proponuje wybrać na początek przypadek z bramą, bo będzie łatwiej. Następnie przerobimy przykład WOL, bo on wymaga dobrania metody na wysłanie pakietu, a metod jest w HA kilka. Generalnie, w HA na wszystko jest przynajmniej kilka możliwości osiągnięcia tego samego celu. Dlatego ważne jest aby zrozumieć ogólne zasady działania i zależności między klockami.

1 polubienie

Jak pisałem wcześniej moim celem jest otwieranie bramy, a nie studiowanie HA. Ale przykłady z uruchomieniem przycisku chwilowego opisują, rzeczy, których nie rozumiem, a nie lubię układać słoików na półce w ciemnej piwnicy na ślepo. :wink:

Reasumując stan u mnie jest następujący:

  • wyklikałem już wcześniej w Settins->Devices…->Helpers rzeczowy Button

Aby użyć identyfikator encji “input_button.chwilowy” gdzieś, to muszę wiedzieć gdzie i przykład, który tam jest mi tego nie wyjaśnia. ;-(

Przeczytałem jeszcze raz

I rozumiem to tak:

  1. Encja, która powstała “input_button.chwilowy” jest “State-less”, dostaje w momencie uruchomienia TimeStamp.
  2. Teraz doczytałem, że ten przycisk może ewentualnie uruchomić jakąś automatyzację.
  3. Wracamy do przykładu czym jest kluczy trigger z elementem “platform” z wartością “state” ?
  4. Czym jest klucz action z elementem service…?
  5. Czym jest usługa “input_button.press” ?

Szukam wyłącznika światła, który włączy jakieś oświetlenie w tej ciemnej dla mnie nadal piwnicy. ;-(

P.S.
Nie próbowałem robić żadnej automatyzacji w HA, bo czytając różne posty na forach i filmiki ArturHome wydedukowałem, że i tak niewiele się da zrobić i lepiej Node-Red. Tam mamy klocki z funkcjami a w nich możemy wszystko zaprogramować (programowałem w PHP, Java-Script, różne proste rzeczy, w C Arduino w tym całkiem duży program na ArduinoMega, gdzie delaya zastąpiłem milis i była wielozadaniowość. Program był tak duży, że ledwo się mieścił w pamięci uC. Pojęcie obiektów, metod nie jest mi obce.

Założyłeś taki a nie inny temat, więc studiujemy składnie YAML, ale ona jest tylko językiem do opisu składników HA. Moim zdaniem łatwiej zrozumieć zależności jeśli zaczynamy od GUI i narzędzi w nim zawartych.
Pomocnicy generalnie służą do uzupełnienia bytów potrzebnych w automatyzacjach. Oprócz pomocników, są w HA usługi (service), które mają za zadanie wywołanie danego zachowania w systemie, dotyczącego danego elementu. Akcja jest skutkiem jakiejś automatyzacji lub zdarzenia w systemie. Pobaw się zakładką narzędzia deweloperskie. Rozjaśni się po części to o czym piszę.
Wracając do tematu, należy zacząć od informacji, jakim urządzeniem wykonawczym sterujesz dla otwarcia bramy, innymi słowy z jakiej integracji dla tego urządzenia korzystasz? Ponieważ metod osiągnięcia tego samego celu jest wiele i ważna jest wiedza o punkcie wyjścia i założeniach. Podejrzewam, że może nie być potrzeby użycia pomocnika imput button.

Obecnie jest to Shelly-Uni z oprogramowaniem Shell. On ma dwa wejścia i dwa przekaźniki (chyba jakieś mikroskopijne SSR’y). Jeden z tych SSR’ów zwiera wejście PP sterownika bramy Nice Robus 600. Wejście jest impulsowe. Integracja na dziś jest zatem Shelly. To urządzenie posiada takie encje:

To co mi się udało, to podpiąć do Lovelance “switch.brama_p_p”. Jako switch = muszę kliknąć dwa razy. Włączyć i wyłączyć.


Poniższe piszę tylko dlatego, że planuję zmianę kiedyś na ESPHome, nie ma nic wspólnego z momentary-switch itd…

Odczyt ADC w obecnej konfiguracji, cały czas się zmienia (napięcie odczytywane skacze), to chcę to w przyszłości przeprogramować na ESPHome, bo tam mogę założyć filtr i raportować tylko dużą zmianę do bazy danych. ADC odcztuje napięcie na kontaktronie i wiem, czy brama jest zamknieta, czy nie.

Dziś więc jest to integracja Shelly, a kiedyś będzie ESPHome. Wygooglało mi się, że w ESPHome jest jakaś forma obsługi Momentary-Switch, cokolwiek by to znaczyło, ale nie chcę nowego wątku zaczynać.

1 polubienie

Zawsze jeśli tylko jest to możliwe, to należy rozwiązania dla pracy impulsowej szukać w oprogramowaniu urządzenia.

To raczej dobra wiadomość. Podejrzewam, że producent przewidział pracę impulsową/czasową dla wyjścia. Nie mam tego sprzętu, więc sprawdź w ustawieniach tego urządzenia w UI Shelly czy jest taka opcja. Moje doświadczenia z Shelly są bardzo pozytywne i byłbym zaskoczony gdyby tej opcji nie było.

Nie rozumiem dlaczego robisz to przez ADC zamiast wykorzystać wejścia IN1 i IN2.

Najpierw prostsze (nie związane z tematem): na pinach od kontaktronów, jest napięcie 11-13V gdy brama zamknięta oraz coś pomiędzy 20-30V jeśli brama otwarta. Kontaktron ma jedno wejście chyba na stałe do plusa. Być może ono wisi w powietrzu i dlatego napięcie szumi dosyć istotnie. Być może mógłbym je opornikiem ściągnąć do masy, ale nie chciałem nic przerabiać w napędzie, bo po co, skoro mam nieużywane ADC, które doskonale mierzy, z dokładnością, która wystarcza jeśli się programowo to przefiltruje.

Chwila, HomeAssistant wstawi sterowanie otwórz (czyli shelly zamknie jakiś switch,który zewrze wejścia PP napędu bramy). W HA zmieni stan jakiejś encji na “Otwórz”. Do kolejnego otwarcia musi znowu zmienić… W którymś momencie HA musi sobie zmienić “Otwórz” na “zamknij”

Zupełnie sobie nie wyobrażam jak by to miało działać w twojej wizji.

Moja brama jest skonfigurowana w automacie, że po przejechaniu się sama zamyka. Klikam zbliżając się do bramy z pilota bramowego (albo HA), brama się otwiera, przejeżdżam, brama się zamyka - to jest codzienne używanie bramy.

Niezależnie od codziennego otwierania bramy “do przejazdu/przejścia”, używam i chce mieć taką funkcjonalność “otwórz na stałe” Taką funkcjonalność w przypadku Napędu bramy Robus Nice 600 robi się tak, że zwiera się na stałe wejście PP. Np. gdy chce mieć otwartą bramę przez godzinę. Po godzinie zdejmuje sygnał na wejście PP i brama się zamknie.

Czytając dokumentację Shelly nie trafiłem na pomysł który sugerujesz, zresztą z logiki mi wynika, że HA winien wiedzieć, że za chwilę będzie zamknięta, zmienić stan jakiejś swojej encji itd… Wracamy do tematu, że w HA winna być jakaś encja typu Momentary, której nie potrafię skonfigurować.

Może rozumiesz co piszą w tch przykładach i pomożesz przy wersji Momentary, który jest w ramach pomocników HA. Wolałbym zastosować, coś co się bardziej klika, niże przepisuje do YAML’a.

Opiszę jak ja mam to zrobione.
Brama wjazdowa, dwuskrzydłowa i pod styk na płycie napędy bramy podpięty przekaźnik dla impulsu, który uruchamia otwieranie/stop/zamykanie bramy. Przekaźnikiem steruje za pomocą ESP z Tasmota. W przypadku Tasmota, funkcją programowalną jest opcja PulseTime.
Brama segmentowa, garażowa, tu steruje w oparciu o ESPHome i opisałem to dokładnie na innym forum.
Za działanie przekaźnika odpowiedzialnego za napęd odpowiada ten fragment kodu konfiguracji modułu w ESPHome:

cover:
  - platform: template
    device_class: garage
    name: "Garaż"
    id: template_cov
    lambda: |-
      if (id(contact_sensor).state) {
        return COVER_OPEN;
      } else {
        return COVER_CLOSED;
      }
    open_action:
      - switch.turn_on: relay
      - delay: 0.3s
      - switch.turn_off: relay
#    stop_action:
#      - switch.turn_on: relay
#      - delay: 0.3s
#      - switch.turn_off: relay
    close_action:
      - switch.turn_on: relay
      - delay: 0.3s
      - switch.turn_off: relay

O tym nie wiedziałem, natomiast wyobrażam sobie wykorzystanie jednego wyjścia z Shelly UNI jako działające impulsowo (czasowy impuls), a drugie wyjście z Shelly dla funkcji “otwórz na stałe”. Nie wiem tylko czy bez dokładania przekaźników bezpotencjałowych się obejdzie. Czy możliwa jest praca równoległa (elektrycznie) tych, jak to nazwałeś - “mikroskopijne SSR’y”.

To jest na razie Twoje wyobrażenie jak to powinno działać, ale uwierz jest więcej możliwych scenariuszy.
Opisze jeden z możliwych. Twoje Shelly otrzymuje komendę ON i wie, że ta komenda ma trwać 0,3s zawsze (ustawiłeś to w oprogramowaniu Shelly). Otwiera się kontaktron i HA otrzymuje informacje, że brama nie jest zamknięta, jeśli masz drugi kontaktron, to HA otrzymuje informację, że bramna sie otworzyła. Te informacje sa już w HA i na ich podstawie możesz to obrazować na dashboard dowolnie, jak tylko pozwala Ci na to wiedza i wyobraźnia. Mogą zmieniać się ikony w zależności od stanu bramy itd. Przycisk może mieć kłódkę, która uniemożliwia przypadkowe jego użycie itp. Możesz ustawić obok drugi przycisk, który otworzy bramę na dany czas i pozostawi ją otwartą. W konfiguracji samego przycisku na karcie dashboard możesz wykorzystywać usługi i wymuszać akcje.

Spróbujmy… utworzyłem pomocnika typu przycisk o nazwie my_button

Tworzę nową automatyzację:

Mam do wyboru interfejs graficzny lub tryb edycji YAML.
Pozostaję na domyślnym trybie wizualnym. Zaczynam od wybrania wyzwalacza. Chcę aby był im stworzony we wcześniejszym kroku wirtualny przycisk my_button więc wybieram go z listy dostępnych wyzwalaczy spod grupy stan (tak jak sugeruje to dokumentacja w przykładzie dla Input Button):

Odnajduje interesującą mnie encję:


Wyzwalacz mamy gotowy, każda zmiana stanu encji wirtualnego przycisku uruchomi automatyzację.
Przechodzę do wyboru akcji, co ma się zadziać dalej gdy nacisnę przycisk:

Wybiorę sobie urządzenie, bo chcę aby jego przekaźnik załączył się.

W tej akcji włączam przykładowe urządzenie. Dodaje kolejną akcję, bo chcę aby po określonym czasie urządzenie wyłączyło się. Czyli kolejną akcją będzie opóźnienie

A po opóźnieniu kolejna akcja - wyłączenie urządzenia:

Tak powstał przycisk, którego użycie załączy urządzenie na zadany czas i który możesz umieścić na dashboard i używać w każdym miejscu HA.

A tak ta automatyzacja wygląda w postaci YAML:

alias: Nowa automatyzacja
description: ""
trigger:
  - platform: state
    entity_id:
      - input_button.my_button
condition: []
action:
  - type: turn_off
    device_id: 3d42a1efad3e5ca8305f3d67e1ffdd84
    entity_id: light.gniazdo_lidl1
    domain: light
  - delay:
      hours: 0
      minutes: 0
      seconds: 0
      milliseconds: 300
  - type: turn_off
    device_id: 3d42a1efad3e5ca8305f3d67e1ffdd84
    entity_id: switch.gniazdo_lidl1
    domain: switch
mode: single
1 polubienie

:wink:
Tak u mnie powstała automatyzacja. Jak włączę jej PLAY, to działa. Jak chcę jakiś przycisk na Dashboardzie, i TĄ automatyzację wybiorę jako encję, to mam do wyboru kolejne check-boxy, w których znowu nie ma światła i nic nie działa. ;-( ;-(

Edit:

FInalnie działa, ale rzecz, która wdaje się bardzo prosta okazała się bardzo skomplikowana. IMHO.

  1. W lovelance definiuje przycisk, którego encją jest pomocnik “INPUT_BUTTON.xxx”, który musiałem zainstalować jako dodatek z HACS (no właśnie tego nie jestem pewien).
  2. Akcja DOTKNIĘCIA wywołuje usługę określoną dalej.
  3. Usługa to: “automatyzacja.trigger”
  4. Do usługi wybrałem wcześniej zdefiniowaną automatyzację “OpenTheDoor” (to moja nazwa).
  5. Automatyzacja opisana w poście wyżej przez kolegę @angler - dziękuję za pomoc.

Nadal mam wiele pytań, ale brak czasu aby je opisywać. Jak znajdę na niektóre odpowiedzi, to je tutaj opisze. Bo mam wrażenie, że zrobiłem automatyzację, którą mogłem zrobić równie dobrze w NodeRed, a do czego mi tutaj InputButtom, który miał być Momentary, to nie mam pojęcia.

Edit (2023-10-27)
Całość przełącznika monostabilnego do otwierania bramy można też załatwić inną metodą, która jednak ma pewną wadę. A mianowicie u mnie Shelly-Uni zwiera styki PP bramy. (przekaźnik w Shelly-Uni jest izolowany, tak BTW). Wprowadziłem automatyzację, która jest wyzwalana zmianą stanu encji tego przekaźnika. Jeśli jest WŁĄCZONY (warunek w automatyzacji), to włączam opóźnienie 300ms i zmieniam stan tej encji na WYŁĄCZONY. Bez żadnych dodatkowych pomocników, nowych integracji z HACS itd…

Jaki minus: minus jest taki, że nie mam możliwości, aby brama była stale otwarta. Automatyzacja ją po prostu za każdym razem po 300ms zamyka (zdejmuje sygnał otwarcia).

Nadal proponuje przegląd ustawień w samum webUI urządzenia Shelly-Uni. Sprawdź proszę czy można ustawić czasowe załączenie wyjścia organoleptycznie. Jestem bardzo ciekaw czy jest tam ta funkcja, może w dokumentacji jest pominięta, bo wydaje się być oczywistą.

Jak pisałem wcześniej Shelly nie ma opcji sterowania impulsowego. Jego wejścia mogą być włącznikami światła dzwonkowymi, albo zwykłe. Może po załadowaniu ESPHoma taka funkcjonalność istnieje, nie wiem.
Nie zgadzam się, że należy przenosić inteligencje (algorytmy sterowania) do urządzeń w każdym przypadku. Decentralizować w opozycji do centralizacji. Decentralizacja ma sens, jeśli urządzenie jest w stanie samodzielnie pracować (typu termostat utrzymać temperaturę zadaną wcześniej), czy gotowe urządzenia, typu alarm, źródło ciepła, klimatyzacja. Jeśli część akcji ma być wykonana w HA, to IMHO im prostsze urządzenia wykonawcze tym łatwiej je wymienić jeśli się zepsują. Ale to pewno zależy od konkretnego przypadku i ma znamiona wyższości świąt jednych nad drugimi.

Chodziło raczej o tryb wyjścia…

Nie wiem jaką dokumentację czytałeś, ale mi od razu rzuca się w oczy opis funkcji auto_off

Rzeczywiście. Jest Auto off i auto on. Do skonfigurowania zarówno logując się przez chmurę (aplikacje na telefonie) jak i bezpośrednio po IP na urządzenie. Musiało się pojawić przy okazji którejś aktualizacji. Jak uruchamiałem i podłączałem bramę wiele miesięcy temu nie było takiej opcji, bo bym z niej wówczas skorzystał. Przeglądałem dziś jeszcze interfejs ale nie dość dokładnie jak widać. Meakulpa

Edit
Przejrzałem jeszcze inne urządzenia Shelly i jest taka opcja wszędzie. Mam dimmer2, Shelly 2.5 ver1, sprawdziłem jeszcze Em3 (licznik energii 3f)