Zakupiłem na ali taką antene. Ta dołączona do xiaoseed raz na jakiś czas miała problem z odbiorem ramek.
Wersja 3dbi
Dwa tygodnie już śmiga bez zająkniecia.
2 Likes
Ponieważ nie mam GAM-y i jej ramki o długości 326 bajtów RAW, musiałem taki przypadek odtworzyć sztucznie w eterze.
Kuriozalnie, gotowe moduły SX1262/LoRa świetnie nadają się do odbioru takich ramek, ale kiepsko nadają się do ich generowania jako testowy nadajnik wM-Bus T1. Normalna ścieżka TX GFSK kończy się praktycznie na granicy 255 bajtów, a właściwy tryb long-packet TX wymaga DIO2/DIO3, które na takich płytkach są zwykle zajęte przez RF switch/TCXO.
Dlatego testowo użyłem starszego SX1276 w FSK Direct Mode, który paradoksalnie świetnie się do tego nadał i wysłał poprawną syntetyczną ramkę T1 A odpowiadającą 326 bajtom RAW.
Układ testowy:
- TX: LilyGO T3-S3 / SX1276 w trybie FSK Direct Mode
- RX: odbiornik SX1262 z włączonym long_gfsk_packets
- Tryb: wM-Bus T1 A
- Częstotliwość: 868.950 MHz
- Bitrate: 100 kbps
- Odchyłka częstotliwości: 50 kHz
- Sync: 0x54 0x3D
- Producent testowy: TST
- ID testowe: 12345678
Logi ESP : ( po przetworzeniu )
L_FIELD=40:
[20:37:16.240][I][wmbus_user:2457]: ★ Have data / odebrano dane (41 bytes) [RSSI: -107dBm, mode: T1 A, mfr:TST id:12345678 ver:255 type:0 ci:7A]
L_FIELD=149:
[20:38:46.986][I][wmbus_user:2457]: ★ Have data / odebrano dane (150 bytes) [RSSI: -106dBm, mode: T1 A, mfr:TST id:12345678 ver:255 type:0 ci:7A]
L_FIELD=150:
[20:40:06.599][I][wmbus_user:2457]: ★ Have data / odebrano dane (151 bytes) [RSSI: -106dBm, mode: T1 A, mfr:TST id:12345678 ver:255 type:0 ci:7A]
L_FIELD=190:
[20:41:26.273][I][wmbus_user:2457]: ★ Have data / odebrano dane (191 bytes) [RSSI: -115dBm, mode: T1 A, mfr:TST id:12345678 ver:255 type:0 ci:7A]
W logu ESPHome długość w nawiasie pokazuje ramkę już po dekodowaniu 3-of-6 i po usunięciu blokowych CRC DLL. Dlatego np. Have data (191 bytes) nie oznacza 191 bajtów odebranych fizycznie z radia.
Dla realnych logów z testu:
Have data (41 bytes)oznacza 49 bajtów z CRC DLL, czyli 74 bajty RAW po radiu.Have data (150 bytes)oznacza 170 bajtów z CRC DLL, czyli 255 bajtów RAW po radiu.Have data (151 bytes)oznacza 171 bajtów z CRC DLL, czyli 257 bajtów RAW po radiu.Have data (191 bytes)oznacza 217 bajtów z CRC DLL, czyli 326 bajtów RAW po radiu.
Kluczowy test to Have data (191 bytes), bo odpowiada ramce 326 RAW bajtów, czyli przekracza granicę 255 bajtów RAW.
Reasumując: sprawdziłem tor radiowy i logikę komponentu, a nie dekodowanie ramki do dalszej obróbki.
Celem testu było potwierdzenie, że SX1262 poprawnie odbiera prawidłowe ramki wM-Bus T1 przekraczające standardową granicę 255 bajtów RAW — i ten cel został spełniony.
EDIT:
Naniosłem kosmetyczną poprawkę do kodu i teraz w logu będzie widać obie wartości:
[I][wmbus_user:2457]: ★ Have data / odebrano dane (decoded=143 bytes, raw=245 bytes) [RSSI: -127dBm, mode: T1 A, mfr:NES id:24681357 ver:3 type:2 ci:7A]
Dla testowej ramki:
[I][wmbus_user:2457]: ★ Have data / odebrano dane (decoded=191 bytes, raw=326 bytes) [RSSI: -115dBm, mode: T1 A, mfr:TST id:12345678 ver:255 type:0 ci:7A]
Na końcu test maksymalnej długości ramki jaki komponent może przyjąć czyli 435 bajtów :
[I][wmbus_user:2457]: ★ Have data / odebrano dane (decoded=256 bytes, raw=435 bytes) [RSSI: -117dBm, mode: T1 A, mfr:TST id:12345678 ver:255 type:0 ci:7A]
Zostawiłem to na 15 minut i po tym czasie dostałem summary dla licznika testowego ( log skrócony) :
interval_s=900
listen_mode=T1 only
total=63
ok=63
truncated=0
dropped=0
crc_failed=0
drop_pct=0
trunc_pct=0
crc_fail_pct=0
sym_invalid=0
sym_invalid_pct=0
hint=GOOD
W teście użyto maksymalnych syntetycznych ramek T1 A o długości 435 bajtów RAW nadawanych co 30s.
Pole “total=63” to suma wszystkich zebranych odczytów w ciągu 15 minut a nie wyłącznie z licznika testowego.
Jak widać SX1262 odebrał długie ramki T1 bez ucięć, dropów i błędów DLL CRC.
Test wykonałem po godzinie 2 w nocy gdzie u mnie panuje cisza radiowa, więc traktuję go jako walidację funkcjonalną toru RX, a nie jako benchmark odporności na zatłoczony kanał.
2 Likes
Szukam ochotnika do testów eksperymentalnej obsługi CC1101 w moim komponencie RAW-only.
Nie posiadam fizycznie takowej płytki.
Założenie jest inne niż w komponentach all-in-one: ESP ma odebrać i zwalidować telegram wM-Bus, a następnie wysłać go jako HEX do MQTT. Dekodowanie robi dalej wmbusmeters po stronie Home Assistant / hosta.
Wymagania do testu:
- CC1101 z wyprowadzonymi pinami GDO0 i GDO2,
- oba piny muszą być podłączone do ESP,
- brak konfiguracji typu „jeden IRQ i reszta n/c”,
- krótkie przewody i pewne zasilanie 3.3 V,
- możliwość zebrania logów z ESPHome,
- najlepiej licznik, który już nadaje i był wcześniej potwierdzony innym odbiornikiem.
To jest backend eksperymentalny, więc nie obiecuję gotowego rozwiązania ani encji po wgraniu YAML-a. Na tym etapie celem jest sprawdzenie, czy CC1101 poprawnie łapie pełny telegram i czy po walidacji pojawia się on na topicu MQTT.
Jeśli ktoś ma taki zestaw i chce potestować, mogę przygotować przykładowy YAML oraz powiedzieć, jakie logi są potrzebne.
Aby nie generować OFF-Topic prosze pisać do mnie na PW.
1 Like
Mały update w temacie testów CC1101.
Ponieważ nadal nie mam u siebie fizycznego modułu CC1101, a chciałem ruszyć temat bez czekania na ochotnika z hardware, zrobiłem stanowisko testowe do sprawdzenia samej logiki odbioru.
Układ testowy wygląda tak:
SX1276 jako nadajnik testowy
↓ RF
SX1262 jako rzeczywisty odbiornik z eteru
↓
ukryty RAW topic MQTT: wmbus_bridge/raw
↓
Home Assistant add-on: CC1101 RX Testbench
↓
symulacja FIFO / threshold / ogona ramki
↓
ta sama logika dekodowania T1
↓
wmbusmeters jako walidator
Czyli nie emuluję całego układu CC1101. Nie testuję jeszcze SPI, GDO, rejestrów, prawdziwego FIFO ani fizycznego zachowania radia.
Testuję natomiast to, co można sprawdzić bez hardware:
surowy pakiet radiowy
→ buforowanie
→ porcjowanie jak przy FIFO/threshold
→ doczytanie ogona poniżej progu
→ dekodowanie T1 / 3of6
→ kontrola długości ramki
→ finalny telegram dla wmbusmeters
Do odsiania normalnego zapchanego eteru użyłem fake meter ID:
12345678
Add-on filtruje ramki po tym ID, więc normalne liczniki z otoczenia są ignorowane.
Przetestowane przypadki:
RAW 71 B → chunks=32+32+7 → OK, final frame len=41
RAW 111 B → chunks=32+32+32+15 → OK, final frame len=64
RAW 435 B → chunks=32+...+32+19 → OK, final frame len=256
Najważniejszy test to maksymalna ramka:
input_len=435
tail=19
delivered_len=435
tail_dropped=false
OUT len=256 meter=12345678
Zrobiłem też test negatywny, czyli celowe zgubienie ogona poniżej threshold:
input_len=435
tail=19
delivered_len=416
tail_dropped=true
DROP stage=t1_length_check reason=truncated
decoded_len=277 need_total=290 l_field=255
Wniosek jest prosty:
ogon FIFO doczytany → ramka przechodzi
ogon FIFO zgubiony → ramka jest ucięta i dekoder to wykrywa
Czyli sama logika odbioru/buforowania/dekodowania T1 została przetestowana na realnym torze MQTT i realnie odebranych pakietach z eteru, ale bez fizycznego CC1101.
To nie zamyka tematu testów sprzętowych. Nadal potrzebny jest test na prawdziwym CC1101, bo dopiero on sprawdzi SPI, GDO, konfigurację rejestrów, rzeczywiste FIFO i zachowanie układu radiowego.
Ale na tym etapie mam już mocny argument, że problem nie leży w samej logice dekodowania/bufora po mojej stronie. Jeżeli na prawdziwym CC1101 coś się wyłoży, to będzie trzeba patrzeć przede wszystkim w stronę hardware/SPI/GDO/FIFO timing, a nie zaczynać od założenia, że sam tor T1 jest napisany w ciemno.
Poniżej licznik testowy w moim addonie wmbusmeters:
Received telegram from: 12345678
manufacturer: (TST) Unknown (0x5274)
type: Other (0x00) encrypted
ver: 0xff
driver: unknown!
[wmbus-bridge][WARN] === NEW METER CANDIDATE DETECTED ===
[wmbus-bridge][WARN] Received telegram from: 12345678
[wmbus-bridge][WARN] Suggested driver: unknown
[wmbus-bridge][WARN] Add to options.json meters[] (example):
[wmbus-bridge][WARN] {"id":"meter_12345678","meter_id":"12345678","type":"auto","type_other":"","key":"NOKEY"}
[wmbus-bridge][WARN] ==================================
Received telegram from: 12345678
manufacturer: (TST) Unknown (0x5274)
type: Other (0x00) encrypted
ver: 0xff
driver: unknown!
Received telegram from: 12345678
manufacturer: (TST) Unknown (0x5274)
type: Other (0x00) encrypted
ver: 0xff
driver: unknown!
Pokazuje jak to działa:
Nadajnik SX1262 który czyta normalnie ( bez fake licznika ) :
[12:24:28.507][I][wmbus:949]: DIAG hint: OK | looks good / wygląda dobrze
[12:24:33.892][I][wmbus:2478]: Have data / odebrano dane (77 bytes) [RSSI: -59dBm, mode: T1 A, mfr:BMT id:03534167 ver:23 type:7 ci:7A]
[12:24:35.808][I][wmbus:2478]: Have data / odebrano dane (77 bytes) [RSSI: -59dBm, mode: T1 A, mfr:BMT id:03534157 ver:23 type:7 ci:7A]
[12:24:37.731][I][wmbus:2478]: Have data / odebrano dane (77 bytes) [RSSI: -59dBm, mode: T1 A, mfr:BMT id:03528107 ver:23 type:6 ci:7A]
Addon w HA który udaje CC1101 :
[I] [SIM] fifo=on size=64 threshold=32 chunks=32+32+32+32+6 tail=6 delivered_len=134 tail_dropped=false
[I] [OUT] topic=wmbus_bridge/telegram_cc1101_sim mode=T1 format=A len=77 meter=03528302
[I] [IN ] origin=mqtt topic=wmbus_bridge/raw chip=SX1262 mode=T1 rssi=-59 input_len=134 delivered_len=134
[I] [SIM] fifo=on size=64 threshold=32 chunks=32+32+32+32+6 tail=6 delivered_len=134 tail_dropped=false
[I] [OUT] topic=wmbus_bridge/telegram_cc1101_sim mode=T1 format=A len=77 meter=03528297
[I] [IN ] origin=mqtt topic=wmbus_bridge/raw chip=SX1262 mode=T1 rssi=-59 input_len=134 delivered_len=134
[I] [SIM] fifo=on size=64 threshold=32 chunks=32+32+32+32+6 tail=6 delivered_len=134 tail_dropped=false
[I] [OUT] topic=wmbus_bridge/telegram_cc1101_sim mode=T1 format=A len=77 meter=03551593
[I] [IN ] origin=mqtt topic=wmbus_bridge/raw chip=SX1262 mode=T1 rssi=-59 input_len=134 delivered_len=134
[I] [SIM] fifo=on size=64 threshold=32 chunks=32+32+32+32+6 tail=6 delivered_len=134 tail_dropped=false
[I] [OUT] topic=wmbus_bridge/telegram_cc1101_sim mode=T1 format=A len=77 meter=03534249
[I] [STAT] rx=85 ok=71 drop=14 ignored=0 parse_fail=0 hex_fail=0 decode_fail=13 crc_fail=1 truncated=0 tail_dropped=0 invalid_symbols=56 in_bytes=12096 delivered_bytes=12096 out_bytes=5949 ok_pct=83.5%
[I] [IN ] origin=mqtt topic=wmbus_bridge/raw chip=SX1262 mode=T1 rssi=-59 input_len=134 delivered_len=134
[I] [SIM] fifo=on size=64 threshold=32 chunks=32+32+32+32+6 tail=6 delivered_len=134 tail_dropped=false
[I] [OUT] topic=wmbus_bridge/telegram_cc1101_sim mode=T1 format=A len=77 meter=03536902
Addon wmbusmeters który to czyta :
No meters configured. Printing id:s of all telegrams heard!
Received telegram from: 03534249
manufacturer: (BMT) BMETERS, Italy (0x9b4)
type: Water meter (0x07)
ver: 0x17
driver: hydrodigit
Received telegram from: 03536902
manufacturer: (BMT) BMETERS, Italy (0x9b4)
type: Water meter (0x07)
ver: 0x17
driver: hydrodigit
Received telegram from: 03528221
manufacturer: (BMT) BMETERS, Italy (0x9b4)
type: Warm Water (30°C-90°C) meter (0x06)
ver: 0x17
driver: hydrodigit
Received telegram from: 03534237
manufacturer: (BMT) BMETERS, Italy (0x9b4)
type: Water meter (0x07)
ver: 0x17
driver: hydrodigit
Received telegram from: 03533991
manufacturer: (BMT) BMETERS, Italy (0x9b4)
type: Water meter (0x07)
ver: 0x17
driver: hydrodigit
Received telegram from: 03551587
manufacturer: (BMT) BMETERS, Italy (0x9b4)
type: Water meter (0x07)
ver: 0x17
driver: hydrodigit
Received telegram from: 00089907
manufacturer: (NES) NORA ELK MALZ SAN ve TIC, Turkey (0x38b3)
type: Electricity meter (0x02) encrypted
ver: 0x03
driver: amiplus
Received telegram from: 03575413
manufacturer: (BMT) BMETERS, Italy (0x9b4)
type: Water meter (0x07)
ver: 0x17
driver: hydrodigit
Received telegram from: 03534167
manufacturer: (BMT) BMETERS, Italy (0x9b4)
type: Water meter (0x07)
ver: 0x17
driver: hydrodigit
Received telegram from: 03534157
Sorry za tak długi post.
1 Like
Dzięki współpracy z @bodek85 ( Dziękówa za czas i chęci 
) wklejam zanonimizowane logi.
[07:36:58.502][C][logger:219]: Max Level: DEBUG
[07:36:58.502][C][logger:219]: Initial Level: DEBUG
[07:36:58.502][C][logger:226]: Log Baud Rate: 115200
[07:36:58.502][C][logger:226]: Hardware UART: USB_SERIAL_JTAG
[07:36:58.504][C][logger:235]: Task Log Buffer Size: 768 bytes
[07:36:58.509][C][logger:241]: Level for 'component': WARN
[07:36:58.510][C][logger:241]: Level for 'mqtt': WARN
[07:36:58.510][C][logger:241]: Level for 'wmbus': DEBUG
[07:36:58.518][C][spi:066]: SPI bus:
[07:36:58.523][C][spi:152]: CLK Pin: GPIO12
[07:36:58.523][C][spi:152]: SDI Pin: GPIO13
[07:36:58.523][C][spi:152]: SDO Pin: GPIO11
[07:36:58.525][C][spi:074]: Using HW SPI: SPI2_HOST
[07:36:58.531][C][homeassistant.time:010]: Home Assistant Time
[07:36:58.532][C][time:049]: Timezone: UTC+1:00 (DST UTC+2:00)
[07:36:58.532][C][time:055]: Current time: 2026-04-30 07:36:58
[07:36:58.549][C][CC1101:418]: Transceiver: CC1101
[07:36:58.549][C][CC1101:152]: GDO0/FIFO Pin: GPIO21
[07:36:58.549][C][CC1101:152]: GDO2/SYNC Pin: GPIO14
[07:36:58.549][C][CC1101:421]: Frequency: 868.950 MHz
[07:36:58.551][C][CC1101:422]: SPI/RX: experimental CC1101, requires GDO0+GDO2
[07:36:58.556][C][CC1101:423]: RF profile: compatibility modem profile, infinite packet mode
[07:36:58.557][C][CC1101:427]: Listen mode: T1 only
[07:36:58.557][C][wmbus:2008]: wM-Bus Radio:
[07:36:58.559][C][wmbus:2014]: Radio type: CC1101
[07:36:58.563][C][wmbus:2015]: Listen mode: T1 only
[07:36:58.564][C][wmbus:2017]: Receiver task stack: 3072 bytes
[07:36:58.564][C][wmbus:2021]: SX1276 busy ether mode: adaptive
[07:36:58.568][C][wmbus:2023]: Diagnostics MQTT topic: wmbus/[DEVICE]/diag
[07:36:58.579][C][wmbus:2024]: MQTT boot topic: wmbus/[DEVICE]/diag/boot
[07:36:58.580][C][wmbus:2025]: Summary interval: 120s -> wmbus/[DEVICE]/diag/summary
[07:36:58.580][C][wmbus:2026]: 15min summary: enabled (900s) -> wmbus/[DEVICE]/diag/summary_15min
[07:36:58.583][C][wmbus:2027]: 60min summary: disabled -> wmbus/[DEVICE]/diag/summary_60min
[07:36:58.590][D][api:220]: Accept [HA_IP]
[07:36:58.591][D][api:220]: Accept [HA_IP]
[07:36:58.591][D][api.connection:2409]: Home Assistant 2026.4.4 ([HA_IP]): connected
[07:36:58.600][D][api.connection:2409]: ESPHome Logs 2026.4.3 ([HA_IP]): connected
[07:36:58.616][C][restart:088]: Restart Switch 'Reset'
[07:36:58.616][C][restart:088]: Restore Mode: always OFF
[07:36:58.617][C][restart:223]: Icon: 'mdi:restart'
[07:36:58.617][C][wifi:1505]: WiFi:
[07:36:58.617][C][wifi:1505]: Local MAC: [ESP_MAC]
[07:36:58.617][C][wifi:1505]: Connected: YES
[07:36:58.620][C][wifi:1216]: IP Address: [ESP_IP]
[07:36:58.638][C][wifi:1227]: SSID: [redacted]
[07:36:58.638][C][wifi:1227]: BSSID: [redacted]
[07:36:58.638][C][wifi:1227]: Hostname: '[DEVICE_NAME]'
[07:36:58.638][C][wifi:1227]: Signal strength: -25 dB ▂▄▆█
[07:36:58.638][C][wifi:1227]: Channel: 1
[07:36:58.638][C][wifi:1227]: Subnet: 255.255.255.0
[07:36:58.638][C][wifi:1227]: Gateway: [GATEWAY_IP]
[07:36:58.638][C][wifi:1227]: DNS1: [DNS_1]
[07:36:58.638][C][wifi:1227]: DNS2: [DNS_2]
[07:36:58.638][C][esphome.ota:071]: Over-The-Air updates:
[07:36:58.638][C][esphome.ota:071]: Address: [DEVICE_NAME].local:3232
[07:36:58.638][C][esphome.ota:071]: Version: 2
[07:36:58.639][C][safe_mode:026]: Safe Mode:
[07:36:58.639][C][safe_mode:026]: Successful after: 60s
[07:36:58.639][C][safe_mode:026]: Invoke after: 10 attempts
[07:36:58.639][C][safe_mode:026]: Duration: 300s
[07:36:58.643][C][safe_mode:043]: Bootloader rollback: supported
[07:36:58.675][C][api:235]: Server:
[07:36:58.675][C][api:235]: Address: [DEVICE_NAME].local:6053
[07:36:58.675][C][api:235]: Listen backlog: 4
[07:36:58.675][C][api:235]: Max connections: 8
[07:36:58.676][C][api:247]: Noise encryption: NO
[07:36:58.676][C][mdns:194]: mDNS:
[07:36:58.676][C][mdns:194]: Hostname: [DEVICE_NAME]
[07:36:58.679][C][mqtt.switch:040]: MQTT Switch 'Reset':
[07:36:58.722][C][mqtt.switch:043]: State Topic: '[DEVICE_NAME]/switch/reset/state'
[07:36:58.722][C][mqtt.switch:045]: Command Topic: '[DEVICE_NAME]/switch/reset/command'
[07:36:58.880][W][component:422]: mqtt cleared Warning flag
[07:36:58.995][W][component:522]: mqtt took a long time for an operation (116 ms), max is 30 ms
[07:36:59.088][I][wmbus:2068]: Radio active / radio aktywne: CC1101 | Listen mode / tryb nasluchu: T1 only | receiver_stack=3072 bytes
[07:37:04.103][I][wmbus:2068]: Radio active / radio aktywne: CC1101 | Listen mode / tryb nasluchu: T1 only | receiver_stack=3072 bytes
[07:37:05.111][I][wmbus:2478]: Have data / odebrano dane (decoded=26 bytes, raw=45 bytes) [RSSI: -44dBm, mode: T1 A, mfr:SAP id:[METER_SAP_1] ver:152 type:1 ci:A2]
[07:37:09.103][I][wmbus:2068]: Radio active / radio aktywne: CC1101 | Listen mode / tryb nasluchu: T1 only | receiver_stack=3072 bytes
[07:37:14.063][I][wmbus:2478]: Have data / odebrano dane (decoded=26 bytes, raw=45 bytes) [RSSI: -43dBm, mode: T1 A, mfr:SAP id:[METER_SAP_1] ver:152 type:1 ci:A2]
[07:37:22.979][I][wmbus:2478]: Have data / odebrano dane (decoded=26 bytes, raw=45 bytes) [RSSI: -43dBm, mode: T1 A, mfr:SAP id:[METER_SAP_1] ver:152 type:1 ci:A2]
[07:37:31.760][I][wmbus:2478]: Have data / odebrano dane (decoded=26 bytes, raw=45 bytes) [RSSI: -43dBm, mode: T1 A, mfr:SAP id:[METER_SAP_1] ver:152 type:1 ci:A2]
[07:37:40.557][I][wmbus:2478]: Have data / odebrano dane (decoded=26 bytes, raw=45 bytes) [RSSI: -43dBm, mode: T1 A, mfr:SAP id:[METER_SAP_1] ver:152 type:1 ci:A2]
[07:37:42.500][W][api.connection:2415]: ESPHome Logs 2026.4.3 ([HA_IP]): Reading failed CONNECTION_CLOSED errno=128
[07:37:48.787][I][wmbus:2478]: Have data / odebrano dane (decoded=26 bytes, raw=45 bytes) [RSSI: -43dBm, mode: T1 A, mfr:SAP id:[METER_SAP_1] ver:152 type:1 ci:A2]
[07:37:49.945][I][wmbus_user:2457]: ★ Have data / odebrano dane (decoded=191 bytes, raw=326 bytes) [RSSI: -56dBm, mode: T1 A, mfr:APA id:[METER_APA_1] ver:1 type:2 ci:7A]
[07:37:49.951][I][wmbus_user:2469]: ★ [id:[METER_APA_1]] first packet / pierwszy pakiet (packet #1)
[07:37:53.983][I][safe_mode:091]: Boot seems successful; resetting boot loop counter
[07:37:56.856][I][wmbus:2478]: Have data / odebrano dane (decoded=26 bytes, raw=45 bytes) [RSSI: -43dBm, mode: T1 A, mfr:SAP id:[METER_SAP_1] ver:152 type:1 ci:A2]
[07:37:58.475][D][preferences:152]: Writing 1 items: 0 cached, 1 written, 0 failed
[07:38:06.822][I][wmbus:2478]: Have data / odebrano dane (decoded=26 bytes, raw=45 bytes) [RSSI: -44dBm, mode: T1 A, mfr:SAP id:[METER_SAP_1] ver:152 type:1 ci:A2]
[07:38:15.276][I][wmbus:2478]: Have data / odebrano dane (decoded=26 bytes, raw=45 bytes) [RSSI: -44dBm, mode: T1 A, mfr:SAP id:[METER_SAP_1] ver:152 type:1 ci:A2]
[07:38:24.238][I][wmbus:2478]: Have data / odebrano dane (decoded=26 bytes, raw=45 bytes) [RSSI: -43dBm, mode: T1 A, mfr:SAP id:[METER_SAP_1] ver:152 type:1 ci:A2]
[07:38:28.132][I][wmbus_user:2457]: ★ Have data / odebrano dane (decoded=111 bytes, raw=191 bytes) [RSSI: -53dBm, mode: T1 A, mfr:APA id:[METER_APA_2] ver:5 type:7 ci:7A]
[07:38:28.137][I][wmbus_user:2472]: ★ [id:[METER_APA_2]] packet #2 received / odebrano pakiet nr 2
[07:38:33.155][I][wmbus:2478]: Have data / odebrano dane (decoded=26 bytes, raw=45 bytes) [RSSI: -43dBm, mode: T1 A, mfr:SAP id:[METER_SAP_1] ver:152 type:1 ci:A2]
Wstępnie jak widać CC1101 działa i czyta.
EDIT:
Oprogramowanie uruchomiono na ESP32-S3FH4R2:
ESP32-S3FH4R2
- dual-core Xtensa LX7
- 240 MHz ( w software zejście na 160 Mhz)
- 4 MB flash
- 2 MB PSRAM
- Wi-Fi + BLE
spi:
clk_pin: GPIO12
mosi_pin: GPIO11
miso_pin: GPIO13
cs_pin: GPIO10
gdo0_pin: GPIO21
gdo2_pin: GPIO14
1 Like
Do main trafiła wersja 1.1.7 komponentu wmbus_radio.
Najważniejsze zmiany:
- dodany
topic_name, czyli prostsze generowanie topiców MQTT, - dodany tryb
listen_mode_filter_after_parse, - uporządkowane tryby diagnostyki:
off,low,normal,debug,dev, - poprawione
busy_ether_statedla radii innych niż SX1276, - zachowana kompatybilność ze starszymi opcjami typu
telegram_topic,diagnostic_topic,raw,medium,full, - do
maintrafiła poprawka logu długości ramek:decoded=...,raw=....
Nowy tryb odbioru
Doszła opcja:
listen_mode_filter_after_parse: true
Domyślnie zostaje:
listen_mode_filter_after_parse: false
czyli tryb konserwatywny.
Tryb true jest bardziej agresywny — parser dostaje większą szansę na ocenę ramki, zamiast odrzucać ją zbyt wcześnie na samej heurystyce.
U mnie, mimo że liczniki są blisko odbiornika, nowy tryb dał lepsze wyniki dla części słabszych / trudniejszych liczników.
Przykłady z testu 15-minutowego na tym samym urządzeniu:
| Licznik | Stary kod | Nowy kod | Różnica |
|---|---|---|---|
| Licznik A | 3 | 7 | +133% |
| Licznik B | 3 | 7 | +133% |
| Licznik C | 5 | 7 | +40% |
| Licznik D | 4 | 8 | +100% |
| Licznik E | 7 | 7 | bez zmian |
| Licznik F | 30 | 28 | podobnie |
| Licznik G | 26 | 28 | podobnie |
Najważniejszy wniosek: mocne / regularnie odbierane liczniki działały podobnie jak wcześniej, ale słabsze albo bardziej problematyczne zaczęły wpadać regularniej.
Przykład:
Licznik B:
stary kod: 3 ramki
nowy kod: 7 ramek
interwał: około 121 s
Czyli licznik nadawał regularnie, ale stary algorytm łapał tylko część transmisji. Nowy złapał praktycznie całe okno testowe.
Tryby diagnostyki
Diagnostyka została uproszczona do presetów:
diagnostic_mode: off
diagnostic_mode: low
diagnostic_mode: normal
diagnostic_mode: debug
diagnostic_mode: dev
W praktyce:
| Tryb | Opis |
|---|---|
off |
diagnostyka wyłączona |
low |
minimalna diagnostyka, podstawowe informacje |
normal |
zalecany tryb do normalnego używania i testów |
debug |
więcej informacji do analizy problemów |
dev |
tryb developerski, najbardziej szczegółowy |
Do zwykłego używania polecam:
diagnostic_mode: normal
Ten tryb daje sensowną diagnostykę bez zalewania MQTT nadmiarem danych.
Jeżeli chcesz obserwować konkretne liczniki, dodajesz je w:
highlight_meters:
- "12345678"
- "87654321"
Wtedy w normal dostajesz również meter_snapshot dla tych liczników, czyli najważniejsze dane do porównywania odbioru:
count_window
count_total
avg_interval_s
win_avg_interval_s
Stare wartości typu medium, full, raw nadal działają, ale są traktowane jako legacy/deprecated.
Jak oceniać nowy tryb?
Nie patrzeć wyłącznie na globalny drop_pct.
Przy listen_mode_filter_after_parse: true mogą wzrosnąć dropy typu:
false_start_like
payload_size_unknown
t1_decode3of6
To nie musi oznaczać pogorszenia.
Najważniejsze jest meter_snapshot i konkretne liczniki:
count_window
count_total
avg_interval_s
win_avg_interval_s
Jeżeli licznik, który wcześniej wpadał nieregularnie, zaczyna mieć stabilne odczyty zgodne z interwałem nadawania, to tryb działa na plus — nawet jeśli globalne summary wygląda brzydziej.
MQTT po nowemu
Zamiast ręcznie wpisywać pełne topiki, można użyć:
topic_name: "xiao_s3"
Komponent sam wygeneruje:
wmbus/xiao_s3/telegram
wmbus/xiao_s3/diag
wmbus/xiao_s3/diag/summary
wmbus/xiao_s3/diag/meter_snapshot
Jeśli topic_name nie jest podany, używany jest esphome.name.
friendly_name celowo nie jest używany jako baza topiców.
Przykład
external_components:
- source: github://Kustonium/esphome-wmbus-bridge-rawonly@main
components: [wmbus_radio]
refresh: 0s
wmbus_radio:
- radio_type: SX1262
listen_mode: T1
listen_mode_filter_after_parse: false
topic_name: "xiao_s3"
diagnostic_mode: normal
highlight_meters:
- "12345678"
- "87654321"
cs_pin: GPIO41
reset_pin: GPIO42
busy_pin: GPIO40
irq_pin:
number: GPIO39
mode: input
has_tcxo: true
rx_gain: boosted
Dla testów można sprawdzić:
listen_mode_filter_after_parse: true
ale wynik porównywać po meter_snapshot konkretnych liczników, a nie po samym globalnym summary.
CC1101
Obsługa CC1101 jest w kodzie, ale traktuję ją jako techniczną/testową.
To nie jest oficjalnie polecany wariant dla początkujących.
Do użycia świadomie i na własną odpowiedzialność. CC1101 jest tani, ale wymaga poprawnego okablowania SPI oraz osobnych linii GDO0/GDO2. To nie jest wariant „kup, wgraj i zapomnij”.
Krótko
1.1.7 porządkuje MQTT, diagnostykę i dodaje opcję bardziej agresywnego filtrowania ramek po parsowaniu.
Domyślnie zostaje tryb konserwatywny, a listen_mode_filter_after_parse: true warto traktować jako opcję testową do porównania po konkretnych licznikach.
========
Uwzględniłem zmiany w addonie po stronie HA/Docker => defaultowo on też słucha wmbus/+/telegram.
2 Likes
Dodałem eksperymentalny tryb obsługi S1, przeznaczony głównie do diagnostyki i testów kompatybilności.
Ponieważ S1 używa innego profilu radiowego / częstotliwości niż typowe T1/C1, nie ma możliwości pracy w trybie BOTH razem z T1/C1. W praktyce wybór jest więc taki: T1, C1, BOTH jako T1/C1 albo wyłącznie S1.
Jeżeli telegram S1 zostanie odebrany poprawnie, komponent odczyta podstawowy nagłówek, np. producenta i ID, oraz przekaże surowy telegram dalej przez MQTT do dalszej obróbki. Dekodowanie wartości zależy już od wmbusmeters, drivera i ewentualnego szyfrowania.
[17:14:22.594][I][wmbus:2083]: Radio active / radio aktywne: SX1262 | Listen mode / tryb nasluchu: S1 only | receiver_stack=3072 bytes | RF: freq=868.300MHz bitrate=32kbps fdev=50kHz BT=0.5 RxBW=312kHz Manchester/S-mode
...
[17:30:12.724][I][wmbus:953]: DIAG hint: GOOD | RF link looks stable / łącze radiowe wygląda stabilnie
[17:30:42.510][I][wmbus:2515]: Have data / odebrano dane (decoded=41 bytes, raw=416 bytes) [RSSI: -69dBm, mode: S1 A, mfr:TST id:12345678 ver:255 type:0 ci:7A]
[17:31:12.519][I][wmbus:2515]: Have data / odebrano dane (decoded=41 bytes, raw=416 bytes) [RSSI: -74dBm, mode: S1 A, mfr:TST id:12345678 ver:255 type:0 ci:7A]
[17:31:12.722][I][wmbus:947]: DIAG summary / podsumowanie diag: topic=wmbus/heltec/diag/summary interval=60s uptime_ms=1020325 listen_mode=S1 only total=2 ok=2 truncated=0 dropped=0 crc_failed=0
[17:31:12.727][I][wmbus:953]: DIAG hint: GOOD | RF link looks stable / łącze radiowe wygląda stabilnie
[17:31:42.523][I][wmbus:2515]: Have data / odebrano dane (decoded=41 bytes, raw=416 bytes) [RSSI: -68dBm, mode: S1 A, mfr:TST id:12345678 ver:255 type:0 ci:7A]
[17:32:12.532][I][wmbus:2515]: Have data / odebrano dane (decoded=41 bytes, raw=416 bytes) [RSSI: -79dBm, mode: S1 A, mfr:TST id:12345678 ver:255 type:0 ci:7A]
[17:32:12.731][I][wmbus:947]: DIAG summary / podsumowanie diag: topic=wmbus/heltec/diag/summary interval=60s uptime_ms=1080334 listen_mode=S1 only total=2 ok=2 truncated=0 dropped=0 crc_failed=0
Poprawek ciąg dalszy.
Teraz padło po stronie HA co wynikło z lektury nie tylko tego Forum ale również Ha Community.
Dorobiłem szukajkę wodomierzy czyli przypadek kiedy na liczniku nie ma ID tylko cyferki z czapy.
Z grubsza szukajka działa że user podaje faktyczny odczyt jaki ma na liczniku do Addonu, plus tolerancje szukania ( np 0.05m3 ) i puszcza to sobie … Trzeba poczekać aż addon to sobie pozbiera ( w zależności od liczby słyszanych liczników):
Ja podałem że szukam wartości 22.91 z tolerancją 0.05.
[wmbus-bridge][WARN] SEARCH discovered: id=04875707 driver=hydrodigit type=Warm Water (30°C-90°C) meter (0x06) stored as water candidate (cached=33, ignored=6).
Tutaj mamy info że zapamiętał 33 liczniki , 6 zignorował.
Restartujemy Addon i po chwili 
[19:02:31] INFO: Starting core bridge...
[wmbus-bridge] core: bridge.sh (base=/data)
[wmbus-bridge] wmbusmeters binary: /usr/bin/wmbusmeters
[wmbus-bridge] wmbusmeters runtime version: wmbusmeters: 2.0.0-448-gf8938787
[wmbus-bridge] MQTT: core-mosquitto:1883 topic=wmbus/+/telegram
[wmbus-bridge] state: prefix=wmbusmeters retain=false
[wmbus-bridge] discovery: enabled=true prefix=homeassistant retain=true
[wmbus-bridge] wmbusmeters: loglevel=normal filter_hex_only=true debug_every_n=0
[wmbus-bridge] search: mode=true expected_value_m3=22.91 tolerance_m3=0.05 delta_mode=false min_delta_m3=0.001 topic=wmbus/search/candidates
[wmbus-bridge] robust: ignore_retained=true require_timestamp=false restart_on_exit=true
[wmbus-bridge][WARN] No user meters configured -> SEARCH MODE (temporary cached candidates=35, expected=22.91 m3, tolerance=0.05 m3).
[wmbus-bridge][WARN] SEARCH MODE uses cached candidates from /data/search_candidates.tsv. Remove that file or disable search_mode to return to pure LISTEN MODE.
[wmbus-bridge] Starting wmbusmeters...
[wmbus-bridge] Waiting for MQTT broker core-mosquitto:1883...
[wmbus-bridge] MQTT broker ready (attempt 1/30)
Started config hextty on stdin listening on any
[wmbus-bridge][WARN] SEARCH MATCH: id=12345678 driver=hydrodigit media=warm water field=total_m3 value=22.907 m3 expected=22.91 diff=0.003000 m3
[wmbus-bridge][WARN] SEARCH SUGGESTED CONFIG: {"id":"meter_12345678","meter_id":"12345678","type":"hydrodigit","type_other":"","key":""}
Co się zgadza - znalazł mój licznik.
Niestety działa tylko z nieszyfrowanymi licznikami.
3 Likes
Postanowiłem po stronie Ha dać bardziej ludzki intefejs.
Na razie wersja na “brudno”.
EDIT:
Doszedłem do takiego GUI - testy logiki interfejsu w toku…
Wersja 1.5.0 Eksperymentalna została opublikowana.
Nie powiem że jest bezbłędna , nie byłem wstanie wszystkiego przetestować.
Interfejs UX działa po staremu więc można ktoś nie chce WebGUI to może dalej korzystać jak dotychczas.
Uzupełniłem o dokumentacje.
Interfejs graficzny :
1 Like
Zgodność z ESPHome 2026.5.1
Przetestowano poprawnie z ESPHome 2026.5.1 na ESP32-S3 + SX1276/SX1262.
Ale nowy UX ESP - wygląda całkiem , całkiem wg mnie . ( Off topic )
GUI zostało przebudowane , wszystko się odświeża samo , już bez klikania.
Dodałem funkcjonalność że Addon jednocześnie słucha i dekoduje.
Nadmieniam iż Addon po stronie HA jest samodzielny - potrzebuje tylko HEX na wejściu aby zdekodować liczniki.
1 Like
Cześć, jaka polecasz na chwile obecna płytkę pod Twój komponent ?
Cześć.
Używam obecnie 3 płytki:
- Lilygo T3S3 Sx1276.
- Xiao Seed Wio SX1262
- Heltec V4
Najbardziej czuła jest Heltec V4 - słyszy najwięcej . I jest najdroższa z zestawienia.
Xiao jest malutka i mniej słyszy.
dziękuje, mam helteca v4 i dzis domówiłem 2 szt( pod mesha) na ali bo z kodami jakis chyba był bład wyszło mi po 45zł za sztuke myślę spróbować też testowo odpalić na lilygo t3s3 SX1262 i heltec v2 i eora pi z sx1262. Ciekawe czy będa jakieś rożnice
Dla ścisłości - Heltec V2 to Sx1276
tak wiem obecnie mam na tym meshcore ale potestuje z licznikami
Przetestowałem współprace komponentu z EMQX - działa i user dostaje info czy encje zostały utworzone ( bez TLS ).
Pokazuje jak sobie trzy różne ESP w tym samym środowisku radiowym radzą z czytaniem telegramów.
W tej samej lokalizacji i z identyczną listą liczników na wszystkich trzech odbiornikach: Heltec V4 (SX1262 + FEM/LNA), LilyGO (SX1276), moduł XiaoSeed Wio SX1262 bez FEM. Kluczowa obserwacja: istnieją liczniki, które dekoduje wyłącznie Heltec — pozostałe dwie płytki nie odbierają ich ani razu. To są słabe/dalekie liczniki przy progu szumu i to one różnicują czułość (bliskie/mocne łapią wszystkie). Liczby pakietów per płytka nie są tu porównywalne (licznik kumulatywny od startu, różne uptime) — miarodajne jest pokrycie: ile liczników dana płytka w ogóle słyszy. Wniosek: przewagę daje front-end (FEM/LNA) + antena, nie sama nazwa chipa — ten sam SX1262 bez FEM (drugi moduł) tych słabych liczników nie łapie.
I jak widać najsłabiej wypada SX1276 “lilygo”
1 Like
Lektura tego Forum oraz czasem PW są dla mnie materiałem do wprowadzania usprawnień na które bym sam nie wpadł lub które mi nie przyszły do głowy.
Po stronie ESP kod został usprawniony dla jednordzeniowych ESP - trzeba przekompilować sobie manualnie.
Natomiast po stronie HA dodatek dostał funkcje :
- bezpośrednie zgłoszenie Issue do wmbusmeters telegramu ( nie testowałem czy tworzy na ich stronie ),
- możliwość “w locie” zmiany drivera bez ponownego dodawania licznika,
- podgląd jakie wartości są eksponowane przez dany driver bezpośrednio w programie,
Dalsze prace w toku.
1 Like