0.117.7 wydana
Uwaga . Wyjątkowo ta aktualizacja będzie 2 etapowa.
Każde wymagane kliknięcie 
opisane krok po kroku na blogu - w wolnej chwili zapraszamy do lektury i aktualizacji.
5 polubień
@jolka W domumentacji jest chyba błąd bo powinno być 0.117.7 Automatyzujemy i w opinie jest chyba zła wersja ha
Po aktualizacji mam problem z sensorami, a mianowicie często pokazują błąd odczytu, a co za tym idzie sypią się automatyzacje
Witam wszystkich czy to możliwe ze po aktualizacji mam zła date zamiast 18/11 mam 17/11 jak to zmienić,a jescze jedno zniknęła ikonka zigbee z bocznego paska
Cześć,
zigbee znikneło z bocznego paska w poprzedniej wersji i wtedy o tym informowaliśmy
teraz nowa aplikacja zigbee jest tu
1 polubienie
Cześć Mariusz,
przy tej złożoności systemu… wszystko się może zdarzyć jak w “efekt motyla”
Zobacz proszę czy to się unormuje, czy może jest gdzieś faktycznie problem w HA albo Tasmota (bo domyślam się, że to o te sensory chodzi).
Jeżeli będzie dalej problem to opisz proszę dokładnie jak to “nie działa” / o co chodzi - zobaczymy czy da się to jakoś wytłumaczyć / rozwiązać… po znajomości
Mam taki sam problem jak w tym wątku:
https://github.com/home-assistant/core/issues/42608?fbclid=IwAR27fGxeiqEK6DbTm0kLtxD-PPUzNJAHxdShU3m8-R8JfcKIc8XxnLOO41A
Posiadam serownik PLC Sterbox, a stany odcztywałem za pomocą sensorów:
- platform: rest
name: brama garazowa czujnik
resource: http://192.168.X.XXX/@gcd?bragarcz
payload: ‘{ “device” : “heater” }’
value_template: “{{ value | replace(’,’, ‘.’) }}”
scan_interval: 1
Logi:
Logger: homeassistant.components.sensor
Source: helpers/entity_platform.py:604
Integration: Sensor (documentation, issues)
First occurred: 18:27:54 (3660 occurrences)
Last logged: 19:27:04
- Updating rest sensor took longer than the scheduled update interval 0:00:01
- Updating rest sensor took longer than the scheduled update interval 0:00:03
- Updating rest sensor took longer than the scheduled update interval 0:00:05
Logger: homeassistant.components.rest.data
Source: components/rest/data.py:63
Integration: rest (documentation, issues)
First occurred: 18:27:12 (6693 occurrences)
Last logged: 19:27:03
- Error fetching data: http://192.168.X.XXX/@gcd?rwkki failed with
- Error fetching data: http://192.168.X.XXX/@gcd?zukue failed with
- Error fetching data: http://192.168.X.XXX/@gcd?wykk failed with
- Error fetching data: http://192.168.X.XXX/@gcd?rwyli failed with
- Error fetching data: http://192.168.X.XXX/@gcd?rwyl failed with
Wykasowanie scan_interval nic nie pomogło
Zrobiłem wczoraj aktualizacje, wszystko działa jak należy.
Do tego zniknął problem o którym pisałem tu.
Po aktualizacji bramka zdecydowanie przyspieszyła 
Co do kalendarza wydań Asystenta domowego to coś jest nie tak:
Integracje mam zrobioną poprzez wpis w configuration.yaml i konsole programistyczną google czyli nie przez Kalendarz Ais, ale czytam że tam jest tak samo.
OK, czyli Home Assistant nie czeka na odpowiedz ze sterowanika i jest timeout… a potem następny update jest ustawiony na za seknde… itd… bez końca, aż coś/ktoś w końcu nie wytrzyma, albo ten sterownik albo Home Assistant albo bramka albo ja!
Na początku zastanawiałem się po co wysyłasz do czujnika w bramie garażowej komunikat
payload: ‘{ “device” : “heater” }’
tak jakby ta brama była podgrzewaczem …
Wzieło to się pewnie ze strony HA, gdzie był przykład wysłania POST-a:
oczywiście nikt już nie doczytał, co znaczy payload
Pomyślałem, że najlepiej sprawdzę co to jest Sterbox, zobacze jakie mają API żeby normalnie się z nimi komunikować.
No i wszedłem na stronę producenta a tam niespodzianka:
Czyli oni podają skopiowany przykład komunikatu HA, jako komunikat w swojej dokumentacji.
Prawdę mówiąc, tego typu konunikacja - odczytywanie stanu co sekundę za pomocą GET-a to trochę jak krzesanie ognia za pomocą pocierania gałęziami.
Miło, że napisali o nas na stronie… ale ja bym się wstydził opisywać komunikację za pomocą GETów co sekundę jako API.
Jak by wszystkie urządzenia IoT komunikowały się za pomocą GET po HTTP to nie dało by się w internecie strony otworzyć bo cała sieć była by przeciążona.
Wyobraź sobie, że ktoś Ciebie pyta co sekundę o status:
Hej, czy jesteś otwarty czy zamknięty?
1s
Hej, czy jesteś otwarty czy zamknięty?
1s
Hej, czy jesteś otwarty czy zamknięty?
1s
Hej, czy jesteś otwarty czy zamknięty?
1s
Hej, czy jesteś otwarty czy zamknięty?
…
i tak w nieskończoność.
To jest słabe… to jest złe - nie róbcie tego typu komunikacji 
Poczytajcie o MQTT o lekkim protokole stworzony do komunikacji IoT w którym nik nikogo nie pyta o nic a jednak wszyscko wiadomo.
3 polubienia
Możliwe, że jakieś typy zdażeń (może cykliczne) mają ten problem…
Zobaczymy jak się potoczy temat z cetyfikacją w Google. Jak dostaniemy full dostęp to poprawimy ten rzeczy, jeżeli nie to przejdziemy na inny kalendarz, może offline na bramce.
Spoko - pomyślimy 
1 polubienie
Bramkę konfiguruję od kilku miesięcy ucząc się wszystkiego od początku, YT, fora i Google. Teraz jeszcze muszę jakieś MQTT ogarnąć, nie lubię się pytać o gotowce, bo nie chce wyjść na totalnego amatora, staram się zrozumić dlaczego jest tak, a nieinaczej. Problemem dla mnie jest znikoma (praktycznie żadna) informacja z integracją Sterbox.
Czytając teraz o MQTT to też brak szablonu jak połączyć ten sterownik z bramką ehhh.
Idę z żoną spędzić wieczór.
Mqtt to raczej powinien mieć zaimplementowane ten sterbox.
Kilka dni temu spotkałem się z czujnikiem do Szamba polskiej produkcji który łączył się z mqtt - banalne rozwiązanie, a o ile łatwiejsza integracja.
Ta instrukcja na ich stronie jest ode mnie. Dopiero zaczynałem zabawę z HA i rzeczywiście nie usunąłem tego nie doczytujac do czego służy. Potem już nie robiłem aktualizacji.
Niestety sterbox oferuje tylko resta. Zresztą ich aplikacja działa dokładnie w ten sam sposób, a producent twierdzi że nawet tak częste odpytywanie nie stanowi dla bramki problemu, choć na początku miałem obawy co do tego.
Mam już masę czujników po rest i wszystko działa stabilnie - zarówno sterbox jak i AIS.
Manual w wolnej chwili poprawie i podeślę im.
Sterbox sam w sobie ma stronę sterowania. Producent nie przewidział integracji z HA. To był stricte mój pomysł by tak to spiac.
Jeśli coś jest głupie ale działa, to już nie jest takie głupie 
choć do ideału oczywiście daleko.
Ale z drugiej strony też bym tak nie demonizował rest-a, jeśli redfish, którego oferują producenci enterprise hardware dla korporacji także opiera się się na restfull. Co innego ładować stronę generwana dynamicznie co 1 sek, a co innego pobierać jedną zmienną w sieci prywatnej na dedykowanym do tego urządzeniu. Możnaby się pokusić o zebranie wszystkich stanów jednym requestem i parsowac przez template, ale jeśli działa tak jak działa…
1 polubienie
Czołem @Owczar
poczytałem teraz posty - to co zrobiłeś, to są fajne rzeczy i naprawdę dzięki w imieniu AI-Speaker, bardzo lubimy takich kreatywnych użytkowników.
Mało kto był w stanie tak jak Ty, rozkminić takie rzeczy jak integracja REST i doprowadzić do działania z np. taki sterownikiem.
Dodatkowo (i co faktycznie najważniejsze), jeżeli to działa i jest stabilne to kolejny maga Kudos to you!
Bo jako nieliczny na tym forum 
piszesz, że Tobie coś działa 
Postaram się wytłumaczyć co ja zobaczyłem i dlaczego tak zareagowałem:
RESTfull jest OK do pewnych zastosowań, na bramce mamy API w RESTfull
po tym API można np. wysłać tekst do przeczytania albo komendę do wykonania i wszystko będzie OK.
Ale pytanie w ten sposób co sekundę o np. status bramki uznałbym za przynajmniej nie najlepszy pomysł albo nawet kwalifikowałbym to jako jakiś atak typu DDoS
Chodzi o to, że protokół HTTP (którego używa RESTfull) ma spory narzut wielkości wiadomości i jej komplikacji co powoduje, że jest on 100 razy wolniejszy od MQTT. Jak zaczniemy pytać co sekundę urządzenia o ich status za pomocą RESTfull to scenariusz jest taki, że urządzenie przestanie odpowiadać w ustalonym czasie, a potem my zaczniemy logować problemy i nie będziemy w stanie wykonywać automatyzacje itd… w konsekwencji wszystko zwolni i przestanie normalnie działać.
Za pomocą RESTfull (działającym po HTTP) możemy zapytać serwera o pogodę, odświeżyć stronę w przeglądarce.
Metoda GET w przeglądarce którą wykonujesz wchodząc na dowolną stronę internetową to jest dokładnie to samo co wywołujesz z HA pytając o status to urządzenie Sterbox.
Wyobraźmy sobie, że odświeżamy przeglądarkę co sekundę, żeby zaczytać stronę (najnowszą wersję bez cache) przy odpowiedniej liczbie klientów każdy serwer padnie - tak działa DDoS.
Protokół HTTP został wymyślony do dokumentów nie do przesyłania danych pomiędzy urządzeniami.
Ale skracając już wątek - pytając co sekundę o status urządzeń za pomocą RESTfull to nie jest integracja urządzeń, to jest trochę gwałt urządzenia przez urządzenie
Żeby temat był jasny, mnie to absolutnie nie rusza dopóki ktoś sobie z tym radzi tak jak Ty.
Każdy może sobie odpytywać urządzenia w pętli co sekundę jeżeli mu to działa
Niestety potem ktoś inny to wkleja i już mu nie działa… no i wiadomo nie jest winny ten sterownik za 1000 zł który komunikuje się po HTTP bo on pewnie jest super, tylko pewnie ta tania bramka i ta aktualizacja którą nieudacznicy po miesiącu wydali (pewnie bez testów) 
Oczywiście specjalnie przesadzam, ale w sumie tak możemy być postrzegani przez kogoś kto wejdzie na to forum z Internetu i nie ma pojęcia co robimy i czym jest ten produkt (99.99% ludzi).
Ale żeby było konstruktywnie, wg mnie żeby uniknąć problemów trzeba rzadziej pytać urządzenia o status po HTTP, a najlepiej przejść na MQTT.
Przepraszam z przydługi wywód i jak mówią starożytni Rosjanie - no hard feelings
Tu jeszcze argumenty:
2 polubienia
Ale tak czytam o mqtt i dobrze rozumiem, że to musiałoby być wspierane po stronie urządzenia?
Więc tak czy inaczej w tym przypadku nie pozostaje nam nic innego.
Na pewno dobrze by było ograniczyć scan interval dla sensorow, które tego nie wymagają tak często.
Oczywiście rozumiem, Twój punkt widzenia i zgadzam się w pełni. Ale z drugiej strony to nie przestało działać po dodaniu x sensorów i restarcie, tylko po update do nowej wersji.
Kiedy rozmawiałem z producentem tego pudełka sam byłem pełen obaw ile to wytrzyma requestow. Nie był w stanie podać liczby ale według niego aplikacja na telefon działa w ten sposób, a nawet natywny frontend odświeża informacje tak samo. U mnie na służbie są 3 sztuki - co prawda nie mam jeszcze wszystkiego, ale czujników już kilka jest i to w ogóle nie puchnie - co nie znaczy że w pewnym momencie nie zacznie. Nie jestem specjalistą, ale ddos znam. Może z ciekawości przetestuję granicę bólu w sterbox.
Tak czy inaczej, na ten moment to według mnie nie jest problem samego sposobu komunikacji, bo kiedy ha nie może uzyskać odpowiedzi, sterbox odpowiada na requesty. Maniek pytał mnie czy mam taki sam problem, ale ostatnia wersja 0.116.6 działa u mnie bardzo stabilnie i nie robiłem aktualizacji.
Nasze podejrzenie potwierdzaja liczne tematy na github: https://github.com/home-assistant/core/issues/42589
I żeby nie było - nikt nie wini samej bramki, a po prostu wygląda to na problem w ha.
Robicie tutaj super robotę i wszyscy jesteśmy dalecy od tego żeby szukać dziury w całym, a po prostu rozwiązania.
Wbrew pozorom sterbox ma sporo klientów i już z kilkoma osobami pisałem o integracji ha ze sterbox - jedna z nich to maniekbeton. Pomijając to pseudo API - urządzenie ma też swoje zalety
Spoko, ważne, że rozumiemy jak to działa i o co chodzi.
Żeby wszyscy zrozumieli to podsumuję tu klika rzeczy:
-
HTTP i RESTful jest OK do API pomiędzy aplikacjami
jak wchodzisz do apki mobilnej, ablo wywołujesz stronę w przeglądarce to robisz GET-a do serwera żeby wczytać dane (może klika GETów) i to jest OK
jak chcesz włączyć światło to klikasz i robisz kolejn jedno wywołanie RESTful i do jest OK - nikogo to nie boli -
jak zlecasz bramce żeby robiła GET-a co sekundę do jakiegoś urządzenia, to NIE jest OK
metoda jest tak sama co w telefonie, przeglądarce, ale częstotliwość powoduje, że to już nie jest komunikacja interfejsem ale atak DDoS (tam też metoda jest ta sama ale częstotliwość powoduje problem).
Jak bramka tak działa to przestaje być “Smart IoT gateway” a zaczyna być “IoT device rape gateway”
-
Wg nas HA nie powinno pozwolić na wysyłanie tak często zapytań do urządzeń i jak dla mnie to oni tego nie zepsuli tylko poprawili. My raportujemy stataus sensorów online po zmianie statusu. W MQTT nie pytasz o status tylko deklarujesz, że chcesz otrzymać informacje o statusie i słuchasz co urządzenie raportuje. Nie ma bezsensownego odpytywania, obciążania sieci, grzania procesorów i marnowania prądu.
-
Jeżeli urządzenie nie rozumie MQTT a tylko HTTP, to może samo jest w stanie raportować status sensorów po ich zmianie do bramki (bez potrzeby ciągłego pytania w nieskończonej bezsensownej pętli) - np. po webhooku za pomocą HTTP RESTful. Jeżeli trzeba to wyjaśnimy jak to zrobić.
Musi być jakaś lepsza metoda niż odpytywanie co sekundę… Mnie jako osobę która programuje systemy, odpytywnaie czegoś co sekundę, fizycznie boli jak na to patrze. Nigdy czegoś atkiego nie zaimplementowałem w kodzie u Klienta bo nie mógł bym spać w nocy
Nie traktujcie tego proszę, że się przyczepiłem, fajnie, że razem integrujemy i pełny respect dla Was Panowie @Owczar @maniekbeton i dzięki, że jesteście z nami i nas popieracie 
Napisałem to tylko po to żebyśmy trochę byli świadomi tego jak to działa pod spodem.
PS
Wyjaśnię, że “gwałcenie urządzeń IoT” to termin, który wymyśliłem kiedyś… i który pewnie tylko mnie bawi (specyficzne poczucie humoru). To było trochę pod wpływem komentarzy “Integratorów HA z forum na FB”. którzy ze swojego doświadczenia wiedzą, że - żeby porządnie sterować żarówką w domu to trzeba mieć:
- co najmniej poleasingowego HP z i5 8G RAM i dyskiem 1TB,
- odpalić na tym serwerze trzeba kilka kontenerów Dockera (za pomocą kliknięcia) i super wisiora (do klikania w późniejszym czasie)
- ma to chodzić w garażu (żeby nie buczało żonie) i w nieskończonej pętli gwałci wszystkie urządzenia IoT aż żar z jego brzucha niech bucha!
- Nie ważne, że rachunek w moim “smart” home za prąd wzrósł o 50 zł miesięcznie! Ważne, że jest smar!
- AI-Speaker nie jest OK, bo chcą pieniądze za OpenSource a ich bramka ma za małego *RPS-a do smart home
*RPS - rape per second
2 polubienia
W pełni się z Tobą zgadzam, że to złe, nieelganckie i może szkodzić. Urządzenie nie zadziała z MQTT i raczej wątpię by producent do tej wersji zaimplementował MQTT, aczkolwiek z nim pogadam. Jakby nie było to jedyna metoda na ten moment - znana mi.
Jest jedna opcja do raportowania statusu między sterboxami - tzw aliasy. Ustawiamy IP innego sterboxa i po zmianie wysyłana jest informacja o zmianie statusu. Zapytam producenta jak to działa i zobaczę, czy jest jakaś opcja by HA to w jakiś sposób zrozumiało.
Odnośnie “PS”-a, tak widziałem te wpisy. Oni sobie zrobią za “darmo”. Szczerze mówiąc to więcej jest wart czas na szukanie urządzenia, stawianiue linuxa, androida, dockera czy co tam jeszcze potrzeba. Cena tej bramki jest naprawdę symboliczna w stosunku do tego co dostajemy - gotowego.
Choć tak jak pisałem - w tej chwili to raczej wygląda na jakiś problem po stronie rest-a, a konkretnie pythona.
Nie działa nawet u osób, które mają scan interval 30s.
1 polubienie
Dzięki pomocy kolegi @Owczar udało się postawić połącznie między Sterbox a AIS Dom. Sensor został przerobiony z platform: rest na platform: commond_line
Oto Przykład:
- platform: command_line
name: gaz
command: ‘curl http://192.168.X.XXX/@gcd?gaz’
scan_interval: 10
Niestety dalej katuję komunikację między urządeniami, ale liczę że uda się połączyć te dwa projekty w całość, co stworzyło by super produkt dla domowego pasjonaty.
Panie @araczkowski żeby nie było że na tym forum wszystkim coś nie działa i mamy same problemy to chcę powiedzieć że bramka AIS Dom bardzo mi się podoba i co chwilę odkrywam jej nowe funkcje
Bramka obsługuje u mnie:
83 Sensory
115 automatyzacji
Kalendarz już od kilku miesięcy
Alarm z 4 strefami
Powiadomienia o zagrożeniach pogodowych
Notyfikacje z Telegramem HA i AIS Dom
Lokalizacje domowników
NFC
Sterowanie głosowe zegarkiem
i będą jeszcze inne
Dziękuję za pomoc i zrozumienie że nie wszyscy jesteśmy na tym forum fachowcami w tym temacie.
5 polubień
Dzięki za takie miłe słowa Przyjacielu! Naprawdę imponująca ilość integracji - Szacun 
Gdyby pojawiły się jakieś problemy wydajnościowe, to zacząłbym od wyłączenia tych sensorów, które robią w nieskończonych pętlach GET-y żeby pytać o statusy, które się nie zmieniły. Nie rozwiązuj ewentualnych wydajnościowych problemów (które niestety mogą się pojawić przy większej ilości tego typu integracji), przez zakup serwera… bo to nie tędy droga. Szkoda na to prądu, pieniędzy i naszej piękniej planety 
PS
Ja oczywiście ja wiem, że pisanie:
Wyobraź sobie, że ktoś Ciebie pyta co sekundę o status:
Hej, czy jesteś otwarty czy zamknięty?
1s
Hej, czy jesteś otwarty czy zamknięty?
1s
Hej, czy jesteś otwarty czy zamknięty?
1s
Hej, czy jesteś otwarty czy zamknięty?
1s
Hej, czy jesteś otwarty czy zamknięty?
…
i tak w nieskończoność.
I tłumaczenie, że to nie jest fajne, dla kogoś kto nie wie, ile niepotrzebnych rzeczy w systemie się dzieje przy takim zapytaniu… to jest abstrakcja.
Pewnie podobna abstrakcja jak to, kiedy mówię mojej córce:
Asiu, nie ciągnij kota za ogon, bo to go boli.
Pomyśl, jak byś się czuła, jakby to ciebie ktoś za ogon ciągnął?
Tym humorystycznym akcentem zakończę ten wątek, mam nadzieje, że nikogo nie uraziłem moim specyficznym poczuciem humoru i komentarzami. Miłego Weekendu Panie Mariuszu
PS2
@Owczar gdyby trzeba było pomóc przy integracji po webhook-u to pisz śmiało na info@ai-speaker.com postaramy się podpowiedzieć jak to zrobić żeby było bardziej efektywnie
3 polubienia