Alternatywa: “odchudzony” komponent ESPHome (wM-BUS) – tylko RF→MQTT, dekodowanie poza ESP ( HA )

Urządzenia ESPHome
, , , ,
84

Hmm, moim skromnym zdaniem to rozwiązanie mogłoby uratować inwestycję intela od Wrocławiem, ale jakoś tak mi pachnie niezgodnością z prawami fizyki…

85

[WARN] Invalid meter_id for ‘Licznik Izar’ → skipping (got: ‘215f1155’)

Zwróć uwage na ten zapis w logu

86

Tak wiem, ID Jest prawidłowy. Przynajmniej na takim kiedyś dział. W trybie słuchania żadnego izara nie wykrywa. PS licznik na pewno sprawny.

87

Odkręć wodę, cokolwiek. Ja nie wróże z fusów. To jest tak zrobione abyś Ty widział co wpada do radia.

88

serio z tą wodą? licznik bez odkręcania wody wypluwa ramki i to co 8 sekund. A po którejś aktualizacji przestał. Da się cofnąć jakoś do starszej wersji komonentu?

89

Tu nie ma starszej wersji. ESP to tylko radio. Wmbusmerers wersja 1.20 ale pewności nie mam . Styczniowa lub lutowa.
Wklej log co pokazuje wmbusmeters lub wklej do ESP dodatkowe pola aby Ci wytłuścił Twój licznik w logu.

 highlight_meters:
    - "12345678"
    # - "12345678"           # możesz dodać więcej / add more as needed
  highlight_ansi: true        # domyślnie: false / default: false
  highlight_tag: "wmbus_user" # domyślnie: "wmbus_user" / default: "wmbus_user"
  highlight_prefix: "★ "      # domyślnie: "★ " / default: "★ "
90

image
image1916×1089 192 KB

Wróciłem do tematu pomiaru bo już mam gdzie to wrzucać.
Na razie wersja “na brudno” czyli sam SX1276 - na czas pomiaru wrzucę SX1262 i 1276 aby jednocześnie nadawały do tej samej bazy plus dłuższy czas pomiaru.

Ok. Zrobione:

image
image1471×812 146 KB

image
image1479×600 89 KB

image
image1512×801 100 KB

Wstępne wnioski AI :
SX1262 (Heltec) vs SX1276 (LilyGO) — benchmark wMBus T1/C1, te same liczniki, ten sam czas, to samo miejsce:

Odbiór ramek

  • Heltec total mean 29.4 vs LilyGO 24.7 — SX1262 odbiera +19% więcej ramek

  • Dominuje T1, C1 marginalny w obu przypadkach

Drop rate

  • Heltec 8.83% vs LilyGO 13.8% — SX1262 gubi ~37% mniej ramek

RSSI

  • T1-OK: Heltec ~-72 dBm, LilyGO ~-72 dBm — identyczny poziom sygnału OK

  • Drop RSSI: ~-85 dBm na obu — granica czułości podobna, ale SX1262 skuteczniej dekoduje ramki na tej granicy

Przyczyny dropów

  • Dominuje decode_failed — Heltec 2.72 vs LilyGO 3.36

  • dll_crc praktycznie zero na obu — brak zakłóceń RF

  • too_short i unk_mode = 0 — środowisko RF czyste

Wniosek SX1262 ma realnie lepszą czułość demodulacji przy identycznym poziomie sygnału. Różnica nie jest w RSSI progu — obie płytki “widzą” ramki na tym samym poziomie — ale SX1262 skuteczniej je dekoduje. Przekłada się to bezpośrednio na ~37% niższy drop rate i ~19% więcej odebranych danych.

1 polubienie
91

Komentarz od AI :
Przeprowadziłem benchmark SX1262 (Heltec WiFi LoRa 32 V4) vs SX1276 (LilyGO T3-S3) równolegle przez 1 godzinę per konfigurację — obie płytki 0,5m od siebie, ten sam zasilacz 230V, ta sama instancja wmbusmeters, te same liczniki w zasięgu.

Diagnostyka działa przez własny komponent ESPHome który co 120s publikuje statystyki per tryb (T1/C1): total, ok, dropped, decode_failed, dll_crc, RSSI ok/drop, sym_invalid_pct. Dane lądują w InfluxDB i Grafanie.

Wyniki @ 160MHz (1h pomiar):

  • SX1262 drop_pct: 8.83%, SX1276: 13.8% → SX1262 gubi 37% mniej ramek

  • decode_failed: SX1262 2.72, SX1276 3.36

  • Total ramek/interwał: SX1262 29.4, SX1276 24.7 (+19%)

Wyniki @ 80MHz (1h pomiar, zmiana CPU w locie):

  • SX1262 drop_pct: 9.33% — praktycznie bez zmian

  • SX1276 drop_pct: 22.8% — wzrost o 10pp

  • SX1276 decode_failed: 5.67 (+69% względem 160MHz)

  • SX1276 sym_invalid_pct: 1.62% (przy 160MHz było ~0.14%)

  • SX1276 RSSI OK: -95.5 dBm przy 80MHz vs -72.7 dBm przy 160MHz — utrata ~23 dBm czułości

SX1262 @ 80MHz RSSI: -80.2 dBm — bez zmian względem 160MHz.

Wniosek: SX1262 jest odporny na EMI z CPU. SX1276 przy 80MHz traci 23 dBm czułości — mechanizm: CPU → zakłócenia → błędy dekodowania symboli 3of6 → decode_failed +69% → drop_pct x1.65. SX1262 tego łańcucha nie wykazuje przy żadnej częstotliwości CPU.

Rekomendacja: SX1262 + 160MHz. Przy SX1276 minimum 160MHz.

92

Nie do końca mi się wierzyć chce, że jedenasta harmoniczna 80MHz (880MHz) ma tu realny wpływ, ale nie da się tego wykluczyć… (najbliższe do pasma 868MHz harmoniczne dla 160MHz, czyli piąta i szósta wypadają odpowiednio na 800MHz i 960MHz, czyli znacznie dalej, ale z drugiej strony dalekie od częstotliwości podstawowej harmoniczne jak jedenasta mają zwykle już naprawdę bardzo niską gęstość energii).

93

Ja niestety nie mam wiedzy. Jest tylko pomiar który pokazuje że na 80 Mhz SX1276 zaczyna więcej dropować. Tu by się musiał wypowiedzieć ktoś kto ma wiedzę radiową.
Starałem się aby test był rzetelny czyli nie 5 minut a pełna godzina.
Jutro puszcze na 240 Mhz bo zaraz będziesz cisza u mnie w eterze.

94

Celowo kazałem ten sam problem rozstrzygnąć ale nie Claude tylko ChatGPT ver 5.4 rozszerzone myślenie. Doszedł do innych wniosków ( w skrócie ):

Najbardziej prawdopodobna teoria:

SX1276 przegrywa nie dlatego, że „gorzej słyszy”, tylko dlatego, że jego ścieżka odbioru wymaga znacznie szybszej i bardziej deterministycznej obsługi przez MCU.

Przy 80 MHz:

  • task odbiorczy ma mniej czasu,

  • SPI dalej jest na stałe DATA_RATE_2MHZ,

  • FIFO SX1276 trzeba opróżniać na bieżąco,

  • każda zwłoka = większe ryzyko poszatkowania ramek i błędów symboli.

A SX1262 tego problemu nie ma w takim stopniu, bo odbiór jest dużo bardziej zbuforowany.

95

Zgadzam się z @szopen że 11. harmoniczna powinna być słaba, ale w elektronice cyfrowej rzadko problemem jest czysta harmoniczna, a raczej problemem jest alasing szumu i praca wewnętrznych stabilizatorów.

Przy 80mHz oszczędzanie energii w ESP może przełączać wewnętrzną przetwornicę w tryb PFM lub obniżać częstotliwość kluczowania co generuje szum w pasmach, które przeciekają do radia przez masę lub linie zasilania.
Przy 80 MHz taktowanie szyny APB (z ktrej wynika taktowanie SPI) się zmienia. Jeśli sterownik radia w ESPHome nie skoryguje timingów, komunikacja z radiem może być na granicy błędu co system raportuje jak niską czułość (błędy w odczycie rejestrów statusu).

To jest dobre wyjaśnienie.

96

Dlatego napisałem w skrócie bo o napisał tego więcej wraz z opisaniem pracy obu układów ( jak one czytają ) a różnice są.

97

Mały update z mojej strony odnośnie SX1276.

Przegadałem wczoraj temat z Claude i ChatGPT, po czym kazałem rozebrać na części obecną obsługę SX1276 i finalnie skończyło się to przepisaniem warstwy odbioru / drivera SX1276 pod realne zachowanie FIFO, a nie dotychczasowe „czytaj bajt po bajcie i licz, że MCU nadąży”.

W skrócie, stara wersja działała, ale była dość toporna:

  • FIFO było obsługiwane praktycznie 1 bajt = 1 transakcja SPI,

  • przy większym ruchu w eterze sporo wydajności ginęło nie na RF, tylko na samym sofcie,

  • SX1276 zostawiał przez to osiągi na stole.

Nowa wersja robi to sensowniej:

  • burst read z FIFO, gdy radio zgłasza FifoLevel,

  • końcówka ramki domykana ostrożnie bajt po bajcie,

  • poprawione domknięcie taila,

  • poprawione raportowanie RSSI, żeby nie było brane „po fakcie”, tylko na początku ramki.

Efekt praktyczny z testów równoległych z Helteciem SX1262:

Przed zmianą

LilyGo SX1276 brał mniej więcej:

  • ~52% tego, co łapał Heltec

  • total: 2.52

  • ok: 2.12

Po zmianie

LilyGo SX1276 doszedł do:

  • ~72% tego, co łapie Heltec

  • total: 18.7

  • ok: 15.8

Czyli po ludzku:
nie poprawiłem czułości radia ani anteny, tylko sprawiłem, że software mniej marnuje to, co radio już odebrało.

Najważniejszy wniosek jest taki, że poprawka nie zrobiła z SX1276 magicznie SX1262, ale wyraźnie zmniejszyła dystans między nimi i poprawiła zachowanie przy większym ruchu w eterze.

Do tego RSSI zaczęło w końcu wyglądać sensownie:

  • bliskie liczniki raportują mocny sygnał,

  • dalsze wyraźnie słabszy,

  • bez wcześniejszych odczytów „z kosmosu”.

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

Pokazuje to jako ciekawostkę bo tego normalnie nie widać :

image
image1588×894 154 KB

Czyli u mnie w 10-o piętrowcu liczniki somsiadów milkną około godz. 20 , “pobudka” jest o 6 rano.

99

Ja wiem że tego nikt nie czyta a nawet nie używa.
Dorobiłem szerszą diagnostykę a nie suche info.
Mnie spamu w MQTT ( opcje w kodzie YAML ) , tylko samo summary :slight_smile:

{
  "event": "summary",
  "total": 32,
  "ok": 25,
  "dropped": 7,
  "truncated": 0,
  "drop_pct": 21,
  "crc_failed": 0,
  "avg_ok_rssi": -80,
  "avg_drop_rssi": -81,
  "t1": {
    "total": 31,
    "ok": 24,
    "dropped": 7,
    "per_pct": 22,
    "sym_total": 5780,
    "sym_invalid": 13,
    "sym_invalid_pct": 0
  },
  "c1": {
    "total": 1,
    "ok": 1,
    "dropped": 0
  },
  "dropped_by_reason": {
    "decode_failed": 7
  },
  "dropped_by_stage": {
    "t1_decode3of6": 7
  },
  "rx_path": {
    "payload_size_unknown": 11
  },
  "hint_code": "OK",
  "hint_pl": "wygląda dobrze"
}
  • total — wszystkie ramki widziane w oknie pomiarowym
  • ok — ramki poprawnie zdekodowane
  • dropped — ramki odrzucone przez parser / pipeline
  • truncated — ramki ucięte
  • drop_pct — procent odrzuconych ramek
  • avg_ok_rssi / avg_drop_rssi — średni RSSI dla ramek poprawnych i odrzuconych

Sekcje trybów

  • t1 — statystyki dla ramek T1
  • c1 — statystyki dla ramek C1

T1 — pola dodatkowe

  • sym_total — liczba symboli 3-of-6 przeanalizowanych w oknie
  • sym_invalid — liczba symboli błędnych
  • sym_invalid_pct — udział błędnych symboli

Diagnostyka przyczyn

  • dropped_by_reason.decode_failed — ramki odrzucone przez błąd dekodowania
  • dropped_by_stage.t1_decode3of6 — etap, na którym najczęściej padły ramki

Ścieżka RX

  • rx_path.payload_size_unknown — przypadki, gdy radio zgłosiło ramkę, ale nie udało się ustalić poprawnej długości payloadu

Hint

  • hint_code / hint_pl — szybka interpretacja całości, ale to nadal tylko skrót nad twardymi liczbami

Krótsza wersja opisu pod JSON

W tym oknie odebrano 32 ramki, z czego 25 poprawnie i 7 odrzucono. Wszystkie dropy dotyczą T1 i padły na etapie t1_decode3of6, czyli podczas dekodowania symboli 3-of-6. Brak błędów CRC i brak ramek uciętych. RSSI ramek poprawnych i odrzuconych jest zbliżony, więc sam poziom sygnału nie tłumaczy całości problemu.

100

Wczoraj poprawiłem głównie parser: doszedł fallback T1/C1, łagodniejszy precheck i lepsza diagnostyka etapów odrzutu. Dzięki temu mniej ramek odpada zbyt wcześnie i łatwiej odróżnić problem parsera od problemu radiowego.

Na nowym kodzie , przy małym ruchu radiowym (21:30–6:00) platforma z SX1262 wypada wyraźnie lepiej: widzi ok. 63% więcej ramek i dowozi ok. 65% więcej poprawnych telegramów niż SX1276, przy bardzo podobnej skuteczności procentowej. Z kolei przy większym ruchu oba odbiorniki widzą podobny wolumen ramek, ale SX1262 mniej traci. W praktyce u mnie zestaw z SX1262 wypada lepiej zarówno przy małym, jak i dużym obciążeniu eteru.

Nie znaczy to że układ SX1262 jako Heltec V4 jest lepszy od Lilygo T3S3 - byłbym ostrożny ze stawianiem takiej tezy.

Edit :
Od 6:00 do 18:30 oba odbiorniki widziały praktycznie tyle samo ruchu (total ~29.8), ale Heltec/SX1262 utrzymał wyższą skuteczność (~88.6% vs ~85.2%) i niższy drop rate (~11.6% vs ~14.8%), więc w moim środowisku wypada lepiej końcowo niż Lilygo/SX1276.

101

Wiem że OFF topic.
Zakończyłem prace na komponentami , suma summarum zajęło mi to 26 dni dzięki pomocy AI - dalsze losy zależą już od społeczności - na dzień dzisiejszy u mnie działa tak jak to założyłem.

1 polubienie
102

Mój egzotyk jednak się przydaje.
Powstała wersja 1.0.1 po stronie ESP.
Komponent słucha albo T1 albo C1 albo obu naraz.

103

Dobra robota!
Śmiga bez problemu na XIAO nRF52840 i LoRa Wio-SX1262

z taka konfiguracją pinów:

spi:

  clk_pin: GPIO7 

  mosi_pin: GPIO9 

  miso_pin: GPIO8 


wmbus_radio:

  radio_type: SX1262

  cs_pin: GPIO41

  reset_pin: GPIO42

  irq_pin: 

    number: GPIO39

    mode: input

  busy_pin: GPIO40

  has_tcxo: true

  rx_gain: boosted

  long_gfsk_packets: true

Macie jakąś sprawdzoną antene?