Witajcie, próbuję swoją pompę (Kaisai KHC-12RY3-B) połączyć do ESPHome, używam mikrokontrolera ESP32-S3 oraz konwertera RS485/UART (jakaś chińska płytka no-name).
Eksperymentuję od pewnego czasu, ale bez skutku, nie udaje mi się nawiązać komunikacji po modbus ani odczytać choćby jednego rejestru. Czy może dysponuje ktoś przykładowym plikiem .yaml który działa dla w/w pompy?
Nie wiem w tym momencie gdzie dokładnie jest problem, jest kilka elementów mojej konfiguracji które sprawiają problemy i chciałbym choć wiedzieć że plik yaml dla esphome jest ok i powinien działać.
PS czy ‘segmentation fault’ podczas kompilacji modułu ESPHome (wywala się kompilator gcc na jakimś kodzie z esp-idf) to czasem nie jest sygnał że mój hardware niedomaga? Miałem już problemy tego rodzaju związane z kartą sieciową (terminal T630) ale może ten komputer ma więcej problemów…
Dzięki
RG
ostatni yaml:
substitutions:
device_name: kaisai-heat-pump
friendly_name: "Kaisai KHC Heat Pump"
esphome:
name: ${device_name}
friendly_name: ${friendly_name}
esp32:
board: esp32-s3-devkitc-1
framework:
type: esp-idf
# Enable logging (set to WARN or ERROR in production to reduce noise)
logger:
level: DEBUG
api:
encryption:
key: "***"
ota:
- platform: esphome
password: "***"
wifi:
ssid: 'p0g016'
password: '****'
mqtt:
broker: 192.168.32.25
uart:
id: modbus_uart
tx_pin: GPIO17
rx_pin: GPIO18
baud_rate: 9600
stop_bits: 1
data_bits: 8
parity: NONE
modbus:
id: modbus_bus
uart_id: modbus_uart
modbus_controller:
id: kaisai
modbus_id: modbus_bus
# Default slave address for Kaisai/Midea heat pumps is 1.
# If communication fails, try address: 16 (0x10 per Kaisai docs).
address: 1
update_interval: 30s
# Allow extra time between requests — heat pump controller can be slow
command_throttle: 200ms
################################################################################
# SENSORS
################################################################################
sensor:
- platform: modbus_controller
modbus_controller_id: kaisai
name: "Water Outlet Temperature"
id: water_outlet_temp
# Register 0x0121 = decimal 289
# This is the actual water outlet temperature (Tw / TW on the display)
address: 0x0121
register_type: holding
value_type: S_WORD # Signed 16-bit integer
unit_of_measurement: "°C"
device_class: temperature
state_class: measurement
accuracy_decimals: 1
icon: "mdi:thermometer-water"
i rezultat kompilacji
INFO ESPHome 2026.3.2
INFO Reading configuration /config/esphome/esphome-web-312c6c-1.yaml...
INFO Generating C++ source...
INFO Compiling app... Build path: /data/build/kaisai-heat-pump
Processing kaisai-heat-pump (board: esp32-s3-devkitc-1; framework: espidf; platform: https://github.com/pioarduino/platform-espressif32/releases/download/55.03.37/platform-espressif32.zip)
--------------------------------------------------------------------------------
HARDWARE: ESP32S3 240MHz, 320KB RAM, 4MB Flash
- contrib-piohome @ 3.4.4
- framework-espidf @ 3.50503.0 (5.5.3)
- tool-cmake @ 4.0.3
- tool-esp-rom-elfs @ 2024.10.11
- tool-esptoolpy @ 5.1.2
- tool-ninja @ 1.13.1
- tool-scons @ 4.40801.0 (4.8.1)
- toolchain-xtensa-esp-elf @ 14.2.0+20251107
Reading CMake configuration...
Dependency Graph
|-- noise-c @ 0.1.11
Compiling .pioenvs/kaisai-heat-pump/src/esphome/components/api/api_connection.cpp.o
Compiling .pioenvs/kaisai-heat-pump/src/esphome/components/api/api_frame_helper.cpp.o
Compiling .pioenvs/kaisai-heat-pump/src/esphome/components/api/api_pb2.cpp.o
Compiling .pioenvs/kaisai-heat-pump/src/esphome/components/api/api_pb2_service.cpp.o
In file included from /data/cache/platformio/packages/toolchain-xtensa-esp-elf/xtensa-esp-elf/include/c++/14.2.0/bits/shared_ptr.h:53,
from /data/cache/platformio/packages/toolchain-xtensa-esp-elf/xtensa-esp-elf/include/c++/14.2.0/memory:80,
from src/esphome/core/string_ref.h:6,
from src/esphome/components/api/api_pb2.h:5,
from src/esphome/components/api/api_pb2.cpp:3:
/data/cache/platformio/packages/toolchain-xtensa-esp-elf/xtensa-esp-elf/include/c++/14.2.0/bits/shared_ptr_base.h: In member function 'void std::_Sp_counted_base<_Lp>::_M_release_last_use()':
/data/cache/platformio/packages/toolchain-xtensa-esp-elf/xtensa-esp-elf/include/c++/14.2.0/bits/shared_ptr_base.h:180:28: internal compiler error: Segmentation fault
180 | if (_Mutex_base<_Lp>::_S_need_barriers)
| ^
0x18c6546 internal_error(char const*, ...)
???:0
0x81b7ef most_general_template(tree_node const*)
???:0
0x842552 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*, int, int)
???:0
0x85f2bd finish_template_type(tree_node*, tree_node*, int)
???:0
0x813b98 c_parse_file()
???:0
0x908d20 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using -freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
*** [.pioenvs/kaisai-heat-pump/src/esphome/components/api/api_pb2.cpp.o] Error 1
src/esphome/components/api/api_connection.cpp:2450:1: internal compiler error: Segmentation fault
2450 | } // namespace esphome::api
| ^
0x18c6546 internal_error(char const*, ...)
???:0
0x9b5c25 symbol_table::finalize_compilation_unit()
???:0
Please submit a full bug report, with preprocessed source (by using -freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
*** [.pioenvs/kaisai-heat-pump/src/esphome/components/api/api_connection.cpp.o] Error 1
A dowiemy się czegoś więcej o jego konfiguracji?
(zajrzałem w twoje starsze posty, ale nie było tam za wiele… w dodatku tam sugerowano wykonanie pełnych testów sprzętu - zrobiłeś to? przyczyna tamtego problemu była wprawdzie inna, ale w przypadku szykowania jakiegokolwiek sprzętu do wieloletniej pracy trzeba wykonać takie testy, a to jest może jeszcze nie zupełnie zabytkowy komputer, ale zapewne intensywnie eksploatowany polizing…)
i chyba muszę napisać jakąś instrukcję jak wstawiać YAMLe z ESPHome, tj. nie rzucać nam kłód pod nogi (aby nie usuwać danych które nie są danymi wrażliwymi, a z danymi potencjalnie wrażliwymi takimi jak dane logowania do WiFi postępować sensownie) wstępnie można korzystać z tamtego posta
PS Jeśli instalowałeś ESPHome przed podłączeniem karty Ethernet nie stwarzającej problemów, to
odinstaluj ESPHome
zrestartuj HAOS (nie sam HA, tylko z restartu zaawansowanego cały system!)
zainstaluj ESPHome używając tej nowej karty Ethernet (swoją drogą o ile masz monitor i klawiaturę, które możesz dopiąć do maszyny, to możesz w punkcie 2. zajrzeć do BIOS i wyłączyć tą onboard, ewentualnie zrób zdjęcia, bo może można z poziomu BIOS wyłączyć offloading w tej problematycznej i to rozwiąże w sposób alternatywny problem, który obszedłeś dokładając kartę USB)
To są kontenery Dockera, trochę zapomnij o “klasycznym linuxie” sprzed lat (to dla mnie była duża przeszkoda na początku zabawy z HAOS, bo nie dość że Docker, to jeszcze system na bazie Buildroot).
Natomiast poza konkurencją - nie wiem jak duże zmiany wprowadzałeś w YAML, ale teoretycznie zmienione części powinny zostać od nowa skompilowane a nie pobierane z cache.
Nawet nie będę próbował szukać dziury w całym, po prostu używaj CLEAN BUILD FILES jeśli zmiany są istotne.
Tak, zaczałem od yamla generic-r32 z tego repozytorium ( GitHub - Mosibi/Midea-heat-pump-ESPHome · GitHub ). Niestety nie mam komunikacji. Nie mialem też pewnosci czy to akurat do mojego modelu pompy pasuje. Najbardziej brakuje mi jakieś metody na debugowanie/testowanie tego modbusa żeby wiedzieć czy w ogóle komunikacja ma szansę zadziałać. Bo np nic w logach się nie zmienia jeśli odepnę zasilanie od konwertera rs485 czy inne połączenia pozmieniam.
ps konfiguracja logowania - w powyższym pliku r32-generic.yaml (i w innch przykładach także) ustawiany jest baud_rate loggera na 0, co powoduje że logowanie jest wyłączone. Domyślam się że po to żeby UART był tylko do modbusa wykorzystywany. Ale ESP32 ma więcej niż jeden UART, na dodatek nie korzystam z połączenia szeregowego do monitorowania logów tylko z wifi - czy to baud_rate w takim wypadku koniecznie musi być 0?
logger:
level: INFO
baud_rate: 0
Na razie pomyślę jak skutecznie upewnić się że ta komunikacja modbus w ogóle funkcjonuje bo wrzucanie przypadkowych konfiguracji do esphome gdy ona nie działa jest bez sensu.
Jako interfejsu do modbus używam taniego chińskiego modułu UART ←> rs485 który wygląda mniej więcej tak. Moze ktoś ma to już przetestowane?
Zacznij do podłaczenia np. do PC z jakimś programem ModbusMaster (który działa na pewno) . Potrzebowałbyś tylko dodatkowego konwertera USB <> ttl. Sprawdzisz wtedy i ustalisz parametry transmisji i adresację rejestrów.
.. zastanawia mnie czy ESPHome jest do d…y, czy przestano używac już innego oprogramowania - bo czytam tylko o wiecznych z nim problemach.
No i od takich informacji powinieneś w ogóle zacząć, wtedy czytelnik ma jakiś punkt zaczepienia (będę miał czas, to pomyślę czy ujedziemy z tym tematem na spokojnie)
“prędkość zero” nie powoduje, że logowanie jest wyłączone całkowicie, tylko, że jest wyłączone na porcie szeregowym, to jest konfiguracyjna zaszłość po ESP8266/8285 (gdzie użytkowo jest dostępny tylko jeden UART, więc nie może służyć do logowania, gdy robi co innego)
tak, ESP32 i ESP32-S3 (będę go skrótowo nazywał S3, by nie mylić ze starszym innym modelem MCU) mają więcej niż jeden UART, w dodatku UART0 jest w nich zazwyczaj na stałe podłączony do mostka UART-USB (jeśli płytka ma taki mostek zamontowany, bo MCU S3 ma też własny port USB)
nie ma to żadnego wpływu na logi wysyłane kanałem OTA (przez WiFi), UWAGA jest jedno istotne ograniczenie tego kanału - nie można w ten sposób zobaczyć co się dzieje w trakcie bootowania MCU (ani w jakiejkolwiek sytuacji, gdy zostaje z dowolnych powodów utracona łączność WiFi), logi portem szeregowym są znacznie bardziej rozsądnym rozwiązaniem
twój problem leży raczej tutaj
czyli masz zbyt niski poziom logowania, w zależności od potrzeb należy wykorzystywać poziom DEBUG, VERBOSE lub nawet VERY_VERBOSE (dopiero ten ostatni daje głębszy podgląd co się dzieje na kontrolerach magistral w tym na UART)
jest bez sensu, dlatego potrzebujesz dokumentacji od swojego sprzętu (pompy ciepła), jako totalne minimum jest to mapa rejestrów
możesz więc ograniczyć testy do jednego rejestru co do którego masz pewność, że jest i działa oraz znasz jego adres (a najlepiej aby to był jakiś sensor numeryczny, czyli coś co jest tylko do odczytu)
ESPHome jest prosty jak klocki lego, dlatego jest świetny dla nie-programistów (swoją drogą ten projekt zdobył tak dużą popularność szczególnie wśród użytkowników HA, bo zarówno konfiguracja była wzorowana na dawnej konfiguracji HA w YAML, jak i to był projekt dedykowany głównie do współpracy z HA, a, że HA zdobył niebywałą popularność to i splendor słynął na ESPHome).
A, że z klocków lego ciężko zbudować coś niekanciatego i skomplikowanego to inna kwestia
Mały problem w tym że nie mam mapy rejestrów swojej pompy. Nie ma tego w dokumentacji i już. Są w sieci różne mapy zebrane przez różnych ludzi, ale która jest właściwa - nie wiem.
W dodatku nie umiem odróżnić czy nie działa komunikacja czy np działa, ale podaję nieprawidłowe adresy rejestrów. Gdyby to rejestry były nieprawidłowe to powinny wracać śmieci albo jakieś komunikaty błędu (protokół Modbus chyba takowe przewiduje?) a tu jest głucho i ciemno - timeouty na komunikacji i to wszystko.
Pokazałeś płytkę konwertera UART-RS485, ona ma 2 kontrolki LED: nadawania i odbioru - to jest najbardziej podstawowy test komunikacji.
Zwiększ sobie poziom logowania
Częsty błąd to połączenie RX z TX oraz TX z RX zamiast TX z TX i RX z RX, (bądź odwrotnie, jak należy podłączyć tę płytkę nie pamiętam, ale to jest pierwsze do sprawdzenia, a zamiana na krzyż to zero roboty, kontrolki na konwerterze muszą mrugać w trakcie pracy), normalnie media-konwertery łączy się TX (MCU) do TX (konwertera) i RX (MCU) do RX (konwertera)
Połączenie RS485 to zawsze A do A i B do B.
Czyli masz jednak jakieś podejrzenia do jakiego modelu twój jest najbardziej zbliżony?
Więc wybierz jakiś jeden rejestr (co do którego masz pewność, że istnieje, bo np. na wyświetlaczu masz prezentowane to wskazanie sensora), który jest tylko do odczytu i na nim testuj (dla różnych modeli może są to różne adresy rejestru, ale gdy uzyskasz prawidłową odpowiedź to będzie krok w dobrą stronę)
Dlatego nie oprotestowałem tego YAMLa na początku - on wygląda bardzo sensownie i wskazuje na właściwą metodologię poszukiwań.
Dobra, mam tę komunikację. Problem był prawdopodobnie z polączeniem TX/RX do modułu konwertera ttl ←> rs485 - okazuje się że pin TX łączymy do TX, RX do RX (a byłem przekonany że w połączeniach szeregowych łączy się TX z RX ‘na krzyż’)
Wymieniłem też rezystor terminujący po stronie modułu na bardziej zbliżony do 120 ohm bo było chyba 270 albo 470 - ale nie wiem czy to miało znaczenie.
Ten yaml z repozytorium powyżej jest sensowny, najważniejsze parametry odczytuje choć jest sporo takich co nie są raportowane. Dzięki wszystkim za popychanie tego we właściwym kierunku. Swoim T630 i jego problemami nie będę się na razie zajmował bo dziś kompilacje przechodziły bez problemu. Dopóki tak zostanie to go nie ruszam.
Ale jak widać ‘rabbit hole’ nie odpuszcza - jeden problem zastępuje kolejnym.
Teraz się okazuje że mój ESP32 działa, przez jakiś czas. Potem ustaje komunikacja.
Po resecie wstaje, ale w logach widać podpowiedź że był jakiś crash
Nie mam pojęcia co tu się stanęło, załączam mój plik yaml niżej.
Może da się w ESPHome wstawić jakiegoś watchdoga który sam zrestartuje urządzenie jeśli ono się zwiesi?
INFO ESPHome 2026.3.2
INFO Reading configuration /config/esphome/midea-generic.yaml...
WARNING 'Status BIT 1 Remote On/Off' contains '/' which is reserved as a URL path separator. Automatically replacing with 'Status BIT 1 Remote On⁄Off' (Unicode FRACTION SLASH). Please update your configuration. This will become an error in ESPHome 2026.7.0.
WARNING Captive portal is enabled but no WiFi AP is configured. The captive portal will not be accessible. Add 'ap:' to your WiFi configuration to enable the captive portal.
INFO Starting looking for IP in topic esphome/discover/heatpump
INFO Connected to MQTT broker!
INFO Send discover via MQTT broker topic: esphome/ping/heatpump
INFO Found IP: ['192.168.32.177']
INFO Starting log output from 192.168.32.177 using esphome API
INFO Successfully resolved heatpump @ 192.168.32.177 in 0.000s
INFO Successfully connected to heatpump @ 192.168.32.177 in 0.123s
INFO Successful handshake with heatpump @ 192.168.32.177 in 0.016s
[20:44:51.909][E][esp32.crash:224]: *** CRASH DETECTED ON PREVIOUS BOOT ***
[20:44:51.915][E][esp32.crash:227]: Reason: Fault - Unknown
[20:44:51.916][E][esp32.crash:231]: PC: 0x40378E76 (fault location)
WARNING Decoded 0x40378e76: esp_cpu_wait_for_intr at /data/cache/platformio/packages/framework-espidf/components/esp_hw_support/cpu.c:64
[20:44:52.733][E][esp32.crash:245]: BT0: 0x40378E73 (backtrace)
WARNING Decoded 0x40378e73: xt_utils_wait_for_intr at /data/cache/platformio/packages/framework-espidf/components/xtensa/include/xt_utils.h:82
(inlined by) esp_cpu_wait_for_intr at /data/cache/platformio/packages/framework-espidf/components/esp_hw_support/cpu.c:55
[20:44:53.559][E][esp32.crash:245]: BT1: 0x420AE4AD (backtrace)
WARNING Decoded 0x420ae4ad: esp_vApplicationIdleHook at /data/cache/platformio/packages/framework-espidf/components/esp_system/freertos_hooks.c:58
[20:44:54.188][E][esp32.crash:245]: BT2: 0x420B0133 (backtrace)
WARNING Decoded 0x420b0133: prvIdleTask at /data/cache/platformio/packages/framework-espidf/components/freertos/FreeRTOS-Kernel/tasks.c:4350 (discriminator 1)
[20:44:54.833][E][esp32.crash:258]: Use: addr2line -pfiaC -e firmware.elf 0x40378E76 0x40378E73 0x420AE4AD 0x420B0133
[20:44:54.833][I][app:231]: ESPHome version 2026.3.2 compiled on 2026-04-05 19:34:37 +0200
[20:44:54.834][I][app:233]: Project heatpump.Heatpump Controller version 9.1.0
[20:44:54.834][I][app:238]: ESP32 Chip: ESP32-S3 rev0.2, 2 core(s)
[20:44:54.834][C][logger:229]: Logger:
[20:44:54.834][C][logger:229]: Max Level: DEBUG
[20:44:54.834][C][logger:229]: Initial Level: DEBUG
[20:44:54.834][C][logger:236]: Log Baud Rate: 115200
[20:44:54.834][C][logger:236]: Hardware UART: USB_SERIAL_JTAG
Tak, połączenie “null modem” się stosuje zawsze, gdy ze sobą rozmawiają jakieś aktywne urządzenia, więc np. gdybyś UARTami bezpośrednio łączył jakieś 2 MCU, które się mają między sobą komunikować to nigdy inaczej - zawsze Tx do Rx. (i szczerze mówiąc logika opisywania konwerterów jest dla mnie żadna)
W czym wymieniłeś ten terminator? bo nie zrozumiałem.
Konwerter z twojego zdjęcia ma terminator R9 120om (opis na smd 121→120om), ale nieaktywny, jeśli jest potrzebny zwierasz R0.
Przy krótkich kablach terminacja nie jest niezbędna.
W ten sposób jak teraz działasz… no nie da rady, mając 170kB YAMLa nigdy w tym nie znajdziesz błędów, musisz uruchamiać to fragmentami (tak, wiem - to zabawa i może nawet na tygodnie).
Możesz też swoje błędy wraz z YAMLem wrzucić do AI…
To właśnie watchdog restartuje MCU (to między wierszami wynika z tego loga).
Możesz uprościć kod wywalając wszystkie sekcje z lambdami (i inne od nich zależne).
Generalnie powinieneś wywalić wszystko co nie działa z twoim sprzętem w takiej konfiguracji pompy ciepła jak masz u siebie.
ech, nawet nie wiedziałem że jest zworka włączająca rezystor. Brak dokumentacji (więc wsadziłem tam jeden co mi wpadł w ręce - dziś go wymieniłem na 120).
I oczywiście odchudzę tego yamla, na razie próbuję nacieszyć się tym że w ogóle działa.
Jeśli połączenie jest długie to przewodem ma być “skrętka komputerowa” lub inna o tych samych parametrach elektrycznych (jako A/B używasz jedną parę, a nie przewody z różnych par), ale przykładowo nie przewód teletechniczny prosty np. YTDY (bez skręconych par).
Terminatory mają być na obu końcach linii 120om, a nie żadne inne (inne i tak nie zadziałają prawidłowo, bo chodzi o linię długą, gdzie impedancja skrętki to właśnie 120om).
Przy realnie krótkim przewodzie (gdzie jest od biedy dopuszczalne też coś innego niż skrętka) nie są wymagane żadne terminatory, bo sygnał użytkowy jest i tak znacznie wyższy niż odbicia w linii. Dlatego fabrycznie masz wyłączony wbudowany terminator.
YAMLa musisz odchudzić, bo najprawdopodobniej te części które nie pasują do twojego sprzętu są przyczyną ostatniego problemu (ale potencjalnych przyczyn może być wiele łącznie z niestabilnym zasilaniem ESP).
Jakkolwiek lepiej byłoby go budować sekcja po sekcji i od razu wywalać to co nie pasuje.
