Forum ZAMEL Exta Life - opinie, wymiana doświadczeń, baza wiedzy
XTA Developers => Integracje Exta Life z innymi systemami => Development => Wątek zaczęty przez: admin w Grudnia 21, 2018, 15:35:14
-
Oto pakiet oprogramowania pozwalający zintegrować Exta Life z Home Assistant za pośrednictwem MQTT.
UWAGA: Od dnia 14.11.2019 pojawiła się także możliwość integracji natywnej, bez konieczności używania MQTT - opis w tym (https://www.forumextalife.pl/index.php/topic,311.0.html) wątku.
Opis rozwiązania / wprowadzenie:
Integracja oparta jest o 1 bibliotekę napisaną w Python 3.5 oraz 2 programy także napisane w Pythonie. Programy te za pośrednictwem biblioteki symulują komunikację z EFC-01, jak gdyby komunikowała się z nim aplikacja Exta Life. Zmiany stanów z poziomu Home Assistant odbywają się w czasie rzeczywistym. Reakcja kontrolera jest natychmiastowa - tak jak w aplikacji Exta Life. Natomiast update statusu odbiornika Exta Life jest realizowany za pośrednictwem poolingu stanu domyślnie odbywającego się co 5 minut. Do ich uruchomienia stworzone zostały dodatkowo skrypty shellowe (pliki z rozszerzeniem .sh). Jeden z programów (main_ha2exta.py) tworzy połaczenie między kontrolerem EFC-01 a Home Assistant i przekazuje komendy sterowania z HA do EFC-01 na bieżąco. Drugi program (main_exta2ha.py) służy do cyklicznego odczytywania bieżących stanów wszystkich odbiorników i czujników Exta Life z instalacji, do których użytkownik podany w konfiguracji ma dostęp.
Integracja wykorzystuje mechanizm HA MQTT Discovery co oznacza, że urządzenia Exta Life dodawane są do HA automatycznie przy najbliższym odczycie stanów przez program main_exta2ha.py. Nie oznacza to jednak, że będą widoczne w GUI HA. To zawsze wymaga ręcznej konfiguracji poprzez edycję plików HA. HA daje pełną dowolność jak i gdzie urządzenia będą wyświetlane - w jakiej zakładce, z jaką ikoną, w jakiej kolejności, z jakimi opcjami itp. dlatego ręczna konfiguracja jest niezbędna.
Automatyzm Discovery oznacza jednak, że urządzenia Exta Life będą automatycznie skonfigurowane dla HA pod kątem komunikacji, możliwości (czy odbiornik typu światło (czy ściemnialny, czy zwykłe włącz, wyłącz), czy roleta, tematy MQTT do komunikacji itp) oraz widoczne w widoku deweloperskim HA w liście encji.
Plik konfiguracyjny:
Obydwa programy korzystają z pliku konfiguracyjnego exta_ha_config.yaml, niezbędnego do działania całego rozwiązania, który zawiera informacje o tym, jak dane urządzenie Exta Life zostało skonfigurowane w Home Assistant. Jest łącznikiem pomiędzy obydwoma programami, ponieważ obydwa programy muszą wiedzieć jak dane urządzenie Exta Life zostało przypisane do Home Assistant. Plik jest samoczynnie generowany i aktualizowany przez program main_exta2ha.py. Plik ma format YAML (https://yaml.org/). Przed jego edycją silnie polecam zaznajomić się ze składnią YAML, ponieważ wcięcia mają tam znaczenie i nieumiejętna edycja spowoduje błędy w działaniu programu. Zawarte są w tym pliku następujące informacje:
- nazwa encji w Home Assistant zbudowana jako złożenie ID urządzenia (https://www.forumextalife.pl/wiki/index.php?title=EFC-01:Karta_SD:Struktura_katalog%C3%B3w:DEVICES:DEVICES.JS)(wartość 'device') Exta Life oraz numeru kanału. Przykładowo niech ROP-22 w kontrolerze EFC-01 ma ID (pole 'device') o wartości 1. Powstaną dla niego dwa wpisy w pliku wg reguły [id]-[kanał] czyli odpowiednio 1-1, 1-2. Generalnie w Home Assistant powstanie dla ROP-22 tyle encji, ile kanałów czyli 2. Analogicznie dla odbiorników ROM mogą być 4 kanały więc powstaną 4 osobne encje.
- typ komponentu HA reprezentującego dany kanał urządzenia Exta Life: light, switch, cover, sensor
- tematy MQTT do sterowania urządzeniem przez HA oraz do zwracania stanu urządzenia Exta Life do HA. Aby uniknać nadmiarowości danych to zapisany jest tylko człon główny wszystkich tematów oraz poszczególne końcówki
Przykładowy wpis z pliku:
0-1:
brightness_scale: 100
can_dim: true
can_rgb: false
component: light
name: Punkt 1
on_command_type: brightness
topic_base: homeassistant/light/0-1/
topics:
brightness_command_topic: set_value
brightness_state_topic: state_value
command_topic: switch
config: config
state_topic: stateWpis taki reprezentuje urządzenie Exta Life o ID 0 i kanale 1 (stąd: 0-1:). Dokładnie rzecz ujmując jest to RDP-21. Zmapowany jest on na komponent HA typu 'light', ponieważ komponent ten pozwala na regulację natężenia oświetlenia (can_dim: true) oprócz włączania i wyłączania.
Przykładowo temat MQTT do przekazywania stanu odbiornika Exta Life do HA to połączenie wartości pola topic_base oraz state_topic - czyli 'homeassistant/light/0-1/state'
Jeśli ktoś poczyta dokumentację elementu light komponentu MQTT w HA to zauważy, że wiele z pól tego wpisu odpowiada dokładnie polom konfiguracyjnym komponentu MQTT.
UWAGA: program main_exta2ha.py posiada domyślą logikę mapującą urządzenia Exta Life (ROP, ROM, RDP, SRP, itp) na komponenty HA. Logika ta stworzona została na moje potrzeby. Mam świadomość, że wypadałoby, aby byłą konfigurowalna, ale elastyczność i konfigurowalność niestety zawsze oznacza większy nakład pracy programistycznej, czyli czasu. Do tej pory nie miałem na tyle czasu, aby wprowadzić tutaj konfigurowalność tej logiki.
Oznacza to, że aby dostosować logikę procesu Discovery do swoich potrzeb potrzebna jest zmiana kodu w bibliotece ExtaLife_HA.py w metodzie add_entry_from_device klasy HAConfig.
Drugim rozwiązaniem jest dokonanie ręcznych zmian w wygenerowanym pliku i ponowne przesłanie konfiguracji do HA programem main_exta2ha.sh. O tym jak to zrobić - poniżej w procedurze postępowania.
Ogólna reguła jest taka, że ROP i ROM mapowane są jako switch, chyba, że mają w aplikacji Exta Life przypisane ikony kierunkowego reflektora sufitowego (https://www.forumextalife.pl/wiki/images/c/c4/Rec_15_0.png)lub ikonę zwykłej żarówki E27 (https://www.forumextalife.pl/wiki/images/5/5c/Rec_13_0.png)- wtedy będą zmapowane jako light bez możliwości ściemniania.
Pozostałe komponenty mapowane są wg intuicyjnych reguł - ściemniacz jako light z regulacją, czujniki temperatury jako sensor, SRP/M jako cover.
Obsługiwane urządzenia Exta Life:
* Odbiorniki: ROM, ROP, RDM, RDP, SRP, SRM, przygotowane podwaliny po obsługę SLR
* Czujniki: czujnik temperatury z RNK oraz czujniki RCT
Urządzenia Exta Free nie są na razie wspierane. Z racji, że z Exta Free posiadam tylko jeden ROP-01 - mam za mało informacji, aby dodać ich obsługę.
Reprezentacja w Home Assistant jako następujące komponenty:
* MQTT Light - https://www.home-assistant.io/components/light.mqtt/
* MQTT Switch - https://www.home-assistant.io/components/switch.mqtt/
* MQTT Cover - https://www.home-assistant.io/components/cover.mqtt/
* MQTT Sensor - https://www.home-assistant.io/components/sensor.mqtt/
Wymagania - w co się trzeba będzie wyposażyć:
1. Home Assistant - hass.io na Raspberry Pi, ale moim zdaniem nawet lepszym pomysłem jest HA na Dockerze (czyli dyski NAS, inne Linuxy oraz Docker dla Windows ) - pobrać najnowszą wersję stabilną (nie betę)
2. Broker MQTT - polecam Mosquitto - można także w dockerze
3. Python 3.5 lub nowszy do uruchomienia 2 programów integracji Exta Life <-> MQTT w Home Assistant. Na starszej wersji będą błędy składniowe
4. Dodatkowe pakiety w Pythonie (doinstalować przez: pip install): mqtt (paho mqtt), json, yaml, unidecode
Procedura wdrożenia:
0. Otworzyć butelkę/puszkę piwa ;)
1. Zainstalować Home Assistant oraz dodać w pliku configuration.yaml konfigurację dla komponentu MQTT według instrukcji https://www.home-assistant.io/components/mqtt/ oraz https://www.home-assistant.io/docs/mqtt/discovery/
Ustawić parametr discovery_prefix na wartość homeassistant, czyli discovery_prefix: homeassistant
2. Przetestować poprawność instalacji i konfiguracji według instrukcji: https://www.home-assistant.io/docs/mqtt/testing/
To będzie wymagało edycji głównego pliku konfiguracyjnego HA - configuration.yaml i ręcznego dodania testowego, wirtualnego urządzenia MQTT.
Polecam też instalację jakiegoś dobrego klienta MQTT np MQTT.fx i zasubskrybowanie wszystkich wątków do monitorowania przyszłej komunikacji HA z Exta Life poprzez subskrybcję tematu homeassistant/# i monitorować co wysyła nam HA i czy HA reaguje na zmiany stanów poprzez wysyłanie wiadomości w tematach MQTT dla zmian stanów dla urządzeń.
Testy wykonujemy poprzez zmianę stanów naszego wirtualnego urządzenia MQTT w widoku deweloperskim w widoku encji (url: /dev-state) i patrzymy w naszym kliencie MQTT co nam nasz HA wysyła i czy w ogóle. Jeśli nic się nie dzieje przy załączaniu/wyłączaniu urządzenia - patrzymy do loga HA w poszukiwaniu błędów inicjalizacji MQTT.
Chodzi o to, aby sprawdzić czy komunikacja brokera MQTT z HA działa poprawnie. Jeśli wszystko działa prawidłowo - usuwamy nasze wirtualne urządzenie z pliku konfiguracyjnego HA (configuration.yaml) i restart HA.
3. Rozpakować pliki z załącznika do jednego folderu na hoście/systemie, gdzie zainstalowany jest Python 3.5. Upewnić się, że w tym folderze jest dostęp do komendy python, która uruchamia interpreter Python - czyli, że zmienna środowiskowa path ma wpisany katalog z interpreterem Python 3.5 lub nowszym.
UWAGA: w plikach skryptów shell start_ha2exta.sh oraz start_exta2ha.sh użyta jest komenda python3, gdyż taka funcjonuje w moim systemie Synology. Jeśli u Was ta komenda jest inna np. po prostu python to trzeba wyedytować te pliki .sh i podmienić komendę.
Okazuje się, że na danym systemie linux może być zainstalowanych kilka wersji interpretera Python np 2.5, 2.7 itp. W Synology właśnie dlatego jest oddzielna komenda do wywołania Python 3.5
4. Wyedytować plik config.py i wprowadzić tam adresy IP i porty dla kontrolera EFC-01, brokera MQTT, a także wprowadzić użytkownika i hasło dla dostępu do kontrolera. Użytkownikiem nie musi być root ani adminitrator, ale także zwykły użytkownik. Zasada jest taka, że do Home Assistant dodadzą się automatycznie tylko te urządzenia Exta Life, które przypisane ma do siebie dany użytkownik aplikacji Exta Life.
5. Nadać skryptom (pliki .sh) uprawnienia do bycia wykonywalnymi: chmod +x
6. Przeprowadzić wstępną konfigurację programów (wygenerowanie pliku konfiguracji exta_ha_config.yaml) poprzez uruchomienie skryptu start_exta2ha.sh z parametrem --testrun. Czyli pełna komenda w shellu:
./start_exta2ha.sh --testrunTen parametr spowoduje wygenerowanie pliku konfiguracyjnego, ale konfiguracja nie zostanie zapisana w HA na stałe, więc po restarcie HA wszystkie encje powstałe z wygenerowania konfiguracji znikną i można je ładować ponownie.
Jeśli zawartość pliku odpowiada oczekiwaniom co do mapowna na komponent HA to dalej do kroku 7. W przeciwnym przypadku wyedytować plik i uruchomić MQTT discovery (przesyłanie konfiguracji) poprzez uruchomienie skryptu ./start_exta2ha.sh --filediscoveryTa komenda spowoduje wysłanie konfiguracji załadowanej z pliku konfiguracyjnego zamiast wygenerowanej w locie z danych otrzymanych z EFC-01.
Koniecznie zrestartować HA, aby zmiany w konfiguracji MQTT zostały zastosowane
Jest jeszcze jeden parametr dla tego skryptu, który warto wspomnieć. W przypadku gdyby zaszła potrzeba wygenerowania pliku konfiguracyjnego od nowa (np. po nieudanej edycji) należy uruchomić skrypt z parametrem --initialize.
Pełna komenda: ./start_exta2ha.sh --initializePlik wygeneruje się także za pierwszym uruchomieniem skryptu bez parametrów, lub po skasowaniu pliku konfiguracyjnego.
7. W widoku deweloperskim w HA GUI (URL z końcówką: /dev-state) sprawdzić, czy urządzenia Exta Life są widoczne jako encje light, switch, cover, sensor. W przypadku gdy mapowanie nie spełnia oczekiwań - powrót do punktu 6 i edycja pliku
8. Wprowadzić encje urządzeń Exta Life do konfiguracji Home Assistant (configuration.yaml lub groups.yaml), aby były widoczne w GUI na kartach.Od wersji Home Assistant 0.86 domyślnym interfejsem użytkownika jest Lovelace. Tam nie ma konieczności edycji plików konfoguracyjnych, aby uwidocznić encje w interfejsie. Można wszystko wyklikać na zakładkach GUI. Więcej tutaj (https://www.home-assistant.io/lovelace/)
9. Dodać skrypty start_exta2ha.sh oraz start_ha2exta.sh do autostartu swojego linuxa. W związku z tym że w różnych dystrybucjach linuxa są na to różne rozwiązania - odsyłam po pomoc do Google. Ja w moim Synology dodałem je po prostu w Panelu Sterowania jako Zadania (Task scheduler) z automatycznym startem przy rozruchu DSM (triggered task, event: boot-up). Programy powinny być odporne na sytuację, gdy wystartowały wcześniej niż broker MQTT i Home Assistant oraz na niedostępność EFC-01, więc raz uruchomione powinny działać bez przerwy.
WAŻNE: testując te programy powalajcie im na nieprzerwaną pracę. Nie należy ich przerywać, ponieważ wtedy nic się nie będzie działo. MQTT nie będzie dostawać ani stanów urządzeń Exta Life, ani konfiguracji. Programy te pełnią w pewien sposób rolę usług systemowych (tzw. daemon'ów), choć nimi nie są. Minus jest taki, że blokują konsolę ssh i aby robić coś innego na linuxie to musicie odpalić osobną sesję. Niestety jest tak ze względu na to, że różne dystrybucje mają różne sposoby na tworzenie usług. Ja chciałem przygotować rozwiązanie uniwersalne, które ruszy na każdej maszynie. Stąd "czysty" program, który ma w sobie nieskończoną pętle, a nie prawdziwa usługa działająca w tle i nieblokująca konsoli.
Do testów zamiast autostartu możecie spróbować też użyć linuksowej komendu nohup (odsyłam do google), która pozwala uruchomić każdy program w tle i tym samym nie będzie on blokował konsoli i (chyba) nie zostanie zamknięty przez Linuxa gdy odłączycie się od sesji ssh.
Od tej pory Wasza instalacja Exta Life wchodzi na nowy poziom swojej egzystencji i pozwala być sterowaną z pięknego i minimalistycznego GUI wraz z całą masą innych smart-urządzeń w Waszym domu poprzez znacznie bardziej złożone scenariusze automatyki domowej.
Po spędzeniu godzinki czasu na konfiguracji komponentu HA o nazwie 'Google Assistant' (https://www.home-assistant.io/addons/google_assistant/) będziecie też w stanie sterować swoją Extą z aplikacji Google Home oraz poprzez Asystenta Google (po angielsku już to działa, a po polsku zacznie od połowy stycznia).
Miłej zabawy! 8)
EDIT 10.01.2019
Dodano poprawkę main_ha2exta.py w wersji 1.0.1 w załączniku
EDIT 15.01.2019
Dodano poprawkę main_ha2exta.py w wersji 1.0.2 w załączniku
EDIT 17.09.2019
Wersja 1.0.2 - dodano obsługę czujnika temperatury z RNK-22 oraz poprawiono crash, gdy wykryte są nieobslugiwane urządzenia
-
W programie
main_ha2exta.py wykryłem błąd objawiający się crashem programu przy niedostępności EFC-01, utratą sterowania z HA i koniecznością restartu programu, aby wznowić sterowanie.
Wystarczy podmienić plik main_ha2exta.py nowszą wersją 1.0.1 z załącznika w pierwszym poście powyżej.
Przy okazji informacja dla posiadaczy OpenHAB lub Domoticz - ten pakiet integracyjny powinien także pozwalać na współpracę Exta Life z tymi systemami przy założeniu, że współpracują one z MQTT i że da się dostosować tematy i Payload MQTT dla ich encji tak, aby pasowały do tych z Home Assistant.
-
Wypuszczona poprawka programu main_ha2exta.py w wersji 1.0.2
CHANGELOG:
* kolejne "uodpornienie" programu przekazującego sterowanie z HA do EFC-01 na brak łączności z EFC-01. W specyficznej sytuacji, gdy EFC-01 nie jest dostępny przez dłuższy czas - np awaria zasilania, ale serwer hostujący HA i ruter sieciowy jest dostępny w programie występował inny błąd "rzucany" przez pythonowy komponent systemowy
Instalacja poprawki jak poprzednio. Wystarczy zatrzymać aktualnie uruchomiony program (np ps -ef | grep python a potem kill x gdzie x to numer procesu zwrócony przez poprzednią komendę dla programu main_ha2exta.py.
Potem nadpisać plik i uruchomić program ponownie.
Zachęcam Was do wpisywania odkrytych błędów tutaj, w tym wątku. Sam na pewno nie wyłapię wszystkiego :)
-
Wczoraj znalazłem troszkę czasu i zainstalowałem pakiet, działa bez najmniejszego problemu - dzięki bardzo!
HA tez całkiem fajny z dużymi możliwościami, na te chwile dodałem sobie jeszcze obsługę centrali alarmowej Ropam Optima po modbus, amplituer Yamahy, Tv LG i Miboxy - wszystko w zasadzie OOTB :D
-
Wczoraj znalazłem troszkę czasu i zainstalowałem pakiet, działa bez najmniejszego problemu - dzięki bardzo!
HA tez całkiem fajny z dużymi możliwościami, na te chwile dodałem sobie jeszcze obsługę centrali alarmowej Ropam Optima po modbus, amplituer Yamahy, Tv LG i Miboxy - wszystko w zasadzie OOTB :D
Noooo, w końcu jakiś feedback! :D Już myślałem, że te 10 pobrań pliku to tylko z ciekawości i nikt tego u siebie nie uruchamiał. A powiedz - odpaliłeś to też na jakimś NAS? Ja mam jeszcze jeden sygnał od innego kolegi z forum, który próbował uruchamiać na malince (RPI), ale są z tym tam jakieś problemy, których do tej pory nie udało mi się ustalić.
A jeszcze a propos Home Assistant - to koleha Automatic w tym wątku (https://www.forumextalife.pl/index.php/topic,256.15.html) pokazywał bardzo ładne panele z Domoticza. Wczoraj chwilę posiedziałem na Necie po instalacji nowej wersji HA (0.86.3), bo teraz Lovelace UI to domyśle GUI w HA i co się okazało - na stronie https://www.awesome-ha.com/ także można odnaleźć nieoficjalne dodatki do HA pozwalające na dodanie takich ładnych paneli dla tabletów - zarówno kafelki jak i widok układu pokojów od góry :)
A wprowadzenie oficjalnej obsługi Lovelace UI oznacza także, że kolejna bariera wejścia w HA pękła - teraz całe GUI w HA można wyklikać w UI!! Nie trzeba już edytować plików. Oczywiście nadal można pliki edytować, a nawet trzeba jeśli ktoś chce na prawdę bardzo głęboko pod siebe to wszystko dopasować, ale w skali 1-10 wyklikać można w stopniu 7. 8 z edycją plików a 10 gdy się poprogramuje (customowe karty-komponenty).
W każdym razie - miło, że odpaliłeś HA i że integracja HA-ExtaLife się przydała :) Jak będziesz miał jakieś spostrzeżenia to pisz tutaj.
-
Mam w domu serwer postawiony na Ubuntu i na nim zainstalowałem, ale w dockerze.
Mosquitto broker zainstalowany z add-on store z Hass.io
-
Mam w domu serwer postawiony na Ubuntu i na nim zainstalowałem, ale w dockerze.
Mosquitto broker zainstalowany z add-on store z Hass.io
OK, czyli podobnie jak ja - także Docker. Co prawda na Synology, ale to też jakiś linux.
Czy ktoś uruchamiał skrypty na Raspberry? (oprocz kolegi jm)
-
Ale się zestarzałem - ja już nic z tego nie kapuje co wy tu piszecie. Chyba że jestem jak większość która nie ma pojęcia co dokładnie zrobić. Pozdrawiam
-
Ja też już stary jestem :'(
Co do malinki to gdzieś miałem jakąś starą 1 B, a widzę ze jest na nią obraz (https://www.home-assistant.io/hassio/installation/) więc przy chwili wolnego czasu postaram się przetestować.
-
OFFTOPIC:
Ale się zestarzałem - ja już nic z tego nie kapuje co wy tu piszecie. Chyba że jestem jak większość która nie ma pojęcia co dokładnie zrobić. Pozdrawiam
Ja też już stary jestem :'(
Co do malinki to gdzieś miałem jakąś starą 1 B, a widzę ze jest na nią obraz (https://www.home-assistant.io/hassio/installation/) więc przy chwili wolnego czasu postaram się przetestować.
;D Ale się uśmiałem...Panowie, błagam...jeśli jeszcze nie bawicie prawnuków będąc na emeryturze to o jakiej starości my tu mówimy? ;)
To prawda, że technologia niestety ma to do siebie, że 5-10 lat to już cała epoka. Faktycznie trudno za tym nadążyć, ale jedno jest pewne: żyjemy w takich czasach, że przy głowie otwartej na nowości i informacje można się nauczyć prawie wszystkiego z internetu. Wystarczy tylko poświęcić trochę czasu. W czasach, gdzie na prawie każdy temat są jakieś tutoriale na YouTube nauka jest prostsza niż kiedykolwiek wcześniej. Obsługa skomplikowanych systemów także jest prostsza niż kiedykolwiek - kto by pomyślał bawić się w linuxy kiedyś.. a teraz kupuje się jakiegoś NASa typu Synology albo QNAP i mamy prywatnego, dobrze działającego linuxa. Linia komend? Jak kto woli to można używać (czasem się nie obejdzie - to fakt), ale bardzo wiele rzeczy można robić z wygodnego, webowego GUI.
Programowanie mikrokontrolerów, przeprogramowanie Sonoffa? To pierwsze znam co prawda z technikum, ale to były inne czasy, inne czipy etc. To drugie to niedawno też byłą dla mnie czarna magia. Ale jak to w ostatnich czasach bywa - ktoś kiedyś zbudował jakiegoś toola, potem ktoś wiął tego toola oraz parę innych i zbudował innego, bardziej złożonego o większych możliwościach. Mówię tu o Arduino i esphomeyaml. Dla średnio obeznanego z tematem programowanie kontrolera sprowadza się w tym przypadku do zakupu programatora za 7 zł, przylutowaniu 4 kabelków, ściągnięciu pliku i wyedytowaniu pliku tekstowego i wsadzeniu tam kilkunastu linijek konfiguracji. Zero potrzeby znajomości C, C++, tajnik programowoania, bootloaderów i innych rzeczy, na widok których przeciętny Kowalski uznałby nas za wariatów mówiących w jakimś obcym języku. Parę klików i mikrokontroler zaprogramowany....i to jeszcze jak - MQTT, update softu przez WiFi itp.
Na prawdę, żyjemy we wspaniałych czasach, gdzie wszystko jest coraz prostsze do osiągnięcia. Dlatego tak szybko to wszystko się rozwija. Efekt kuli śnieżnej.
Ja parę miesięcy temu nie słyszałem o Dockerze, MQTT, YAML, a o Pythonie wiedziałem tylko, że istnieje. A teraz? Czuję się w tych rzeczach dość komfortowo. Musiałem "jedynie" poświęcić trochę czasu na przyswojenie tego wszystkiego. Zapewniam Was, że prawie każdy, kto ma jakieś pojęcie o podstawach informatyki (tak, trochę więcej niż Word i Excel ;)) sobie z tymi rzeczami poradzi.
ONTOPIC:
To jak ktoś z Was da radę przeprowadzić testy na malince to będę wdzięczny za feedback :)
-
Ok pobawiłem się malinką i działa ::)
Tak jak pisałem mam wersję 1 B więc do perfekcji opanowałem sztukę cierpliwości >:D
Instalacja standard -> https://www.home-assistant.io/getting-started/
Po odczekaniu dość sporego czasu mogłem się zalogować w przeglądarce do HA
tutaj z ADD-ON STORE zainstalowałem:
- Mosquitto broker - wiadomo
- Configurator - do edycji plików i ładowania plików na serwer
- SSH server - żeby móc się zdalnie po sieci zalogować do serwera
Domyślnie w obrazie nie ma zainstalowanego pythona, więc przez ssh trzeba zalogować do serwera i zainstalować
apk add --no-cache python3do tego doinstalować brakujące liby pythona
pip3 install pyyaml paho-mqtt unidecodei mamy gotowe środowisko do uruchomienia skryptów kolegi admina O:-)
-
Kawał dobrej roboty kolego SebiCo!!! 8)
Cierpliwość w IT bardzo się przydaje :) Doceniam tym bardziej. No i super - mamy w takim razie potwierdzenie, że skrypty działają na innych systemach niż mój NAS: Ubuntu i hass.io. Dziwi mnie tylko, że musiałem doinstalować Pythona. Przecież Home Assistant jest napisany w Pythonie i aby mógł działać to gdzieś tam na pewno jest ukryty interpreter Python. Ale nie wnikam. Jak się da dołożyć osobno to też dobrze.
Teraz jakby ktoś jeszcze potestował czy da się te skrypty użyć z OpenHAB lub Domoticz to byłoby super. Dla Domoticza moim zdaniem trzeba będzie skorzystać z Node-RED albo innego narzędzia pośredniczącego. Dla OpenHAB - nie wiem.
-
No właśnie też się zdziwiłem, ale może python siedzi w innym kontenerze do którego nie ma dostępu z tego poziomu, w każdym razie po zalogowaniu przez ssh do shella nie ma pythona :-[
-
Jadę wg. zamysłu autora i dochodzę do uruchomienia main_exta2ha. Nie wiem dlaczego python nie widzi pyyamla zainstalowanego z pip :(
HA postawiony w formie wirtualki hass.io, skrypty pythona mają działać na osobnej wirtualce - debianie 8. Proszę o pomoc
EDIT: Błąd był trywialny w wersjach pythona 2 - 3
EDIT2:
marcin@www:~/extalife$ ./main_exta2ha.py --testrun
./main_exta2ha.py: linia 40: błąd składni przy nieoczekiwanym znaczniku `('
'/main_exta2ha.py: linia 40: `logging.basicConfig(filename=(os.path.basename(__file__)+'.log'),level=LOG_LEVEL, format='%(asctime)s %(levelname)s:%(message)s')
-
Jadę wg. zamysłu autora i dochodzę do uruchomienia main_exta2ha. Nie wiem dlaczego python nie widzi pyyamla zainstalowanego z pip :(
HA postawiony w formie wirtualki hass.io, skrypty pythona mają działać na osobnej wirtualce - debianie 8. Proszę o pomoc
EDIT: Błąd był trywialny w wersjach pythona 2 - 3
EDIT2:
marcin@www:~/extalife$ ./main_exta2ha.py --testrun
./main_exta2ha.py: linia 40: błąd składni przy nieoczekiwanym znaczniku `('
'/main_exta2ha.py: linia 40: `logging.basicConfig(filename=(os.path.basename(__file__)+'.log'),level=LOG_LEVEL, format='%(asctime)s %(levelname)s:%(message)s')
Tak właśnie myślałem, że to problem równoległych instalacji Pythona. Dla pewności lepiej używać polecenia pip3 dla Pythona 3.
Czy EDIT2 oznacza, że nadal masz błąd?
Jaką wersją Pythona uruchamiasz skrypt? Upewnij się, że jest to wersja minimum 3.5
Zaobserwowałem 2 istotne rzeczy:
1. Wygląda, że do uruchomienia skryptu nie używasz programu .sh tylko bezpośrednio programy .py. Błąd nie mówi zbyt wiele, ale podejrzewam, że może chodzić o formatowanie stringa, które może nie działać w starych wersjach Pythona. Upewnij się, że uruchamiasz program .py poleceniem python3 i, że twój Python 3 to wersja minimum 3.5
2. Wygląda, że używasz starszej wersji programu .py. W obecnej 1.0.1 linia 40 toCMD_RT_SNS = '{"command":38,"data": null}'+chr(3)ściągnij i skopiuj najnowsze wersje z pierwszego posta na samej górze. Tam załączam aktualizacje
Daj znać co odkryłeś i czy pomogło. Skrypty powinno działać bez problemu jeśli tylko uruchamia je odpowiednia wersja Pythona i gdy zainstalowane są wsyzstkie potrrzebne moduły/bilblioteki pythona.
-
To mój pierwszy post więc Witam wszystkich.
Extalife mam od raptem kilku dni. Póki co zestaw startowy ale mam zamiar go szybko rozbudowywać. Trafiłem na to forum i zaiteresowałem się integracją z HA. Postawiłem debiana, w nim HA, mosquitto i wszystko co wymagane. Stanąłem na testrun który kończy się komunikatem:
./start_exta2ha.sh --testrun
Traceback (most recent call last):
File "main_exta2ha.py", line 196, in <module>
prog.main()
File "main_exta2ha.py", line 181, in main
self.ha_mqtt.ha_update_state_from_device(device)
File "/home/rootmr/HA/ExtaLife_HA.py", line 742, in ha_update_state_from_device
cfg_dict = self.HAConfig.get_from_device(i_device)
File "/home/rootmr/HA/ExtaLife_HA.py", line 552, in get_from_device
cfg_dict[objid] = self.cfg_dict[objid] # may raise KeyError exception
KeyError: '1-1'
W logach wygląda to tak:
2019-05-22 09:57:12,781 INFO:>>PID<<
2019-05-22 09:57:12,781 INFO:18701
2019-05-22 09:57:12,782 INFO:No customizing file
2019-05-22 09:57:12,782 WARNING:Loading config from file failed
2019-05-22 09:57:12,784 INFO:Running with command parameter: --testrun
2019-05-22 09:57:12,784 INFO:No customizing file
2019-05-22 09:57:14,923 DEBUG:Applying filters
2019-05-22 09:57:14,923 DEBUG:[37, 38]
2019-05-22 09:57:14,923 DEBUG:json elements before: 3
2019-05-22 09:57:14,923 DEBUG:json elements after: 3
2019-05-22 09:57:14,923 DEBUG:Applying filters
2019-05-22 09:57:14,923 DEBUG:[37, 38]
2019-05-22 09:57:14,923 DEBUG:json elements before: 3
2019-05-22 09:57:14,924 DEBUG:json elements after: 3
2019-05-22 09:57:14,925 WARNING:No config found for device: 2
2019-05-22 09:57:14,925 INFO:About to publish MQTT config payload topic: {"command_topic": "homeassistant/light/2-1/switch", "state_topic": "homeassistant/light/2-1/state", "name": "Przedpokoj"}
2019-05-22 09:57:15,226 DEBUG:Publishing topics:
2019-05-22 09:57:15,226 DEBUG:[{'payload': 'OFF', 'topic': 'homeassistant/light/2-1/state'}]
2019-05-22 09:57:15,228 WARNING:No config found for device: 0
2019-05-22 09:57:15,229 INFO:About to publish MQTT config payload topic: {"command_topic": "homeassistant/light/0-1/switch", "state_topic": "homeassistant/light/0-1/state", "name": "Salon 1-2"}
2019-05-22 09:57:15,530 INFO:About to publish MQTT config payload topic: {"command_topic": "homeassistant/light/0-2/switch", "state_topic": "homeassistant/light/0-2/state", "name": "Salon 3"}
2019-05-22 09:57:15,831 DEBUG:Publishing topics:
2019-05-22 09:57:15,831 DEBUG:[{'payload': 'OFF', 'topic': 'homeassistant/light/0-1/state'}, {'payload': 'OFF', 'topic': 'homeassistant/light/0-2/state'}]
2019-05-22 09:57:15,833 WARNING:CONFIG: Unknown Exta Life sensor type: 2. Mapping failed
2019-05-22 09:57:15,833 WARNING:No config found for device: 1
Wcześniej bolał go ściemniacz - usunąłem z kontrolera bo i tak mam z nim problem. Później scena i logika powiązana ze ściemniaczem - usunąłem. Ale teraz zostały mi tylko ROP-21 i ROP-22, przycisk RNK-22 + czujnik temperatury oraz pilot 2-kanałowy, który realizuje 2 sceny: wyjście z domu - zgaś wszystkie światła, wejście do domu - zapal wybrane światła. Ot cała konfiguracja.
Pytanie co go boli i jak to ugryźć.
-
Przyjrzę się temu w wolnej chwili, ale uprzedzam, że to może potrwać parę dni, bo ciasno u mnie ostatnio z czasem.
Napisz dokładnie jakie urządzenia Exta Life masz sparowane z kontrolerem.
Ale tak na szybko - w logu widzę jedną podejrzana rzecz CONFIG: Unknown Exta Life sensor type
. Być możę to jest problem. Wygląda jakbyś miał jakiś czujnik, którego skrypt nie obsługuje.
Spróbuj w pliku ExtaLife_HA.py w linii 89 zrobić zmianę - zamień [4,20,21]na[2,4,20,21]. Chodzi o dodanie cyfry 2. Być może to sensor z twojego RNK.
Zrób zmianę i daj znać czy pomogło. Jak nie to jeszcze dokładniej się temu przyglądnę.
-
dodanie "2" pomogło :) testrun przechodzi. Walczę dalej.
2019-05-22 10:48:52,848 INFO:Running with command parameter: --testrun
2019-05-22 10:48:52,848 INFO:No customizing file
2019-05-22 10:48:54,989 DEBUG:Applying filters
2019-05-22 10:48:54,990 DEBUG:[37, 38]
2019-05-22 10:48:54,990 DEBUG:json elements before: 3
2019-05-22 10:48:54,990 DEBUG:json elements after: 3
2019-05-22 10:48:54,990 DEBUG:Applying filters
2019-05-22 10:48:54,990 DEBUG:[37, 38]
2019-05-22 10:48:54,990 DEBUG:json elements before: 3
2019-05-22 10:48:54,991 DEBUG:json elements after: 3
2019-05-22 10:48:54,992 WARNING:No config found for device: 2
2019-05-22 10:48:54,992 INFO:About to publish MQTT config payload topic: {"state_topic": "homeassistant/light/2-1/state", "command_topic": "homeassistant/light/2-1/switch", "name": "Przedpokoj"}
2019-05-22 10:48:55,293 DEBUG:Publishing topics:
2019-05-22 10:48:55,293 DEBUG:[{'topic': 'homeassistant/light/2-1/state', 'payload': 'OFF'}]
2019-05-22 10:48:55,295 WARNING:No config found for device: 0
2019-05-22 10:48:55,295 INFO:About to publish MQTT config payload topic: {"state_topic": "homeassistant/light/0-2/state", "command_topic": "homeassistant/light/0-2/switch", "name": "Salon 3"}
2019-05-22 10:48:55,596 INFO:About to publish MQTT config payload topic: {"state_topic": "homeassistant/light/0-1/state", "command_topic": "homeassistant/light/0-1/switch", "name": "Salon 1-2"}
2019-05-22 10:48:55,897 DEBUG:Publishing topics:
2019-05-22 10:48:55,898 DEBUG:[{'topic': 'homeassistant/light/0-2/state', 'payload': 'OFF'}, {'topic': 'homeassistant/light/0-1/state', 'payload': 'OFF'}]
2019-05-22 10:48:55,899 WARNING:No config found for device: 1
2019-05-22 10:48:55,900 INFO:About to publish MQTT config payload topic: {"state_topic": "homeassistant/sensor/1-1/state", "name": "Salon", "unit_of_measurement": "\u00b0C"}
2019-05-22 10:48:56,175 DEBUG:Publishing topics:
2019-05-22 10:48:56,177 DEBUG:[{'topic': 'homeassistant/sensor/1-1/state', 'payload': '23.8'}]
czyli sensor 2 to czujnik temperatury z RNK-22
zauważyłem też kolejny warning:
# ./start_exta2ha.sh --filediscovery
/home/rootmr/HA/ExtaLife_HA.py:574: YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as the default Loader is unsafe. Please read https://msg.pyyaml.org/load for full details.
self.cfg_dict = yaml.load(cfg_file)
-
OK, to wypuszczę w najbliższych dniach poprawkę skryptu z dodaniem tego sensora. Postaram się też zrobić zmiany, aby skrypt był odporny na nieobsługiwane urządzenia. Nie powinien się wykrzaczać, tylko zignorować nieznane urządzenie i działać dalej. W przeciwnym przypadku nie będzie działał, gdy ktoś kupi jakiś nowy element Zamela, którego skrypt jeszcze nie obsługuje.
-
dzięki i cieszę się, że mogłem pomóc.
Udało mi się odpalić HA, nawet pojawiły się czujniki i odbiorniki ale pojawiły się dopiero po skonfigurowaniu integracji MQTT: 127.0.0.1:1883, bez login i hasła, z zaznaczoną opcją wygrywania. Gdy teraz wejdę w tą integrację to pokazuje mi "Ta integracja nie ma żadnych urządzeń.". Pytanie czy tak ma być, bo nie widzę o tym wzmianki w opisie (albo mi to umknęło).
Mam też problem z "mapą". Za Chiny ludowe nie widzę opcji wczytania jakiegoś rzutu lub przypisania odbiorników, sensorów do pomieszczeń ale to może jeszcze za mało wiem - to moja pierwsza styczność z HA
-
Udało mi się odpalić HA, nawet pojawiły się czujniki i odbiorniki ale pojawiły się dopiero po skonfigurowaniu integracji MQTT: 127.0.0.1:1883, bez login i hasła, z zaznaczoną opcją wygrywania. Gdy teraz wejdę w tą integrację to pokazuje mi "Ta integracja nie ma żadnych urządzeń.". Pytanie czy tak ma być, bo nie widzę o tym wzmianki w opisie (albo mi to umknęło).
Oczywiście - MQTT musi być aktywowane w configuration.yaml. Inaczej HA nie będzie w ogóle obsługiwał tego protokołu.
U mnie w widoku integracji też nie ma moich urządzeń Exta Life. W sumie nie wiem dlaczego, bo inne, która łączą się po WiFi (mam 1 Sonoff'a i jeden moduł na ESP32) tam są i są ich wszystkie encje.
Niemniej jednak to nie problem że ich tam nie ma. To co się liczy to ich widok w widoku encji/stanów - przycisk "< >" w menu bocznym w GUI. Tam ich poszukaj. Powinny tam się pojawić. Jeśli ich nie ma to prawddopodobnie niepoprawnie ustawiłeś konfigurację MQTT w HA i HA oczekuje innego prefiksu dla komunikatów MQTT od skryptu.
Mam też problem z "mapą". Za Chiny ludowe nie widzę opcji wczytania jakiegoś rzutu lub przypisania odbiorników, sensorów do pomieszczeń ale to może jeszcze za mało wiem - to moja pierwsza styczność z HA
Mapa nie działa out of the box. Nie jest oficjalnie częścią HA, ale są oczywiście rozszerzenia społeczności. Polecam ci odwiedzić ten (https://www.forumextalife.pl/index.php/topic,256.msg1446.html#msg1446) wątek.
Generalnie HA podoba mi się coraz bardziej. Czytałem o planach na ten rok i w wersji 1.0 będzie jeszcze przyjaźniejszy w obsłudze, a plany co do współpracy z producentami sprzętu i certyfikowaniu integracji z nimi brzmią po prostu rewelacyjnie. To oznaca dla użytwkonikó, że system będzie działał po prostu dobrze i stabilnie ze sprzętem danego producenta.
-
przyszedł mi nowy ściemniacz, podpiąłem, działa z HA bardzo ładnie. Przyjemna sprawa, że można sparować ściemniacz (bez scen czy logiki) z przyciskiem RNK-22 i za jego pomocą rozjaśniać i ściemniać (poprzez przytrzymanie) a nie tylko włączać/wyłączać.
Za około tydzień będę miał kolejne pastylki i przycisk 4-kanałowy RNK-24. Dam znać czy zostanie wykryty przez skrypt poprawnie czy będzie nowe ID sensora.
-
przyszedł mi nowy ściemniacz, podpiąłem, działa z HA bardzo ładnie. Przyjemna sprawa, że można sparować ściemniacz (bez scen czy logiki) z przyciskiem RNK-22 i za jego pomocą rozjaśniać i ściemniać (poprzez przytrzymanie) a nie tylko włączać/wyłączać.
Elementy, które posiadam (zobacz moją stopkę) powinny działać dobrze z HA. Testowane na sobie codziennie od 6 miesięcy :)
A co do parowania ściemniacza z RNK - tu zgoda - Zamel ma niekiedy dobre pomysły, tylko gorzej z ich wykonaniem. Gdybym znalazł odpowiednik nadajnika puszkowego na Z-Wave to już pozbyłbym się klocków Exta Life, ale niestety nie znalazłem takich elementów.
Za około tydzień będę miał kolejne pastylki i przycisk 4-kanałowy RNK-24. Dam znać czy zostanie wykryty przez skrypt poprawnie czy będzie nowe ID sensora.
Tak jak powyżej - RNK-24 (a w zasadzie jego czujnik temperatury) będzie działać na 100% poprawnie ze skryptem. Sam używam, więc nie przewiduję z tym problemów u ciebie. RNK-22 to było moje ewidentne przeoczenie.
Gdybyś się natomiast wyposażył np w SLR-21/22 to daj znać, bo tego skrypt nie obsługuje, a nie znam dokładnych id tych urządzeń i info z loga byłoby pomocne, aby je zaimplementować.
-
SLR nie planuję, przynajmniej na razie, gdyż nie mam żadnym ledów RGB u siebie. Planuję natomiast kupić głowice termostatyczne do grzejników ale to tak za miesiąc/dwa... Po instalacji kolejnych pastylek dopuszkowych czeka mnie wymiana wszystkich przycisków z monostabilnych na bistabilne, bo obecne zaczynają mnie irytować ;)
-
SLR nie planuję, przynajmniej na razie, gdyż nie mam żadnym ledów RGB u siebie.
Zdaje się, że jeden SLR jest do RGB a drugi do zwykłych LED - chodzi o zasilanie i ściemnianie.
Planuję natomiast kupić głowice termostatyczne do grzejników ale to tak za miesiąc/dwa...
Obsługi głowic niestety nie dodam do skryptu, gdyż byłoby z tym trochę roboty, a bez dostępu do takiego urządzenia ciężko będzie to jakoś testować. Potrzebne byłyby komendy wysyłane przez aplikację, a bez sprzętu tego nie sprawdzę. Musiałbym też obadać jaka encja w HA mogłaby to reprezentować - może Climate, ale pewności nie ma. Na pewno nie dałoby się wszystkich feature'rów głowicy przenieść do HA. Harmonogramy to najlepszy przykład. Samą bieżącą temperatury to jeszcze jeszcze.
Tak czy owak potrzebne będzie uodpornienie skryptu na nieznane urządzenia. Sama głowica pewnie zostanie zignorowana, ale sensor temperatury głowicy już nie. Jak znajdę czas to popracuję nad skryptem trochę.
Po instalacji kolejnych pastylek dopuszkowych czeka mnie wymiana wszystkich przycisków z monostabilnych na bistabilne, bo obecne zaczynają mnie irytować ;)
Ale lepiej jak będziesz miał monostabilne - takie są preferowane do takich systemów, gdzie sterowanie najczęściej jest impulsem lub zmianą stanu. Dla pewności - monostabilne to typowo "dzwonkowe' łączniki
-
Ale lepiej jak będziesz miał monostabilne - takie są preferowane do takich systemów, gdzie sterowanie najczęściej jest impulsem lub zmianą stanu. Dla pewności - monostabilne to typowo "dzwonkowe' łączniki
teraz mam bardzo standardowe Simony (przełącznik góra/dół) i żeby działało poprawnie musiałem w Zamelu na odbiorniku ustawić typ Monostabilny. Jak dla przykładu włączę światło przyciskiem, następnie wyłączę z aplikacji lub pilotem, to po ponownym wejściu do pokoju przełączam włącznik i nic się nie dzieje, bo dopiero przyciskiem wróciłem do pozycji "wyłączony", zatem muszę go przełączać 2x co jest irytujące.
Zamówiłem więc Simony 54 Premium (wczoraj przyszły, dziś będę montował) i są właśnie "dzwonkowe" i z tego co rozumiem, żeby działały poprawnie w Zamelu będę musiał zmienić typ wejścia na odbiornikach na bistabilny.
-
Ale lepiej jak będziesz miał monostabilne - takie są preferowane do takich systemów, gdzie sterowanie najczęściej jest impulsem lub zmianą stanu. Dla pewności - monostabilne to typowo "dzwonkowe' łączniki
teraz mam bardzo standardowe Simony (przełącznik góra/dół) i żeby działało poprawnie musiałem w Zamelu na odbiorniku ustawić typ Monostabilny. Jak dla przykładu włączę światło przyciskiem, następnie wyłączę z aplikacji lub pilotem, to po ponownym wejściu do pokoju przełączam włącznik i nic się nie dzieje, bo dopiero przyciskiem wróciłem do pozycji "wyłączony", zatem muszę go przełączać 2x co jest irytujące.
Zamówiłem więc Simony 54 Premium (wczoraj przyszły, dziś będę montował) i są właśnie "dzwonkowe" i z tego co rozumiem, żeby działały poprawnie w Zamelu będę musiał zmienić typ wejścia na odbiornikach na bistabilny.
Akurat kwestię łączników Zamel rozwiązał dość dobrze (ale dopiero od roku, bo na początku działało tylko z dzwonkowymi). Typ łącznika można konfigurować. Do zwykłych SImonów trzeba ustawić bistabilny, wtedy każde przełączenie (dół lub góra) będzie zmieniało stan odbiornika. Natomiast do Twojego Simona 54 będziesz musiał zmienić typ łącznika na Monostabilny.
-
Jakiś czas temu testowo odpaliłem integrację na czystym debianie. Teraz chciałbym przenieść do na NASa: Netgear ReadyNAS Pro4, pod spodem Debian Jessie (doinstalowany przez apt-get python3 i doinstalowane przez pip3 moduły pyyaml paho-mqtt unidecode), w dockerze zaś homeassistant i mosquito.
Do HA dodana integracja MQTT, plik config.py zawiera poprawne dane. Próba uruchomienia skryptu kończy się błędem:
root@nas:/apps/docker-root/homeassistant/scripts# ./start_exta2ha.sh --testrun
Traceback (most recent call last):
File "main_exta2ha.py", line 27, in <module>
from ExtaLife_HA import ExtaLifeTCPStream
File "/apps/docker-root/homeassistant/scripts/ExtaLife_HA.py", line 391
cfg_ret = {**self.cfg_dict[ha_object_id[chn]]}
^
SyntaxError: invalid syntax
Prośba o pomoc.
PS Wczoraj zamontowałem dwie głowice RGT-01. Nie wiem czy to nie jest problemem...
-
@shibbby ten błąd wygląda mi raczej na problem ze zrozumieniem kodu przez interpreter Python. Czy zmieniałeś coś w pliku start_exta2ha.sh? Chodzi mi o to czy skrypt jest na pewno uruchamiany przez python 3 a dokładnie minimum 3.5?? Wstawianie / dodawanie elementów zmiennej typu dictionary do innej zmiennej typu dictionary jest wspierane dopiero od wersji Python 3.5. Między innymi dlatego moje skrypty wymagają Pythona minimum 3.5
Postaram się w najbliższym czasie wypuścić wersję skryptów uodpornioną na nowe, nieznane moduły. Jednak w mojej ocenie ten błąd, który się u ciebie pojawia to nie problem z nieznanym modułem, a właśnie wersją pythona którą posiadasz. Sprawdź proszę
-
a widzisz.... zainstalowałem "python3" i przez myśl mi nie przeszło, że w jessie`m jest wersja 3.4 i stąd problemy.
Postawiłem się pythona 3.6 w dockerze. Musiałem zrobić własny obraz by doinstalować brakujące moduły
root@nas:/apps/docker-root/homeassistant/scripts/docker# docker build -t python-ha .
Sending build context to Docker daemon 2.048kB
Step 1/3 : FROM python:3.6-stretch
---> 36509c62ad26
Step 2/3 : WORKDIR /scripts
---> Running in fda2b4d14805
Removing intermediate container fda2b4d14805
---> a2d0c93bd38e
Step 3/3 : RUN pip install --no-cache-dir pyyaml paho-mqtt unidecode
---> Running in 11c06795ca5c
Collecting pyyaml
Downloading https://files.pythonhosted.org/packages/e3/e8/b3212641ee2718d556df0f23f78de8303f068fe29cdaa7a91018849582fe/PyYAML-5.1.2.tar.gz (265kB)
Collecting paho-mqtt
Downloading https://files.pythonhosted.org/packages/25/63/db25e62979c2a716a74950c9ed658dce431b5cb01fde29eb6cba9489a904/paho-mqtt-1.4.0.tar.gz (88kB)
Collecting unidecode
Downloading https://files.pythonhosted.org/packages/d0/42/d9edfed04228bacea2d824904cae367ee9efd05e6cce7ceaaedd0b0ad964/Unidecode-1.1.1-py2.py3-none-any.whl (238kB)
Building wheels for collected packages: pyyaml, paho-mqtt
Building wheel for pyyaml (setup.py): started
Building wheel for pyyaml (setup.py): finished with status 'done'
Created wheel for pyyaml: filename=PyYAML-5.1.2-cp36-cp36m-linux_x86_64.whl size=415539 sha256=b856aa9ddb1ea26dc5f23979654f3713ddff028fb090276750e8c3875a4913a8
Stored in directory: /tmp/pip-ephem-wheel-cache-gvfw5xex/wheels/d9/45/dd/65f0b38450c47cf7e5312883deb97d065e030c5cca0a365030
Building wheel for paho-mqtt (setup.py): started
Building wheel for paho-mqtt (setup.py): finished with status 'done'
Created wheel for paho-mqtt: filename=paho_mqtt-1.4.0-cp36-none-any.whl size=48331 sha256=43e3fd53030a8293ee6a78c6c236941c60ad2cf68485bb329c50fa7a3057f467
Stored in directory: /tmp/pip-ephem-wheel-cache-gvfw5xex/wheels/82/e5/de/d90d0f397648a1b58ffeea1b5742ac8c77f71fd43b550fa5a5
Successfully built pyyaml paho-mqtt
Installing collected packages: pyyaml, paho-mqtt, unidecode
Successfully installed paho-mqtt-1.4.0 pyyaml-5.1.2 unidecode-1.1.1
Removing intermediate container 11c06795ca5c
---> 19af89d87b1d
Successfully built 19af89d87b1d
Successfully tagged python-ha:latest
Teraz wysypuje się na
root@nas:/apps/docker-root/homeassistant/scripts# docker run -it --rm --name python3 -v /apps/docker-root/homeassistant/scripts:/scripts python-ha:latest python /scripts/main_exta2ha.py --testrun
Traceback (most recent call last):
File "/scripts/main_exta2ha.py", line 196, in <module>
prog.main()
File "/scripts/main_exta2ha.py", line 181, in main
self.ha_mqtt.ha_update_state_from_device(device)
File "/scripts/ExtaLife_HA.py", line 742, in ha_update_state_from_device
cfg_dict = self.HAConfig.get_from_device(i_device)
File "/scripts/ExtaLife_HA.py", line 552, in get_from_device
cfg_dict[objid] = self.cfg_dict[objid] # may raise KeyError exception
KeyError: '13-1'
log:
2019-09-16 12:25:00,936 WARNING:CONFIG: Unknown Exta Life device. Mapping failed. Device Category: 1, Type: 16
2019-09-16 12:25:00,937 WARNING:No config found for device: 13
i to pewnie moje nieszczęsne głowice...
PS zauważyłem, że w opublikowanym skrypcie brakuje wsparcia dla sensora temperatury z RNK-22 - to co wcześniej rozmawialiśmy czyli e ExtaLife_HA.py w linii 89 dodać 2.
-
a widzisz.... zainstalowałem "python3" i przez myśl mi nie przeszło, że w jessie`m jest wersja 3.4 i stąd problemy.
Tak myślałem :)
Teraz wysypuje się na
root@nas:/apps/docker-root/homeassistant/scripts# docker run -it --rm --name python3 -v /apps/docker-root/homeassistant/scripts:/scripts python-ha:latest python /scripts/main_exta2ha.py --testrun
Traceback (most recent call last):
File "/scripts/main_exta2ha.py", line 196, in <module>
prog.main()
File "/scripts/main_exta2ha.py", line 181, in main
self.ha_mqtt.ha_update_state_from_device(device)
File "/scripts/ExtaLife_HA.py", line 742, in ha_update_state_from_device
cfg_dict = self.HAConfig.get_from_device(i_device)
File "/scripts/ExtaLife_HA.py", line 552, in get_from_device
cfg_dict[objid] = self.cfg_dict[objid] # may raise KeyError exception
KeyError: '13-1'
Tak, to właśnie problem z nieodpornością programu na nowe moduły. I jak się okazało - grzebałem w tym jeszcze w maju, gdy zgłaszałeś problemy z czujnikiem. Po 4 miesiącach nie pamiętam czy rozwiązałem problem, ale patrząc na kod oceniam że z dużym prawdopodobieństwem - tak :)
Chcąc nie chcąc zostajesz testerem nowej wersji. Załączam program z drobnymi zmianami. Podmień plik i zobacz czy teraz będzie działało. Wg mnie powinno. Koniecznie daj znać, to opublikuję w pierwszym poście całą paczkę dla potomnych.
log:
2019-09-16 12:25:00,936 WARNING:CONFIG: Unknown Exta Life device. Mapping failed. Device Category: 1, Type: 16
2019-09-16 12:25:00,937 WARNING:No config found for device: 13
i to pewnie moje nieszczęsne głowice...
Zdecydowanie tak. Sprawdziłem na naszej wiki i nawet kiedyś z kodu aplikacji Exta Life wywnioskowałem, że typ 16 to głowica
W najnowszej wersji powinna zostać zignorowana i wszystko powinno śmigać.
PS zauważyłem, że w opublikowanym skrypcie brakuje wsparcia dla sensora temperatury z RNK-22 - to co wcześniej rozmawialiśmy czyli e ExtaLife_HA.py w linii 89 dodać 2.
Dodane.
Dodatkowo niedawno odkryłem dlaczego urządzenia nie pojawiają się w HA w ekranie integracji w MQTT. Jeśli zgodzisz się trochę potestować to spróbuję zmodyfikować program tak, aby encje wygenerowane przez pakiet integracyjny pojawiły się w ekranie integracji. Daj znać :)
-
na skrypcie 1.0.1 parametr testrun wywala
Traceback (most recent call last):
File "/scripts/main_exta2ha.py", line 27, in <module>
from ExtaLife_HA import ExtaLifeTCPStream
File "/scripts/ExtaLife_HA.py", line 895
SyntaxError: (unicode error) 'utf-8' codec can't decode byte 0xb0 in position 0: invalid start byte
nie tworzy się nawet plik z logiem.
-
hmm, brzmi poważnie. To o tyle dziwne, że tam nic nie było zmieniane. Plik wyedyowałem notatnikiem windows - może coś się z kodowaniem znaków pochrzniło. Skopiowałem teraz z oryginalnego pliku z linuxa.
Podmień jeszcze raz - załączam ponownie. Mam nadzieję, że ruszy, bo jeśli nie to na razie nie mam pojęcia co jest źle.
-
znak °C go bolał. Poprawiłem.
PS zauważyłem, że w opublikowanym skrypcie brakuje wsparcia dla sensora temperatury z RNK-22 - to co wcześniej rozmawialiśmy czyli e ExtaLife_HA.py w linii 89 dodać 2.
Dodane.
nie dodałeś ;)
WARNING:CONFIG: Unknown Exta Life sensor type: 2. Mapping failed
w 1.0.1 wciąż jest
JSON_DEVICE_ARR_SENS_TEMP = [4,20,21]
;)
-
na pierwszy rzut oka wygląda że działa. Jak chcesz bym coś testował to pisz śmiało :)
BTW
/scripts/ExtaLife_HA.py:578: YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as the default Loader is unsafe. Please read https://msg.pyyaml.org/load for full details.
self.cfg_dict = yaml.load(cfg_file)
ale to tylko warning.
-
znak °C go bolał. Poprawiłem.
hmm, kompletnie nie rozumiem dlaczego python tutaj zaprotestował ??? U mnie używam tego znaku i czujnik temperatury pokazuje jednostkę pomiaru w stopniach celsjusza poprawnie. Nie mam tego syntaxa.
PS zauważyłem, że w opublikowanym skrypcie brakuje wsparcia dla sensora temperatury z RNK-22 - to co wcześniej rozmawialiśmy czyli e ExtaLife_HA.py w linii 89 dodać 2.
Dodane.
nie dodałeś ;)
WARNING:CONFIG: Unknown Exta Life sensor type: 2. Mapping failed
w 1.0.1 wciąż jest
JSON_DEVICE_ARR_SENS_TEMP = [4,20,21]
;)
Faktycznie, nie wiem jak to się stało - patrzyłem na to jeszcze dzisiaj przed opublikowaniem...może ctrl-z wcisnęło się przypadkowo..nie wiem - ale ważne że zauważyłeś i naprawiłeś.
Czyli teraz wszystko działa?? Głowica jest ignorowana?
-
tak, wszystko co miało być wykryte zostało, głowica została pomimięta.
Z tym znakiem st. celcjusza chodziło o to, że po zapisie (wersja z notatnika) było .C z czego kropka była jeszcze w czarnej kratce, czyli ewidentnie wina kodowania. Ja poprawiłem na °C, tak jak podesłałeś w drugim skrypcie i działa.
-
Do pobrania uaktualniona wersja pakietu integracyjnego! Wprowadziłem numerację wersji dla całości, aby łątwiej było śledzić zmiany. Szczegóły w pliku readme[PL].txt
REJESTR ZMIAN:
- uodporniono pakiet na nowe, nieobsługiwane przez pakiet urządzenia Exta Life np RGT-01
- dodano obsługę czujnika temperatury z RNP-22
Całość do pobrania tradycyjnie w pierwszym poście
-
na pierwszy rzut oka wygląda że działa. Jak chcesz bym coś testował to pisz śmiało :)
ano chętnie skorzystam z Twojej propozycji. Dodałem grupowanie encji Exta Life tworzonych przez pakiet integracyjny w ekranie 'Integrations' w Home Assistant w sekcji 'MQTT'. Wygląda to jak w załączniku. Działa analogicznie do innych integracji, które pokazują się na tym ekranie. Wszystkie encje zgrupowane będą pod jedną nazwą 'Exta Life' i urządzeniem EFC-01.
Aby urządzenia się w ten sposób pokazały - wymagane jest przeprowadzenie procedury MQTT Discovery czyli uruchomienie skryptu z parametrem --testrun, lub po prostu uruchomienie 'normalne', gdy nie ma wygenerowanego pliku konfiguracyjnego.
Jeśli skrypt zarejestrował już wcześniej urządzenia Exta Life w HA (encje się wygenerowały) to ponowny proces Discovery w tym przypadku może spowodować pojawienie się zdublowanych encji z numerkami _1 na końcu nazwy. Nie jestem pewny czy tak będzie, ale to bardzo prawdopodobne. Lepiej jest więc to robić na 'czystym' HA. Ewentualnie potem można naprawić duplikaty w ekranie rejestru encji w HA. Tam można zmienić im nazwy, a stare skasować.
Oddaję w Twoje ręce do testowania :)
BTW
/scripts/ExtaLife_HA.py:578: YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as the default Loader is unsafe. Please read https://msg.pyyaml.org/load for full details.
self.cfg_dict = yaml.load(cfg_file)
ale to tylko warning.
Postanowiłem się zająć również i tym. Fix wydaje się banalny. Przyczyną tego warninga jest to, że posiadasz najnowszą wersję biblioteki yaml a tam wprowadzono zmianę ze względó bezpieczeńśtwa. Zmieniłem nieco kod i wygląda, że poprawka działa także na sterej wersji. Pytanie czy będzie dizałać także u ciebie. Sprawdź proszę.
Instalacja wersji z obsługą ekranu integracji oraz poprawką dla yaml - banalna jak zawsze - podmień plik z załącznika.
Miłęgo używania. Jeśli okaże się, że wszystko dobrze to w niedługim czasie opublikuję wersję 1.1 dla wszystkich.
-
HA mam już czystego do testów. Teraz walczę z pythonem 3.5 na Debian Jessie (niestety coś Netgear nie kwapi się by udostępnić choćby stretcha na Readynasy). Jednak python w dockerze to pomyłka. Raz, że bardzo wolno chodzi na NASie, a dwa to nie jestem w stanie odpalić twoich skryptów by działały jako "daemon" czyli z & na końcu. Właśnie kompiluję 3.5.2 i jak ruszy to sprawdzę twój skrypt :)
-
mam ogromne problemy z działaniem HA i mosquitto w dockerze :/ Co rusz mam błędy w stylu
2019-09-18 10:51:59,242 ERROR:Error connecting to MQTT broker
Traceback (most recent call last):
File "main_exta2ha.py", line 73, in conn_mqtt
self.mqtt.connect(MQTT_IP, MQTT_PORT, 60)
File "/root/.pyenv/versions/3.6.9/lib/python3.6/site-packages/paho/mqtt/client.py", line 839, in connect
return self.reconnect()
File "/root/.pyenv/versions/3.6.9/lib/python3.6/site-packages/paho/mqtt/client.py", line 962, in reconnect
sock = socket.create_connection((self._host, self._port), source_address=(self._bind_address, 0))
File "/root/.pyenv/versions/3.6.9/lib/python3.6/socket.py", line 724, in create_connection
raise err
File "/root/.pyenv/versions/3.6.9/lib/python3.6/socket.py", line 713, in create_connection
sock.connect(sa)
OSError: [Errno 113] No route to host
muszę odpalić wirtualkę, na której mam czystego debiana, HA, MQTT i tam mi wszystko działało jak trzeba i na niej potestuję.
-
Jednak python w dockerze to pomyłka. Raz, że bardzo wolno chodzi na NASie, a dwa to nie jestem w stanie odpalić twoich skryptów by działały jako "daemon" czyli z & na końcu. Właśnie kompiluję 3.5.2 i jak ruszy to sprawdzę twój skrypt :)
Hmm, dziwna sprawa, że działa wolno w dockerze. To może kwestia twojego NASa, Docker to bardzo lekka wirtualizacja i strata na wydajności jest minimalna. Inaczej nie dałoby się odpalić HA na malinie. Przecież hass.io działa na dockere, a jakże. Każdy add-on hass.io to osobny kontener dockera.
Podejrzewam, że problem leży jednak w Twoim NAS.
Niestety producenci NASów lubią coś skopać lub pozmieniać na niekorzyść oryginalnego oprogramowania. Na ten przykład - na QNAP Docker niby istnieje, ale pod inną nazwą i jest mocno pozmieniany przez QNAP. W Synology co prawda Docker to Docker, ale Synology także wprowadza do niego swoje małe modyfikacje (na szczęście więcej na plus niż minus - np obsługa przez GUI).
Może twój ReadyNAS ma zmodyfikowaną wersję Dockera i stąd całe kłopoty?
mam ogromne problemy z działaniem HA i mosquitto w dockerze :/ Co rusz mam błędy w stylu
2019-09-18 10:51:59,242 ERROR:Error connecting to MQTT broker
Traceback (most recent call last):
File "main_exta2ha.py", line 73, in conn_mqtt
self.mqtt.connect(MQTT_IP, MQTT_PORT, 60)
File "/root/.pyenv/versions/3.6.9/lib/python3.6/site-packages/paho/mqtt/client.py", line 839, in connect
return self.reconnect()
File "/root/.pyenv/versions/3.6.9/lib/python3.6/site-packages/paho/mqtt/client.py", line 962, in reconnect
sock = socket.create_connection((self._host, self._port), source_address=(self._bind_address, 0))
File "/root/.pyenv/versions/3.6.9/lib/python3.6/socket.py", line 724, in create_connection
raise err
File "/root/.pyenv/versions/3.6.9/lib/python3.6/socket.py", line 713, in create_connection
sock.connect(sa)
OSError: [Errno 113] No route to host
Patrząc na Twój błąd to wygląda jalby kontenery nie mogły się ze sobą skomunikować. Rozumiem, że masz HA i MQTT w osobnych kontenerach docker? Jeśli tak to koniecznie sprawdź ustawienia dockera dla tych kontenerów. Wg mnie to może być problem. Tylko w tym przypadku raczej nie powinno to działać na zasadzie czasem zadziałą, a czasem nie... ???
Niestety niewiele tutaj pomogę - moja znajomość linuxa jest dość ograniczona. Powodzenia!
-
Akurat mój NAS ma to co cenię sobie w nim najbardziej, czyli prawie nietknięty Debian :) Pełny apt, pełne możliwości, czego producent nie przewidział można sobie doinstalować, dokompilować. Docker jest czyściutki, wprost z oficjalnego repo. Jako GUI jest poprostu Portainer jako contener :)
ReadyNAS Pro4, bo o nim mowa, a na pokładzie Atom D510 (2-core, 4-threads), 4GB ram (oryginalnie 1GB, wykosztowałem się 4GB DDR2 so-dimm w jednej kości ale warto było), no i 2x WDred 4TB w RAID1. Tak więc o jego wydajność bym się nie martwił.
Mam na nim php7.2, Nextcloud, mysql, zaś w dockerze siedzi kontroler unifi, pihole, Collabora Online, watchtower i wspomniany wcześniej Portainer.
Żeby było zabawniej w Synology nie udało mi się odpalić Collabora Online w dockerze - nie działa i już :)
Wracając jednak do tematu: poddałeś mi myśl. Ja instalowałem osobno HA (homeassistant/home-assistant) i osobno mosquitto (eclipse-mosquitto) i może tu był problem. Nie przyszło mi do głowy by mosquitto zainstalować jako add-on w HA, a chyba tak właśnie wcześniej na czystym linuxie robiłęm. Zaraz spróbuję.
-
Intel Atom. Dobry wybór. Ja mam Celeron. Ważne żeby CPU nie był ARMem. Jako serwer słabo by się wtedy sprawdzał. Szczególnie przy obrabianiu multimediów lub szukaniu w bazach czyli dla HA byłoby słabo.
Z wydajnością chodziło mi nie o podzespoły tylko o problemy w sofcie (jakieś sterowniki, błędy w Linuxie itp). U mnie z wydajnością dockerze nie ma żadnych problemów.
Ja też mam HA i MQTT jako osobne kontenery. Oba działają z siecią jako hist. Może ty masz bridge? Sprawdź bo jak jest 'no ruote to host' to jest jakiś problem z siecią
-
Oba działają z siecią jako hist. Może ty masz bridge?
bingo :) dockera dopiero się uczę ;) Jakieś 2 m-c temu go zainstalowałem. Faktycznie miałem jako bridge. Stawiam na nowo jako host i zobaczymy.
-
coś jest nie tak z tym nowym skryptem. W logach nie mam żadnych błędów ale encje w HA się nie pojawiają.
Wrzucam stary skrypt ExtaLife_HA.py, wywołuję testrun i encje pojawiają się momentalnie.
-
coś jest nie tak z tym nowym skryptem. W logach nie mam żadnych błędów ale encje w HA się nie pojawiają.
Wrzucam stary skrypt ExtaLife_HA.py, wywołuję testrun i encje pojawiają się momentalnie.
Zrestartuj HA I spróbuj ponownie. Czy uruchamialeś z parametrem --testrun?? Discovery w HA zapamiętuje komunikaty. Być może coś się zabuforowało w HA i encje się nie pojawiły. Zrestartuj i spróbuj nowego ponownie. U mnie na testowym HA działało bez problemu. Po restarcie mogłem ponownie wykonać --testrun i encje się pojawiały i grupowały w widoku Integrations MQTT
-
niestety próbowałem. Ale pokolei:
1) HA i MQTT postawione, widzą się bez problemu, python 3.6.9 z potrzebnymi modułami
2) w HA dodaję integrację MQTT, podaję IP brokera i zaznaczam autowykrywanie
3) uzupełniam dane w config.py
4) odpalam nowy skrypt z parametrem --testrun. Skrypt wykonuje się bez błędów, tworzy się config, w logu nie ma błędów ale w HA nie pojawiają się encje
5) podmieniam plik ExtaLife_HA.py na wcześniejszy, odpalam raz jeszcze --testrun i od strzała mam encje w HA
-
Wiem! Mój błąd :-[
Linia 632. Zmień 'ha' na 'homeassistant'.
Rdzeń wątku MQTT zostawiłem że swojego testowego setupu. Powinno zacząć działać
-
noo :) teraz encje się pojawiły, nawet w integracjach->MQTT się teraz pojawiły ale... wcześniej z automatu tworzył też się widok wszystkich elementów na głównej stronie HA a teraz się nie tworzy... tak ma być?
-
noo :) teraz encje się pojawiły, nawet w integracjach->MQTT się teraz pojawiły
I o to chodziło ;)
ale... wcześniej z automatu tworzył też się widok wszystkich elementów na głównej stronie HA a teraz się nie tworzy... tak ma być?
Hmm u mnie tak nigdy nie było... zawsze musiałem dodawać ręcznie do ekranów. Raczej niezwiązane ze skryptem. Dobrze że ruszyło :)
-
A, no i daj znać jak się nowa wersja sprawuje jak ja trochę poużywasz. Moim zdaniem będzie działać ok. Zmiany są minimalne aby dodać do ekranu integracji
-
Spójrz proszę na te screeny. testrun1 to wygląd HA po odpaleniu nowego skryptu na świeżo postawionym HA i mosquitto. Czyli nic nowego na stronie głównej nie przybyło ale encje są do dodania.
screen testrun2 to wygląd HA po odpaleniu komendy testrun na starym skrypcie na czystym HA. Jak widzisz encje od razu się pojawiły na stronie głównej. Głównie chodzi mi o wskazania temperatur w pomieszczeniach, które ładnie wskoczyły na górę.
Nie jest to oczywiście problem by dodać je samemu. Po prostu ciekawi mnie czemu wcześniej się to robiło z automatu a teraz nie chce :)
-
albo ne było tematu. Teraz postawiłem wszystko raz jeszcze od zera i pojawiło się wszystko na stronie głównej HA, tak jak na drugim screenie XD
Nie wiem od czego to zależy :)
Za to jest inny problem: jak np włączam światło w HA, to w aplikacji extalife też stan się zmienia i światło faktycznie się zapala (w logu main_ha2exta.py.log też się stan zapisuje). Natomiast gdy zapalam światło przez aplikację Zamela, to w HA stan się nie zmienia, a w logu main_exta2ha.py.log nic się nie pojawia.
-
Spójrz proszę na te screeny. testrun1 to wygląd HA po odpaleniu nowego skryptu na świeżo postawionym HA i mosquitto. Czyli nic nowego na stronie głównej nie przybyło ale encje są do dodania.
screen testrun2 to wygląd HA po odpaleniu komendy testrun na starym skrypcie na czystym HA. Jak widzisz encje od razu się pojawiły na stronie głównej. Głównie chodzi mi o wskazania temperatur w pomieszczeniach, które ładnie wskoczyły na górę.
Nie jest to oczywiście problem by dodać je samemu. Po prostu ciekawi mnie czemu wcześniej się to robiło z automatu a teraz nie chce :)
Jedynie jak mogę to wytłumaczyć, to tak, że jakimś cudem stary skrypt tworzy encje w HA o nazwach, które masz użyte na swoim ekranie Lovelace, a nowy skrypt tworzy inne. Jedyną różnicą może być jedynie dodanie do nazwy końcówki "_1" albo "_2" itp. Łatwo to sprawdzić w rejestrze encji lub ekranie Narzędzia deweloperskie > Stany. Jeśli nazwy encji Exta Life po odpaleniu skryptu starego i nowego będą inne to to jest powód.
Lovelace działa prosto - bierzesz nazwę encji i dodajesz ją do danego ekranu i widoku. Jeśli nazwa encji jest inna niż ta przypisana do danego widoku to nic się faktycznie nie wyświetli.
Reguły nazewnictwa nie zmieniły się w tej testowej wersji skryptu (1.1). Są takie same, więc encje powinny nazywać się tak samo. Być może odpaliłeś skrypt więcej niż jeden raz między restartami HA i HA zgłupiał?
albo ne było tematu. Teraz postawiłem wszystko raz jeszcze od zera i pojawiło się wszystko na stronie głównej HA, tak jak na drugim screenie XD
Nie wiem od czego to zależy :)
j.w.
Za to jest inny problem: jak np włączam światło w HA, to w aplikacji extalife też stan się zmienia i światło faktycznie się zapala (w logu main_ha2exta.py.log też się stan zapisuje). Natomiast gdy zapalam światło przez aplikację Zamela, to w HA stan się nie zmienia, a w logu main_exta2ha.py.log nic się nie pojawia.
To normalne. Poczekaj 5 minut od włączenia w aplikacji Zamela, a stan w HA także się zmieni. Skrypt używa koncepcji poolingu stanu tzn cyklicznie odpytuje EFC-01 o stany urządzeń. Domyślnie co 5 minut.
EFC-01 co prawda chyba rozsyła do innych użytkowników zmiany stanu na bieżąco tzn. jeśli ktoś inny zmieni stan danego odbiornika w aplikacji(bo wyłącznikiem już nie), ale obsłużenie tego wymagałoby dodatkowego nakładu pracy w programie i dość dużej zmiany w programie do obsługi stanów Exta Life (ten, który co 5 minut odpytuje kontroler). Być może kiedyś to dodam, ale moja koncepcja integracji z HA zakłada porzucenie aplikacji ExtaLife :P na rzecz pięknego Lovelace UI z HA :) Tak więc "problem" jest wg mnie mało palący.
Czasem używam aplikacji Exta Life do obsługi mojego elementu Exta Free, gdyż skrypt nie integruje elementów Exta Free oraz czasem w "nagłych" wypadkach używam funkcji czasowych w aplikacji. Czasem jest szybciej to zrobić z aplikacji ExtaLife niż w HA, ponieważ w HA zaprogramowanie automatyzacji w GUI wymaga jeszcze trochę gimnastyki i na ekranie smartfona potrafi być uciążliwe....ale HA nadal ewoluuje. Co rusz dostaje nowe usprawnienia. Nowa wersja 0.99, która dzisiaj ujrzała światło dzienne upraszcza tworzenie automatyzacji wprowadzając pojęcie 'Urządzenia'. I tak się składa, że urządzeniem jest encja, która należy do danego typu integracji w widoku 'Integracje'. Automatycznie pojawia się wtedy lista triggerów dla tego urządzenia i cały proces jest szybszy i prostszy. I tutaj nowa wersja testowa skryptu pasuje jak znalazł! Dzięki temu, że encje ExtaLife pojawiają się w widoku Integracje to będą kiedyś obsługiwane także w uproszczonym tworzeniu automatyzacji. Na razie obsługiwanych jest tylko kilka typów urządzeń, ale wierzę, że MQTT znajdzie się tam szybko, gdyż jest jednym z podstawowych protokołów IoT i konstrukcji DIY.
-
no to elegancko. Myślałem, że komunikacja w obie strony jest natychmiastowa, bo po to odpalamy w tle oba skrypty shellowe, ale skoro to zamierzone to nie mam uwag.
Ja ogólnie mało używam Extalife. Raz skonfigurowane ma po prostu działać :) Przyciski poustawiane, głowice również. HA bawię się po prostu, nie po to by go używać jakoś intensywnie ale po to by poznać coś nowego i na swój sposób pomóc w rozwoju tego projektu :)
-
no to elegancko. Myślałem, że komunikacja w obie strony jest natychmiastowa, bo po to odpalamy w tle oba skrypty shellowe, ale skoro to zamierzone to nie mam uwag.
Niestety nie. Natychmiastowe jest tylko przesyłanie zmiany stanu z HA do ExtaLife. Wynika to głównie z tego, że Zamel zmienił sposób komunikacji modułów z EFC-01 w kwietniu zeszłego roku. Stany odbiorników nie są aktualizowane na bieżąco czyli EFC-01 nie wie że ktoś zmienił stan w odbiorniku, gdy ktoś będzie nim sterował lokalnie lub pośrednio przez nadajnik. EFC-01 dowie się o tym dopiero gdy odpyta dany odbiornik. Kiedyś było inaczej i wtedy faktycznie komunikacja ExtaLife <-> HA byłaby natychmiastowa w obie strony, ponieważ EFC-01 od razu powiadamiał aplikację, że jakiś odbiornik zmienił swój stan. Teraz EFC-01 powiadamia aplikację w czasie rzeczywistym tylko gdy inny użytkownik zmieni stan odbiornika poprzez aplikację.
Popatrzę ile wymagałoby to pracy, aby obsłużyć ten przypadek, choć podejrzewam, że trochę zabawy będzie, ponieważ zmienia to nieco założenia programu, który na swoje rządanie odpytuje kontroler a nie czeka non stop na zdarzenia z kontrolera. Mimo wszystko zobaczę, ale niczego nie obiecuję 8)
Ja ogólnie mało używam Extalife. Raz skonfigurowane ma po prostu działać :) Przyciski poustawiane, głowice również. HA bawię się po prostu, nie po to by go używać jakoś intensywnie ale po to by poznać coś nowego i na swój sposób pomóc w rozwoju tego projektu :)
Ja HA używam ciągle. A wynika to w głównej mierze z tego, że ma on niewyobrażalnie większe możliwości jeśli chodzi o tworzenie różnych automatyzacji niż biedne funkcje logiczne i czasowe Zamela w aplikacji, a poza tym - nie mniej ważne - potrafi integrować tysiące różnych urządzeń ze sobą i tworzyć automatyzacje z użyciem ich wszystkich tzn każde urządzenie może być triggerem dla sterowania innego i vice versa. Genialna sprawa. No i pozwala wypełnić braki sprzętowe w serii Exta Life innymi produktami (np czujniki bluetooth, z-wave, ZigBee i tony innych rzeczy).
HA pozwolił mi zrealizować wszystkie scenariusze, które opisałem na forum w tym (https://www.forumextalife.pl/index.php/topic,65.0.html) wątku.
Otwarty system smart home to zarówno dobre rozwiązanie na zbudowanie systemu inteligentnego domu w oparciu o różne moduły, a także dobre uzupełnienie tradycyjnych systemów smart home (Fibaro, Grenton itp). Mój kolega używa HA do uzupełnienia braków w systemie Grenton (integracja z HA poprzez RestAPI).
-
na logikę w HA przyjdzie jeszcze czas. Na razie system mam na tyle mały, że nie potrzebuję większej funkcjonalności niż daje mi apka Zamela, choć po ostatnich doniesieniach mam smaka na Gekona :)
Czyli mówisz, że jak włączę światło ze zwykłego włącznika bistabilnego to apka się o tym nie dowie w czasie rzeczywistym?!? Aż muszę to sprawdzić jak wrócę do domu.
-
Czyli mówisz, że jak włączę światło ze zwykłego włącznika bistabilnego to apka się o tym nie dowie w czasie rzeczywistym?!? Aż muszę to sprawdzić jak wrócę do domu.
Jeśli wejdziesz w ekran Urządzenia lub w jakąś kategorię widoku Dom to gdy użyjesz łącznika to stan się nie zmieni. Tzn zmieni się dopiero po 30 minutach bo kontroler sam odpytuje wszystkie odbiorniki co pół godziny. Jeśli chcesz zobaczyć zmianę stanu to musisz w aplikacji odświeżyć widok (przeciągnij w dół), albo wyjść i wejść do widoku ponownie. Wtedy właśnie kontroler odświeża stan odbiorników.
Wszystko potoczyłoby się inaczej, gdyby radio Exta Life było wyposażone w detekcję kolizji sygnałów na radiu - wtedy system mógłby działać tak jak pierwotnie i wszystko działałoby ładnie. Ale niestety tak nie działa, i mamy takie kulawe rozwiązanie. Pod tym względem supla wypada znacznie lepiej. A dodatkowo - supla zyskała w wersji HA 0.99 natywne wsparcie(!). Nie wiem czy ktoś z programistów supli o to zadbał czy jakiś użytkownik HA, ale jeśli oficjalny programista supli, to pogratulować im tylko podejścia.
-
jeszcze wracając do głowic... rozumiem, że pełne oprogramowanie ich (harmonogram) nie wchodzi w grę, ale pytanie czy nie szło by z nich zczytywać chociaż temperatury otoczenia i (jakby się dało) temperatury zdefiniowanej. Chciałbyś się tym pobawić? Jak tak to daj znać czy na odległość jestem w stanie dać ci potrzebne dane/logi :)
-
jeszcze wracając do głowic... rozumiem, że pełne oprogramowanie ich (harmonogram) nie wchodzi w grę,
Dokładnie. Nie wchodzi w grę gdyż nie ma jak tego odwzorować w HA za pomocą komponentu MQTT
ale pytanie czy nie szło by z nich zczytywać chociaż temperatury otoczenia i (jakby się dało) temperatury zdefiniowanej. Chciałbyś się tym pobawić? Jak tak to daj znać czy na odległość jestem w stanie dać ci potrzebne dane/logi :)
Powinno się dać...będzie z tym troszkę zabawy gdyż te temperatury to cechu odbiornika a nie czujnika Exta Life (widać je w zakładce odbiorniki a nie czujniki), ale chyba sobie z tym poradzę ;)
Będę jednak potrzebował pomocy - potrzebuje przechwyconego ruchu sieciowego żeby wiedzieć jak kontroler przesyła to do aplikacji. Jutro dam znać co masz zrobić
-
Będę potrzebował przechwycony ruch sieciowy pomiędzy twoim EFC-01 a aplikacją. Chodzi o ekran Urządzenia, gdzie jak mniemam pojawia się głowica RGT-01.
W tym poście (https://www.forumextalife.pl/index.php/topic,216.msg1198.html#msg1198) i wątku masz filmik pokazujący jak to zrobić. Ja używam aplikacji Ja używam apkę "Packet capture" od developera Grey Shirts. W sklepie Play już jej nie ma, ale bezpieczenie można pobrać z APK Mirror - link (https://www.apkmirror.com/apk/grey-shirts/packet-capture/packet-capture-1-4-7-release/packet-capture-1-4-7-android-apk-download/)
Operację przeprowadź może na jakiś testowym użytkowniku, gdyż może zalogować się twoje hasło i user. Powodzenia :)
-
mam, załączyć tu czy podesłać ci gdzieś na maila?
-
mam, załączyć tu czy podesłać ci gdzieś na maila?
Odpisałem Ci na maila. Odpisz na adres forumowy tak jak podałem w mailu.
-
poszło.
Powodzenia :)
-
poszło.
Powodzenia :)
Przeanalizowałem to trochę lepiej dzisiaj doszedłem do wniosku że na razie nie będę robił specjalnego mapowania atrybutów odbiorników na czujniki. Za to zamierzam lepiej rozpoznać komponent HA MQTT HVAC czyli dedykowany komponent do sterowania ogrzewaniem i wentylacją w HA i mapować głowicę na niego. Jak robić - to porządnie, a co 🙂 oczywiście takie podejście spowoduje że zajmie to więcej czasu ale myślę że się opłaca
-
Kolego @shibby - pierwsza wersja testowa kodu, który zmapuje RGT-01 na integrację MQTT HVAC (w HA szukaj encji zaczynającej się od "climate.")! :)
Nie było z tym nawet bardzo dużo pracy. Dużo dobrej roboty, aby skrócić czas odwalił Visual Studio Code, którego używam od niedawna i jestem zachwycony (a i to chyba mało powiedziane). Że ja o nim nie wiedziałem, gdy robiłem pierwszą wersję!! W porównaniu do Notepad++ to jak przejażdżka Bugatti Chiron vs Fiat 126p :)
Z racji tego, że nie posiadam RGT-01 nie miałem jak przetestować kodu, więc nie mam pojęcia czy działa. Polegam jedynie na pylint - wbudowane w VS Code narzędzie rozpoznające i sprawdzające kod Pythona podczas pisania.
Możliwe, że jest nieprawidłowy mapping wartości (nie miałem jak sprawdzić) czyli np w HA zobaczysz tryb manualny zamiast automatycznego i to samo przy sterowaniu z HA do EFC-01. Jeśli tak będzie - daj znać. W atrybutach encji w HA powinny pojawić się dodatkowe informacje jak stan baterii głowicy, info o oczekiwaniu na synchronizację itp.
Jeśli zadziała to powinieneś być użyć karty Lovelace o nazwie Thermostat i zobaczyć coś takiego:
(https://www.forumextalife.pl/index.php?action=dlattach;topic=252.0;attach=290)
(https://www.forumextalife.pl/index.php?action=dlattach;topic=252.0;attach=292)
(https://www.forumextalife.pl/index.php?action=dlattach;topic=252.0;attach=294)
Trzymam kciuki, że zadziała. To byłoby dopiero osiągnięcie :) Jeśli będzie się sypało to daj znać jakie błędy wystąpiły (backtrace)
-
Trzymam kciuki, że zadziała. To byłoby dopiero osiągnięcie :) Jeśli będzie się sypało to daj znać jakie błędy wystąpiły (backtrace)
po odpaleniu testrun mam
root@nas:/apps/docker-root/homeassistant/scripts# ./start_exta2ha.sh --testrun
Traceback (most recent call last):
File "main_exta2ha.py", line 173, in main
self.ha_cfg.get_from_device(device)
File "/apps/docker-root/homeassistant/scripts/ExtaLife_HA.py", line 629, in get_from_device
cfg_dict[objid] = self.cfg_dict[objid] # may raise KeyError exception
KeyError: '13-1'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "main_exta2ha.py", line 201, in <module>
prog.main()
File "main_exta2ha.py", line 182, in main
self.ha_mqtt.ha_do_discovery_single(k, v)
File "/apps/docker-root/homeassistant/scripts/ExtaLife_HA.py", line 944, in ha_do_discovery_single
mq_tp_state = ha_topic.get_state_topic()
File "/apps/docker-root/homeassistant/scripts/ExtaLife_HA.py", line 1079, in get_state_topic
return self.tp_base+self.cfg_item[HAConfig.CFG_TOPICS][HA_MQTT.MQTT_JSON_STATE_TP_TO]
KeyError: 'state_topic'
Log nic ciekawego nie pokazuje a zatrzymuje się na:
2019-09-30 08:16:50,335 WARNING:No config found for device: 13
-
Czyli to było zbyt piękne, aby było prawdziwe ;)
OK, wprowadziłem kilka małych zmian. Zobaczmy dokąd to nas zaprowadzi... kolejna wersja w załączniku.
-
root@nas:/apps/docker-root/homeassistant/scripts# ./start_exta2ha.sh --testrun
Traceback (most recent call last):
File "main_exta2ha.py", line 201, in <module>
prog.main()
File "main_exta2ha.py", line 186, in main
self.ha_mqtt.ha_update_state_from_device(device)
File "/apps/docker-root/homeassistant/scripts/ExtaLife_HA.py", line 861, in ha_update_state_from_device
obj_id = self.k.split('-')
AttributeError: 'HA_MQTT' object has no attribute 'k'
-
ok, faktycznie ma rację, że się wywalił 😅
Żeby nie zamieszczać kolejnych załączników.
Wyedytuj linię 861 i zamień ją na:
obj_id = k.split('-')
-
no to wracamy do punktu wyjścia
root@nas:/apps/docker-root/homeassistant/scripts# ./start_exta2ha.sh --testrun
Traceback (most recent call last):
File "main_exta2ha.py", line 173, in main
self.ha_cfg.get_from_device(device)
File "/apps/docker-root/homeassistant/scripts/ExtaLife_HA.py", line 629, in get_from_device
cfg_dict[objid] = self.cfg_dict[objid] # may raise KeyError exception
KeyError: '13-1'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "main_exta2ha.py", line 201, in <module>
prog.main()
File "main_exta2ha.py", line 182, in main
self.ha_mqtt.ha_do_discovery_single(k, v)
File "/apps/docker-root/homeassistant/scripts/ExtaLife_HA.py", line 947, in ha_do_discovery_single
mq_tp_state = ha_topic.get_state_topic()
File "/apps/docker-root/homeassistant/scripts/ExtaLife_HA.py", line 1082, in get_state_topic
return self.tp_base+self.cfg_item[HAConfig.CFG_TOPICS][HA_MQTT.MQTT_JSON_STATE_TP_TO]
KeyError: 'state_topic'
-
ok, małe nieporozumienie z pythonem.
Próba nie strzelba. Kolejna wersja. Stawiam, że po załadowaniu tej wersji przejdzie przynajmniej proces Discovery i RGT01 pojawi się w HA jako encja climate.grzejnik_salon. A może nawet zacznie działać i status będzie się updateował?...trzymam kciuki. Natomiast nie wiem czy sterowanie z HA będzie działać. Zobaczymy
-
root@nas:/apps/docker-root/homeassistant/scripts# ./start_exta2ha.sh --testrun
Traceback (most recent call last):
File "main_exta2ha.py", line 201, in <module>
prog.main()
File "main_exta2ha.py", line 186, in main
self.ha_mqtt.ha_update_state_from_device(device)
File "/apps/docker-root/homeassistant/scripts/ExtaLife_HA.py", line 913, in ha_update_state_from_device
i_device.get_wait_to_synchron(int(channel))
File "/root/.pyenv/versions/3.6.9/lib/python3.6/json/__init__.py", line 231, in dumps
return _default_encoder.encode(obj)
File "/root/.pyenv/versions/3.6.9/lib/python3.6/json/encoder.py", line 199, in encode
chunks = self.iterencode(o, _one_shot=True)
File "/root/.pyenv/versions/3.6.9/lib/python3.6/json/encoder.py", line 257, in iterencode
return _iterencode(o, 0)
File "/root/.pyenv/versions/3.6.9/lib/python3.6/json/encoder.py", line 180, in default
o.__class__.__name__)
TypeError: Object of type 'set' is not JSON serializable
i log:
2019-09-30 12:12:37,971 WARNING:No config found for device: 13
2019-09-30 12:12:37,972 INFO:About to publish MQTT config payload topic: {"name": "Grzejnik salon", "device": {"identifiers": "zamel_exta_life_efc_01", "manufacturer": "Zamel", "model": "EFC-01", "name":
"Exta Life"}, "unique_id": "13-1", "mode_command_topic": "ha/climate/13-1/mode_set", "mode_state_topic": "ha/climate/13-1/mode_state", "modes": ["auto", "heat"], "temperature_command_topic": "ha/climate/1
3-1/temp_set", "temperature_state_topic": "ha/climate/13-1/temp_state", "precision": 0.5, "json_attributes_topic": "ha/climate/13-1/attributes", "min_temp": 5.0, "max_temp": 50.0, "temp_step": 0.5}
-
Na tym etapie proces Discovery powinien był się już wykonać tzn, że powinna się pojawić encja climate. Czy widzisz ją u siebie w HA (ekran states i Integrations)??
Spróbuję rozkminić co nie gra w aktualizacji stanu.
-
niestety nie ma encji. W integracjach pod EFC-01 widzę tylko 3 światła i 1 sensor temperatury (ale to z przycisku, nie z głowicy)
-
niestety nie ma encji. W integracjach pod EFC-01 widzę tylko 3 światła i 1 sensor temperatury (ale to z przycisku, nie z głowicy)
ok, już wiem dlaczego nie pojawiła się encja - ponownie prefix discovery ma wartość "ha" zamiast "homeassistant". HA Po prostu zignorował wiadomość konfiguracyjną ze skryptu, ponieważ nie zaczynała się od właściwego prefixu. We wszystkich plikach z końcówką "b*" do tej pory było "ha" więc to nie mogło zadziałać.
Natomiast jeszcze nie wiem za bardzo dlaczego kod wysypał się na update stanu. Zrobiłem małą zmianę i dodałem trochę kodu, aby logował wartości w tym miejscu do loga. Jeśli się wysypie to skopiuj z loga to co tam będzie to nieco ułatwi mi sprawę.
Na prawdę sądzę, że jesteśmy już bardzo blisko, aby to odpaliło.
Wersja b6
-
Panie magik... zero błędów :D
-
Panie magik... zero błędów :D
Pierwszy sukces na polu walki! 🤩
Dodaj encję na kartę thermostat w UI i załącz screena :) Czy tryb działania pokazany w HA zgadza się z aplikacją ExtaLife czy jest przeciwny? Czy sterowanie (zmian trybu i temperatury docelowej) działa? Czy skrypt się tam nie wysypał?
-
temperature powinno pokazywać current_temperature, zaś u mnie current jest null.
-
tryb wydaje się poprawny - w sensie mam auto i tak pokazuje. Przestawiłem teraz jedną głowicę w manual przez apkę zamela. Za 5min dam znać czy się zmieni w HA
-
ok, jest nieźle. Brakuje jeszcze dodatkowych atrybutów na ekranie stanu. Już zauważyłem dlaczego i poprawiłem. W następnej wersji powinny się pojawić.
A problem z wartościami null - załącz proszę log tam gdzie widać co skrypt wysyła do MQTT (powinno się zaczynać od "Publishing topics:" albo "Publish topic:" - aby było widać Payload, bo nie wiem czy to problem z wyciągnięciem wartości z EFC-01 czy coś się źle zakodowało w payloadzie dla MQTT
-
2019-09-30 13:01:23,337 DEBUG:Publishing topics:
2019-09-30 13:01:23,337 DEBUG:[{'topic': 'homeassistant/climate/13-1/temp_state', 'payload': '18.0'}, {'topic': 'homeassistant/climate/13-1/mode_state', 'payload': 'auto'}, {'topic': 'homeassistant/climat
e/13-1/temp_state', 'payload': '22.5'}, {'topic': 'homeassistant/climate/13-1/temp_state', 'payload': '{"battery_status": false, "power": 1, "work_mode": true, "waiting_to_synchronize": false}'}]
2019-09-30 13:01:23,348 DEBUG:MQTT HVAC attributes:
2019-09-30 13:01:23,349 DEBUG:{'battery_status': False, 'power': 0, 'work_mode': False, 'waiting_to_synchronize': True}
2019-09-30 13:01:23,350 DEBUG:Publishing topics:
2019-09-30 13:01:23,351 DEBUG:[{'topic': 'homeassistant/climate/14-1/temp_state', 'payload': '20.0'}, {'topic': 'homeassistant/climate/14-1/mode_state', 'payload': 'heat'}, {'topic': 'homeassistant/climat
e/14-1/temp_state', 'payload': '22.0'}, {'topic': 'homeassistant/climate/14-1/temp_state', 'payload': '{"battery_status": false, "power": 0, "work_mode": false, "waiting_to_synchronize": true}'}]
pierwsze wskazanie temp_state (18st) to wartość zadana, drugie to aktualna (22,5).
BTW mode_state ładnie pokazał i zmienił na heat ;)
-
ok, wersja b7 :) Sytuacja z brakiem wartości powinna być opanowana O:-)
Na wszelki wypadek zrestartuj wcześniej HA i pokasuj te encje climate (jeśli będą po restarcie) w ekranie Entity Registry w HA.
Dodatkowo jeśli w pliku konfiguracyjnym dla skryptu (exta_ha_config.yaml) znajdują się te głowice (13-1 i 14-1) to skasuj ich wpisy, albo najlepiej cały plik. Niech wszystko od nowa się wygeneruje, ponieważ problem z Null wynikał z błędu w zapisie konfiguracji (2 razy ten sam MQTT Topic) - typowy błąd copy&paste).
Przetestuj też czy da się zmienić temperaturę docelową oraz tryb z HA. HA może pokazywać, że zmiana się udała (komponent Climate działa w tzn "optimistic mode" i nie czeka na potwierdzenie zmiany stanu w przeciwieństwie do pozostałych komponentów MQTT), ale nie wiadomo czy EFC-01 zmieni faktycznie te rzeczy. Po zmianie w HA zobacz od razu do aplikacji Exta Life czy operacja się udała.
-
restart HA i mosquitto, usunięte encje climate, usunięty config yaml, odpalam testrun i nadal mam nulle
hvac_modes: auto,heat
current_temperature: null
min_temp: 5
max_temp: 50
target_temp_step: 0.5
temperature: 18
battery_status: false
power: 1
work_mode: true
waiting_to_synchronize: false
friendly_name: Grzejnik salon
supported_features: 1
2019-09-30 14:01:09,665 WARNING:No config found for device: 13
2019-09-30 14:01:09,667 INFO:About to publish MQTT config payload topic: {"name": "Grzejnik salon", "device": {"identifiers": "zamel_exta_life_efc_01", "manufacturer": "Zamel", "model": "EFC-01", "name":
"Exta Life"}, "unique_id": "13-1", "mode_command_topic": "homeassistant/climate/13-1/mode_set", "mode_state_topic": "homeassistant/climate/13-1/mode_state", "modes": ["auto", "heat"], "temperature_command
_topic": "homeassistant/climate/13-1/temp_set", "temperature_state_topic": "homeassistant/climate/13-1/temp_state", "precision": 0.5, "json_attributes_topic": "homeassistant/climate/13-1/attributes", "min
_temp": 5.0, "max_temp": 50.0, "temp_step": 0.5}
2019-09-30 14:01:09,969 DEBUG:MQTT HVAC attributes:
2019-09-30 14:01:09,970 DEBUG:{'battery_status': False, 'power': 1, 'work_mode': True, 'waiting_to_synchronize': False}
2019-09-30 14:01:09,970 DEBUG:Publishing topics:
2019-09-30 14:01:09,971 DEBUG:[{'topic': 'homeassistant/climate/13-1/current_temp', 'payload': '22.5'}, {'topic': 'homeassistant/climate/13-1/mode_state', 'payload': 'auto'}, {'topic': 'homeassistant/clim
ate/13-1/temp_state', 'payload': '18.0'}, {'topic': 'homeassistant/climate/13-1/attributes', 'payload': '{"battery_status": false, "power": 1, "work_mode": true, "waiting_to_synchronize": false}'}]
2019-09-30 14:01:09,979 WARNING:No config found for device: 14
2019-09-30 14:01:09,980 INFO:About to publish MQTT config payload topic: {"name": "Grzejnik pokoj", "device": {"identifiers": "zamel_exta_life_efc_01", "manufacturer": "Zamel", "model": "EFC-01", "name":
"Exta Life"}, "unique_id": "14-1", "mode_command_topic": "homeassistant/climate/14-1/mode_set", "mode_state_topic": "homeassistant/climate/14-1/mode_state", "modes": ["auto", "heat"], "temperature_command
_topic": "homeassistant/climate/14-1/temp_set", "temperature_state_topic": "homeassistant/climate/14-1/temp_state", "precision": 0.5, "json_attributes_topic": "homeassistant/climate/14-1/attributes", "min
_temp": 5.0, "max_temp": 50.0, "temp_step": 0.5}
2019-09-30 14:01:10,282 DEBUG:MQTT HVAC attributes:
2019-09-30 14:01:10,283 DEBUG:{'battery_status': False, 'power': 0, 'work_mode': False, 'waiting_to_synchronize': True}
2019-09-30 14:01:10,283 DEBUG:Publishing topics:
2019-09-30 14:01:10,284 DEBUG:[{'topic': 'homeassistant/climate/14-1/current_temp', 'payload': '22.0'}, {'topic': 'homeassistant/climate/14-1/mode_state', 'payload': 'heat'}, {'topic': 'homeassistant/clim
ate/14-1/temp_state', 'payload': '20.0'}, {'topic': 'homeassistant/climate/14-1/attributes', 'payload': '{"battery_status": false, "power": 0, "work_mode": false, "waiting_to_synchronize": true}'}]
-
hmm 🤔
Bez loga i twojego pliku exta_ha_config.yaml się nie obejdzie. Teraz nie wiem co może być nie tak. Załącz te dwie rzeczy i zobaczymy.
A i jeszcze jedno - pobaw się trochę w przestawianie parametrów głowicy w aplikacji ExtaLife- tzn tryb na manual, odczytaj po 5 minutach w HA stan encji, potem na harmonogram i znowu odczytaj. W obu przypadkach podeślij screena albo copy&paste, żebym widział i się upewnił czy mapping wartości działa poprawnie. I daj znać jaki stan encji w HA odpowiada jakiemu ustawieniu w aplikacji.
-
łap załączniki.
Z tego co widzę to tryb Auto odpowiada autmatycznemu, natomiast tryb ręczny w HA pokazuje jako grzanie "heat".
-
Z tego co widzę to tryb Auto odpowiada autmatycznemu, natomiast tryb ręczny w HA pokazuje jako grzanie "heat".
Tak, tego nie zmienimy. Tak musi zostać, bo te nazwy to reprezentacja tych trybów w komponencie HA. Musiałem dobrać najbardziej pasujące i wydaje mi sę, że auto jest ok, a heat musi odpowiadać trybowi manualnemu. Możliwości są takie:
[“auto”, “off”, “cool”, “heat”, “dry”, “fan_only”]
Zerknę na logi i plik konfiguracyjny i zobaczę co może być nie tak, że wciąż nie ma wartości dla current temperature.
-
[“auto”, “off”, “cool”, “heat”, “dry”, “fan_only”]
może być zatem heat, bo faktycznie nic lepszego nie wymyślimy.
-
ok, chyba wiem dlaczego nie ma current temperature. Ale zanim wrzucę kolejny plik - sprawdzałeś czy działa sterowanie z HA? Jeśli się sypie to wrzuć log i backtrace i poprawię przy okazji w jedne edycji.
-
nie działa sterowanie temperaturą i trybem pracy z poziomu HA. W pliku main_ha2exta.py.log nic się nie loguje w tej kwestii.
-
nie działa sterowanie temperaturą i trybem pracy z poziomu HA. W pliku main_ha2exta.py.log nic się nie loguje w tej kwestii.
Hmm, a powinna być zalogowana komenda do EFC-01 z poziomem DEBUG. Coś podobnego do:
{
"command": 20,
"data": {
"id": 13,
"channel": 1,
"state": 1,
"value": 220
},I dodatkowo kolejna linia:
'TCP Response: z wartością tego co zwrócił EFC-01.
Poszukaj jeszcze raz, albo po prostu podeślij plik loga.
Nawet jeśli uda się odszukać info w logu, to może okazać się, to czego się obawiałem tzn. że EFC-01 wymaga przy komendzie sterującej podania wszystkich możliwych danych, które można zmieniać. Tzn tutaj można zmieniać tryb i temperaturę i być może wymaga obu tych informacji. Problem jest taki, że HA MQTT przysyła do skryptu tylko jedną z tych informacji na raz. Zmieniając tryb dostajemy tylko info o trybie, brakuje temperatury docelowej. I vice versa. I to jest problem, ponieważ skrypt odbierający komendy od HA i wysyłający komendy do EFC-01 nie ma świadomości pozostałych danych. Tymi danymi może dysponować drugi skrypt. Tylko, że to są dwa zupełnie niezależne programy, które nie komunikują się między sobą w żaden sposób.
Chcąc odczytać ostatnią wartość temperatury dla zmiany trybu i trybu dla zmiany temperatury skrypt sterujący musiałby się skomunikować albo z EFC-01 albo z drugim programem. W obu przypadkach to duża zmiana w koncepcji całej integracji :( Komponent MQTT w HA ma swoje ograniczenia. Byłoby super gdyby przysyłał pełną wartość stan encji w HA dla każdej możliwej komendy sterującej. Niestety tego nie robi i trzeba jakoś radzić sobie z tym ograniczeniem.
Zobaczmy - podeślij mi loga, ja może zrobię jakąś zmianę i zobaczymy co z tego wyjdzie.
-
aha, chyba wiem dlaczego nie masz info w logu. Prawdopodobnie nie zrestartowałeś programu "start_ha2exta.sh"? Jeśli cały czas działa stara wersja to program nie zasubskrybował się na wątki z komponentu climate i nie będzie reagował na komendy z HA. I w logu też nic nie będzie.
-
stopuję oba skrypty, usuwam oba logi, startuję skrypty i mam:
main_exta2ha.py.log
2019-09-30 15:27:00,138 INFO:>>PID<<
2019-09-30 15:27:00,139 INFO:19632
2019-09-30 15:27:00,140 INFO:No customizing file
2019-09-30 15:27:00,377 INFO:Connected to MQTT broker
2019-09-30 15:27:02,705 DEBUG:Applying filters
2019-09-30 15:27:02,706 DEBUG:[37, 38]
2019-09-30 15:27:02,706 DEBUG:json elements before: 11
2019-09-30 15:27:02,707 DEBUG:json elements after: 11
2019-09-30 15:27:02,707 DEBUG:Applying filters
2019-09-30 15:27:02,707 DEBUG:[37, 38]
2019-09-30 15:27:02,708 DEBUG:json elements before: 11
2019-09-30 15:27:02,708 DEBUG:json elements after: 11
2019-09-30 15:27:02,709 DEBUG:Publishing topics:
2019-09-30 15:27:02,709 DEBUG:[{'topic': 'homeassistant/light/2-1/state', 'payload': 'OFF'}]
2019-09-30 15:27:02,715 DEBUG:Publishing topics:
2019-09-30 15:27:02,715 DEBUG:[{'topic': 'homeassistant/light/0-1/state', 'payload': 'OFF'}, {'topic': 'homeassistant/light/0-2/state', 'payload': 'OFF'}]
2019-09-30 15:27:02,721 DEBUG:Publishing topics:
2019-09-30 15:27:02,722 DEBUG:[{'topic': 'homeassistant/light/4-1/state', 'payload': 'OFF'}, {'topic': 'homeassistant/light/4-1/state_value', 'payload': 16}]
2019-09-30 15:27:02,727 DEBUG:Publishing topics:
2019-09-30 15:27:02,728 DEBUG:[{'topic': 'homeassistant/light/11-1/state', 'payload': 'OFF'}, {'topic': 'homeassistant/light/11-2/state', 'payload': 'OFF'}]
2019-09-30 15:27:02,734 DEBUG:Publishing topics:
2019-09-30 15:27:02,734 DEBUG:[{'topic': 'homeassistant/light/12-1/state', 'payload': 'OFF'}, {'topic': 'homeassistant/light/12-2/state', 'payload': 'OFF'}]
2019-09-30 15:27:02,741 DEBUG:Publishing topics:
2019-09-30 15:27:02,741 DEBUG:[{'topic': 'homeassistant/light/8-1/state', 'payload': 'OFF'}, {'topic': 'homeassistant/light/8-2/state', 'payload': 'OFF'}]
2019-09-30 15:27:02,748 DEBUG:MQTT HVAC attributes:
2019-09-30 15:27:02,748 DEBUG:{'battery_status': False, 'power': 1, 'work_mode': True, 'waiting_to_synchronize': False}
2019-09-30 15:27:02,749 DEBUG:Publishing topics:
2019-09-30 15:27:02,749 DEBUG:[{'topic': 'homeassistant/climate/13-1/current_temp', 'payload': '22.5'}, {'topic': 'homeassistant/climate/13-1/mode_state', 'payload': 'auto'}, {'topic': 'homeassistant/clim
ate/13-1/temp_state', 'payload': '18.0'}, {'topic': 'homeassistant/climate/13-1/attributes', 'payload': '{"battery_status": false, "power": 1, "work_mode": true, "waiting_to_synchronize": false}'}]
2019-09-30 15:27:02,757 DEBUG:MQTT HVAC attributes:
2019-09-30 15:27:02,758 DEBUG:{'battery_status': False, 'power': 1, 'work_mode': True, 'waiting_to_synchronize': True}
2019-09-30 15:27:02,758 DEBUG:Publishing topics:
2019-09-30 15:27:02,759 DEBUG:[{'topic': 'homeassistant/climate/14-1/current_temp', 'payload': '22.0'}, {'topic': 'homeassistant/climate/14-1/mode_state', 'payload': 'auto'}, {'topic': 'homeassistant/clim
ate/14-1/temp_state', 'payload': '22.0'}, {'topic': 'homeassistant/climate/14-1/attributes', 'payload': '{"battery_status": false, "power": 1, "work_mode": true, "waiting_to_synchronize": true}'}]
2019-09-30 15:27:02,766 DEBUG:Publishing topics:
2019-09-30 15:27:02,767 DEBUG:[{'topic': 'homeassistant/sensor/9-1/state', 'payload': '23.1'}]
2019-09-30 15:27:02,774 DEBUG:Publishing topics:
2019-09-30 15:27:02,774 DEBUG:[{'topic': 'homeassistant/sensor/6-1/state', 'payload': '22.6'}]
2019-09-30 15:27:02,780 DEBUG:Publishing topics:
2019-09-30 15:27:02,781 DEBUG:[{'topic': 'homeassistant/sensor/1-1/state', 'payload': '23.2'}]
oraz main_ha2exta.py.log
2019-09-30 15:26:35,232 INFO:>>PID<<
2019-09-30 15:26:35,233 INFO:19506
2019-09-30 15:26:35,234 INFO:No customizing file
2019-09-30 15:26:35,470 DEBUG:Subscribing to topics:
2019-09-30 15:26:35,471 DEBUG:['homeassistant/light/0-1/switch', 'homeassistant/light/0-2/switch', 'homeassistant/light/11-1/switch', 'homeassistant/light/11-2/switch', 'homeassistant/light/12-1/switch',
'homeassistant/light/12-2/switch', '', 'homeassistant/climate/13-1/mode_set', 'homeassistant/climate/13-1/temp_set', '', 'homeassistant/climate/14-1/mode_set', 'homeassistant/climate/14-1/temp_set', 'home
assistant/light/2-1/switch', 'homeassistant/light/4-1/switch', 'homeassistant/light/4-1/set_value', 'homeassistant/light/8-1/switch', 'homeassistant/light/8-2/switch']
i teraz jakakolwiek zmiania w HA w climate (zmiana temperatury na okręgu lub wejście w opcje i zmiana trybu pracy nic nie robi, w logu nic nowego się nie pojawia, w Ha po odświeżeniu wraca do pierwotnej postaci.
Natomiast wystarczy że przez HA zapalę i zgaszę światło i mamw logu
2019-09-30 15:30:45,220 DEBUG:Received: homeassistant/light/0-1/switch ON
2019-09-30 15:30:45,221 DEBUG:{"command": 20, "data": {"channel": 1, "state": 1, "id": 0, "value": null}}.
2019-09-30 15:30:45,262 DEBUG:TCP Response: {"command":20,"data":{"id":0,"channel":1,"state":true},"status":"notification"}.
2019-09-30 15:30:45,263 DEBUG:Publishing topics:
2019-09-30 15:30:45,263 DEBUG:[{'topic': 'homeassistant/light/0-1/state', 'payload': 'ON'}]
2019-09-30 15:30:47,194 DEBUG:Received: homeassistant/light/0-1/switch OFF
2019-09-30 15:30:47,195 DEBUG:{"command": 20, "data": {"channel": 1, "state": 0, "id": 0, "value": null}}.
2019-09-30 15:30:47,196 DEBUG:TCP Response: {"command":20,"status":"success","data":null}.
2019-09-30 15:30:47,197 DEBUG:Publishing topics:
2019-09-30 15:30:47,197 DEBUG:[{'topic': 'homeassistant/light/0-1/state', 'payload': 'OFF'}]
-
No to mamy zagadkę :) ok, w takim razie trzeba sprawdzić czy z HA wychodzą wiadomości MQTT wygenerowane przez komponent MQTT HVAC.
Idź do narzędzi deweloperskich w HA GUI i odszukaj zakładkę MQTT. W niej zasubskrubuj się na temat jak na załączonym screenie.
Potem otwórz inne okno przeglądarki, albo na telefonie otwórz swój GUI HA i próbuj sterować głowicą z HA. Obserwuj co się będzie działo na ekranie MQTT. Powinny pojawiać się kolejne message MQTT. Jeśli ich nie ma to coś jest nie tak z HA lub z konfiguracją tej integracji (czyli skrypty).
Jeśli message MQTT będą się pojawiać, to będziemy dalej szukać co jest nie tak ze skryptami. Obecnie nie mam pojęcia dlaczego nic się nie dzieje jeśli restartujesz oba programy...
PS. Może na wszelki wypadek sprawdź czy napewno skrypt start_ha2exta.sh jest zrestartowany. Sprawdź czy nie masz kilka instancji pythona z tego skryptu odpalonych:ps -ef | grep python
-
Message 4 received on homeassistant/climate/13-1/mode_set at 21:00:
heat
QoS: 0 - Retain: false
Message 3 received on homeassistant/climate/13-1/temp_set at 21:00:
22.5
QoS: 0 - Retain: false
Message 2 received on homeassistant/climate/13-1/mode_set at 21:00:
heat
QoS: 0 - Retain: false
Message 1 received on homeassistant/climate/13-1/temp_set at 21:00:
16
QoS: 0 - Retain: false
Message 0 received on homeassistant/climate/13-1/temp_set at 20:59:
29
QoS: 0 - Retain: false
root@nas:~# ps -ef | grep python
root 1307 1265 1 13:59 ? 00:04:41 /usr/local/bin/python3 -m homeassistant --config /config
root 7367 7291 0 21:02 pts/2 00:00:00 grep python
root 19506 19505 2 15:26 pts/1 00:07:25 /root/.pyenv/versions/3.6.9/bin/python3 main_ha2exta.py
root 19632 19631 0 15:26 pts/1 00:00:11 /root/.pyenv/versions/3.6.9/bin/python3 main_exta2ha.py
root@nas:~#
a mimo to w logu main_ha2exta.py.log cisza.
-
No to mamy zagadkę z archiwum X... :( kompletnie nie mam pomysłu co się dzieje. Odezwę się jak coś wymyślę.
-
Jedyne co mi przyszło do głowy to to, że podejrzanie wygląda pusty wątek MQTT w liście subskrybowanych przez skrypt wątków. Być może jest tak, że przy subskrybowaniu pustego tematu moduł MQTT pythona szwankuje i wszystkie tematy występujące po '' są potem ignorowane. Jeśli moja teoria jest poprawna, to light 2-1, light 4-1, 8-1 i 8-2 też powinny nie być sterowalne z HA. Zrobiłem małe zmiany i pusty temat teraz nie powinien dodać się do listy wątków. Zobacz wersję b8
Dodatkowo problem z current temperature już powinien być rozwiązany. Powodzenia :)
-
No panowie czapki z głów!!! 8)
Kolega admin to już widzę że staje się masterem HA :)
Naprawdę aż miło się czyta jak to ogarniasz, powodzenia!
P.S w mojej kwestii coś drgnęło, ale dam z nać w odpowiednim temacie jak wszystko "rozeznam"
-
Jeśli moja teoria jest poprawna, to light 2-1, light 4-1, 8-1 i 8-2 też powinny nie być sterowalne z HA.
ooo i tak właśnie jest! klikam i po sekundzie znów zmienia się na wyłączone. Już sprawdzam nową wersję.
-
na nowej wersji światło już działa. Co do sterowania głowicami to też już coś się dzieje ale nie do końca poprawnie
2019-10-01 08:12:31,676 DEBUG:Received: homeassistant/climate/13-1/mode_set heat
2019-10-01 08:12:31,677 DEBUG:{"command": 20, "data": {"channel": 1, "state": 0, "id": 13, "value": null}}.
2019-10-01 08:12:31,678 DEBUG:TCP Response: {"command":20,"data":{"id":2,"channel":1,"state":false},"status":"notification"}.{"command":20,"status":"success","data":null}.
2019-10-01 08:14:14,316 DEBUG:Received: homeassistant/climate/13-1/temp_set 20.0
2019-10-01 08:14:14,317 DEBUG:{"command": 20, "data": {"channel": 1, "state": 0, "id": 13, "value": 2000}}.
2019-10-01 08:14:14,318 DEBUG:TCP Response: {"command":20,"data":{"id":13,"channel":1,"state":1,"value":0},"status":"notification"}.{"command":20,"status":"success","data":null}.
w pierwszym przypadku zmieniłem tryb na "grzanie" czyli tryb manualny. Ten się nie zmienił za to w Zamelu pokazało mi temperaturę zero (w logu jest value null), w drugim przypadku zmieniłem temperaturę na 20st a w Zamelu zrobiło się 200st (value 2000).
BTW temperatury już pokazuje poprawnie :)
-
No panowie czapki z głów!!! 8)
Kolega admin to już widzę że staje się masterem HA :)
Naprawdę aż miło się czyta jak to ogarniasz, powodzenia!
P.S w mojej kwestii coś drgnęło, ale dam z nać w odpowiednim temacie jak wszystko "rozeznam"
Dzięki :) Daj znać jak co wyniknęło z Twojego rozeznania, bo jestem ciekawy :)
-
w pierwszym przypadku zmieniłem tryb na "grzanie" czyli tryb manualny. Ten się nie zmienił za to w Zamelu pokazało mi temperaturę zero (w logu jest value null), w drugim przypadku zmieniłem temperaturę na 20st a w Zamelu zrobiło się 200st (value 2000).
Problem z wartośćią o 10 razy za dużą to problem skryptu. Faktycznie jest mnożenie przez 100 zamiast 10 i stąd błędna wartość. Nie wiem czemu wsadziłęm tam 100, chyba późno było ;)
W linii 376 zamień 100 na 10 i zacznie być prawidłowo.
Natomiast problem z temperaturą = 0 przy przestawianiu trybu to już niestety problem związany z kwestią, którą opisałem wcześniej - brak danych z MQTT w skrypcie gdy EFC-01 wymaga obu danych (jakby nie mógł sobie odczytać aktualnej wartości...🤦♂️). No ale nic, Zamel podjął taką strategię w EFC-01, a ja podjąłem swoją z rozdziałem programów. Niestety tak jak pisałem - na razie nic z tym z poziomu skryptów nie da się zrobić. To duża przebudowa całego rozwiązania, aby zapamiętywało stany lub odczytywało je z EFC-01 na żądanie.
Jednakże nie ma sytuacji bez wyjścia. Myślałem o tym wczoraj i wymyśliłem workaround. Użyjemy samego HA, aby sobie z tym poradzić. Wymyśliłem, że wykorzystamy mechanizm automatyzacji HA i stworzymy automatyzację, która będzie się odpalała, gdy nadejdzie wiadomość MQTT dotycząca głowicy. HA sprawdzi, że jest to wiadomość z samą wartością trybu lub temperatury. Jeśli tak, to HA z poziomu automatyzacji wyśle kolejną wiadomość MQTT o tym samym temacie (np /climate/13-1/set_mode) , w której umieści cały stan danej encji - czyli m.in. temperatury i tryb. Tu jednak mam też do rozwiązania problem, ponieważ w HA z poziomu stanu encji nie ma danych dotyczących tematów MQTT, z którymi ta encja jest związana a co za tym idzie - brak identyfikacji i mapowania z np climate.grzejnik_salon na wartości EFC-01 czyli device 13. Czyli dostając wiadomość /climate/13-1/mode_set nie będzie wiadomo, którą encję w HA należy odczytać i wysłać w kolejnej wiadomości MQTT. Ale to może uda się rozwiązać wysyłając w dodatkowych atrybutach stanu wartość identyfikującą w skrypcie :) Np dodatkowy atrybut "mapping_id": "13-1". Wtedy można porównać id z tematu MQTT z kolejnymi encjami climate i wyszukać tą pasującą i wysłać.
To jest workaround i to powinno działać. Będę musiał pomyśleć jak sobie z tym poradzić w przyszłości i znaleźć jakiś złoty środek, aby nie rozwalać całego rozwiązania i nie przebudowywać go zupełnie, bo to wymagałoby pewnie zbudowania tylko jednego programu realizującego dwie funkcje (chciałem tak na początku, ale nie potrafię w Pythonie programować równoległych zadań w ramach jednego programu). Pythona używam tylko tutaj do tych skryptów więc nie znam go zbyt dobrze, aby sobie z tym poradzić. A poza tym nie mam na to ani czasu, ani ochoty, bo to byłaby prawdziwa rewolucja.
Cóż, czasem myślę, że najlepiej byłoby zbudować natywną integrację ExtaLife dla HA, ale to dla mnie zdecydowanie za wysokie progi. HA wymaga solidnej znajomości programowania asynchronicznego w Pythonie, a ja jakoś nie mogę tego rozgryźć.
Może kiedyś, gdy Exta Life będzie miało miliony użytkowników to znajdzie się jakiś zacny śmiałek, który tego dokona ::)
BTW temperatury już pokazuje poprawnie :)
W końcu przełom ;)
-
zmieniłem mnożnik ze 100 na 10 i teraz wartość wysyłana jest dobra. Jednakże w Zamelu dziele się następująca rzecz: wartość wskazywana jest nowa ale tryb pracy pozostaje bez zmian czyli auto, zatem po synchronizacji znów wskakuje wartość z harmonogramu.
Apka zamela działa tak, że jeżeli jest tryb auto i tylko tknę suwak temperatury to samoczynnie zmienia się tryb pracy na ręczny anulując tym samym wartości z harmonogramu.
Suma sumarum założony cel został osiągnięty: dodanie wskazań temperatury głowicy do HA. Nie było mowy o sterowaniu :P Od Ciebie tylko zależy czy chcesz iść dalej. Ja chętnie zostanę testerem :)
-
zmieniłem mnożnik ze 100 na 10 i teraz wartość wysyłana jest dobra. Jednakże w Zamelu dziele się następująca rzecz: wartość wskazywana jest nowa ale tryb pracy pozostaje bez zmian czyli auto, zatem po synchronizacji znów wskakuje wartość z harmonogramu.
Apka zamela działa tak, że jeżeli jest tryb auto i tylko tknę suwak temperatury to samoczynnie zmienia się tryb pracy na ręczny anulując tym samym wartości z harmonogramu.
No właśnie. W instrukcji czytałem o tym, że przy zmianie temperatury tryb samoczynnie przełącza się na manual. I starałem się to tak zaimplementować. Widocznie wartości przy sterowaniu nie podobają się EFC-01 i w efekcie niczego nie zmienia.
Aby to naprawić potrzebowałbym znowu przechwycony ruch z aplikacji dla dokładnie takiego przypadku. A najlepiej gdybyś przechwycił w osobnych plikach najpierw zmianę temperatury, a potem w osobnym pliku zmianę trybu np z harmonogramu na manual. Wtedy będę widział co wysyła aplikacja do kontrolera i może uda się to zrobić tak samo.
Suma sumarum założony cel został osiągnięty: dodanie wskazań temperatury głowicy do HA. Nie było mowy o sterowaniu :P Od Ciebie tylko zależy czy chcesz iść dalej. Ja chętnie zostanę testerem :)
To prawda, ale dla mnie wykorzystywanie HA tylko na 50% do wyświetlania stanu to za mało :) Chciałbym także aby działało sterowanie, więc chętnie wykorzystam cię jako testera :)