Natywna integracja z Home Assistant (komponent)

Bardzo proszę odpowiedź w tym temacie:
https://extalife.pl/forum/topic/131/#postid-426

Cytuj

Dzień dobry,
Sposób komunikacji został zmieniony, aby zyskać w 99.9% pewność, że stan wskazywany w aplikacji jest poprawny (załącz lub wyłącz). Przy większej ilości urządzeń, a zarazem większym czasie odpowiedzi wszystkich odbiorników zdarzały się sytuacje, w których były pomyłki. Gdy będziemy mieć rozwiązanie, które pozwoli na uzyskanie pewności wyświetlania stanu odbiorników to taką funkcjonalność wprowadzimy.

Na dzień dzisiejszy nie zalecamy stosowania komponentu Home Assistant, który nie jest przez nas autoryzowany. Po analizie i testach zauważyliśmy pewne problemy, które powodują zawieszanie się kontrolera, kasowanie odbiorników lub samych ustawień kontrolera. Temat integracji EXTA LIFE z innymi systemami, traktujemy bardzo poważnie.

Przemek, ZAMEL

Cytat: przemek.zamel w Maja 08, 2020, 15:52:24

Temat integracji EXTA LIFE z innymi systemami, traktujemy bardzo poważnie.

Nie wiem jak rozumieć te słowa. Nadal nie wiemy jaka przyszłość czeka nas jako użytkowników systemu ExtaLife. "Poważnie" - to znaczy integracja jako zagrożenie, czy "poważnie" - będziemy integrować z innymi?

Czy możemy poznać, choć trochę, ze strategii rozwoju tego produktu? Innymi słowy, czy są decyzje w jakim kierunku będą szły prace?  I najważniejsze, z naszego punkty widzenia, czy soft kontrolera pozwoli na pełną integrację z Home Assistant?
Odczytuję powyższą odpowiedź jako zarzut dla autora integracji, iż takowa powoduje problemy z kontrolerem.
Osobiście śpię spokojniej po integracji z HA i przejęciu przez niego automatyzacji w moim domu. Winy doszukiwał bym się w wadliwym oprogramowaniu kontrolera. Błędy w oprogramowaniu bywały krytyczne. Obecnie jest ich mniej ale mam wrażenie, że w największej mierze właśnie dzięki testerom z tego forum. Gubienie odbiorników prawie regularnie mam od 4 lat. Na długo przed tym jak zacząłem czytać na tym forum i upewniłem się, że nie jestem sam. Najgorsze, że użytkownicy klną pod nosem a po latach nawet zaczęli się przyzwyczajać do tych chorych niespodzianek. Jestem fanem ExtaLife jako idei - pomysłu rodzimego producenta (podobnie jak Supli). Wiele można zarzucić wprowadzeniu systemu ExtaLife ale, to może być super produkt o wielkim zasięgu rynkowym. Jest prosty w konfigurowaniu i intuicyjny dla laika. Kibicuję zwłaszcza Tobie i liczę na więcej konkretnych informacji o planach i produktach. Mogą przekonać niezdecydowanych, mogą podtrzymywać nasze nadzieje i nie wypierać tych fajnych urządzeń z rynku. Wszyscy na tym mogą zyskać.

Szkoda, że informacja "nie zalecamy stosowania komponentu Home Assistant idzie w takim tonie. Uważam, że jasne powiedzenie o konkretnych faktach było by in plus, dla świadomie kupujących ExtaLife. A tak niektórzy mogą się czuć oszukani. Jak kolega Piotrek_M.
"Działało? Działało...

Działa? Nie działa..."

Minęło tyle czasu, że odpowiedzi raczej nie wypada się spodziewać...Zdjęcie strony extalife.pl raczej też nie napawa optymizmem, chyba że to zwiastun czegoś większego. Nie wiadomo...

Tymczasem ja przygotowuję się do wypuszczenia kolejnej, "dużej" wersji naszej integracji. Jak już wspominałem w kilku postach zmian i nowości będzie dużo. Mam nadzieję, że stabilną wersję testową uda mi się wypuścić przed wakacjami, czyli do połowy czerwca. Stay tuned

Moje środowisko testowe już czeka...HA Supervisor w docker, host Linux Ubuntu 20.04 LTS.

Moje środowisko testowe już czeka...HA Supervisor w docker, host Linux Ubuntu 20.04 LTS.

No to git! 👍 Potencjalni testerzy niech zbroją się w cierpliwość i w wolne moce systemowe 😉

Ja zamierzam upiec dwie pieczenie na jednym ogniu i nową wersję przenieść na nową instancję HA na moim Synology - ze zwykłej HA Core w Docker na HA Supervised za pomocą nieoficjalnego pakietu hass.io na Synology, który umożliwia uruchomienie typu Supervised. Skok na kolejny poziom

Extę mam zintegrowaną z Bramką AIS i korzystam z jej dodatkowych funkcji typu komendy głosowe i multimedia.
Czy mogę równolegle podpiąć się z integracją na drugim HA w Linux, jako  środowisko testowe? Widzisz jakieś zagrożenia dla stabilności pracy Exta Life w domu, w takim przypadku?

Extę mam zintegrowaną z Bramką AIS i korzystam z jej dodatkowych funkcji typu komendy głosowe i multimedia.
Czy mogę równolegle podpiąć się z integracją na drugim HA w Linux, jako  środowisko testowe? Widzisz jakieś zagrożenia dla stabilności pracy Exta Life w domu, w takim przypadku?

Tak, możesz. Ja prawie na co dzień tak robię i instancja produkcyjna nie ma z tym problemu. Jest możliwe, że zużyte zostaną wszystkie dostępna w kontrolerze połączenia. U mnie jest to max 4, choć czasem i 3 to już maksimum. Integracja zużywa 2 połączenia. Oznacza to, że być może (podkreślam - być może) nie będziesz wtedy w stanie używać aplikacji Exta Life dopóki nie wyłączysz jednej z instancji.
Dla mnie maksymalna ilość połączeń to sprawa dyskusyjna i nie wiem od czego zależy. Czasem kontroler pozwala na 4 połączenia, a czasem tylko na 3. Jak donosi kolega Gadulowaty teoretycznie jest to aż 10, ale w praktyce zatyka mi się przy 3-4.
To jedyne "zagrożenie" jakie widzę. Pocieszające jest natomiast to, że w dowolnym momencie będziesz w stanie usunąć integrację z działającego HA bez potrzeby jego restartu. To jedna z nowych funkcji, gdy integracja jest dodawana z GUI (a ściślej poprzez tzw Config Entry, które typowo tworzy się z GUI, ale można także stworzyć je z poziomu kodu, z czego skorzystałem ja, aby uprościć użytkownikom migrację do nowej wersji)

Cześć,

Na własne potrzeby dodałem obsługę do tej natywnej integracji dla urządzeń ExtaFree (posiadam obok ROP-22 jeszcze ROP-02 i RWG-01, które w wersji 1.6.6 EFC-01 są również wspierane). Jakby ktoś potrzebował to dodałem kod jako pull request do gita:

https://github.com/dgtal1/extalife_custom_component/pull/18

Właśnie przetestowałem i działa jak złoto. Jako, że urządzenia są tylko jednokierunkowe to obok ikony pojawiają się dwa przełączniki - jeden do włączenia i drugi do wyłączenia urządzenia. Stan nie zmienia się tylko zawsze ustawiony jest na sztywno na 'wyłączony'.

Mam nadzieję, że komuś również się przyda

Pozdrawiam
Mateusz

Cześć,

Na własne potrzeby dodałem obsługę do tej natywnej integracji dla urządzeń ExtaFree (posiadam obok ROP-22 jeszcze ROP-02 i RWG-01, które w wersji 1.6.6 EFC-01 są również wspierane). Jakby ktoś potrzebował to dodałem kod jako pull request do gita:

https://github.com/dgtal1/extalife_custom_component/pull/18

Właśnie przetestowałem i działa jak złoto. Jako, że urządzenia są tylko jednokierunkowe to obok ikony pojawiają się dwa przełączniki - jeden do włączenia i drugi do wyłączenia urządzenia. Stan nie zmienia się tylko zawsze ustawiony jest na sztywno na 'wyłączony'.

Mam nadzieję, że komuś również się przyda

Pozdrawiam
Mateusz

Super wieści! Przejrzeć PR jak wrócę z urlopu. Na pewno wyląduje w integracji na stałe 👍
Dzięki

Siemka admin - Jolka przesłała prośbę na twojego GITHab, chcą integrację dodać do listy na bramce AIS.
Miłego odpoczynku... 

Siemka admin - Jolka przesłała prośbę na twojego GITHab, chcą integrację dodać do listy na bramce AIS.
Miłego odpoczynku... 

Tak widziałem 🙂 Rozeznam temat i odpowiem im jak wrócę z wakacji

Cześć,

Na własne potrzeby dodałem obsługę do tej natywnej integracji dla urządzeń ExtaFree (posiadam obok ROP-22 jeszcze ROP-02 i RWG-01, które w wersji 1.6.6 EFC-01 są również wspierane). Jakby ktoś potrzebował to dodałem kod jako pull request do gita:

https://github.com/dgtal1/extalife_custom_component/pull/18

Właśnie przetestowałem i działa jak złoto. Jako, że urządzenia są tylko jednokierunkowe to obok ikony pojawiają się dwa przełączniki - jeden do włączenia i drugi do wyłączenia urządzenia. Stan nie zmienia się tylko zawsze ustawiony jest na sztywno na 'wyłączony'.

Mam nadzieję, że komuś również się przyda

Pozdrawiam
Mateusz

Witaj ponownie,
Przejrzałem kod i widzę, że PR jest do wersji 1.1. czyli takiej, której już nie chcę rozwijać dalej, ponieważ w międzyczasie wydałem wersję 2.0. Najpewniej było tak, że zrobiłeś forka na githubie 1-2 dni przed wydaniem wersji 2.0. Zamierzam włączyć twoje zmiany do wersji 2.0, więc kod wymaga adaptacji z czym sobie poradzę.
Generalnie jest ok, ale koncepcyjnie widzę to ciut inaczej i finalnie zaimplementuję nieco inaczej w integracji (głównie kwestia assumed state) + potrzebuję kilka rozszerzeń do tego co dodałeś, ponieważ wersja 2.0 ma dodatkowe mappingi i kilka kwestii więcej do obsłużenia w HA.

Mam pytanie do ciebie: czy posiadasz wszystkie te urządzenia, które wspomniałeś w PR? Tzn

Switches: ROP-01, ROP-02, ROP-05, ROP-06, ROP-07, ROM-01, ROM-10
* Dimmers: RDP-01, RDP-02, RDP-11
* Smart sockets: RWG-01
* Roller blind controllers: SRP-02, SRP-03, ROB-01

??
Chodzi o to, że potrzebowałbym kogoś do testów, aby sprawdzić czy wszystko w obszarze sterowaniem Exta Free z HA działa. Jedną zasadniczą różnicą pomiędzy tym, co dodałeś ty, a tym co zamierzam dodać ja jest to, że u ciebie urządzenia Exta Free są mapowane jako light lub switch łącznie ze sterownikiem rolet, a ja chcę, aby sterowniki rolet Exta Free były reprezentowane jako cover w HA, a nie switch. I ta różnica będzie wymagała dotestowania. Reszta czyli gniazdko i ROP/ROM powinny działać bez problemu.

Pytanie do @wszystkich: czy jest ktoś na forum, kto używa integracji z HA i jednocześnie ma jakieś moduły Exta Free spięte z EFC-01 i pomógłby w testowaniu?

Witaj,

Niestety właśnie spostrzegłem się w dniu forka, że zrobiłeś wersję 2.0, a ja swoje zmiany robiłem lokalnie na wersji 1.1.
Co do assumed state to zrobiłem to specjalnie tak, bo to wymusza pokazanie się dwóch przycisków (on/off) a nie toggle. Nie znam się za bardzo na HA, a to rozwiązanie zdawało mi się proste i szybkie do implementacji.

Z tych urządzeń posiadam tylko ROP-02 i RWG-01, ale jak sniffowałem ruch z aplikacji Zamela to zrobiłem to od razu dla wszystkich tych urządzeń (w aplikacji można sobie dodawać ich ile się człowiekowi podoba) i wszystkie jak jeden zgłaszają się z device id = 80 i przy akcjach włącz / wyłącz używają tych samych rozkazów (1 dla BUTTON_ON_PRESS, 2 dla BUTTON_ON_RELEASE, 3 dla BUTTON_OFF_PRESS, 4 dla BUTTON_OFF_RELEASE). Dla trybów bi/monostabilnych/czasowych używane są tylko 1 i 2. Jako, że to urządzenia jednokierunkowe to wiadomo, że aplikacja i tak nie czeka na żadną odpowiedź, a jak wyśle się to samo co ona to powinno działać (takie moje naiwne założenie ).

Nie ukrywam, że dałem wszystko jako light i switch, bo było mi w wersji 1.1 tak wygodniej (nie posiadam rolet). Z tego co widziałem to kod urządzenia exta-free jest wysyłany w innym polu niż device_id, więc jak co to jest szansa rozpoznawać po nim co to za konkretnie urządzenie jest i na tej podstawie przypisywać to light, switch lub cover.

Jakbyś potrzebował z czymś pomocy to pisz śmiało - będę się starał w wolnej chwili coś pomóc. Jestem trochę z innej parafii niż Python, ale coś tam zawsze mogę doimplementować

Witaj,

Niestety właśnie spostrzegłem się w dniu forka, że zrobiłeś wersję 2.0, a ja swoje zmiany robiłem lokalnie na wersji 1.1.
Co do assumed state to zrobiłem to specjalnie tak, bo to wymusza pokazanie się dwóch przycisków (on/off) a nie toggle. Nie znam się za bardzo na HA, a to rozwiązanie zdawało mi się proste i szybkie do implementacji.

Tak, assumed state to dobre rozwiazanie. Chodziło mi tylko o logikę do jego wyznaczania (property assumed_state). Chcę to zrobić w opartiu o pole 'exta_free_device' i globalnie dla wszystkich typów encji czyli jako część klasy ExtaLifeChannel

Z tych urządzeń posiadam tylko ROP-02 i RWG-01, ale jak sniffowałem ruch z aplikacji Zamela to zrobiłem to od razu dla wszystkich tych urządzeń (w aplikacji można sobie dodawać ich ile się człowiekowi podoba)....

Faktycznie, zapomniałem kompletnie, że Exta Free nie wymaga parowania i można sobie dodawać co się chce! W takim razie tak to sobie przetestuję.

Z tego co widziałem to kod urządzenia exta-free jest wysyłany w innym polu niż device_id, więc jak co to jest szansa rozpoznawać po nim co to za konkretnie urządzenie jest i na tej podstawie przypisywać to light, switch lub cover.

Tak, type = 80 dla urządzeń Exta Free a do rozpoznawania jakie to dokładnie urządzenie jest ine pole: exta_free_type. Tutaj jest mała pułapka, bo ta wartość przesunięta jest o 300 i żeby wyszedł typ mapowany dla pola 'type' to trzeba dodać 300 czyli dla 26 type = exta_free_type + 300. W kodzie aplikacji też taką zależność znalazłem.
Generalnie to prawie to mam zrobione, tylko wstrzymała mnie ta kwestia cover, ale przechwycę sobie ruch i dodam i tam. Zrobię to w nowym branch'u i potem przez PR wciągnę do kodu dev, to zobaczysz o czym mówiłem.

Jakbyś potrzebował z czymś pomocy to pisz śmiało - będę się starał w wolnej chwili coś pomóc. Jestem trochę z innej parafii niż Python, ale coś tam zawsze mogę doimplementować

Na pewno chętnie skorzystam w  przyszłości Ja też jestem z zupełnie innej planety niż Python, a samego Pythona nauczyłem się na potrzeby właśnie tej integracji. W sumie język fajny, ale ten brak typowania mnie dobija. Testowanie tego to koszmar, bo dopiero w runtime błędy wychodzą, nawet drobnostki jak błędna nazwa zmiennej. Ale taki już jego urok.
Dzięki za odpowiedź i za wkład