Panasonic Aquarea + GoHeishaMon + HA

@paweljarmuszkiewicz , wszystko działa tak jak powinno na najnowszej aktualizacji , więc póki co Panasonic nic nie mieszał 🙂

Pendrive masz sformatowany w FAT32 ?

Po trzymaniu trzech przycisków widzisz ,czy coś się odczytuje z pendriva ? ( w sensie czy dioda na nim miga , czy coś się z niego choćby przez chwilę odczytuje)

No i jak długo trwa to zmienianie kolorów diody ( niebieski zielony czerwony) , bo musi ponad minutę , żeby sflashować partycję i się zresetować ( jak obi to szybciej to znaczy ,że jakiś błąd przy odczycie z pendrive )

@marcingajda 

FAT32 - tak

Migały dość długo 2-3min - potem przeskakuje na zielone... możesz spróbuje wszystko uruchomić od zera i wgrać raz jeszcze

Dobra, pompa się wgrała, ale niestety mqtt się nie loguje do HA

Straszne skróty myślowe stosujesz ... "Pompa się wgrała" to rozumiem ,że CZ-TAW1 się sflashował i jest GoHeishaMon na nim ( była biała dioda po restarcie)....

A teraz co to znaczy "mqtt się nie loguje do HA" ? 

Broker MQTT ( czyli jakby serwer) jest na maszynie z HA  ( uruchomiony dodatek Mosquitto broker) ? 

Jeśli tak ,to czy możesz się do tego brokera zalogować np przez MQTT Explorer ? (tymi samymi danymi ,co wpisałeś w GoHeishaMonConfig.new)

Dodane przez: @lobuz

↑

@marcingajda

 Dzieki kolego wszystko działa. A czy jest możliwość równoległego działania Panasonic Comfort Cloud? 

Opracowałem interfejs HeishaMonBoth który ma możliwość równoległej pracy pomp Aquarea  z chmurą Panasonic i lokalnym serwerem MQTT. Dostępna też jest integracja z HomeAssistance umożliwiająca sterowanie pompą i monitorowanie jej parametrów.

Można podłączyć kilka termometrów Dallas i dwa liczniki impulsowe do pomiaru zużycia energii lub wody.

Kod programu na ESP32, schemat, pliki płytek PCB i instrukcja dostępne są na github.com/salakrzy/HeishaMonBoth

Płytka interfejsu Heishamon both zasilana jest przez kabel CZTAW z pompy i łączy się z serwerem MQTT przez WiFi. Gniazda na płytce są identyczne jak w pompie i CZTAW więc całe uruchomienie sprowadza się do wpięcia wtyczek i skonfigurowania dostępu do sieci WiFi i serwera MQTT. 

@krzysiek , jak zrealizowałeś  to połączenie ? Czy to jest po prostu przerzucanie wszystkiego co wyśle CZ-TAW1 , czy może jakaś analiza ? ( Bo np nie warto wysyłać tych samych pakietów przez Heishamon i CZ-TAW1) ?

Czy zamierzasz za każdym razem "kopiować" nowe wydania Heishamon , czy też zamierzasz rozwijać to niezależnie ?

Bo Igor niestety jest zakładnikiem swojego projektu , zainwestował sporo w płytki ,które sprzedaje , i teraz nie chce przejść na ESP32 ( a ESP8266 po prostu już się dusi).

@mig41 W obecnej wersji softu HeishaMonBoth v 2.1.1 jest tak że pompa jest odpytywana równolegle przez 3 źródła zapytań CZTAW , MQTT i HeishaMonBoth na tych samych uprawnieniach bez priorytetyzacji źródła zapytań. HesihaMonBoth generuje zapytanie co ustalony okres czasu definiowany w Setting parametrem  waitTime.  W poprzedniej wersji mojego softu było tak, że jak interfejs widział że poszło zapytanie z CZTAW to przez ustalony odcinek czasu interfejs sam z siebie nie wysyłał zapytań do pompy o status. Teraz zapytania z CZTAW i MQTT obsługiwane są asynchronicznie tak jak nadchodzą a HeishaMonBoth pyta o status co ustalony odcinek czasu po obsłużeniu zapytań które wcześniej wpadły do kolejki zapytań w buforze. Widać to na załączonym screenshocie.

Nie chciałem się bawić w analizowanie treści zapytań z CZTAW  bo chciałem aby interfejs był przeźroczysty od strony chmury Panasonic. Takie podejście zabezpiecza przed niespodziankami typu zmiana formatu komunikacji CZTAW z chmurą. Można się zastanowić nad ograniczeniem zapytań o status generowanych okresowo przez HeishaMonBoth jeśli pompa zaraportowała swój status na zapytanie CZTAW lub MQTT. To ma sens i pochylę się nad tym.

Co do konwertowania kodu nowych wersji HeishaMon z procesora ESP8266 na ESP32 to zamierzam przy  update dodających nowe typy pomp  dostosowywać mój kod jeśli ktoś poprosi mnie o to. Wymieniliśmy z Igorem korespondencję w sprawie możliwości równoległej pracy interfejsu z chmurą i lokalnym MQTT. Spodobało mu się moje rozwiązanie i zapytał czy może wykorzystać mój pomysł. Oczywiście zgodziłem się , ponieważ po to publikuję wyniki moich prac na githubie na zasadach Open Source aby każdy kto ma potrzebę, mógł wykorzystać je do realizacji własnych potrzeb. Cieszę się gdy ktoś zainteresuje się moim rozwiązaniem, a osoby które mają problem z uruchomieniem staram się wspierać i pomagać na ile umiem.

Co do moich kierunków rozwoju HeishaMonBoth to pytam osoby do mnie piszące o to jakie mają potrzeby. Jeśli masz jakieś pomysły to napisz do mnie albo otwórz Issue na zasobie github.com/salakrzy/HeishaMonBoth i opisz co by się przydało. Platforma ESP32 daje zupełnie nowe możliwości w postaci dużej ilości GPIO, liczne interfejsy typu Bluetooth, SDI, I2C itp.

Obecnie najbliższe pomysły to:

1 podniesienie poziomu bezpieczeństwa i przejście na komunikację https

2 dodanie możliwości odczytu po RS485/modbus  liczników Energii Elektrycznej

3 dodanie możliwości odczytu głowicą optyczną liczników Energii Elektrycznej

4 dodanie możliwości odczytu danych z falowników PV

5 dodanie możliwości odczytu  liczników IZAR zużycia wody

O tym które pomysły i w jakiej kolejności  zaimplementuję, zależeć będzie od ujawnionego zainteresowania , dostępności dokumentacji opisującej protokoły komunikacyjne, no i moich umiejętności, które stale staram się rozwijać ale sporo mam jeszcze do nadrobienia...  

A Emulację płyty opcjonalnej też przeportowałeś ?

Nie urywam , że na tym mi najbardziej zależy , używam też czujników temperatur Dallas , natomiast odczyt liczników , czy PV to nie moja bajka. Prowadzić kable od liczników i inwertera , żeby móc go odczytać... Toż to taniej wyjdzie drugi ESP podłączony bezpośrednio do licznika /inwertera , który ładuje dane do MQTT , na to są też projekty na githubie.

Natomiast mnie interesowałaby takie rzeczy przy emulacji opcjanalnej płyty , jak "hardwarowe" / bezpośrednie sterowanie obiegówkami na razie muszę mieć osobne ESP i działający serwer MQTT , żeby obiegówki były wysterowane , tak to powiedzmy serwer MQTT siada , ale dopuki HeishaMon żyje to jest grzanie ( Nie ,żeby mi serwer MQTT padał, po prostu bardziej byłoby to niezawodne). 

To samo tyczy się styków termostatów , na razie załączenie termostatu polega na wysłaniu komendy przez MQTT , a tak GPIO jest zwierane przez fizyczny termostat , i Heishamon załącza grzanie bez udziału MQTT...

@mig41 Chodzi ci o opcjonalne PCB? 

Tak , na emulatorze mi chodzi a w praktyce nie mam jak sprawdzić bo nie mam takiej konfiguracji pompy.

Opcjonalna PCB generuje dużo ruchu bo co jakiś krótki ustalony czas musi być wysłane zapytanie bo jak nie ma to jest alarm. Pewnie stąd twoje pytanie o optymalizację ilości podpytań pompy?

 Z twojego postu wynika że na płytkę warto wyprowadzić więcej pinów GPIO aby się  można było bawić w to o czym piszesz. Jak nie używasz  impulsowych liczników to masz dostępne 2 GPIO a i z UART0 też można by skorzystać z 2 pinów (ale stracisz monitoring po porcie szeregowym) a więc w tej wersji są już 4GPIO. No i do sterowania wyjściem można by jeszcze od biedy wykorzystać pin PROGRAM (GPIO0) . Więcej jest dostępnych na pinach procesora ale nie są wyprowadzone na goldpiny na płytkę.

Co do inwerterów PV to sporo chodzi po JSON więc nic nie trzeba ciągnąć a czy nie chciałbyś wiedzieć że masz nadwyżkę produkcji prądu i może by tak bufor podładować?

Tak , o opcjonalną PCB 🙂

W zasadzie możesz włączyć w opcjach Heishamon emulację , w pompie włączyć Opcjonalna PCB i już będzie 🙂

Trzeba tylko jeszcze pamiętać , żeby ustawić HeishaMon jakąś temperaturę wody dla strefy 1  komendą SetZ1WaterTemp , bo inaczej błąd wyskoczy . A później choćby Demand Control włączyć.

Tak , prawdziwa płyta wysyła soje krótkie pytania i dostaje krótkie odpowiedzi non-stop , tylko w międzyczasie się trafiają pakiety z cz-taw1 ( co 3s).

No i gdy opcjonalna PCB jest w pompie włączona , to przy podnoszeniu zasilania taki pierwszy pakiet musi trafić do pompy w 1,5s , inaczej pompa zainicjuje się z błędem. Natomiast podczas normalnego działania , jeśli pompa nie dostanie krótkiego pakietu w ciągu 40s to wywala błąd. 

Także to często , to jest na wzór prawdziwej Opcjonalnej PCB , nic się nie stanie , jak przez parę sekund go nie będzie ( oczywiście wtedy będzie opóźnienie w stylu aktualizacji temperatur , włączenie dodatkowych obiegówek  , czy wyłączenie pompy z termostatów).

Stąd wg mnie potrzeba "inteligentnego" zarządzania , co aktualnie wysłać do pompy a czego nie ( choćby właśnie po co wysyłać ten sam pakiet z CZ-TAW1 skoro przed chwilą poszedł z Heishamon dokładnie ten sam ) , tak samo buforowanie i łączenie komend ... O ile buforowanie Heishamon ma ( np. automatyzacja wyśle na raz parę komend na raz , np zmień temperaturę , zmień tryb , zmien temperaturę CWU , itp) , to można te komendy połączyć i wysłać jedną "zbiorczą" , a nie wysłać je po kolei do pompy...

Tak , mogę wykorzystać jeszcze parę wolnych GPIO , tylko po prostu kiepski ze mnie programer 🙂 i tego ogarnąć nie umiem .

Co do PV , to moja automatyzacja wie kiedy jest nadprodukcja ( bo mam osobny moduł do importowania danych po modbusie i przesyłania tego do MQTT) , i jak najbardziej mogę wysłać do HeishaMon odpowiednie sterowanie , ale nie uważam , że Heishamon bezpośrednio musi to wiedzieć 🙂

Poza tym też wiem , że zimą jest tyle tych dni z nadprodukcją co kot napłakał...

Nie mam też bufora , nim jest podłogówka , a jak jest słońce ( to jest dosłownie kilka dni zimą) to i tak bardzo szybko w domu robi się za gorąco z właczoną pompą i odsuniętymi roletami.