To działa tak, że SUPLA robi MQTT discovery - przedstawia urządzenia w AIS
Czyli opisuje czym są (klasa urządzenia - sensor, przełącznik, zasłona…) , jak się nazywają, co mogą robić, jakie mają jednostki też
Na spokojnie przyglądnij się temu jak to działa, co jest nie tak i zgłosimy do Przemka z SUPLA.
PS
właśnie wydaliśmy wersję z poprawką na integrację z SUPLA.
Przeczytaj proszę zaktualizowany opis tej integracji, staraliśmy się trochę wyjaśnić jak to działa.
Jest też przykład jak tą integrację robić ręcznie, powinno być przydatne dla osób które nie mają brokera MQTT w chmurze SUPLA lub mają niestandardową konfigurację MQTT.
W razie problemów pisz co jest nie tak, my to wszytko czytamy i wiemy… ale przepraszamy, nie jesteśmy w stanie robić wszystkiego na raz.
Pamiętajmy proszę, że to nie jest elektrownia jądrowa w której reaktor płonie i musimy wszyscy gasić… na spokojnie będziemy poprawiać i rozwijać tą integrację. Mamy już urządzenia do Zamel, dzięki temu wyszło co jest nie tak i mamy integrację w wersji 2.0.
Na pewno jeszcze sporo przed nami ale za jakiś czas ta integracja będzie śmigać
Zaręczam, że byłem bardzo spokojny zgłaszając ten błąd z jednostkami miary Co jeszcze powinienem podać, żebyście mieli kompletne dane na temat problemu?
OK, na spokojnie i po zapoznaniu się z nową wersją dokumentacji AIS SUPLA MQTT.
W instrukcji w sekcji UWAGA napisano:
Podczas dodawania lub usuwania integracji SUPLA MQTT konfiguracja brokera MQTT działającego na bramce jest nadpisywana i usługa MQTT jest automatycznie restartowana w celu zatwierdzenia zmian w konfiguracji połączenia.
Niestety, dzieje się to także podczas każdego restartu bramki… Integracja zawłaszcza sobie mosquitto.conf i jeśli mamy wprowadzone jakiekolwiek zmiany zostają one usunięte a przywrócony jest tylko wpis mostka do Supli. Moim zdaniem integracja powinna modyfikować wpis w mosquitto.conf zgodnie z opisem w sekcji Uwaga czyli podczas dodawani i usuwania integracji z Supla i powinna działać tylko i wyłącznie na wpisie dotyczącym tej integracji. Teraz niestety usuwa mi wpis dotyczący mostka integrującego bramkę Dev3 z bramka Dev1.
Przy okazji nie wiem czy były także jakieś zmiany w tym zakresie czy może przypadkiem w końcu wpisałem mostek prawidłowo, ale zaczęło działać sterowanie urządzeniami Supli na obu bramkach
Wyjaśniła się także sprawa niedziałającego połączenia z brokerem lokalnym dla lokalnej instancji Supli. Otóż mój broker MQTT nie korzysta z połączenia szyfrowanego, a integracja takie połączenie wymusza. Jeśli dodam integrację do swojej lokalnej Supli, to ona nie działa, bo AIS wymusza połączenie szyfrowane, którego mój broker nie obsługuje. Ale wystarczy, że zakomentuję w mosquitto.conf linijkę ze ścieżką do certyfikatu #bridge_cafile /data/data/pl.sviete.dom/files/usr/etc/tls/cert.pem
i mostek przestaje być szyfrowany i wszystko łączy się jak należy (do czasu restartu bramki, wtedy integracja przywraca zapisy domyślne i # jest usuwany).
Reasumując, dopóki integracja z Suplą v2.0 zawłaszcza sobie mosquitto.conf na wyłączność i to także podczas restartu bramki, a mamy także własne wpisy w tym pliku, to lepiej wpisać dane mostka do Supli “z palca” do mosquito.conf i nie używać jeszcze integracji w tej wersji. Jeszcze kroczek może dwa i będzie jak należy
Moja sugestia do v2.1: modyfikować w pliku mosquitto.conf tylko wpis dotyczący samej integracji, dodać opcję czy połączenie szyfrowane czy nie.
Nie zmieniasz nic w ustawieniach brokera mqtt ręcznie i chcesz żeby AIS tym zarządzał
Wtedy dodajesz integracje konfiguratorem jak 99% użytkowników (info od SUPLA). Jak AIS przy starcie integracji zobaczy, że konfiguracja jest taka jak powinna być to nie będzie jej zmieniał.
Chcesz sam zarządzać ustawieniami brokera MQTT na bramce.
Wtedy nie dodajesz integracji konfiguratorem bo nie ma takiej potrzeby.
Ten konfigurator integracji służy tylko do tego, żeby włączyć broker MQTT w SUPLA Cloud, pobrać z SUPLA Cloud ustawienia do brokera MQTT i zapisać je w konfiguracji MQTT.
Nie robimy miksowania konfiguracji i dopisywania / usuwania wpisów do tego, co dodał użytkownik.
Zgłoś to do SUPLA proszę. Jeżeli uznają, że to błąd to poprawią w MQTT i będzie OK dla wszystkich którzy się integrują brokerem MQTT (nie tylko dla AIS).
Oczywiście, że zgłoszę zgodnie z sugestią. Jednak osobiście myślę, że problem jest po stronie HA i sposobu w jakim zamienia dane z MQTT na encje.
OK. Ale tutaj widzę brak konsekwencji. Na przykład integracja AIS MQTT Bridge nie dodaje swojej konfiguracji do mosquitto.conf a wcześniej integracja AIS SUPLA MQTT też tego nie robiła.
A teraz AIS SUPLA MQTT zawłaszczyła mosquito.conf
Ja myślę, że można pogodzić obie sytuacje a także przyszłe rozwiązania oparte o MQTT.
Gdyby w katalogu /data/data/pl.sviete.dom/files/usr/etc/mosquitto umiećić podkatalog config.d i umieścić o nim wpis w mosquitto.conf include_dir config.d wtedy spokojnie można koniguracje dla integracji MQTT umieszczać w plikach obsługiwanych przez te integracje. Zamiast zawłaszczać plikiem mosquitto.conf można w config.d umieścić plik ais_supla.mqtt.conf z odpowiednią konfiguracją połączenia mostkowego. Wtedy zarządzanie tym plikiem nie ma żadnego wpływu na inne ręczne ustawienia połączeń mostkowych wykonanych przez użytkownika.
tak, to jest bardzo dobry pomysł, wiemy, że tak to trzeba docelowo zrobić
zastanawialiśmy się czy dodać wiele include_dir per integracja (to jest możliwe), albo jednoinclude_dir z różnymi plikami z konfiguracjami do integracji które tam będą (to ma chyba większy sens)
tak nawet to wczoraj przez chwilę działało, ale ostatecznie nie zrobiliśmy tego w ten sposób z jednego powodu - bo nie mamy jeszcze możliwości edycji plików w include_dir z aplikacji
docelowo chcemy dodać możliwość łączenia bramek po mqtt bridge i coś takiego powstanie… ale teraz są 2 opcje
MQTT discovery to nie jest coś co wymyśliliśmy z SUPLA, stosuje to wiele projektów, my chcieliśmy tak się integrować z SUPLA i sugerowaliśmy SUPLA żeby tak to zrobić (dzięki temu integrują się z każdym a nie tylko AIS).
Gdyby po stronie HA był błąd to chyba by już wyszło przy innych projektach:
Podawałem wcześniej, że Supla przedstawia w dicovery jednostki miary w prawidłowy sposób:
Sprawdziłem w pliku ~/AIS/.storage/core.entity_registry i tam encje mają prawidłowe jednostki miary
Encja licznika wody ma "unit_of_measurement": "l",
a encja licznika energii ma "unit_of_measurement": "kWh",
Problem pojawia się przy wizualizacji w lovelace. W widoku encji oraz na wykresie historii dla licznika energii pojawia się jednostka miary “l”. W widoku encji można ja nadpisać ręcznie na kWh, ale w widoku wykresu historii nie znalazłem takiej opcji.
Nie wiem dlaczego tak się dzieje, ale na 99% dzieje się to po stronie HA i prawdopodobnie w samym lovelace…
Sugerowałem to zbieżnością nazw kanałów i nazw encji, które z tych nazw powstały. Oba kanały nazywały się Główny. Supla w MQTT wysłała ich nazwy jako Główny (Value). HA zrobił z nich encje o nazwach sensor.glowny_value i sensor.glowny_value_2. Lovelace dla obu tych encji wyświetla jednostkę miary taką jak w pierwszej encji.
Dziękuję za poprawkę Supli. Wybrałem drugą opcję, zgodnie z dokumentacją na stronie AIS oraz Supli. Ten parametr certyfikacji TLS to niezauważona przeze mnie i pewnie przez kol. @Goral64 opcja a faktycznie jest opisany w Supli
Ja na razie swój problem z jednostkami miary naprawiłem w ten sposób, że usunąłem te urządzenia z AIS, zmieniłem opisy tych kanałów w Supli na różniące się od siebie, po zapisaniu zmian Supla zrobiłą discovery i w AIS pojawiły się nowe encje z nowymi różniącymi się nazwami. Teraz jednostki są OK.
Ale błąd dalej istnieje.
Od dłuższego czasu nic nie ruszam w systemie, a integracja supli coraz częściej się wiesza. Jak podziała 24h bez ruszania to jest sukces. Jutro dodam ręcznie most. I będę obserwował. Bo w obecnej formie to nie ma sensu.
Mam pytanie - most z mqtt A do mqtt B i działa. Ale jak B przestanie być dostępne (np restart maszyny lub chwilowa utrata połączenia) to A już polaczenia sam nie wznowi. Trzeba A zrestartować by ponownie nawiązał połączenie z B
Hej. Integracja, zwłaszcza manualna, wydaje się teraz ok. Prawdopodobnie chodzi o to co pisałem wyżej - mosquitto nie wznawia połączenia po zerwaniu transmisji internetowej lub restartu zdalnego serwera MQTT. To może mosquitto ma jakiś błąd? Dwa lata temu któraś wersja miała taki bug (było coś na forach).
Koledzy wyżej mają lepsze łącza i pewnie nie obserwują takich symptomów. U mnie wyraźnie po kilku chwilowych zwisach łącza mosquitto w obecnej wersji tak właśnie się zachowuje.
Natomiast jak łącze jest stabilne to i bridge do Supli działa bez zarzutu.
Hejka,
Zamontowałem sobie licznik energii Zamel MEW-01 i zanim na stałe zmienię połączenie na bezpośrednie po mqtt chciał najpierw się pobawić poprzez Most z brokerem suplowym. Problem z tym, że mój broker mqtt stoi w dockerze na synology i nie wiem co wpisać w Lini #bridge_cafile /data/data/pl.sviete.dom/files/usr/etc/tls/cert.pem
Czy mam wybrać któryś z dysku, czy powinienem zainstalować? Nie mogę tego rozkminić.
No i wszystko pięknie śmiga
Dzięki @bartik22
PS. Ma ktoś z forum już ten licznik energii? Jeżeli jest ktoś prosumentem to za nieduże pieniądze ma super statystyki. Teraz tylko rozkminić jak zrobić takie super wykresy jak na supli. Jeżeli już ktoś posiada MEW-01 to warto wspólnie powalczyć.
Potem przeczytałem, że niby ustawa mówi, że rozliczanie między fazowe jest i to w bilansie godzinnym, czyli zliczamy przez godzine sumy pobrane faz i odejmujemy z sumami wysłanych faz, trzeba by było utility meterem zliczać godzinne pobrania, wysłania i sumować, potem zliczać już chyba czymś innym(NR) bo utility meter nie zliczy godzinnych sum… chyba
Bujam sie z tym bo nie wiem jak oni liczą, niby licznik pokazuje jedno, a oni na poziomie systemów informayucznych mogą bilanować międzyfazowo… Zadzwonie chyba to tej Energa, ale kompetencją tam nie grzeszą, Po rachunku moze dojdę, jeszcze pierwszego nie miałem od instalacji PV