Nie wiem czy wszyscy o tym wiedza, ale jest mozliwosc integracji urzadzen firmy Sonoff z AIS bez potrzeby zmiany softu. Przydatne dla tych, ktorzy albo nie chca albo nie moga podmienic softu (bo np nie chca stracic dostepu do oryginalnej apki EweLink lub boja sie podpinac kabelkow tudziez rozbierac urzadzen).
Cala procedura polega na wykorzystaniu tzw custom_components i jest opisana na tej stronie: GitHub - peterbuga/HASS-sonoff-ewelink: Home Assistant component to control Sonoff/eWeLink devices with original firmware. Jedyne co - domyslnie bramka AIS nie ma obslugi websocket w pythonie i trzeba je doinstalowac. U mnie pomogly komendy:
pip install websockets
pip install websocket-client
pip3 install -r requirements.txt
pip3 install websockets
pip3 install websocket-client
Wydaje mi sie czesc z tych komend byla zbedna ale zadna nie zaszkodzila. A robilem to jakies 2tyg temu, pozno w nocy wiec przepisalem po prostu polecenia z historii.
Nastepnie w configuration.yaml dopisujemy sekcje sonoff wg instrukcji i finito - mozna dodawac urzadzenia sonoff do AIS.
Teraz uwaga praktyczna - u mnie wiekszosc urzadzen sonoff sluzy do zapalania swiatel a AIS (podobnie jak HA) domyslnie traktuje je jako przelaczniki (czym w praktyce sa). Na szczescie HA/AIS daja mozliwosc zmiany typu urzadzenia. Aby to uczynic nalezy:
w pliku configuration.yaml dopisac sekcje light: !include light.yaml
stworzyc sobie plik ~/AIS/light.yaml w ktorym beda wpisy typu
platform: switch
name: Twoja nazwa nr 1
entity_id: switch.sonoff_xxxxxxx
platform: switch
name: Twoja nazwa nr 2
entity_id: switch.sonoff_xxxxxxx
Gdzie sonoff_xxxxxxx to id urzadzenia. Mozna je znalezc na liscie encji w AIS.\
Uwagi praktyczne:
przedefiniowanie przelacznikow jako swiatla pozwoli na latwe operowanie typu “wylacz wszystkie swiatla”. ponadto, latwiej uzywac identyfikatorow typu light.kuchnia niz switch.sonoff_10890890
zamiast tworzenia light.yaml mozna te informacje wpisac bezposrednio w pliku configuration.yaml. Ja po prostu lubie miec porzadek
kazdy przelacznik Sonoff przedefiniowane w pliku light.yaml bedzie dostepne w AIS w obydwu postaciach - zarowno jako typ switch jak i light
Sonoff ma ograniczenia jesli chodzi o jednoczesne sesje logowania sie uzytkownika. To oznacza ze zalogowanie sie na konto Sonoff w AIS spowoduje automatyczne wylogowanie z aplikacji EweLink. Natomiast ciekawostka - nie spowoduje to wylogowania na koncie Amazon Alexa ani Google Home
Aha - tradycyjnie na koniec nalezy sprawdzic poprawnosc pliku configuration.yaml (menu Configuration → Server Controls → Check Config) i zrestartowac bramke poprzez panel www/aplikacje
Zgadza się działa ale w logach ten custom component sonoff sypie błędami. Używam jednego sonoff SV (do włączania pieca gazowego), który nie dał się sflashować bo nie ma pinów do programowania ale za to ma fabrycznie pełne wyjście beznapięciowe przekaźnika NC/NO/COM bez żadnych przeróbek.
Skoro nie dal sie sflaszowac to rozumiem ze masz oryginalny soft Sonoff. Wkleisz logi? U mnie tez sypalo logami wlasnie zwiazanymi z websockets. Ja co prawda nie integrowalem Sonoff SV ale parowalem kilka innych urzadzen (slampher, sonoff rf oraz sonoff s20/s26).
Moze byc tez temat roznic w platformie - z tego co zrozumialem watek odnosnie hard resetu, rozne urzadzenia moga miec rozne wersje softy platformy AIS, wiec Tobie moze brakowac czegos innego.
Takiego bledy nie mialem, zwlaszcza ze ja nigdzie nie podaje adresu serwera sonoff Rozumiem ze DNS na AIS dziala Ci poprawnie? Warto na wszelki wypadek sprawdzic:
Ja integracje Sonoff-HA robilem w pazdzierniku. Teraz prostu przegralem folder sonoff z RPi na AIS. Ale sprawdzilem, od pazdziernika nie zmienil sie kod na githubie, wiec zmiane w sofcie mozna odrzucic. Na liscie wspieranych urzadzen nie ma Sonoff SV ale z tego co kojarze roznica pomiedzy Sonoff SV a Sonoff Basic to tylko kwestia napiec.
Mozesz przetestowac jedna rzecz - zaloz sobie zupelnie nowe konto ewelink, nie podpinaj do niego zadnych urzadzen ale sprobuj je zintegrowac z AIS.
Ok, pobawię się ale bardziej szukam takiego rozwiązania, żeby encje switch.kuchnia zamienić na light.kuchnia bez tworzenia nowej encji
Edit:
tu chyba jest błąd, winno być: light: !include light.yaml
Edit:
Nigdy tego nie testowalem ale wg dokumentacji HA mozna zdefiniowac czy encja ma byc widoczna czy nie. Trzeba uzyc sekcji customize , opis jest tutaj
Coś nie działa te ukrywanie, zrobiłem zgodnie z opisem czyli w customize.yaml ma wpis:
switch.incan_korytarz_gora:
friendly_name: Korytarz Góra
hidden: true
a i tak encja jest widoczna
Ktoś ma jakiś pomysł ?
Mam kilka własnych DIY w których np. 2 przełącznik są switch (gniazdko + pompa do basenu) a 2 to włączniki światła a wszystkie w AIS pokazują się albo jako 4 switch albo 4 light (zależy jak wybiorę przy dodawaniu do bramki), muszę je rozdzielić…tylko jak ?
Enforce Home Assistant auto-discovery as ligh 0 = relays are announced as a switch and PWM as a light (default) 1 = both relays and PWM are announced as light
czyli jak coś takiego wpiszesz w konsoli urządzenia które jest przełącznikiem:
SetOption30 1
to w Asystencie domowym takie urządzenie przedstawi się jak światło a nie przełącznik
@jolka dziękuje pięknie.
Oczywiście działa z tym, że można tylko zmienić wszystkie na Light albo wszystkie na Switch, czyli jak mam na jednym DIY cztery przekaźniki to nie można cześć zrobić Light a część Switch.
Po wczorajszej aktualizacji bramki cos mi sie popsulo i mam dokladnie ten sam problem. “No address associated with hostname” pojawia sie kilkukrotnie. Wyglada na jakas regresje.
Zalaze osobny watek bo problemy sa nie tylko z modulem sonoff.
To nie jest wspierane, trzeba zrozumieć czy są custom componetns i dlaczego nie są dodane oficjalnie do Home Assistant.
Nikt nie zagwarantuje działania czegoś takiego bo to nie jest legalne - producent (Sonoff czy Tuya) nie wie o tym, że ktoś tego w ten sposób używa (podszywając się pod ich aplikacje), to w każdej chwili może przestać działać. Nie mamy żadnej umowy z Tuya czy Sonoff (nie informują nikogo o zmianach w interfejsie). Jedyny sposób na stabilnie działające urządzenia tych firm to lokalne MQTT które dostarczamy na bramce i wspieramy. Bo do tego mamy kody i na działanie tego mamy wpływ.
Stosowanie custom components może powodować, że będziesz miał problemy ze stabilnością całego systemu na bramce, tym bardziej, że jak sam przyznajesz nie dokońca rozumiesz co robisz:
U mnie pomogly komendy:
pip install websockets
pip install websocket-client
pip3 install -r requirements.txt
pip3 install websockets
pip3 install websocket-client
Wydaje mi sie czesc z tych komend byla zbedna ale zadna nie zaszkodzila.
To co instalujesz na bramce ma wpływ na inne komponenty. I może prowadzić do tego, że przestanie Ci coś działać lub się instalować - z powodu zależności pomiędzy pakietami.
PS
Żeby była sprawa jasna nie zabraniamy nikomu eksperymentować, ale nie zgłaszaj wyniku swoich eksperymentów jako problemów/regresji na bramce, bo to nie prawda.
Wprowadzimy kategorie: Komponenty niestandardowe / Custom components i będziemy tam przenosili te tematy żeby była jasność, że to nie jest wspierane.
Po czesci sie zgadzam. Na pewno dobrym pomyslem jest stworzenie osobnej kategorii dla custom components
W konkretnym przypadku z instalacja websockets - moje watpliwosci byly glownie czy powinienem uzyc pip czy pip3 bo nie wiem czy sonoff wymagal pythona 2.x czy tez 3.x.
instalujesz websockets w najnowszej wersji dostępnej w repo z którego to zostanie zainstalowane
w sumie to nie wiadomo w jakiej
Jeżeli jakiś wbudowany komponent w Home Assistant będzie wymagał websockets we innej wersji niż ta którą ręcznie zainstalowałeś, to nie uda się jego instalacja - nie będą spełnione zależności.
Jeżeli ten komponent dojdzie w aktualizacji to nie uda się aktualizacja Twojego systemu.
Ok a mam pytanie jeśli wydałem polecenie
pip install websockets
i chyba po nim zaczęły szwankować komendy wydawane do pilota, to jak powrócić do oryginalnej wersji?
Rozumiem ze DNS na AIS dziala Ci poprawnie? Warto na wszelki wypadek sprawdzic:
