Jesteś pewny? Bo obserwuje /diag i własnie tam są tylko dropped i summary, niczego innego nie widzę.
Topic/diag:
Topic debug:
Mam nadzieję że teraz rozwiałem Twoje wątpliwości
Do topic diag trafia co odrzucił i z jakiego powodu oraz cykliczny podsumowanie.
Tu są bardziej szczegółowo podane błędy.
Do debug trafia to co jest prawidłowe oraz tylko info podsumowania.
Chyba wiem o co chodzi : aby RSSI było przekazywane a nie tylko samo dekodowanie.
Widzę
BTW GitHub - Kustonium/esphome-wmbus-bridge-rawonly: Bez kombajnu WMBUS · GitHub to Twoje repozytorium?
Tak - jest moje, stworzone na początku z repo Szczepana.
Przy czym “moje” to trochę nadużycie.
Kod stworzyło AI , logikę Ja podpowiadałem , testowałem .
Spoko.
A co z T2 / C2 / S2? Dałoby radę to wyłapywać? Wiem, że to rzadkie w eterze, ale jak u siebie zdejmę nakładkę to wodociągi odczytując stan kasują błędy, ustawiają m3 i być może ustawiają godzinę też, chętnie bym podejrzał jak wygląda taki T2, C2 lub S2 w szczególności dla moich liczników.
T2 jest bardzo rzadkie z tego co wiem , z początku był algorytm sygnalizacji i tylko sygnalizacji na zasadzie heurystyki ale to usunąłem.
Nigdy nie przewidywałem komunikacji dwustronnej a tylko i wyłącznie czytanie.
Mogę spróbować kazać AI dopisać aby pokazywał.
U mnie nie mam takich liczników więc nie mam jak testować.
Zresztą możesz sam pobrać repo, sklonować je i dopisać to czego potrzebujesz.
Gdyby nie AI Ja bym się za to nigdy nie zabrał - brak wiedzy.Spytałem AI
Sprawdzam kod — co jest zaimplementowane, a co nie:
Mam pełny obraz. Teraz rzetelna odpowiedź techniczna:
Co wpada, co nie, i dlaczego
T2 uplink (licznik → czytnik) — działa już teraz
T2 na warstwie fizycznej uplink jest identyczny z T1 — ta sama częstotliwość (868.95 MHz), to samo kodowanie 3-of-6, ten sam sync word. Kod w
packet.cpprozróżnia tryby tylko po pierwszym bajcie:if (this->data_[0] == 0x54) // C-preamble → C1 this->link_mode_ = LinkMode::C1; else this->link_mode_ = LinkMode::T1; // T1 i T2 wpadną tu tak samoRamka T2 uplink wyląduje u Ciebie jako
T1i zostanie poprawnie opublikowana. wmbusmeters ją zdekoduje — rozróżnienie T1 vs T2 jest w warstwie aplikacji (CI-field), nie fizycznej.C2 uplink (licznik → czytnik) — działa już teraz
Identycznie jak C1. Sync word 0x54/0x3D lub 0x54/0xCD, ta sama fizyka. C2 uplink wpadnie jako
C1.
S1/S2 — nie działa, inne radio
S-mode to zupełnie inne parametry fizyczne:
Parametr T/C mode (aktualny) S mode Częstotliwość 868.950 MHz 868.300 MHz Bitrate 100 kbps 32.768 kbps Fdev ~50 kHz ~38 kHz Sync word 0x54 0x3D/0xCD0x76 0x96Kodowanie 3-of-6 (T) / NRZ (C) Manchester
W SX1276 wszystkie te parametry są zahardkodowane w
transceiver_sx1276.cppna sztywno dla T/C. Żeby odebrać S-mode, trzeba by osobnej instancji radia lub przepinać parametry SPI — nietrywialny refaktoring.
Co Cię tak naprawdę interesuje: DOWNLINK
Kiedy wózkarz wchodzi z czytnikiem i odczytuje licznik, robi to komunikacją dwukierunkową. To co chcesz podejrzeć to właśnie downlink — to co czytnik wysyła do licznika (kasowanie błędów, ustawienie m3, synchronizacja czasu).
I tu jest problem:
Downlink T2/C2 używa innej częstotliwości i innego formatu:
Uplink (licznik→czytnik) Downlink (czytnik→licznik) T2 868.950 MHz 868.300 MHz C2 868.950 MHz 868.300 MHz
Twoje ESP słucha tylko 868.950 MHz. Downlinka nie złapiesz bez przeprogramowania radia na tę częstotliwość — a i tak byłbyś w stanie słuchać tylko w jednym kierunku naraz.
Dodatkowo: downlink jest aktywny przez ułamki sekund, w momencie gdy czytnik jest przy liczniku. Żeby to złapać, trzeba być dokładnie w tym miejscu i czasie.
Praktyczna rekomendacja
Jeśli chcesz podejrzeć pełną sesję T2/C2 przy swoim liczniku:
Uplink odpowiedzi licznika — złapiesz już teraz na 868.950 MHz. Podczas sesji odczytu licznik prawdopodobnie wyśle więcej ramek (z aktualnymi danymi po ustawieniu) i to wpadnie do MQTT.
Downlink od czytnika — tu potrzebujesz albo dedykowanego SDR (RTL-SDR + rtl-wmbus lub wmbusmeters z SDR) nastawionego na 868.300 MHz, albo drugiego ESP z radio nastawionym ręcznie na 868.300 MHz. To jednak wymagałoby rozszerzenia projektu o S-mode lub o konfigurowalną częstotliwość.
Najprościej — przy kolejnym odczycie miej otwarte logi MQTT i patrz co się pojawia. Odpowiedź uplink po zapisie powinna być widoczna i wmbusmeters pokaże zmienione wartości.
Pomysł ciekawy, ale to co wyłapiesz z eteru nic nie da (tryb T-2 jest zabezpieczony przed manipulacją licznikiem komend, więc nie możesz wysyłać własnych, a C-2 korzysta z kluczy generowanych dynamicznie, więc tu dodatkowo będzie w ogóle problem z odszyfrowaniem). Oczywiście mówię o teorii, próbować można, sama idea to niestety woda na młyn tych, którzy nie chcą użytkownikom udostępniać kluczy… (a nuż się komuś uda?)
Co do kluczy generowanych dynamicznie…
Klucz Master (K_master): Jest zaszyty w liczniku i znanytylko dostawcy.
Klucz Sesyjny (K_sess): Jest generowany tylko na czas jednej sesji z inkasentem. Nawet jeśli jakimś cudem zdobyłbyś klucz do jednej sesji, kolejna będzie używać innych wartości.
Najczęściej nie ma jednego klucza dla wszystkichl. Każdy licznik ma swój klucz pochodny wyliczany z jego numeru seryjnego i sekretu producenta.
W MBus klcz to jedno ale drugi składnik to licznik dostępu lub znacznik czasu.
W trybie C2 ramka zmienia się za każdym razem nawet jeśli treść komendy jest taka sama.
To zabezpieczenietzw. Przed tzw. Dictionary Attack (porównywanie ramek w poszukiwaniu wzorców).
A więc fajne wyzwanie, ale wykonywalne w sztucznych warunkach tzn. jak zrobisz sobie symulację z drugiego ESP. (Wtedy będziesz znał klucze bo sam je tam podasz
)
No to chyba chłopaki zaspokoili Twoją ciekawość całkowicie.
Z uwagi na to iż posiadam Sx1262 i Sx1272 , w kodzie jest dodana diagnostyka to zmieniałem ustawienia prędkości ESP 160/240 Mhz.
Logi i telegramy z diagnostyki wrzucałem do AI aby to zebrał do kupy i porównał.
Wpływ częstotliwości CPU (ESP32-S3) na jakość odbioru wM-Bus
Autor: Kustonium
Data: 2026-03-05
Sprzęt: Heltec WiFi LoRa 32 V4 (SX1262) + LILYGO T3-S3 (SX1276), ESP32-S3 rev0.2
Oprogramowanie: esphome-wmbus-bridge-rawonly, ESPHome 2026.2.4
Cel eksperymentu
Sprawdzenie czy częstotliwość CPU ESP32-S3 ma wpływ na jakość odbioru telegramów wM-Bus na częstotliwości 868 MHz.
Metodologia
Oba radia uruchomiono w identycznych warunkach (ta sama lokalizacja, ten sam eter, blok mieszkalny z dużą liczbą liczników wM-Bus) przy dwóch wartościach cpu_frequency: 240 MHz i 160 MHz.
Dane zbierano przez system diagnostyczny MQTT (diagnostic_summary) publikujący co 60 sekund statystyki odbioru, w tym:
drop_pct— procent odrzuconych rameksym_invalid_pct— procent nielegalnych symboli 3-of-6 (quasi-BER dla T1)crc_failed— liczba ramek które padły na CRC DLL mimo dobrego RSSIavg_ok_rssi/avg_drop_rssi— średni RSSI dla ramek odebranych i odrzuconychhint_code— automatyczna diagnoza systemu
Dodatkowo analizowano logi ESP pod kątem Failed to read data — fałszywych wyzwoleń IRQ radia które nie skutkują odebranym pakietem i nie trafiają do statystyk MQTT.
Wyniki
| Parametr | SX1262 @ 240 MHz | SX1262 @ 160 MHz | SX1276 @ 240 MHz | SX1276 @ 160 MHz |
|---|---|---|---|---|
| drop_pct | 12–25% | 8–16% | 0–20% | 8–20% |
| sym_invalid_pct | 0–7% | 0% | 0% | 0% |
| crc_failed | 1–2 per interwał | 0 | 0 | 0 |
| avg_ok vs avg_drop RSSI | identyczne (< 2 dBm) | logiczna różnica RF | logiczna różnica RF | logiczna różnica RF |
| C1 przy dobrym RSSI | pada na CRC (100%) | przechodzi | n/d | n/d |
| Ghost IRQ po pakiecie 143B | nie | nie | 3–5 per pakiet | brak |
| hint_code | C1_INTERFERENCE_OR_RX |
GOOD / OK |
OK / GOOD |
GOOD |
Różnice między chipami
Oba chipy reagują na 240 MHz, ale w odmienny sposób.
SX1276 manifestuje zakłócenia jako fałszywe wyzwolenia IRQ (Failed to read data) — klastry 3–5 ghost IRQ pojawiające się bezpośrednio po każdym dużym pakiecie (143 bajty). Pakiety które zostają odebrane są jednak poprawne — sym_invalid_pct pozostaje na 0%, a droppy mają logiczne wytłumaczenie RF. Na 160 MHz ghost IRQ znikają całkowicie.
SX1262 nigdy nie wykazywał Failed to read data. Jego reakcja na 240 MHz była inna — przekłamania bitów wewnątrz odebranych pakietów (sym_invalid_pct do 7%), błędy CRC DLL przy dobrym sygnale (-68 dBm) i konsekwentne padanie ramek C1. Na 160 MHz wszystkie te objawy znikają.
To samo źródło — EMI od CPU 240 MHz — dwa różne objawy wynikające z różnej architektury krzemu.
Wnioski
-
ESP32-S3 na 240 MHz generuje harmoniczne EMI które zakłócają odbiór na 868 MHz, szczególnie w przypadku SX1262.
-
Objawy różnią się w zależności od chipa. SX1276 reaguje fałszywymi wyzwoleniami IRQ (
Failed to read data) w klastrach po dużych pakietach — na 240 MHz 3–5 ghost IRQ po każdym pakiecie 143B, na 160 MHz zero. SX1262 nigdy nie wykazywał ghost IRQ — jego objawem były przekłamania bitów (sym_invalid_pctdo 7%) i błędy CRC przy dobrym sygnale. -
SX1262 jest bardziej wrażliwy na EMI niż SX1276. Na 240 MHz SX1262 wykazywał
sym_invalid_pctdo 7% (przekłamania bitów przy dobrym RSSI) oraz konsekwentne padanie ramek C1 na CRC DLL mimo sygnału -68 dBm. Na 160 MHz oba zjawiska zniknęły. -
Drop_pct zależy od eteru, nie od częstotliwości CPU. Po obniżeniu do 160 MHz ogólny poziom dropów pozostał podobny — ale zmieniła się ich natura: droppy na 160 MHz mają logiczne wytłumaczenie RF (
avg_drop_rssiwyraźnie niższe niżavg_ok_rssi), podczas gdy na 240 MHz pakiety padały przy dobrym sygnale. -
Domyślna wartość ESP32-S3 to 160 MHz — jest nie bez powodu. Jawne ustawienie
cpu_frequency: 240MHzw konfiguracji ESPHome, popularne w forumowych przykładach YAML, wprowadza problem który użytkownicy diagnozują błędnie np. jako słabą antenę, złe ustawienia radia lub problem z odległością od licznika.
Zalecenie
Dla zastosowań radio bridge wM-Bus na ESP32-S3:
esp32:
variant: esp32s3
cpu_frequency: 160MHz
Lub po prostu nie podawać cpu_frequency wcale — domyślne 160 MHz jest optymalne.
240 MHz nie przynosi żadnych mierzalnych korzyści dla tego zastosowania (odbiór RF + MQTT), natomiast wprowadza mierzalne pogorszenie jakości odbioru, szczególnie dla SX1262.
2 Likes
Obawiam się, że bezwarunkowa wiara w to co pisze Ci to AI to dość wątpliwa ścieżka. Harmoniczne od 160 i 240 są przecież identyczne co do częstotliwości, a jeśli to miałoby taki wpływ na odbiór czegokolwiek, to znaczy że hardware jest totalnie źle zaprojektowany.
2 Likes
Eksperyment przeprowadziłem Ja a nie AI.
Ja tylko wrzucałem logi aby AI poddał analizie bo nie mam wiedzy merytorycznej aby analizować to samemu.
Masz większą wiedze merytoryczną więc możesz przeprowadzić eksperyment również u siebie.
Przez chwilę zgadzałem się z @kubasa, ale…
( Jeszcze dodam: nie jestem specjalistą w tym temacie, a tylko się tym interesuje, a więc nie bierzcie tego że 100% pewnością)
Argument o kwarcu ma się nijak do praktyki na tanim PCB. Przy 240 MHz procesor ma ostrzejsze zbocza sygnałów i większe skoki prądu (di/dt). Na Heltecu czy Lilygo masa i zasilanie są wspólne – te śmieci idą prosto w tor RF.
To, że hardware jest źle zaprojektowany, to fakt – ale zmiana na 160 MHz to najprostszy fix, który poprawia zasięg. Zamiast teoretyzować o harmonicznych, sprawdźcie sym_invalid_pct
Jakby te płytki nie były robione na jakimś 2-4 warstwowym PCB z kiepskim ekranem, albo bez, tylko z 6 warstwowej płytki z pełnym ekranem to wtedy nawet jakbyś podkręcil na 400MHz zapewne byś miał takie same odbory
Ale i tak wydaje mi się że ta różnica jest trochę wyolbrzymiona
Czemu w takiej sytuacji zatrzymać się na 160Mhz? Można zjechać jeszcze dalej przecież.
Które zbocza sygnałów są bardziej ostre? Te wewnątrz krzemu ESPa?
SX1276 na 240 Mhz
[07:59:28.731][I][app:215]: ESPHome version 2026.2.4 compiled on 2026-03-05 07:34:51 +0100
[07:59:28.778][I][app:222]: ESP32 Chip: ESP32-S3 rev0.2, 2 core(s)
[07:59:30.886][I][wmbus:544]: Have data (77 bytes) [RSSI: -79dBm, mode: T1 A, mfr:BMT id:03528557 ver:23 type:6 ci:7A]
[07:59:35.493][W][wmbus:621][radio_recv]: Failed to read data
[07:59:36.273][I][wmbus:269]: DIAG summary published to wmbus/diag (total=11 ok=8 truncated=0 dropped=3 crc_failed=0)
[07:59:36.279][I][wmbus:277]: DIAG hint: OK | wygląda dobrze
[07:59:36.352][W][wmbus:621][radio_recv]: Failed to read data
[07:59:37.669][W][wmbus:621][radio_recv]: Failed to read data
[07:59:38.595][I][wmbus_user:536]: ★ Have data (143 bytes) [RSSI: -54dBm, mode: T1 A, mfr:NES id:00089907 ver:3 type:2 ci:7A]
[07:59:42.454][W][wmbus:621][radio_recv]: Failed to read data
[07:59:48.015][W][wmbus:621][radio_recv]: Failed to read data
[07:59:50.480][I][wmbus:544]: Have data (56 bytes) [RSSI: -82dBm, mode: T1 A, mfr:TCH id:90830781 ver:39 type:195 ci:A2]
[07:59:51.887][W][wmbus:621][radio_recv]: Failed to read data
[07:59:54.991][I][wmbus:544]: Have data (77 bytes) [RSSI: -88dBm, mode: T1 A, mfr:BMT id:03536903 ver:23 type:7 ci:7A]
[07:59:58.992][W][wmbus:621][radio_recv]: Failed to read data
[08:00:01.340][I][wmbus:544]: Have data (77 bytes) [RSSI: -62dBm, mode: T1 A, mfr:BMT id:03551587 ver:23 type:7 ci:7A]
[08:00:01.518][I][wmbus:544]: Have data (77 bytes) [RSSI: -82dBm, mode: T1 A, mfr:BMT id:03528249 ver:23 type:6 ci:7A]
[08:00:07.982][W][wmbus:621][radio_recv]: Failed to read data
[08:00:08.236][W][wmbus:621][radio_recv]: Failed to read data
[08:00:09.641][W][wmbus:621][radio_recv]: Failed to read data
jak zmieniłem na 160 to od ręki Failed to read data zniknęło.
W tej chwili kompiluje na 80 Mhz
Analiza 80 MHz vs 160 MHz — odpowiedź na pytanie “czemu nie niżej?”
Eksperyment rozszerzono o pomiary przy cpu_frequency: 80MHz. Zebrano 4 próbki diagnostic_summary na każdy chip.
SX1262 @ 80 MHz vs 160 MHz
| Próbka | drop_pct | hint_code |
|---|---|---|
| 1 | 5% | GOOD |
| 2 | 19% | C1_INTERFERENCE_OR_RX |
| 3 | 8% | GOOD |
| 4 | 4% | GOOD |
Trzy z czterech próbek wyglądają dobrze. Ale próbka 2 wykazuje identyczny objaw jak na 240 MHz — C1 pada na CRC DLL przy dobrym sygnale (-79 dBm). Zachowanie jest niestabilne i nieprzewidywalne. Dla systemu działającego bez nadzoru niestabilność jest gorsza niż konsekwentnie słabe wyniki — nie wiadomo kiedy problem wystąpi.
Na 160 MHz — żadnej próbki z C1_INTERFERENCE w całym okresie testów.
SX1276 @ 80 MHz vs 160 MHz
| Próbka | avg_ok_rssi | drop_pct | sym_invalid_pct |
|---|---|---|---|
| 1 | -98 dBm | 15% | 2% |
| 2 | -96 dBm | 14% | 0% |
| 3 | -99 dBm | 23% | 0% |
| 4 | -100 dBm | 20% | 1% |
Na 160 MHz avg_ok_rssi wynosił -79 dBm. Na 80 MHz konsekwentnie -96 do -100 dBm — utrata ~20 dBm czułości odbiornika we wszystkich czterech próbkach bez wyjątku.
To nie jest problem z eterem ani zakłóceniami — to timing. CPU na 80 MHz nie nadąża z obsługą SPI i IRQ w oknie wymaganym przez radio. SX1276 efektywnie ślepnie na mocniejsze pakiety i odbiera tylko to co nadaje w bezpośrednim sąsiedztwie.
AI po przetworzeniu logów:
Odpowiedź na pytanie “czemu zatrzymać się na 160 MHz?”
Bo 80 MHz jest gorsze dla obu chipów — z różnych powodów i w różny sposób. 160 MHz to jedyna wartość która daje stabilne i przewidywalne wyniki na SX1262 i SX1276 jednocześnie.
Dodam od siebie : 4 próbki to za mało wg mnie. Musiałbym pozbierać np z 20 minut wtedy było by to miarodajne.
Wcale nie wątpię że zniknęło, wcale nie wątpię że kompilujesz na 80MHz i wcale nie wątpię, że jak porządnie spromptujesz AI to się dowiesz co znaczy ten log który Cię tak bardzo boli. Ale na pewno nie jest on wynikiem tego że są zakłócenia na układzie radiowym.
Tak się akurat składa, że ten log napisałem tymi samymi rękami, które teraz piszą ten post. I nie wiem czy jest sens pisać dalej. Odpowiedzi z AI są proste i takie jak chcesz czytać: zmień jedną rzecz i będzie super.
Kurcze, czyli z pierwszego zdania wynika, że spadła czułość odbiornika. A z drugiego że spadek czułości wynika z tego że za wolno idzie obsługa przerwań?
Wiele osób nadal nie korzysta codzień z modeli językowych i nie jest to czasem łatwe do wychwycenia. Dobrze, że piszesz które części Twoich postów są copy&paste z AI, bo część osób która to czyta może na chwilę się zatrzyma.
Ale obawiam się po prostu do czego my to forum doprowadzimy: ze sposobu w który pisze AI wprost wynika, że zidentyfikowaliśmy problemy, wiemy jak je naprawić i ogólnie jest super. A prawda jest taka, że czasem są to halucynacje wprowadzające informacyjny szum. I ze źródła jako takiej wiedzy zrobimy zrzutowisko ogromnej ilości tekstu, czasem wzajemnie ze sobą sprzecznego.
A że AI crawluje internet i się z niego uczy to w końcu zamażemy źródła rzetelnej informacji, bo zacznie się uczyć sama na swoich odpowiedziach 
2 Likes
Od 2 dni używam Claude bo ChatGPT zaczął mnie wkurzać.
W 99 % kod repo stworzył ten drugi , na Claude poszła końcówka plus zmianą opisu repo na podstawie zawartości, ale mogę się mylić.
Przyznaje Ci racje bo sam to nie raz zauważyłem że model językowy jakby dopasowuje się do piszącego.
Dlatego jak piszę to pisze kiedy AI a kiedy to Ja aby nie wprowadzać w błąd.
Sam zauważyłem tylko po logu że na 80 Mhz SX1276 RSSI poleciało.
Teraz na 160 Mhz:
[10:41:09.613][I][wmbus:544]: Have data (48 bytes) [RSSI: -88dBm, mode: T1 A, mfr:TCH id:41467340 ver:116 type:114 ci:A2]
[10:41:10.919][I][wmbus:544]: Have data (77 bytes) [RSSI: -73dBm, mode: T1 A, mfr:BMT id:03528499 ver:23 type:6 ci:7A]
[10:41:17.844][I][wmbus:544]: Have data (77 bytes) [RSSI: -78dBm, mode: T1 A, mfr:BMT id:03575707 ver:23 type:6 ci:7A]
[10:41:20.216][I][wmbus:544]: Have data (77 bytes) [RSSI: -87dBm, mode: T1 A, mfr:BMT id:03534281 ver:23 type:7 ci:7A]
[10:41:20.591][I][wmbus:544]: Have data (77 bytes) [RSSI: -88dBm, mode: T1 A, mfr:BMT id:03528561 ver:23 type:6 ci:7A]
Claude przyznał się do błędu interpretacyjnego : Ale dlaczego tak się dzieje — tego nie wiem i nie powinienem był pisać pewnie.
RSSI:
AI napisało że spadła czułość, bo CPU nie nadąża. To bzdura. RSSI jest mierzone przez chip radiowy (LNA/RSSI detector) zanim danew ogóle trafią do ESP. Procesor może być nawet wyłączony, a radio i tak zmierzy RSSI poprawnie.
Jeśli na 80 MHz widzisz tylko pakiety -90 dBm, a zniknęły e -60 to znaczy, że albo masz gigantyczny błąd statystyczny (za mało próbekK), albo…
Bardziej prawdopodobne: Przy 80 MHz zmienia się taktowanie szyny APB z której bierze zegar sterownik SPI. Jeśli biblioteka nie przeliczyła poprawnie dzielników, to komuniacja z radiem jest rozjechana. Radio odbiera pakiet, ale ESP odczytuje z niego śmieci (w tym błędne RSSI z rejestru)
“Failed to read data”
Skoro autor kodu napisał, to ten log oznacza: Radio zgłosiło przerwanie (IRQ), że ma dane, ale kiedy ESP poszło je odebrać przez SPI, w buforze FIFO nic nie było (albo status był błędny).
Przy 240KMHz: Skok poboru prądu (di/dt) przy wybudzeniu przerwania generuje szpilkę, która “popycha” linię przerwania (false positive). SP próbuje czytać, radio mówi “ja nic nie mam”.
Przy 160 MHz: System jest stabilniejszy elektrycznie, fałszywe przerwania znikają
Ta, te wewnątrz krzemu.Wyższe taktowanie wymusza mniejsze czasy narastania sygnałów cyfrowych. Im ostrzejsze zbocze tym szersze pektrum zakłóceń generuje każda ścieżka na PCB (działa jak antena). Na 2warstwowym PCB to jest zabójstwo dla RF.
z którąś wersją twojego komponentu nie odczytuje liczników IZAR, a na wcześniejszych na pewno działało.
[11:29:12] INFO: Starting core bridge...
[wmbus-bridge] core: bridge.sh (base=/data)
[wmbus-bridge] MQTT: core-mosquitto:1883 topic=wmbus_bridge/telegram
[wmbus-bridge] state: prefix=wmbusmeters retain=false
[wmbus-bridge] discovery: enabled=true prefix=homeassistant retain=true
[wmbus-bridge] wmbusmeters: loglevel=verbose filter_hex_only=true debug_every_n=0
[wmbus-bridge] robust: ignore_retained=true require_timestamp=false restart_on_exit=true
[wmbus-bridge][WARN] Invalid meter_id for 'Licznik Izar' -> skipping (got: '215f1155')
[wmbus-bridge] Starting wmbusmeters...
(wmbusmeters) using log file /dev/stdout
(wmbusmeters) version: 2.0.0-4-gf77eaec
(config) using device: stdin:hextty:any
(config) number of meters: 0
Started config hextty on stdin listening on any
(serial) override with devicefile: stdin
(hextty) on stdin
(serialfile) reading from stdin (override stdin)
(main) regular reset of hextty on stdin will happen every 82800 seconds
No meters configured. Printing id:s of all telegrams heard!
(telegram) DLL L=6e C=44 (from meter SND_NR) M=0601 (APA) A=01151836 VER=05 TYPE=07 (Water meter) (driver apator162) DEV= RSSI=0
(telegram) TPL CI=7a ACC=df STS=00 CFG=8560 (bidirectional AES_CBC_IV nb=6 cntn=0 ra=0 hc=0)
Received telegram from: 01151836
manufacturer: (APA) Apator, Poland (0x601)
type: Water meter (0x07) encrypted
ver: 0x05
driver: apator162
(wmbus) telegram from TODO ignored by all configured meters!