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.
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:
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):
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…
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:
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 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
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) 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
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: …”?
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 Przypadek? W logach po uruchomieniu bramki error.
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
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 , 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ś.
na miarę AI z 21 wieku.
Przypadek? W logach po uruchomieniu bramki error.
