To że coś jest powtarzalne to nie znaczy że jest spójne logicznie.
To Ci sygnalizuje komponent właśnie tym CRC.
Czyli problem nie brzmi „czy to wygląda podobnie za każdym razem?”, tylko „dlaczego coś rozpoznane jako ramka nie przechodzi podstawowej kontroli integralności?”.
Wrzuciłem te twoje telegramy do zmielenia przez AI, oto odpowiedź
W oficjalnej dokumentacji technicznej i bibliotekach programistycznych (np. dla standardu Wireless M-Bus w trybie Mode T) najczęściej spotyka się zestaw pięciu “złotych sekwencji” (Golden Sequences). Są one dobrane tak, by testować różne kombinacje bitów i długości ramek danych.
Oto spis tekstów, które mi po kolei wysyłałeś (w kolejności ich występowania w zestawach testowych):
- Kosmos: “the universe is a vast and mysterious place, filled with countless wonders and secrets waiting to be discovered. from the smallest subatomic particles to the largest galaxies, everything is interconnected and governed by the laws of physics.”
- Ziemia i ekosystemy: “the earth is a beautiful and diverse planet, with a wide variety of ecosystems and species. from the lush rainforests to the icy tundra, there is so much to explore and appreciate about our home.”
- Oceany: “the oceans are home to a vast array of life, from the smallest plankton to the largest whales. they play a crucial role in regulating the earths climate and providing food and livelihoods for millions of people around the world.”
- Lasy: “forests are essential for life on earth, providing habitat for millions of species and helping to regulate the global climate. they also provide important resources such as timber, food, and medicine, and support the livelihoods of many people.”
- Góry: “the mountains are a majestic and awe-inspiring sight, with their snow-capped peaks and rugged terrain. they are home to a wide variety of wildlife and provide important sources of water for many people around the world.”
Dlaczego akurat te teksty?
W świecie systemów wbudowanych (embedded) używa się ich zamiast klasycznego “Lorem Ipsum”, ponieważ:
- Balans bitów: Są długie i zawierają niemal wszystkie litery alfabetu, co pozwala sprawdzić, czy algorytm 3 z 6 nie gubi się przy rzadkich kombinacjach (np. litery ‘v’, ‘x’, ‘z’).
- Stała długość: Programista wie dokładnie, że jeśli zdekoduje ciąg zaczynający się od
8F27...i nie otrzyma na końcu kropki, to znaczy, że jego bufor jest za mały lub transmisja została ucięta.Wszystkie Twoje ciągi zaczynały się od sekwencji
8F 27 1C CB..., co jest charakterystycznym “podpisem” słowa "the " w tym systemie kodowania.Czy masz może ciąg, który zaczyna się zupełnie inaczej? To by oznaczało, że mamy do czynienia z realnymi danymi z licznika (numer seryjny, stan zużycia), a nie tekstem testowym.
Uruchomiłem ESP32devkitC_v4+C1101 niestety przepełniony bufor FIFO. Ktoś miał taki przypadek?
[12:43:29][D][wmbusmeters:351]: raw packet "B164FB9418A41EE4"
[12:44:13][W][CC1101:278][radio_recv]: RX FIFO overflow
[12:45:05][D][packet:097]: Have data from radio (8 bytes)
[12:45:06][D][wmbusmeters:351]: raw packet "2F944FF62E165280"
[12:45:13][W][CC1101:278][radio_recv]: RX FIFO overflow
[12:45:15][D][packet:097]: Have data from radio (8 bytes)
[12:45:15][D][wmbusmeters:351]: raw packet "0C0330080A006380"
[12:45:33][D][packet:097]: Have data from radio (8 bytes)
[12:45:33][D][wmbusmeters:351]: raw packet "8928C1A120F43BB4"
[12:45:54][D][packet:097]: Have data from radio (8 bytes)
[12:45:54][D][wmbusmeters:351]: raw packet "00513EB310584828"
[12:46:00][D][packet:097]: Have data from radio (8 bytes)
[12:46:00][D][wmbusmeters:351]: raw packet "95A50808483C6E28"
[12:46:08][D][packet:097]: Have data from radio (8 bytes)
[12:46:08][D][wmbusmeters:351]: raw packet "DF4EA03290379990"
[12:46:12][D][packet:097]: Have data from radio (8 bytes)
[12:46:13][D][wmbusmeters:351]: raw packet "39003EA5E52C8380"
[12:46:13][W][CC1101:278][radio_recv]: RX FIFO overflow
[12:46:19][D][wifi:2413]: Roam scan (-81 dBm, attempt 1/3)
Strzelam w ciemno - albo mieszkasz w gęstym blokowisku (i masz “za gęsto w eterze” co by było bardzo dziwne, bo prawne regulacje nakładają dość poważne ograniczenia na częstość nadawania telegramów - musiałbyś mieć raczej grubo ponad 100 liczników w dobrym zasięgu by było trudno złapać chociaż 1 poprawny telegram na wiaderko śmieci) może trzymasz ten odbiornik przy jakimś innym silnym źródle zakłóceń (falownik, SBC, komputer), albo konstrukcja nie jest zbyt udana i CC1101 łapie zakłócenia od samego ESP32 ewentualnie błędy w samym komponencie lub twojej konfiguracji.
Ja nie mam siły już tłumaczyć że dopóki autor nie poprawi logiki kodu to nieważne jaki hardware sie wstawi objaw zawsze będzie ten sam … czyli software dalej będzie sklejał „coś” i traktował to jak kandydata na ramkę, a potem wywalał się na integralności albo na odbiorze.
Jak ktoś chce szczegóły to pokaże w którym miejscu jest błąd logiczny w kodzie.
Żaden YAML tego nie naprawi.
Skoro znasz szczegóły, to zgłoś jako issue - wtedy jest jakakolwiek szansa, że ktoś się tym zajmie.
Ja tego repo nie używam. Na jego podstawie/fundamencie zbudowałem swoje rozwiązanie które działa ale nie jest sexy dla użytkownika końcowego, bo jest bardziej techniczne.
Każdy , absolutnie każdy z Forum może ten błąd sam znaleźć pracując z AI - nie wystarczy wkleić sam log tylko dać AI kontekst.
Z tego co widzę
ludzie na płytkach z dwurdzeniowym prockiem obchodzili podobny problem ustawiając taktowanie SPI na 4MHz (obecny default to bodajże 20MHz)
ESPHome ma od lat braki w dokumentacji (i pamiętam, że kiedyś domyślne taktowanie SPI było zmieniane w ESPHome, bo kiedyś miałem nagłe problemy z wyświetlaczem graficznym po aktualizacji, ponieważ wtedy nie ustawiłem jawnie na sztywno tego taktowania).
Natomiast co do jakości kodu komponentu nie będę się wypowiadał, bo nie jestem programistą (mimo wielu współautorów w zasadzie całą robotę odwala @_Szczepan a chyba nie ma za wiele czasu).
Ale to nie poprawi kodu.
Logika kwalifikowania ramek jest wspólna bez względu na użyty hardware.
Przy czym w przypadku CC1101 dochodzi jeszcze specyficzna jego obsługa.
INFO ESPHome 2026.4.2
INFO Reading configuration /config/esphome/xiao-seed-esp-s3.yaml...
INFO Detected timezone 'Europe/Warsaw'
INFO Starting looking for IP in topic esphome/discover/xiao-seed-esp-s3
INFO Connected to MQTT broker!
INFO Send discover via MQTT broker topic: esphome/ping/xiao-seed-esp-s3
INFO Found IP: ['192.168.100.81']
INFO Starting log output from 192.168.100.81 using esphome API
INFO Successfully resolved xiao-seed-esp-s3 @ 192.168.100.81 in 0.000s
INFO Successfully connected to xiao-seed-esp-s3 @ 192.168.100.81 in 0.003s
INFO Successful handshake with xiao-seed-esp-s3 @ 192.168.100.81 in 0.011s
[13:35:29.494][I][app:154]: ESPHome version 2026.4.2 compiled on 2026-04-24 18:56:05 +0200
[13:35:29.494][I][app:161]: ESP32 Chip: ESP32-S3 rev0.2, 2 core(s)
[13:35:29.765][I][wmbus:917]: DIAG summary / podsumowanie diag: topic=wmbus/xiaoseed/diag/summary interval=60s uptime_ms=660267 listen_mode=T1 only total=11 ok=11 truncated=0 dropped=0 crc_failed=0
[13:35:29.808][I][wmbus:923]: DIAG hint: GOOD | RF link looks stable / łącze radiowe wygląda stabilnie
[13:35:31.841][I][wmbus:2446]: Have data / odebrano dane (77 bytes) [RSSI: -119dBm, mode: T1 A, mfr:BMT id:03575707 ver:23 type:6 ci:7A]
[13:35:32.282][I][wmbus_user:2425]: ★ Have data / odebrano dane (77 bytes) [RSSI: -120dBm, mode: T1 A, mfr:BMT id:03534159 ver:23 type:7 ci:7A]
[13:35:32.288][I][wmbus_user:2440]: ★ [id:03534159] packet #6 received / odebrano pakiet nr 6
[13:35:33.721][I][wmbus_user:2425]: ★ Have data / odebrano dane (143 bytes) [RSSI: -119dBm, mode: T1 A, mfr:NES id:00089907 ver:3 type:2 ci:7A]
[13:35:33.724][I][wmbus_user:2440]: ★ [id:00089907] packet #22 received / odebrano pakiet nr 22
[13:35:43.592][I][wmbus:2446]: Have data / odebrano dane (77 bytes) [RSSI: -120dBm, mode: T1 A, mfr:BMT id:03528308 ver:23 type:6 ci:7A]
[13:36:03.705][I][wmbus_user:2425]: ★ Have data / odebrano dane (143 bytes) [RSSI: -118dBm, mode: T1 A, mfr:NES id:00089907 ver:3 type:2 ci:7A]
[13:36:03.708][I][wmbus_user:2440]: ★ [id:00089907] packet #23 received / odebrano pakiet nr 23
[13:36:20.563][I][wmbus:2446]: Have data / odebrano dane (77 bytes) [RSSI: -118dBm, mode: T1 A, mfr:BMT id:03528499 ver:23 type:6 ci:7A]
[13:36:29.767][I][wmbus:917]: DIAG summary / podsumowanie diag: topic=wmbus/xiaoseed/diag/summary interval=60s uptime_ms=720270 listen_mode=T1 only total=6 ok=6 truncated=0 dropped=0 crc_failed=0
[13:36:29.811][I][wmbus:923]: DIAG hint: GOOD | RF link looks stable / łącze radiowe wygląda stabilnie
[13:36:33.718][I][wmbus_user:2425]: ★ Have data / odebrano dane (143 bytes) [RSSI: -113dBm, mode: T1 A, mfr:NES id:00089907 ver:3 type:2 ci:7A]
[13:36:33.722][I][wmbus_user:2440]: ★ [id:00089907] packet #24 received / odebrano pakiet nr 24
[13:36:51.733][I][wmbus_user:2425]: ★ Have data / odebrano dane (77 bytes) [RSSI: -121dBm, mode: T1 A, mfr:BMT id:03528221 ver:23 type:6 ci:7A]
[13:36:51.735][I][wmbus_user:2440]: ★ [id:03528221] packet #7 received / odebrano pakiet nr 7
[13:36:59.221][I][wmbus:2446]: Have data / odebrano dane (77 bytes) [RSSI: -111dBm, mode: T1 A, mfr:BMT id:03551587 ver:23 type:7 ci:7A]
[13:37:04.716][I][wmbus_user:2425]: ★ Have data / odebrano dane (143 bytes) [RSSI: -118dBm, mode: T1 A, mfr:NES id:00089907 ver:3 type:2 ci:7A]
[13:37:04.722][I][wmbus_user:2440]: ★ [id:00089907] packet #25 received / odebrano pakiet nr 25
SX1262 u mnie.
Nie masz tu RAW , ramek bo nie są potrzebne ( ESP na tym zrzucie nie pracuje w pełnym trybie diagnostycznym ). Są widoczne w MQTT Explorerze. Reszta magii dzieje już po stronie HA czyli dekodowanie i tworzenie encji.
Teren prawie pusty dookola. Mam działające już 2 zestawy (na C1101 oraz SX1262) co prawda nie odebralem nimi zadnych ramek,ktore zdekodowalbym na wmbusmeeters.org, ale.. jeszcze żaden odbiór się nie pokrył pomiedzy zestawami. Zadne bity raw ;-). Kazdy odbiera inne dane. Zesawy leza 1m od siebie
To właśnie potwierdza problem.
Jeżeli dwa zestawy leżą 1 m od siebie, a żaden odebrany RAW nie dekoduje się w wmbusmeters i nie ma żadnego wspólnego poprawnego telegramu, to nie jest jeszcze działający odbiór wM-Bus.
To znaczy tylko, że oba radia COŚ widzą. Poprawną ramkę masz dopiero wtedy, gdy przejdzie walidację/dekodowanie.
A zajrzałeś do tego issue, które linkowałem wyżej?
Ale może kluczowe pytanie - jakiej nakładki/licznika nasłuchujesz? oraz czy masz ewentualnie tuner SDR by nim zweryfikować czy cokolwiek licznik nadaje?
Komponent, który nie dekoduje lokalnie dla SX1262/SX1276 masz tam, wyżej zły link wstawiłem
Pierwotnie komponent @_Szczepan był bez dekodowania lokalnego (i z tego co wiem te funkcje ma zachowane, chociaż nie ma do tego aktualnej dokumentacji, więc posłuż się dokumentacją starych wersji, gdybyś chciał w ten sposób za pomocą aplikacji/addona wmbusmeters odbierać komponentem z tutejszego wątku).
może masz “ciszę w eterze” i wszystko co nasłuchałeś to zwyczajne zakłócenia
odbiornik przecież odbiera wszystko jak leci, a zakłócenia są zjawiskiem normalnym (po to jest tak skomplikowane dekodowanie, by skutecznie odróżnić sygnał użytkowy od śmieci).
Tak to niezły pomysł,ale nie pomógł( próbowałem 4 i 20MHz). Już mam po 20 kompilacji na zestaw. Widać na przesłanym forum u Szczepana że też ktoś mial również 8 bajtowe ramki. Przepełnienie bufora FIFO mineło, ale przestałem odbierać ramki dłuższe niż 8B, więc nie mogę potwierdzić na 100%. Może muszę się przemieścić w stronę aglomeracji i zobaczyć czy zdołam chociaż RAZ odebrać ramke, którą uda się zdekodować. Nie mam tunera SDR, wiec nie wiem czy licznik nadaje. Chcę odebrać dane z licznika Gama 350 G35, który ma dwie diody: sieć pali się na zielono i Rx/Tx - nie widziałem żeby nadawalo/odbieralo. Brak dokumentacji - wiec nie wiadomo co oznacza słowo sieć (DLMS,WMBUS, ENERGETYCZNA)
EDIT:
odebrałe ramkę nie ma przepełnienia FIFO, ale jak zwykle nic z niej nie wynika:
Dziwna rzecz, że raw jest identyczny jak wmbus. Powinien byc krótszy o HEADER i CRC
[18:02:49.687][D][wmbusmeters:351]: raw packet "3A55A3FD4649C034247A1CC4A113280E5615081D6072A15264009608DD97721B9E1B77B14895183A4829ABB8382062A107D3D0063265AA511A241000A84CE5A8D691362B98D02A57"
[18:02:49.688][D][wmbusmeters:351]: (wmbus) trimming frame A "3A55A3FD4649C034247A1CC4A113280E5615081D6072A15264009608DD97721B9E1B77B14895183A4829ABB8382062A107D3D0063265AA511A241000A84CE5A8D691362B98D02A57"
PS. @szopen . Podoba mi się to dekodowanie przez MQTT zamiast na poziomie plytki, ale chce narazie odebrac jakies dane z licznika 
Chcesz rozwiązać problem czy dalej interpretować każdy raw packet jako prawie-sukces?
Tu masz różnicę między kandydatem na ramkę a poprawnym telegramem.
U mnie też wpada RAW, ale komponent nie udaje, że to od razu poprawna ramka:
[20:27:01.805][W][wmbus:2248]: DROPPED packet / odrzucony pakiet:
stage=t1_decode3of6
reason=decode_failed
mode=T1
raw_got=134
decoded_len=0
final_len=0
RSSI=-120dBm
detail=symbols_total=178 symbols_invalid=4 raw_len=134
Czyli coś z eteru wpadło, ale nie przeszło dekodowania T1 3-of-6, więc zostało odrzucone.
Ta konkretna odrzucona ramka RAW wyglądała tak:
73471c8dc5a52d370e64b58b3535936a65b24e65995965965965b434b64db0d58b59659c6b136b2cb665a6cc4d25c5a9b2959659659659659659659659659659659672c5a36b43a95962e35b45964da5b15968e358d59698b58e596c5358b59668e38ea7159c5963ac59a5963ac5835962d65ac5963b25a55966745ac6435a659659695a9995
I dopiero następna linia pokazuje poprawnie odebrany telegram:
[20:27:03.318][I][wmbus_user:2425]: ★ Have data / odebrano dane (77 bytes)
[RSSI: -114dBm, mode: T1 A, mfr:BMT id:03528221 ver:23 type:6 ci:7A]
Czyli sedno jest takie: sam HEX/RAW w logu nie oznacza jeszcze poprawnej ramki. Poprawna ramka to taka, która przechodzi walidację i daje się rozpoznać jako telegram, np. ma mode, mfr, id, ci.
RAW może być tylko kandydatem albo śmieciem z eteru. Dopiero walidacja mówi, czy to faktycznie telegram wM-Bus.
Ty finalnie chcesz zobaczyć to :
Na screenie masz poprawnie zwalidowane telegramy opublikowane przez ESP do MQTT. Dopiero te telegramy trafiają dalej do wmbusmeters i są dekodowane.
W moim przykładzie komponentu cały tor jest taki:
radio → walidacja w komponencie → MQTT topic → wmbusmeters → encje/JSON
natomiast to repo ma tak:
radio → kandydat → RAW w logu → dopiero potem walidacja
Ty cały czas przeskakujesz z pierwszego etapu na ostatni.
Te liczniki domyślnie mają wyłączony wM-Bus (o ile w ogóle twój operator w twoim rejonie dostarcza je w takiej wersji, a nie innej). Więc jeśli operator nie aktywował transmisji na Twoje zlecenie, to na 100% licznik niczego nie nadaje.
Transmisja wMbus z liczników energii elektrycznej jest szyfrowana, więc przy aktywacji dostaniesz też klucz deszyfrujący, z doświadczeń wielu osób wynika, że aktywacja stosunkowo często się nie udaje za pierwszym razem (można też otrzymać niepoprawny klucz…).
Poszukaj wątków o licznikach Elgama Gama (dowolny model), jeśli wrzucisz fotkę licznika z usuniętymi danymi wrażliwymi, to pewnie ktoś postara się zidentyfikować jaką masz wersję licznika (jeśli nie wiesz co zamazać to wyślij zdjęcie na PW do mnie). Informacja jaki to operator też jest istotna (bo każdy operator sobie zamawia wersje pod siebie, w tym niektórzy wymyślili totalnie idiotyczne rozwiązania zamiast użyć coś co już istnieje na rynku od lat i się sprawdza).
Jeśli licznik ma takie logo
Rx/Tx to wskaźnik połączenia z systemem operatora (zwykle w technologii PLC lub GSM) takie działające połączenie jest niezbędne aby operator mógł włączyć moduł wM-Bus zdalnie).
Może być konieczna wizyta technika na miejscu (ponoć były partie liczników z wadliwie działającym oprogramowaniem komunikacyjnym).
Otrzymałem informację “Informuję, że odblokowano interfejs WM-BUS i nadano klucz”. Wiec chyba powinno dzialać. Klucz liczbowy 16znakow. Operator PGE. Licznik ELGAMA Gama 350 Typ G35. Ma logo Mbus i DLMS. Widziałem jest wątek o tych licznikach, ale najpierw musze mieć poprawne ramki. THX
Ma logo M-Bus (bez napisu wireless) czy wM-bus (dokładnie takie jak pokazałem), bo to są 2 różne rozwiązania…
Jeśli licznik faktycznie nadaje, to działającym sprzętem będziesz go w stanie nasłuchiwać.
Dzieki za czujność, detale są najważniejsze. Jest W jak Wireless
Telegramy o długości 326 zaczynające się na 8F27 Wyglądają na poprawne T1A. Poprawne w takim sensie, że poprawnie się zdekodowaly pierwsze trzy bajty, a z nich (po zdekodowaniu 3/6) obliczyliśmy że cały telegram ma 326 bajtow. (Gama 350 w niektórych wariantach nadaje właśnie 326 bajtowe telegramy).
Potem w trakcie ich odbierania, przepełnił się bufor, więc straciliśmy kolejne, nadchodzące bajty. Tak czy inaczej odebraliśmy 326, w środku kilku bajtów brakuje, na końcu mamy bajty z szumem.
I to powoduje odrzucenie pakietu, bo crc z szumu raczej nie jest okej.
