Nie moglem zrobic na framework arduino bo walilo bledami nie do opanowaia dla mnie. Wrocilem do esp-idf i zrobilem clean build. Efekt jest taki ze nie czyta licznika energii. Licznik wody czyta. A ja nic nie zmienialem w sensorach ani konfiguracji mbusa
W logach tylko to:
ime
Level
Tag
Message
18:08:57
[I]
[wmbus:047]
Have data (63 bytes) [RSSI: -99dBm, mode: T1 A]
18:08:57
[I]
[wmbus:056]
Telegram handled by 1 handlers
18:09:22
[I]
[wmbus:047]
Have data (63 bytes) [RSSI: -99dBm, mode: T1 A]
18:09:22
[I]
[wmbus:056]
Telegram handled by 1 handlers
18:09:58
[I]
[wmbus:047]
Have data (63 bytes) [RSSI: -99dBm, mode: T1 A]
18:09:58
[I]
[wmbus:056]
Telegram handled by 1 handlers
18:10:25
[I]
[wmbus:047]
Have data (63 bytes) [RSSI: -99dBm, mode: T1 A]
18:10:25
[I]
[wmbus:056]
Telegram handled by 1 handlers
18:10:55
[I]
[wmbus:047]
Have data (63 bytes) [RSSI: -99dBm, mode: T1 A]
18:10:55
[I]
[wmbus:056]
Telegram handled by 1 handlers
18:11:23
[I]
[wmbus:047]
Have data (63 bytes) [RSSI: -99dBm, mode: T1 A]
18:11:23
[I]
[wmbus:056]
Telegram handled by 1 handlers
18:11:52
[I]
[wmbus:047]
Have data (63 bytes) [RSSI: -99dBm, mode: T1 A]
18:11:52
[I]
[wmbus:056]
Telegram handled by 1 handlers
Widzę że masz słaby zasięg. Ale dane odbiera i nie może dopasować dopasowuje do jednego sensora a do drugiego już nie może.
Po pierwsze zmień logger:
logger:
level: VERY_VERBOSE
To nam pokaże surowe dane(hex). Następnie Spójrz w logi VERY_VERBOSE. Szukaj komunikatów, które mówią: Meter ID [0x12345678] not found in configuration. Jeśli zobaczysz tam ID swojego licznika energii, ale w innej formie, będziemy wiedzieć, że trzeba poprawić config.
I sprawdź klucz deszyfrujący bo jeśli przy Clean Build coś poszło nie tak z bibliotekami kryptograficznymi w esp-idf, system może nie być w stanie rozszyfrować ramki.
18:49:15
[I]
[safe_mode:066]
Boot seems successful; resetting boot loop counter
18:49:15
[W]
[component:543]
safe_mode took a long time for an operation (69 ms)
18:49:15
[W]
[component:546]
Components should block for at most 30 ms
18:49:18
[W]
[component:543]
interval took a long time for an operation (711 ms)
18:49:18
[W]
[component:546]
Components should block for at most 30 ms
18:49:18
[W]
[component:543]
api took a long time for an operation (721 ms)
18:49:18
[W]
[component:546]
Components should block for at most 30 ms
18:50:16
[W]
[component:543]
display took a long time for an operation (267 ms)
18:50:16
[W]
[component:546]
Components should block for at most 30 ms
ESP jest strasznie obciążony te long time for an operation więc dodaj lub zmień to w kodzie:
i2c:
sda: 4
scl: 15
scan: false
# Jeśli ESPHome nadal próbuje ładować sterownik, dodaj pusty komponent
display:
- platform: base
id: dummy_display
update_interval: 100h # Nigdy nie aktualizuj
Jest też problem z api i interval
esp32:
board: heltec_wifi_lora_32_V2
framework:
type: esp-idf
sdkconfig_options:
# Zwiększamy stos dla zadań, żeby deszyfrowanie AES nie wywalało systemu
CONFIG_ESP_MAIN_TASK_STACK_SIZE: "8192"
# Wyłączamy zbędne logi systemowe IDF, które zapychają bufor
CONFIG_LOG_DEFAULT_LEVEL_NONE: "y"
# Optymalizacja API
api:
reboot_timeout: 15min # Nie restartuj się, jeśli na chwilę stracisz połączenie z HA
# Wyłączamy web_server na próbę lub upraszczamy go maksymalnie
web_server:
version: 3
local: true
To powinno poprawić problem z restartem.
[EDIT] Tu jest cały config od Gemini (ale sprawdź go):
esphome:
name: lora
friendly_name: Lora
platformio_options:
upload_speed: 921600
# Zmiana na 1d oszczędza zasoby przy starcie
external_components:
- source: github://SzczepanLeon/esphome-components@main
components: [wmbus_common, wmbus_radio, wmbus_meter]
refresh: 1d
esp32:
board: heltec_wifi_lora_32_V2
flash_size: 8MB
framework:
type: esp-idf
sdkconfig_options:
# KLUCZOWE: Zwiększenie stosu naprawia restarty przy deszyfrowaniu wM-Bus
CONFIG_ESP_MAIN_TASK_STACK_SIZE: "8192"
# Optymalizacja logów systemowych
CONFIG_LOG_DEFAULT_LEVEL_INFO: "y"
# Optymalizacja logowania, by nie zapychać procesora
logger:
level: INFO
logs:
wmbus: ERROR
wmbusmeters: ERROR
# Wyłączamy logi o blokowaniu pętli, żeby nie spamowały logów
component: ERROR
api:
encryption:
key: "HQgeLhbuFOvN73DM0CYaT3qVabF0Euciq2C1aqJ0hLU="
reboot_timeout: 15min
ota:
platform: esphome
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
ap:
ssid: "Lora Fallback Hotspot"
password: "EyK1CEVSi4yt"
# Uproszczony web_server, by oszczędzić RAM na esp-idf
web_server:
version: 3
local: true
time:
- platform: sntp
id: sntp_time
# Jawne wyłączenie pinów wyświetlacza, by nie blokowały procesora
i2c:
sda: 4
scl: 15
scan: false
spi:
clk_pin: GPIO5
mosi_pin: GPIO27
miso_pin: GPIO19
wmbus_radio:
radio_type: SX1276
cs_pin: GPIO18
reset_pin: GPIO14
irq_pin: GPIO35
# Usunięto on_frame z logowaniem hex - przy słabym sygnale i esp-idf to generuje lag
wmbus_meter:
- id: water_meter
meter_id: 0x12345678 # WPISZ SWOJE ID
type: apator162
key: "00000000000000000000000000000000"
- id: electricity_meter
meter_id: 0x87654321 # WPISZ SWOJE ID
type: amiplus
key: "00000000000000000000000000000000"
sensor:
- platform: wmbus_meter
parent_id: water_meter
field: total_m3
device_class: water
name: "Zużycie wody"
accuracy_decimals: 3
state_class: total_increasing
unit_of_measurement: "m³"
- platform: wmbus_meter
parent_id: electricity_meter
field: total_energy_consumption_kwh
name: "Suma konsumpcji"
device_class: energy
state_class: total_increasing
- platform: wmbus_meter
parent_id: electricity_meter
field: current_power_consumption_kw
name: "Aktualny pobór"
device_class: power # Zmieniono na power dla jednostki kW
state_class: measurement
- platform: wmbus_meter
parent_id: electricity_meter
field: total_energy_production_kwh
name: "Suma produkcji"
device_class: energy
state_class: total_increasing
- platform: wmbus_meter
parent_id: electricity_meter
field: current_power_production_kw
name: "Aktualna produkcja"
device_class: power
state_class: measurement
- platform: wmbus_meter
parent_id: electricity_meter
field: voltage_at_phase_1_v
name: "Faza V1"
device_class: voltage
state_class: measurement
unit_of_measurement: "V"
- platform: wmbus_meter
parent_id: electricity_meter
field: voltage_at_phase_2_v
name: "Faza V2"
device_class: voltage
state_class: measurement
unit_of_measurement: "V"
- platform: wmbus_meter
parent_id: electricity_meter
field: voltage_at_phase_3_v
name: "Faza V3"
device_class: voltage
state_class: measurement
unit_of_measurement: "V"
- platform: wmbus_meter
parent_id: electricity_meter
field: rssi_dbm
name: "Licznik RSSI"
Skompilowalem tego yamla od Gemini ktory udostepniles ale restarty sa nadal. A co najciekawsze ze mam dwa identyczne moduly i w jednym jest skonfigurowany wyswietlacz a w drugim nie i obydwa sie restartuja losowo.Czasem dzialaja pol godziny a czasem kilka minut. Brakuje mi juz pomyslow. Przed aktualizacja Esphome obydwa dzialaly idealnie. Licze tylko na to ze @szczepan cos pprawi bo jest porazka w tej chwili na tych akurat modulach
A i logi na tym yamlu sa jakies dziwne. Nie mam pojecia o co w nich chodzi
Dobra to są akurat bardzo specyficzne i dziwne logiktóre wskazują na to że jest problem ze stabilnością ESP lub problemem z zasięgiem sieci bo jakby ESP tracił dane.
Time
Level
Tag
Message
20:40:16
[W]
[component:543]
display took a long time for an operation (248 ms)
20:40:16
[W]
[component:546]
Components should block for at most 30 ms
20:40:16
[I]
[wmbus:047]
Have data (191 bytes) [RSSI: -62dBm, mode: T1 A]
20:40:16
[I]
[wmbus:056]
Telegram handled by 1 handlers
20:40:16
[W]
[component:543]
wmbus_radio took a long time for an operation (67 ms)
20:40:16
[W]
[component:546]
Components should block for at most 30 ms
20:40:43
[W]
[api.connection:2241]
ESPHome Logs 2026.1.0 (192.168.1.5): Reading failed CONNECTION_CLOSED errno=128
20:40:44
[I]
[safe_mode:066]
Boot seems successful; resetting boot loop counter
20:40:44
[W]
[component:543]
safe_mode took a long time for an operation (64 ms)
20:40:45
[W]
[component:546]
Components should block for at most 30 ms
Niestety również potwierdzam że są problemy z licznikami energii jak i unismart. W obu przypadkach również się na kombinowałem z AI i nic nie wyszło, problem z kompatybilnością amipulse i unismart w wersji esphome od 2025.12.xx jak i również 2026.01 i 2026.02 dev. Tu bez pomocy Szczepana nic się nie uda wskórać.
Wyjątkowo toporne ale dlaczego nadal wyświetlacz blokuje nam ESP i automatycznie się resetuje ale chyba jednynie co nas ratuje to całkowite odcięcie ekranu aby wykrywało ESP jako inne bez ekranu.
esp32:
board: esp32dev # Zmiana z heltec... na czysty esp32dev
flash_size: 8MB
framework:
type: esp-idf
sdkconfig_options:
CONFIG_ESP_MAIN_TASK_STACK_SIZE: "8192"
CONFIG_ESP_TASK_WDT_TIMEOUT_S: "60"
CONFIG_LOG_DEFAULT_LEVEL_NONE: "y"
Tu daje ci cały poprawiony kod już sprawdziłem zobaczymy czy działa.
[EDIT] Odniosę się jescze do odpowiedzi @bodek85 ponieważ takie liczniki wysyłają bardzo długie ramki dnaych które wymagają intensywnego deszyfrowania trwają długo a zaktualizowany Task Watchdog resetuje odrazu procesor gdy deszyfrowanie trwa nawet o milisekundę za długo dlatego zwiększyłem teraz limit z 5s na 60s i to powinno poprawić.
I oczywiście postaram Ci się dalej pomagać jutro @kniazio.
Na koniec dodam jeszcze ze wczoraj robilismy z kolega identyczny modul i ja dalem mu swoj config. Jego modul sie nie restartuje ale on nie czyta jeszcze licznika energii bo nie ma jeszcze klucza. Czyta tylko wodę. Moze tu jest jakiś trop.
Podejrzewam ze jak zacznie czytac energie to zaczna sie schody
Ale przed aktualizacja esphome wszystko smigalo pieknie.
Co to sie porobilo?
Tak jak pisałem chodzi o to że starsze wersje ESPHome używały starszych kompilatorów i lżejszych wersji systemu operacyjnego. Było tam po prostu więcej luzu w pamięci RAM i mniej rygorystyczne limity czasu.
Po tych aktualizacjach platformy nie nadążają z deszyfrowaniem danych i je resetuje za przekroczenie limitu czasu bo watchdog myśli że się zapętliło. Dlatego w ostatnim poście dodałem w kodzie CONFIG_ESP_TASK_WDT_TIMEOUT_S: "60" który daje 60s czasu procesorowi który zdąży wszystko na spokojnie przeliczyć. Można także całkowicie wyłączyć watchdog ale jak naprawdę się coś zapętli to sam będziesz musiał resetować.
Jeśli chodzi o że czyta liczniki wody to jest przez to że jest mniej danych do deszyfrowania lub jest rama otwarta (czyli dane nie są zaszyfrowane). A liczniki energi wysyłają dużo danych i są te dane zaszyfrowane co zużywa zasoby i długo to trwa dlatego się resetuje.
Jutro spróbuj dać ten kod co jest w zaktualizowanym poście to powinno rozwiązać problem resetu.
Dobra jak aktualizacja nic nie pomogła i CONFIG_ESP_TASK_WDT_TIMEOUT_S: “60” też nie pomógł to spróbuj zmienić CONFIG_ESP_MAIN_TASK_STACK_SIZE: "8192" zamiast 8192 to zwiększymy ten limit dwa razy na 16384 bo tak krok po kroku dochodzimy do rozwiązania bo jeśli limit nic niedał to oznacza że jest przepełnieniestosu (Stack Overflow)
To jest błąd krytyczny (Kernel Panic) w bibliotekach szyfrujących. Nowe ESPHome (2026.1.x) używa nowszej wersji ESP-IDF i innych bibliotek mbedTLS. Komponent wmbus_meter w momencie inicjalizacji licznika Amiplus (który ma długi klucz i skomplikowany sterownik) próbuje zarezerwować pamięć, której w nowym systemie już nie ma lub która jest inaczej adresowana.
Możesz spróbować na ten moment zakomentować (wyłączyć) tylko licznik energii w YAML-u. Moduł powinien przestać się restartować i będzie stabilnie czytał wodę, dopóki Szczepan nie wypuści poprawki dla Amiplus pod nowe wersje ESPHome."
Ok. Bede sledzil temat. Jak bedziesz cos wiedzial o poprawkach szczepana to bardzo prosze daj mi znac.
Jeszcze raz wielkie dzieki za poswiecony czas.
Pozdrawiam
Musze rano wstac.