@relayer sterowanie krzywą grzewczą w dużej części mam ogarnięte poza 3 brakującymi adresami modbus - dla grzania i CWU brak y4 i chłodzenia y1. Pewnie da się to zrobić prościej ale najważniejsze że działa. @eWuPi raz jeszcze dziękuję za podzielenie się wiedzą.
Mając teraz pełne logowanie testuję grzanie w oparciu o krzywą grzanie i ograniczenie maksymalnej mocy sprężarki (to już ustawiane wyłącznie z poziomu sterownika) w zadanych zakresach temperatur aby w dłuższych cyklach pracowała. Niestety przy temperaturach dodatnich jest przewymiarowana.
Z całą pewnością masz złe wcięcia (co widać nawet na wklejce chociaż nie wiem czy jej nie zwaliłeś, bo do wklejania jakiegokolwiek kodu nie używa się cytatów)
w punkcie 1 masz 2 spacje wcięcia przez elementem listy
a w puncie 2 jest 5 spacji - no ni hu-hu się to nie zgadza (gdzieś jest coś do bani, wcięcia są zawsze wielokrotnością 2 spacji, nie wstawia się też tabulatorów!)
configuration.yaml (51,1 KB)
problem widać, że zaczyna się od 1567 linijki. Niestety jako, że w HA zaczynam bawić się drugi dzień, jeszcze może nie widzę oczywistego błędu. Wrzucam plik
W 1697 linii brakuje jednej spacji… ale czy to wszystko, to nie mam bladego pojęcia, jeśli po 2 dniach masz 50kB pliku konfiguracyjnego to nie wiem co będzie za tydzień
Linter wbudowany w edytor ma tylko podstawowe sprawdzenie składni, więc wskazywany błąd może wynikać z wpadki w zupełnie innym miejscu (ale zwykle w tym samym bloku).
@szopen Faktycznie umknął mi post z plikiem i moja sugestia poprawy jest chybiona
Edit:
Może komuś się przyda.
Po zrobieniu ustawień krzywej grzania przyszła pora na na zmianę innych parametrów pompy tj: prędkość sprężarki i wentylatora w trybie nocnym. Dotychczas zapisywania wartości modbus robiłem poprzez termostat ale w tym przypadku pomimo że zadziałałoby, to niestety nie wygląda to funkcjonalne.
Dlatego użyłem innej opcji podpatrzonej gdzieś na forum HA przy innej integracji.
Na początek zapisałem w configuration.yaml sensor prędkości sprężarki w trybie nocnym z adresu 263
W następnej kolejności utworzyłem pomocnika umożliwiającego wprowadzenie oczekiwanej prędkości
ale nie mam pomysłu jak oddzielnie zapisywać wprowadzone przez pomocnika godziny i minuty (zgodnie z załączoną listą przez @wojciech1039 mają oddzielne adresy).
Postanowiłem wykorzystać Wasze doświadczenia, aby podłączyć się do mojej pompy sprsun i zbierać z niej dane, ale trafiłem na taki problem: po ustawieniu modbus i tcpserver w parametrach EW11 mogę podłączyć się przy pomocy NR do wybranego portu na EW11 (NR: Modbus-Read) i zbierać ramki. Konsola EW11 potwierdza, że odbiera i wysyła poprawne ramki, ale z adresów modbus, które tutaj publikowaliście, przychodzą wartości nijak nie pasujące do niczego. Przykładowo adres 188 (temperatura powrotu wg publikowanych tu yamli) zawsze zwraca 40, adres 189 (temp. zasilania) - zawsze 35, adres 3 (zadana temp. CWU) - 14. Te wartości “w realu” oczywiście są inne. Czy coś mi umyka, czy mogę mieć inne adresy?
Hej,
Jeżeli ktoś by jeszcze miał problemy ze znikającymi parametrami to w configuration.yaml czy gdzie tam macie konfiguracje dla modbusa dorzućcie parametr: retry_on_empty: true
Natomiast ja mam pytanie w jaki sposób zmieniacie nastawy, temperatury zadane itp. Bez problemu odczytuje sobie wszystkie parametry ale nie wiem jak z poziomu HA wysłać temperature zadaną. Próbowałem w sposób jaki @Makki ustawia obroty dla sprezarki ale nie działa. Karta termostat też nie działa wyświetla zadaną temperature ale jak zmieniam wartość to nic sie nie dzieje (ustawia sie tez tam na automatycznie nie wiem o co z tym chodzi)
Z góry dzieki za pomoc
edit: troche wiecej informacji
np dla zadanej temperatury CO (zwykła, nie krzywa grzewcz, nie plan tygodniowy)
Sprsun CGK025V3L-B to nowa wersja pompy z dotykowym wyświetlaczem i płytą główną (cc902) firmy Elechico. Co za tym idzie, zmieniła się adresacja rejestrów modbus. Nie ma też sterowania PID, została natomiast krzywa grzewcza. Ktoś z FB ogarnął parę rejestrów, dostaliśmy także jakąś listę rejestrów od Sprsun, ale chyba wysłali tylko na odczepnego… MODBUS_PROTOCOL_CG248066–CG248067 (2).zip (90,5 KB)
EDIT:
Otrzymałem od kolegi z grupy na fb Sprsun Łukasz Mochylski (Sorato) mapę adresów modbus do nowej wersji pompy. Wydaje się, że zgadza się z tym co już podsłuchał inny kolega. W wolnej chwili postaram się ogarnąć integrację przez ESPHome. RS485-CG248075-MODBUS-V1.2-EN-2022.07.05-.pdf.zip (163,3 KB)
Ale byłbym wdzięczny jeszcze za jakieś wskazówki, jak poprawnie ogarnąć sterowanie tej pompy z HA czyli rejestry R/W. Czy to się da zrobić używając jedynie integracji Modbus?
Nie wiem jak ogarnąć zapis np. w rejestrze nr 0x0033 w ESPHome. Odczyt jest dość łatwy:
- platform: modbus_controller
modbus_controller_id: sprsun_pc
name: ${friendly_name} Failure symbol 7
id: failure_symbol_7
register_type: holding
address: 0x000D
response_size: 2
raw_encode: HEXBYTES
#bitmask: 0
lambda: |-
std::string z = "";
int idx = item->offset+1;
if ((data[idx] & 0x0001) != 0) z += "Invalid, ";
if ((data[idx] & 0x0002) != 0) z += "Ambient temperature is too low, ";
if ((data[idx] & 0x0004) != 0) z += "Invalid, ";
if ((data[idx] & 0x0008) != 0) z += "Invalid, ";
if ((data[idx] & 0x0010) != 0) z += "Frequency conversion module is faulty ";
if ((data[idx] & 0x0020) != 0) z += "2# DC fan failure, ";
if ((data[idx] & 0x0040) != 0) z += "1# DC fan failure, ";
if ((data[idx] & 0x0080) != 0) z += "Invalid, ";
if(z.length() > 0){
z.pop_back();
}
return {z};
interesting thread. I’m also looking for modbus registers for an Elechico Spa Heat Pump Controller (CCYC004). It is build in a PassianSpa XC heatpump (similar to the Balboa clim8zone heatpump with same controller). After many days I figured out the modbus parameters:
115200 bps / 8N1 on the internal second 4PIN RS485 connector.
However I have no documentation about the registers :(. Holding registers range from 0-418 and then occassionally appear from 500 onwards. However I couldn’t locate so far the important ones to set the temperature and to switch modes of the device. Some temperature values I could find on some of the registers (but these are only sensors)e.g. H147 and H154.
Elechico isnt disclosing any information about the interface
Finalnie udało mi się całkiem sporo oprogramować. Dalej się tego uczę, pewnie niektóre rzeczy można zrobić prościej/efektywniej/ładniej. Ale ponieważ zaczynałem od zera w zakresie znajomości HA, to uważam, że jest nieźle. I działa to razem dość stabilnie. Dziękuję wszystkim za pomoc!
@solar007 - I would try to chase Elechico - using all the contacts provided on their webpage. I know this may seem naive but sometimes it works. At least worked for my HP maker.
Super Powodzenia w dalszej konfiguracji. Ja również pracuje nad swoją PC, dałem szanse polskiemu producentowi i teraz próbuje go zintegrować z HA. Do komunikacji z aplikacją mobilną (do sterowania) wykorzystuje też chińskie serwery.
Edit:
Poszedłem w stronę MQTT i mam kompletny brak komunikacji (ale połączenie z serwerem jest zestawione) - w sensie krążenia pakietów:
dlatego na razie odpuściłem sobie ten protokół i chętnie bym podsłuchał co tam sobie gada z tymi chinami przez TCP. W NR ustawiłem serwer TCP In na który zestawiłem nowe połączenie z EW11:
i z obserwacji wyszło że:
Przy pierwszym połączeniu z serwerem EW11 wysyła zawartość pola Register Code z sekcji Protocol Settings, każdy kolejne zapytanie serwera odbywa się w okresach określonych w polu Heart Beat Time a wysyłana jest treść pola Heart Beat Code
Edit 2:
Serwer chińczyk reaguje tylko na wysłanie pola Register Code zwrotnie odsyłając ciąg 33 znaków. Za każdym razem taki sam, więc to nie są parametry pompy - bo odpytywałem po zmianie parametrów. Mimo to ciąg znaków jaki zwraca jest ten sam. - Czyli tą ścieżką dalej nie pójdę. Pytanie się nasuwa inne, po co EW11 wysyła pakiet TCP z pola Heart Beat Code do podtrzymania połączenia z serwerem?
PYTANIE o ścieżkę:
wg. was lepiej wpiąć się w magistrale RS485 i słuchać krążących pakietów, czy odpytać (oczywiście w trybie odczytu) wszystkie rejestry poda adresem PC na magistrali i przypasować odpowiedzi do aktualnych parametrów PC do których mam dostęp.
Z mojego doświadczenia, jeśli Elfin gadał jednocześnie z Chinami i z czymkolwiek innym, to komunikacja się rwała albo umierała. Chyba ktoś wcześniej w tym wątku też to potwierdzał. Usuń może całkowicie oryginalną zakładkę netp do Chin (tylko najpierw zrób sobie backup całej konfiguracji), zrestartuj elfin i spróbuj wtedy jeszcze raz mqtt. (Po każdej zmianie robiłem zawsze restart elfina. Inaczej niby działało, a za chwilę były jakieś problemy). Ale finalnie z mqtt się poddałem - nie umiałem danych zinterpretować…
Po co EW11 “pinguje” serwer: tylko elfin może nawiązać połączenie do serwera - odwrotnie się nie da - bo większość ludzi blokuje dostęp z zewnątrz. Dlatego to elfin zestawia połączenie tcp i musi je potem jakoś podtrzymać. Jak nie będzie periodycznie czegoś na nim wysyłać, to jest duża szansa, że jakieś urządzenie “po drodze” to połączenie tcp po jakimś czasie zamknie. A elfin nic nie będzie o tym wiedzieć - z jego punktu widzenia połączenie nadal będzie wyglądało na otwarte - więc nie nawiąże nowego. W takim przypadku aplikacja przestałaby działać - bo jak coś na niej klikniemy, to serwer w Chinach musi to przesłać po zestawionym wcześniej połączeniu do pompy. A jak to połączenie jest przez coś “uwalone” po drodze, to komenda nigdy do pompy nie dotrze.
Powodzenia w dalszej konfiguracji. Ja również pracuje nad swoją PC, dałem szanse polskiemu producentowi i teraz próbuje go zintegrować z HA. Do komunikacji z aplikacją mobilną (do sterowania) wykorzystuje też chińskie serwery.
