Komponent wM-Bus do ESPHome wersja 5.x - wątek ogólny

Urządzenia ESPHome
, , ,
274

Słuchajcie, po wielu testach i analizie tego co się dzieje pod maską ESP32 udało mi się przygotować finalną poprawkę.

Oryginalny kod przy ramkach Amiplus powodował tzw. Stack Overflow (przepełnienie stosu). Moja pierwsza próba z dynamicznym wektorem naprawiła dane, ale gryzła się z procesami WiFi w esp-idf, co kończyło się restartem przez Watchdoga (system nie wyrabiał z zarządzaniem pamięcią w locie).

Przerobiłem funkcje deszyfrujące tak, aby używały statycznych wektorów z recyklingiem pamięci.

  • Bezpieczeństwo: Dane nie lądują na małym stosie (koniec z wywalaniem systemu przy dużych ramkach).
  • Wydajność: Pamięć jest rezerwowana raz i używana ponownie. Procesor nie traci czasu na alokację przy każdym odczycie więc WiFi i reszta systemu powinny działać płynnie.

Zapraszam do testów.

Wystarczy zmienić źródło komponentów w YAML na moje repo:

external_components:
  - source:
      type: git
      url: https://github.com/AllonGit/esphome-components
      ref: main
    components: [wmbus_common, wmbus_radio, wmbus_meter]
    refresh: 0s`

Zalecam też dla pewności te wpisy w sekcji esp32:

esp32:
  board: Twoja_plytka
  framework:
    type: esp-idf
    sdkconfig_options:
      CONFIG_ESP_MAIN_TASK_STACK_SIZE: "16384"
      CONFIG_ESP_TASK_WDT_TIMEOUT_S: "60"

Zapraszam do testów dajcie znać, czy u Was też ta poprawka rozwiązały problem restartów. Jeśli u wszystkich będzie OK wyślę Pull Request do Szczepana.

275

Do pierwszego restartu wytrzymał 6 min 41 sek
Zrobiony CleanBuild

276

A czy masz jakieś logi?

277

Nie mam bo mam ustawione:

esp32:
  board: heltec_wifi_lora_32_V2
  framework:
    type: esp-idf
    sdkconfig_options:
      CONFIG_ESP_MAIN_TASK_STACK_SIZE: "16384"
      CONFIG_ESP_TASK_WDT_TIMEOUT_S: "60"
      CONFIG_LOG_DEFAULT_LEVEL_NONE: "y"

Zakomentuje to i skompiluje jeszcze raz

278

To jest cały kod? Musmy przywrócić logi
Przywrócenie możliwości logowania w esp32:

esp32:
  board: heltec_wifi_lora_32_V2
  framework:
    type: esp-idf
    sdkconfig_options:
      CONFIG_ESP_MAIN_TASK_STACK_SIZE: "16384"
      CONFIG_ESP_TASK_WDT_TIMEOUT_S: "120"
      CONFIG_LOG_DEFAULT_LEVEL_INFO: "y"

Ustawienie selektywnego logowania w logger:

logger:
  level: INFO
  baud_rate: 115200
  logs:
    esp-idf.wifi: NONE
    wmbus: DEBUG

Proszę ustaw tak jak wysłałem i wtedy sprawdzimy logi i zobaczymy co jest dokładnie nie tak i od tej strony to podejdziemy.

279

logger powoduje bledy

Failed config

logger: [source /config/esphome/wmbus-lora.yaml:27]
  level: INFO
  baud_rate: 115200
  logs: 
    esp-idf.wifi: NONE
    
    The configured log level for wmbus (DEBUG) must not be less severe than the global log level (INFO).
    wmbus: DEBUG
280

Sorki, mój błąd w logice ESPHome. Musimy ustawić globalny poziom na DEBUG, żeby system w ogóle pozwolił na wyświetlanie szczegółów z wM-Bus, a resztę komponentów wyciszyć ręcznie do INFO lub NONE.

logger:
  level: DEBUG 
  baud_rate: 115200
  logs:
    esp32: INFO
    esp-idf.wifi: NONE
    component: INFO
    api: INFO
    sensor: INFO
    wmbus: DEBUG

Wrzuć ten poprawiony blok logger. Dzięki temu zobaczymy dokładnie moment deszyfrowania ramki tuż przed restartem, ale WiFi nie będzie śmiecić w logach. Te 6 minut i 41 sekund to bardzo powtarzalny wynik – to sugeruje, że system ‘puchnie’ do pewnego momentu i musimy zobaczyć co to za moment.

281

Tylko ze jak tylko uruchomimy jakiekolwiek logi to nie czyta licznika energii

obraz
obraz1366×768 92.3 KB

I restarty sa co kilkadziescia sekund

282

Biorąc pod uwagę logi przygotowałem konkretną listę zmian które powinieneś wprowadzić w pliku konfiguracyjnym, aby ustabilizować urządzenie.

Głównym problemem jest to, że ESP32 “dusi się” bardzo słabe WiFi (-85 dBm) dodatkow ciężkąa obróbka ramek radiowych i odświeżaniem wyświetlacza powoduje restarty połączenia API.

Optymalizacja Loggera

Obecnie masz poziom DEBUG, który zalewa procesor tekstem. Zmień go na INFO, ale zostaw tryb debugowania tylko dla samego komponentu wmbus, jeśli nadal chcesz widzieć odczyty:

logger:
  level: INFO
  logs:
    wmbus: DEBUG

Ratowanie WiFi

Sygnał -85 dBm to strefa śmierci. Jeśli nie możesz przenieść urządzenia spróbuj dodać te parametry, aby połączenie było mniej agresywnie zrywane:

wifi:
  # Twoje SSID i Password 
  output_power: 20dBm
  fast_connect: true
  reboot_timeout: 15min

Odciążenie procesora (Wyświetlacz)

Wyświetlacz zajmuje procesorowi aż 252 ms. Zwiększ interwał aktualizacji, aby dać czas radiu i WiFi:

display:
  - platform: ssd1306_i2c
    id: my_display
    update_interval: 5s # Zmień z 1s na 5s lub więcej
    # reszta konfiguracji

Sprawdzenie Drivera

W logach pojawia się komunikat (driver unknown!) dla licznika energii, mimo że ramka jest deszyfrowana. Może to oznaczać, że musisz doprecyzować konfigurację sensora, aby dane “wskoczyły” na swoje miejsce. Sprawdź, czy Twoja sekcja wmbus wygląda podobnie do tej:

sensor:
  - platform: wmbus
    meter_id: 0x31584572
    type: amiplus
    key: "59054358010009128400000000000000"
    total_energy_consumption_kwh:
      name: "Suma konsumpcji"

Co się dzieje w logach:

Twoje urządzenie odbiera dane poprawnie (widzę decrypted "2F2F066D..."), co oznacza, że klucz AES i ID licznika są poprawne. Jednak zaraz po udanym odkodowaniu następuje: INFO Processing unexpected disconnect from ESPHome API Dzieje się tak, bo procesor był tak zajęty mieleniem ramki i rysowaniem po ekranie, że “zapomniał” odpowiedzieć do Home Assistanta, a ten uznał go za martwego.

283

loger znowu daje blad

Failed config

logger: [source /config/esphome/wmbus-lora.yaml:27]
  level: INFO
  logs: 
    
    The configured log level for wmbus (DEBUG) must not be less severe than the global log level (INFO).
    wmbus: DEBUG
284

wyłączymy całkowicie loger bo więcej z nim problemów:

logger:
  level: NONE
  baud_rate: 0

I zobaczymy co będzie dalej.
Jak narazie nie mam więcej pomysłów.

285

To jest jakas wariacja. Wszystko dzialalo do momentu aktualizacji Esphome. To zamiast udoskonalac to psuja?

286

To co kiedyś “jakoś działało” na granicy wydajności po aktualizacji może zacząć przekraczać krytyczne 30 ms (tzw. task watchdog). Nie tyle “psują”, co sprawiaj, że system staje się mniej tolerancyjny dla konfiguracji które mocno obciazają sprzęt .

Z każdą aktualizacją ESPHome dochodzą nowe funkcje lepsza obsługa standardów i bardziej rozbudowane biblioteki (np. nowsze wersje frameworka Arduino lub ESP-IDF) co stawia wyższe wymagania procesorowi.

287

A ja mam wrażenie że to tylko u mnie są problemy. Nikt nie odzywa się w temacie więc domniemam że u innych wszystko działa jak należy.

288

Ja bym zaczął od wywalenia zasobożernego web serwer.

289

Ależ właśnie mi najbardziej na nim zależy :slight_smile:

290

Ale przynajmniej maiłabyś pewność, że chodzi o zasoby.

291

Tu właśnie tylko i wyłącznie o zasoby chodzi. To jest najgorsza konfiguracja jaką kiedykolwiek robiłem🙈

292

Ja bym odchudził YAML do minimum ale jak zależy ci na Web Server to trzeba ograniczać wszystko po kolei z moją poprawką do kodu:

#Logger na absolutne zero 
logger:
  level: NONE
  baud_rate: 0

#Optymalizacja Web Serwera
web_server:
  port: 80
  local: true  # Pobiera zasoby z pamięci urządzenia, nie z internetu

#odciążenie wyświetlacza
display:
  - platform: ssd1306_i2c
    id: my_display
    update_interval: 20s # Zamiast co 1s odświeża co 20s.

# Stabilizacja przy słabym sygnal
wifi:
  # Twoje SSID i Password 
  power_save_mode: NONE
  output_power: 20dBm
  fast_connect: true
  reboot_timeout: 0s # Zakaz restartu, gdy WiFi chwilowo zniknie

api:
  reboot_timeout: 0s # Zakaz restartu przy rozłączeniu z HA

To powinno odciążyć ESP.

293

Jak narazie to juz po wylaczeniu logera obydwa moduly dzialaja ok pol godziny

Panowie. Minęła godzina i moduły działają bez restartu.
Testujemy dalej