Definiowanie poleceń głosowych

Witam,
Chyba utknąłem i nie rozumiem dlaczego :slight_smile:

Próbuję dodać polecenia głosowe do otwarcia bramy i zamknięcia bramy .
Brama nazywa się “switch.brama” i wywołanie w Narzędziach Deweloperskich usługi działa poprawnie:

Dodałem do conversation.yaml:
intents:
GateOpen:
- otwórz bramę
GateClose:
- zamknij bramę
GateStatus:
- co z bramą

a do intents.yaml::
GateOpen:
speech:
text: Brama otwiera się
action:
service: switch.turn_on
entity_id: switch.brama
service: ais_ai_service.say_it
data_template:
text: “Brama otwiera się”
GateClose:
speech:
text: Brama zamyka się
action:
service: switch.turn_off
entity_id: switch.brama
service: ais_ai_service.say_it
data_template:
text: “Brama zamyka się”
GateStatus:
speech:
text: Brama?
action:
service: ais_ai_service.say_it
data_template:
text: “Brama jest {{ ‘otwarta’ if is_state(‘switch.brama’, ‘on’) else ‘zamknięta’ }}.”

W efekcie rozpoznawanie komendy działa ale brama się nie otwiera.
Kiedy powiem “otwórz bramę” to bramka odpowiada “Brama otwiera się” ale fizycznie brama nie otwiera się ani na MQTT nie idzie żaden message do sterownika bramy.

Co jest nie tak?

1 polubienie

Powycinalo mi tabulatory z conversation i intens. Ponizej zrzuty konfiguracji:

conversation.yaml:
conversation.yaml

intents.yaml:
intents.yaml

W akcji masz zdefiniowane 2 serwisy i wg mnie nadpisujesz pierwszy, czyli nadpisujesz zamkniecie bramy komendą say_it. Skasuj linijkę “service: ais_ai_service.say_it” i sprawdź czy działa, a potem bym przetestował czy działają 2 serwisy, ale z myślnikami, czyli coś takiego:

1 polubienie

Ja wyjaśnię tylko, że gdyby Twoja brama była bramą (a nie przełącznikiem) to by działało bez definiowania własnych komend.

Klasa urządzeń cover w HA zawiera:

  • markiza
  • drzwiami
  • żaluzją
  • zasłoną
  • pzepustnicą
  • bramą garażową
  • furtką
  • oknem

dla tych urządzeń działają nasze wbudowane komendy:

Otwórz {urządzenie}; Odsłoń {urządzenie}

Zamknij {urządzenie}; Zasłoń {urządzenie}

Twoja brama jest przełącznikiem (switch) dlatego nie działają na niej wbudowane komendy dotyczące bram.
Ale zadziała komenda “włącz i wyłącz” bo takie komendy są zdefiniowane dla przełączników

Są 2 prostrze wyjścia (nie wymagające definiowania własnych komend głosowych):

  1. Być może łatwiej Ci będzie dodać automatyzację otwierania i zamykania bramy (wraz z powiadomieniami głosowymi) a następnie uruchomić ją komendą:
    Uruchom {nazwa automatyzacji} lub Automatyzacja {nazwa automatyzacji}

Czyli dodaje automatyzację która nazywasz np. “Otwieranie bramy garażowej” tam definiujesz wszystkie akcje które chcesz wykonać żeby otworzyć bramę. Automatyzację uruchamiasz poleceniem głosowym -> Uruchom Otwieranie bramy garażowej itd…

  1. Możesz też przedefiniować swój przełącznik żeby był bramą w systemie (i reagował na polecenia dotyczące bram a nie przełączników).
    Coś takiego robi cover template:

oczywiście to tylko przykład:

cover:
  - platform: template
    covers:
      garage_door:
        friendly_name: "Garage Door"
        open_cover:
          service: switch.turn_on
          data:
            entity_id: switch.garage_door_opener_16
        close_cover:
          service: switch.turn_off
          data:
            entity_id: switch.garage_door_opener_16
        stop_cover:
          service: switch.turn_on
          data:
            entity_id: switch.garage_door_opener_16
        icon_template: >-
          {% if is_state('switch.garage_door_opener_16', 'on') %}
            mdi:garage-open
          {% else %}
            mdi:garage
          {% endif %} 

Ja mam tak ustawione:

a komenda nie działa:
image
Czy zbierzność nazw z binary_sensor może być tego powodem?

masz encje typu switch, powiedz włącz/wyłącz bramę garażową :wink:


Niestety bez zmian :frowning:

Dzieki wszystkim za info.

Stravi,
masz rację. Rzeczywiscie HA nadpisywał jeden serwis drugim i tu był błąd. Zrobiłem z ‘-’ przed “service” i wszystko ruszyło i działa rewelacyjnie !!! Dzieki

Na początku dodaję, że najczęściej używam do sterowania pilota z mikrofonem bo jest najprostszy w uzytkowaniu a poza tym, najbardziej “dla mnie” efektowny :slight_smile: na miarę AI z 21 wieku.
Dodatkowo dla pozostałych moich domowników instalowanie aplikacji, tłumaczenie zasad działania … itp to już nie przejdzie :slight_smile:
Dlatego wybieram pilota z mikrofonem i definiuję własne komendy “poprawnie”, po polsku aby sterowanie odbywało się w sposób jak najbardziej domyślny, naturalny bez szkolenie, uczenia się i problemów.

Co do innych sugestii:

Ja wyjaśnię tylko, że gdyby Twoja brama była bramą (a nie przełącznikiem) to by działało bez definiowania własnych komend.

Urzadzenie zdefiniowane jest jako switch ale to nie był problem. Nawet jakby było zdefiniowane jako “cover” to i tak by nie działało bo drugi service “service: ais_ai_service.say_it” nadpisywał pierwszy czyli otwieranie. W efekcie bramka tylko by mówiła a nie otwierała.

Co do definiowania typu urządzenia “Cover” to jak będę miał czas to się pobawię.

dla tych urządzeń działają nasze wbudowane komendy:
Otwórz {urządzenie}; Odsłoń {urządzenie}
Zamknij {urządzenie}; Zasłoń {urządzenie}

Co do definiowania własnych komend zamiast “Włącz” “Wyłącz” “Otwórz” “Zamknij”. Niestety polski język w przeciwieństwie do angielskiego posiada wiele przypadków i tu pojawia się problem.
Tak jak w ang. “open gate” “close gate” brzmi OK to po polsku “otwórz brama” “zamknij brama” to troche słabo (przynakmniej dla mnie) :slight_smile: Dlatego definiuję własne. “otwórz bramę” “zamknij bramę” “co z bramą?”

Być może łatwiej Ci będzie dodać automatyzację otwierania i zamykania bramy (wraz z powiadomieniami głosowymi) a następnie uruchomić ją komendą:
Uruchom {nazwa automatyzacji} lub Automatyzacja {nazwa automatyzacji}
Z automatyzacją też by zadziałało, ale definiowanie automatyzacji dla 2 akcji: dla switcha i powiedzenia tekstu to troche przerost formy nad trescią. No i przekazanie innym domownikom, że należy powiedzieć “Uruchom otwieranie bramy garażowej” albo “Automatyzacja otwieranie bramy garażowej” nie przejdzie :slight_smile:

Jeszcze raz dzięki za wszystkie odpowiedzi i pytanie:
Przeglądałem troche dokumentacji HA aby rozwiązać problem, ale takich kruczków jak: myślniki przed “service” nigdzie nie znalazłem. Albo kiedy po “service: …” wpisujemy “entity_id: …” czy moze “data: entity_id: …”?

Gdzieś to jest opisane?

zaawansowana konfiguracja systemu Home Assistant jest jeszcze* w języku YAML

myślnik przed elementem oznacza, że jest to element listy
(to nie jest wymysł HA tylko tak działa opisywanie konfiguracji w YAML-u)

Każda integracja HA ma podany przykład konfiguracji w YAML -> Example configuration.yaml entry
z informacją o zmiennych i ich typach

To oczywiście nie jest proste, dlatego od jakiegoś czasu w HA odchodzi się od definicji w YAML na rzecz konfiguratorów w aplikacji i zapisu konfiguracji w plikach JSON.
Z każdą wersję przybywa funkcjonalności i konfiguratorów w aplikacji, idea jest taka, żeby w wersji 1.0 nie było potrzeby definiować niczego w plikach YAML.

*Wersja 1.0 ma być easy - bez potrzeby konfiguracji w plikach. Dlatego nie skupiamy się na wyjaśnianiu jak działa konfiguracja (bo to przejściowe rozwiązanie), ale na dodawaniu funkcjonalności do aplikacji.

W moim przypadku okazało się, że nazwy dla switch oraz binary_switch muszą się różnić - asystent najwyraźniej nie mógł tego odróżnić.

Dodałem też plik covers.yaml, wszystko działa, ale zauważyłem po tej operacji, że po uruchomieniu bramki zniknęła mi w karcie encja związana z openweather :woozy_face: Przypadek? W logach po uruchomieniu bramki error.

image

Traceback (most recent call last):
  File "/data/data/pl.sviete.dom/files/usr/lib/python3.7/site-packages/homeassistant/helpers/entity_platform.py", line 312, in _async_add_entity
    await entity.async_device_update(warning=False)
  File "/data/data/pl.sviete.dom/files/usr/lib/python3.7/site-packages/homeassistant/helpers/entity.py", line 476, in async_device_update
    await self.hass.async_add_executor_job(self.update)
  File "/data/data/pl.sviete.dom/files/usr/lib/python3.7/concurrent/futures/thread.py", line 57, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/data/data/pl.sviete.dom/files/usr/lib/python3.7/site-packages/homeassistant/components/openweathermap/weather.py", line 234, in update
    self._owm.update_forecast()
  File "/data/data/pl.sviete.dom/files/usr/lib/python3.7/site-packages/homeassistant/util/__init__.py", line 240, in wrapper
    result = method(*args, **kwargs)
  File "/data/data/pl.sviete.dom/files/usr/lib/python3.7/site-packages/homeassistant/components/openweathermap/weather.py", line 298, in update_forecast
    self.latitude, self.longitude
  File "/data/data/pl.sviete.dom/files/usr/lib/python3.7/site-packages/pyowm/weatherapi25/owm25.py", line 602, in three_hours_forecast_at_coords
    forecast = self._parsers['forecast'].parse_JSON(json_data)
  File "/data/data/pl.sviete.dom/files/usr/lib/python3.7/site-packages/pyowm/weatherapi25/parsers/forecastparser.py", line 66, in parse_JSON
    for item in d['list']]
  File "/data/data/pl.sviete.dom/files/usr/lib/python3.7/site-packages/pyowm/weatherapi25/parsers/forecastparser.py", line 66, in <listcomp>
    for item in d['list']]
  File "/data/data/pl.sviete.dom/files/usr/lib/python3.7/site-packages/pyowm/weatherapi25/weather.py", line 583, in weather_from_dictionary
    visibility_distance, dewpoint, humidex, heat_index)
  File "/data/data/pl.sviete.dom/files/usr/lib/python3.7/site-packages/pyowm/weatherapi25/weather.py", line 74, in __init__
    raise ValueError("'clouds' must be greater than 0")
ValueError: 'clouds' must be greater than 0

Co robię źle?
Jolka mówi: Jest UNKNOWN stopni w komputerowym.

Wstawienie states.sensor.time.state oczywiście sprawi, że w miejsce UNKNOWN powie godzinę, ale temperatury nie chce powiedzieć… Czemu?

Najwyraźniej stan twojej encji jest UNKNOWN (nie widać tego na twoim zrzucie).
W Narzędziach developerskich możesz sprawdzić swój SZABLON :

oraz STAN swojej encji filtrując po nazwie:

1 polubienie

Nie potrafię powiedzieć dlaczego - sprawdziłem stan encji w/g tego, co napisałeś. Pojawiła się cyfra, a Jolka powiedziała poprawną wartość. A więc działa. Tylko co się zmieniło od wczoraj? [ nie dokonywałem żadnych zmian w konfiguracji. żadnych. ] Magia.

Nie - nie ma tu żadnej magii :slight_smile:, ale łańcuszek jest dość spory i wiele rzeczy po drodze może się nie udać:
Masz LYWSD03 czyli termometr gadający po BLE z ESP32 - w nim zapewne Tasmota deszyfruje komunikat wg bind_key i przesyła wartości przez MQTT po WiFi do bramki AIS-dom, na której HA przechowuje dane w encji, którą to Jolka może oczytać.
Jak zrestartujesz bramkę, a termometr będzie poza zasięgiem ESP32, albo ESP32 nie połączy się z WiFi, to HA nie będzie miało co pokazać, a stan encji jest nieznany = UNKNOWN do czasu otrzymania pierwszego komunikatu.

Przyznam, że też tak to widzę. Bramka BLE<->WiFi jest na NodeMCU z podłączonym HM10 na Tasmota. Reszta się zgadza. Ponieważ TelePeriod=300 sek. to mogło dokładnie zdarzyć się to, co napisałeś.