Działa na takim patyku z pudełka u mnie.
Dzieki za dobre słowo 
A jest szansa na dodanie obsługi CC1101?
Nigdy nie planowałem CC1101 także przepraszam. Od samego początku tworzyłem pod to co sam mam w domu i na czym mogłem to od razu testować.
EDIT : Masz dwie opcje.
- Kupić SX1276 albo SX1262 — to nie jest koszt, który rozwala budżet, a oszczędza dużo czasu i nerwów.
- Pójść własną drogą i rozwijać obsługę CC1101 samodzielnie, np. z pomocą AI — ale to już oznacza realny koszt czasu, testów i pracy, zwykle większy niż zakup sprzętu z punktu 1.
Ponieważ dalej zbieram statystyki pracy chipów SX1262/SX1276 na jednym kodzie mogę już śmiało postawić tezę że oba radia praktycznie odbierają tak samo z lekką przewagą SX1262:
To za ostanie 48h tylko w trybie T1.
Dodatkowo że zbieram statystyki odbioru z konkretnego licznika to w moim przypadku dla licznika energii elektrycznej wygląda to mniej więcej tak :
{"event":"meter_stats","id":"xxxxxxx","count":2087,"last_interval_s":30,"avg_interval_s":68,"last_rssi":-60,"avg_rssi":-57}
Czyli u mnie SX1276 odebrał średnio ramkę co 68 s
Ale już SX1262:
{"event":"meter_stats","id":"xxxxxxx","count":4413,"last_interval_s":29,"avg_interval_s":31,"last_rssi":-74,"avg_rssi":-73}
odebrał z tego samego licznika średnio co 30s.
Testów ciąg dalszy.
Na ten moment widzę, że SX1276 nie przegrywa na czułości, tylko na odporności na syf w eterze.
Mocny licznik słyszy, ale przy dużej liczbie obcych ramek i słabym tle zaczyna się dusić i gubi emisje.
SX1262 w tych samych warunkach radzi sobie wyraźnie lepiej, więc przy gęstym eterze to po prostu lepsza platforma.
2 Likes
Ponieważ dołożyłem tryb adaptacyjny do SX1276 to po jego zastosowaniu i przeanalizowaniu logów diagnostycznych wyszło mi :
SX1276 przegrywa głównie wtedy, gdy spotyka się duży telegram, wysoka częstotliwość emisji i zawalony eter. Dla małych i częstych ramek potrafi być blisko SX1262. Dla dużych i częstych ramek różnica wraca i wygląda już głównie na ograniczenie sprzętowe SX1276, którego soft może tylko częściowo złagodzić.
*) Tryb adaptacyjny skraca czas który SX1276 spędza na obsłudze śmieci. Każdy szybki abort to kilkadziesiąt milisekund odzyskanych dla kolejnego nasłuchu. W gęstym eterze gdzie na sekundę przypada kilka fałszywych startów — to bezpośrednio przekłada się na lepszą dostępność odbiornika dla legitymacyjnych pakietów.
@Krzyszof_K a próbowałeś może odbierać coś na SX1276 używając frameworka Arduino? czy tylko pod ESPHome, które z tego co czytam by default używa ESP-IDF?
walczę już jakiś czas i zawsze odbiera śmieci, gdy próbuje przenieść komponenty z ESPhome , natomiast wgrywając gotowy komponent jak by nigdy nic odbiera.
Od samego początku projekt był esp-idf bo wzorowałem się na projekcie Szczepana i tak już to zostało.
Ponieważ zakończyłem testy u siebie więc wstawiam wnioski ( dużo czytania ) :
DOKUMENT 1 — Techniczny
Analiza logów i danych diagnostycznych przeprowadzona wspólnie przez Claude (Anthropic) i ChatGPT (OpenAI)
Metodologia
Oba radia w tym samym miejscu fizycznym, tryb T1 only, ESPHome 2026.3.2. Środowisko: blok mieszkalny, ~29 urządzeń BMT (77 B, ~121 s) + NES 00089907 (143 B, ~30 s) + TCH 90830781 (56 B, ~34 s) + 2 wodomierze BMT (77 B, ~121 s). Testy nocne (cichy eter) i dzienne (pełny ruch).
W ciągu dnia liczba aktywnych urządzeń wzrosła o ~29 urządzeń BMT, co zwiększyło legitymacyjny ruch w summary ~6–7×. Jednocześnie false_start_like wzrósł tylko ~1.6× (noc ~75 → dzień ~125). Noise nie skaluje się liniowo z liczbą urządzeń — wolne BMT rzadko kolidują. Dominującym źródłem zakłóceń pozostają dwa szybkie urządzenia: 00089907 (143 B, ~30 s) i 90830781 (56 B, ~34 s). Wniosek praktyczny: “gęsty eter” w kontekście SX1276 to przede wszystkim kwestia intensywności nadawania, nie samej liczby urządzeń w zasięgu.
Wyniki ilościowe
| miernik | rozmiar | interwał | SX1276 noc | SX1276 dzień | SX1262 dzień |
|---|---|---|---|---|---|
00089907 |
143 B | ~30 s | 65% | ~40% | ~100% |
90830781 |
56 B | ~34 s | 96% | ~53% | ~100% |
03534159 |
77 B | ~121 s | — | ~88% | ~100% |
03528221 |
77 B | ~121 s | — | ~100% | ~100% |
Narożnik “duży + rzadki” w tym budynku nie istnieje — jedynym 143 B urządzeniem jest 00089907 nadający co 30 s. Na podstawie obserwowanego mechanizmu można oczekiwać wyniku wyraźnie lepszego niż dla 00089907, ale bez bezpośredniego pomiaru pozostaje to hipotezą.
Wzorzec strat SX1276
Straty nie są losowe. Dane z meter_stats dla 00089907 pokazują powtarzalny wzorzec: 30, 60, 30, 90, 60, 30, 89 — straty parami lub pojedynczo, nigdy trójkami. Radio wpada w krótki cykl obsługi zdarzeń false-start-like i wraca do normalnego rytmu. Mechanizm strukturalny, nie szum.
summary vs meter_window — pułapka diagnostyczna
SX1276 ma niski drop_pct w summary (~2–3%) bo adaptive ucina zdarzenia przed decode — te nie wchodzą do total. meter_window zdradza prawdziwą efektywność. SX1262 ma wyższy drop_pct (~11%) bo wchodzi głębiej w każdy sygnał i płaci za kolizje na etapie decode — ale nie traci pakietów przed decode.
Niższy drop_pct na SX1276 nie oznacza lepszego odbioru. Oznacza tylko inny rozkład strat.
Noise floor
false_start_like nocą: SX1276 ~75, SX1262 ~34. W identycznym eterze SX1276 generuje około 2× więcej zdarzeń typu false-start-like niż SX1262. To wygląda na różnicę architektury detekcji i front-endu RX, a nie tylko na tuning softu.
Adaptive skutecznie tnie śmieć (probe_abort_rssi pokazuje 95%+ abortów w ≤–90 dBm, śladowe wartości w –80..–89 dBm przy normalnej pracy — nie wygląda na to, by istotnie ucinał legitymacyjne mierniki) ale nie eliminuje samego kosztu obsługi tych zdarzeń na SX1276.
Próg roboczy
Próg roboczy rzędu ~120–150 s w tym środowisku testowym jest teraz mocno potwierdzony. Dla 03528221 (77 B, ~121 s) SX1276 i SX1262 dały identyczny wynik zarówno w oknie 900 s, jak i w oknie count 10/1096 s — ten sam dzień, ten sam eter. Jednocześnie nie każdy licznik ~121 s wypada identycznie (03534159 nadal pokazuje niewielką różnicę jednej ramki w 900 s), więc próg należy traktować jako praktyczny w tym środowisku testowym, a nie absolutny.
Konkluzja
SX1276 nie przegrywa zawsze — przegrywa wtedy gdy licznik nadaje zbyt często względem jego zdolności do przetrwania śmiecia z otoczenia, a rozmiar pakietu ten problem dodatkowo wzmacnia.
Poniżej progu ~120–150 s straty rosną wraz z częstotliwością i rozmiarem. Powyżej tego progu SX1276 z adaptive może wypadać porównywalnie z SX1262 nawet w dziennym eterze.
Pozostały gap wygląda już głównie na ograniczenie sprzętowe SX1276 (mały FIFO / brak architektury bufora klasy SX1262), którego soft może tylko częściowo złagodzić. SX1262 wygrywa wszędzie gdzie jest presja czasowa: duże pakiety, częste nadawanie, gęsty eter.
O adaptive
Przed poprawką wszystkie tryby psuły odbiór. Po poprawce adaptive działa zgodnie z założeniem: ewaluacja raz na okno summary przed resetem liczników, hold 5 minut z hysteresis, logowanie tranzycji. Nie wygląda na to, by istotnie ucinał legitymacyjne mierniki. Jest to pierwsza wersja adaptive która obroniła się danymi przez całą noc i dzień.
Nota metodologiczna
Wnioski powstały na podstawie rzeczywistych danych diagnostycznych z działającego systemu. Analiza logów, interpretacja danych i wzajemna weryfikacja wniosków prowadzone były równolegle przez Claude (Anthropic) i ChatGPT (OpenAI). Rozbieżności między obiema AI były rozstrzygane danymi, nie argumentami. Końcowy dokument uwzględnia korekty obu stron.
DOKUMENT 2 — Dla użytkownika
Analiza przeprowadzona wspólnie przez Claude (Anthropic) i ChatGPT (OpenAI)
Krótko: który chip wybrać?
Jeśli mieszkasz w domu jednorodzinnym i masz tylko kilka liczników — SX1276 wystarczy. Jeśli mieszkasz w bloku — kup SX1262. Poniżej wyjaśnienie dlaczego.
Na czym polega różnica w praktyce?
Liczniki nadają swoje dane radiowo — mniej więcej tak jak WiFi, tylko na innych częstotliwościach. W bloku mieszkalnym nadaje jednocześnie dziesiątki liczników od sąsiadów. To jest właśnie “gęsty eter” — dużo urządzeń nadających w tym samym czasie w tym samym miejscu.
SX1276 ma starszą architekturę — gdy odbiera jeden pakiet, musi to zrobić w całości zanim będzie gotowy na następny. Gdy w eterze jest dużo ruchu, czasem “nie zdąży” i pakiet przepada. SX1262 ma nowszą architekturę z większym buforem wewnętrznym — radzi sobie znacznie lepiej w zatłoczonym środowisku.
Wyniki testów — ile pakietów dociera?
Testy przeprowadzone w bloku mieszkalnym, oba urządzenia w tym samym miejscu, w tym samym czasie:
| Typ licznika | Jak często nadaje | SX1276 | SX1262 |
|---|---|---|---|
| Licznik ciepła (duży) | co 30 s | ~40% | ~100% |
| Licznik testowy (mały) | co 34 s | ~53% | ~100% |
| Wodomierz | co 2 minuty | ~88–100% | ~100% |
Innymi słowy: SX1276 w bloku gubi co drugi lub co trzeci pakiet z szybkich liczników. Wodomierze które nadają rzadziej — odbiera prawie tak samo dobrze jak SX1262.
Czy to jest problem?
Zależy od zastosowania. Jeśli licznik nadaje co 30 sekund a Ty potrzebujesz odczytu raz na godzinę — utrata połowy pakietów nie robi żadnej różnicy, bo i tak za każdą godzinę masz kilkadziesiąt szans na odczyt. Jeśli jednak zależy Ci na każdym pakiecie albo chcesz monitorować przepływ w czasie rzeczywistym — SX1262 jest właściwym wyborem.
Co to jest “tryb adaptive” i czy pomaga?
SX1276 ma wbudowany mechanizm który uczy się rozpoznawać “śmieciowe” sygnały w eterze i odcina je wcześnie, zamiast marnować czas na ich przetwarzanie. Po poprawkach w kodzie ten mechanizm działa poprawnie — wcześniej był zepsuty i pogarszał odbiór zamiast pomagać.
Adaptive poprawia sytuację — szczególnie stabilizuje odbiór i zmniejsza losowość strat. Ale nie zmienia fizycznych ograniczeń układu. SX1276 z adaptive nadal przegrywa z SX1262 w szybkim ruchu, po prostu przegrywa bardziej przewidywalnie.
Kiedy SX1276 wystarczy, a kiedy potrzebny jest SX1262?
SX1276 wystarczy gdy mieszkasz w domu jednorodzinnym lub masz tylko własne liczniki bez sąsiadów, Twoje liczniki nadają rzadko (wodomierze, liczniki ciepła które nadają co 2+ minuty) albo nie zależy Ci na każdym pojedynczym pakiecie.
SX1262 jest właściwym wyborem gdy mieszkasz w bloku z wieloma licznikami sąsiadów, masz liczniki które nadają często (co 30–60 sekund), planujesz fotowoltaikę lub inne urządzenia z dużymi i częstymi pakietami, albo zależy Ci na maksymalnej niezawodności odczytu.
Nota
Wnioski oparte na rzeczywistych testach w środowisku bloku mieszkalnego. Analiza przeprowadzona wspólnie przez Claude (Anthropic) i ChatGPT (OpenAI) na podstawie danych diagnostycznych z działającego systemu. Wyniki mogą się różnić w zależności od budynku i liczby urządzeń w zasięgu.
UZUPEŁNIENIE :
Tryb both (T1+C1) — analiza i wnioski
Analiza przeprowadzona wspólnie przez Claude (Anthropic) i ChatGPT (OpenAI)
Uwaga metodologiczna
Wyniki trybu both nie mogą być porównywane bezpośrednio z wynikami T1-only — to osobny przypadek testowy. Włączenie nasłuchu C1 fundamentalnie zmienia obraz odbioru dla obu chipów.
Wcześniejsze wersje tej analizy zawierały zastrzeżenie o skażeniu statystyk dla licznika 90830781 (TCH), który nadaje jednocześnie w T1 i C1 pod tym samym ID. Problem ten został rozwiązany przez fix mode-split który wprowadził klucz (meter_id, link_mode) w mapie statystyk — T1 i C1 są teraz śledzone jako osobne strumienie z osobnymi topikami MQTT (/T1/window/ vs /C1/window/). Dane w tej wersji dokumentu są już czyste.
Pułapka summary w trybie both
W tym teście summary dał odwrotny obraz rzeczywistości:
| SX1276 | SX1262 | |
|---|---|---|
ok |
28/28 | 20/24 |
dropped |
0 | 4 |
hint |
GOOD | OK |
Na papierze SX1276 wygląda lepiej. meter_window pokazuje coś przeciwnego. Mechanizm jest ten sam co w T1-only: SX1276 adaptive tnie zdarzenia przed decode, więc summary jest czyste — ale radio traci pakiety zanim trafią do pipeline.
Zasada potwierdzona po raz kolejny: summary mierzy czystość decode. meter_window mierzy realną skuteczność odbioru.
Wyniki ilościowe — tryb both, dzień
| miernik | rozmiar | interwał | SX1276 T1-only | SX1276 both | SX1262 T1-only | SX1262 both |
|---|---|---|---|---|---|---|
00089907 |
143B | ~30s | ~40% | ~13% | ~100% | ~63% |
90830781 T1 |
56B | ~35s | ~53% | ~4% | ~100% | ~81% |
03534159 |
77B | ~121s | ~88% | ~95%† | ~100% | ~100% |
03528221 |
77B | ~121s | ~100% | ~41% | ~100% | ~54% |
†03534159 nadaje przy RSSI –52 dBm (znacznie mocniejszy sygnał niż pozostałe mierniki). Przy wystarczająco silnym sygnale koszt przełączania T1/C1 jest pomijalny — to wyjątek potwierdzający regułę, nie obalający ją.
Uwaga: 00089907 na SX1276 both nie pogarsza się względem T1-only (~40% w obu trybach). Nie oznacza to braku kosztu both — oznacza, że SX1276 był już wcześniej blisko swojego praktycznego sufitu dla tego profilu ruchu.
Koszt przełączania T1/C1 — czysty overhead
W testowanych oknach rzeczywisty ruch C1 był niski lub epizodyczny, a mimo to sama obecność harmonogramu both wyraźnie obniżała skuteczność T1. Degradacja wynika wyłącznie z mechanizmu cyklicznego przełączania synchronizacji, nie z obsługi rzeczywistych pakietów C1.
| koszt | SX1276 | SX1262 |
|---|---|---|
| szybkie liczniki (~30–35s) | –60 do –96% | –19 do –37% |
| wolne liczniki (~121s) | –59 do –46%* | ~0 do –46% |
*03534159 jest wyłączony z tej oceny ze względu na wyjątkowo silny sygnał.
Korekta progu użyteczności
Wcześniej ustalony próg roboczy ~120–150 s dotyczył wyłącznie trybu T1-only. W trybie both:
- Na SX1262 próg nadal obowiązuje dla wolnych liczników przy typowym sygnale.
- Na SX1276 próg przestaje mieć znaczenie — nawet liczniki 121s stają się zawodne, a szybkie liczniki (~30s) są praktycznie niewidoczne.
Ocena C1 w trybie both
Środowisko testowe zawierało tylko jeden licznik nadający w C1 (90830781, TCH), przy RSSI –85 do –99 dBm — na granicy czułości obu chipów. Liczba zdarzeń C1 w oknie 900s była zbyt mała (2–6 pakietów) żeby wyciągać wiarygodne wnioski o skuteczności C1 w trybie both.
Jedyna uczciwa obserwacja: SX1276 w kilku oknach wykazywał c1.total=0 lub c1_preamble drop przy –99 dBm, co sugeruje że C1 jest dla niego dodatkowym obciążeniem przy i tak słabym sygnale. Ocena C1 w both wymaga środowiska z większą liczbą urządzeń C1 i lepszymi poziomami sygnału.
Adaptive nie jest przyczyną
Adaptive działa poprawnie w obu trybach — aktywuje się, trzyma hold, logi są spójne. Problemem jest wyłącznie koszt harmonogramu both i sposób, w jaki SX1276 znosi podział czasu między T1 a C1.
Wniosek praktyczny
Tryb both na jednym urządzeniu jest kompromisem, który osłabia odbiór obu trybów. Optymalnym rozwiązaniem przy środowisku z mieszanym T1/C1 są dwa osobne urządzenia — każde w dedykowanym trybie. Koszt drugiego ESP32 z chipem radiowym jest pomijalny wobec strat pakietów.
- SX1276 +
both: niezalecane w środowisku z istotnym ruchem T1. Szybkie liczniki (~30s) są praktycznie niewidoczne, wolne degradują o 40–60%. - SX1262 +
both: ma sens tylko wtedy, gdy korzyść z odbioru C1 uzasadnia około 19–37% koszt po stronie szybkich liczników T1. - Dwa urządzenia T1-only + C1-only: optymalne dla każdego środowiska z oboma trybami.
Nota
Wnioski oparte na testach w środowisku bloku mieszkalnego z jednym licznikiem C1. Analiza przeprowadzona wspólnie przez Claude (Anthropic) i ChatGPT (OpenAI).
Wrzuciłem release 1.1.0.
Najważniejsza zmiana dotyczy SX1276 i trybu adaptive.
Poprawiona została logika tak, żeby aktywacja reagowała na realne straty odbioru, a nie tylko na sam szum radiowy albo false starty. W praktyce chodzi o to, żeby tryb adaptive był mniej nerwowy w trudnym, ale nadal używalnym środowisku RF.
Do tego doszły:
- nowy topic MQTT
suggestionz podpowiedziami diagnostycznymi i gotowymi snippetami YAML - event MQTT
busy_ether_changedpokazujący zmiany stanu adaptive - rozbudowana diagnostyka
summary,summary_15min,summary_60min - snapshoty per-meter dla wyróżnionych liczników
- porządki w logice i dokumentacji po testach na realnym sprzęcie
Dzień dobry,
Projekt super, tylko zauważyłem małą niedogodność w działaniu. Otóż komponent rozpoznaje bezproblemowo wszystkie moje liczniki (przynajmniej u mnie). Dodać już nie dają się wszystkie. Zauważyłem, że wszystkie liczniki, które przedstawiają się meter_id: w postaci cyfrowej to z nimi nie ma problemu, ale mam kilka liczników, które przedstawiają się ID np: 417f0666 lub 0x414ffb83 gdzie w składni są literki i z tymi jest problem. Pomimo dodania komponent nie rozpoznaje licznika i go odrzuca. Można to jakoś naprawić?
Podajesz w formacie BCD bo taki format przyjmuje czyli dziesiętnie.
Edit.
Poprawiłem - skompiluj jeszcze raz.
Wszystkie poniższe formaty:
0001234
0x0001234
417f0666
zostaną prawidłowo rozpoznane
Możesz podpowiedzieć jak mam skompilować to na nowo? W ESPHOME wyczyściłem poprzednie ściągnięte dane i zainstalowałem do mojego modułu ponownie. Odinstalowałem i usunąłem repo,a następnie dodałem i zainstalowałem na nowo, ale wciąż mam ten sam błąd:
[wmbus-bridge][WARN] Invalid meter_id for ‘licznik_glowny_1’ → skipping (got: ‘0x417f0666’)
[wmbus-bridge][WARN] Invalid meter_id for ‘licznik_ogrod_1’ → skipping (got: ‘0x4140b841’)
@kokot1973 Dzięki , już poprawione. U mnie nie występowały liczniki HEX więc nie brałem tego pod uwagę.
Wersja podniesiona - THX
Bardzo dziękuję, teraz już ładnie śmiga. Pozdrawiam.
Najnowsza wersja na xiao seed niestety z takim błedem:
INFO Successfully resolved xiao-seed-wmbus @ 192.168.68.111 in 0.000s
INFO Successfully connected to xiao-seed-wmbus @ 192.168.68.111 in 0.004s
INFO Successful handshake with xiao-seed-wmbus @ 192.168.68.111 in 0.065s
[17:06:52.077][E][esp32.crash:224]: *** CRASH DETECTED ON PREVIOUS BOOT ***
[17:06:52.089][E][esp32.crash:227]: Reason: Fault - IllegalInstruction
[17:06:52.089][E][esp32.crash:231]: PC: 0x4037B26C (fault location)
WARNING Decoded 0x4037b26c: panic_abort at /data/cache/platformio/packages/framework-espidf/components/esp_system/panic.c:489
[17:06:52.267][E][esp32.crash:245]: BT0: 0x4037B269 (backtrace)
WARNING Decoded 0x4037b269: panic_abort at /data/cache/platformio/packages/framework-espidf/components/esp_system/panic.c:477
[17:06:52.389][E][esp32.crash:245]: BT1: 0x4037B231 (backtrace)
WARNING Decoded 0x4037b231: esp_system_abort at /data/cache/platformio/packages/framework-espidf/components/esp_system/port/esp_system_chip.c:87
[17:06:52.504][E][esp32.crash:245]: BT2: 0x4037B9D2 (backtrace)
WARNING Decoded 0x4037b9d2: vApplicationStackOverflowHook at /data/cache/platformio/packages/framework-espidf/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:563
[17:06:52.626][E][esp32.crash:245]: BT3: 0x4037C20F (backtrace)
WARNING Decoded 0x4037c20f: vTaskSwitchContext at /data/cache/platformio/packages/framework-espidf/components/freertos/FreeRTOS-Kernel/tasks.c:3698 (discriminator 7)
[17:06:52.743][E][esp32.crash:245]: BT4: 0x4037B570 (backtrace)
WARNING Decoded 0x4037b570: _frxt_dispatch at /data/cache/platformio/packages/framework-espidf/components/freertos/FreeRTOS-Kernel/portable/xtensa/portasm.S:451
[17:06:52.866][E][esp32.crash:245]: BT5: 0x4037B566 (backtrace)
WARNING Decoded 0x4037b566: _frxt_int_exit at /data/cache/platformio/packages/framework-espidf/components/freertos/FreeRTOS-Kernel/portable/xtensa/portasm.S:246
[17:06:52.985][E][esp32.crash:258]: Use: addr2line -pfiaC -e firmware.elf 0x4037B26C 0x4037B269 0x4037B231 0x4037B9D2 0x4037C20F 0x4037B570 0x4037B566
Po powrocie na 1.0.1 wszystko wróciło do normy.
Esp home najnowszy 2026.3.3
-
Już poprawione i wprowadzone.
-
W YAML dopisz :
wmbus_radio:
........
listen_mode: t1
receiver_task_stack_size: 6144 # <=zwiększenie stosu , domyślnie jest 3072.
Skompiluj.
Potwierdzenie w log-u ESP :
[17:55:46.605][I][wmbus:2000]: Radio active / radio aktywne: SX1276 | Listen mode / tryb nasluchu: T1 only | receiver_stack=6144 bytes
Daj znać czy pomogło.
Dla testów - bo moduł tani w porównaniu do Heltec - zakupiłem takie małe cuś za 66 PLN:
Jak przetestuję to wrzucę porównanie.
EDIT:
Udało mi się to maleństwo uruchomić.
Czyta :))))
EDIT:
Wstępnie mogę napisać iż Heltec V4 jest bardzo ale to bardzo czuły.
Natomiast XIAO jest bardziej selektywny a jednocześnie głuchy na otoczenie.
Ale statystycznie oba układy czytają liczniki łep w łep.
EDIT:
Pomiar z rana i…
Wstępnie wygląda na to, że Xiao mniej „widzi” całe otoczenie RF, ale lepiej odcina ruch nieistotny dla odbioru testowanych liczników, dzięki czemu skuteczność odbioru target meterów nie spada, a bywa nawet nieco lepsza niż na Heltecu ale jest to wartość marginalna.
1 Like
Chciałbym dodać kilka słów od siebie.
Posiadam odczyt stanu liczników wody (apator 162) już od ponad 2 lat. Korzystałem dotychczas z cc1101 i dodatku od @_Szczepan za co mu serdecznie dziękuje! Obecnie nawet wersja v5 działa bardzo dobrze z cc1101.
Jednakże już kilka razy zdarzała się sytuacja że któraś aktualizacja esphome powodowała problemy z odczytem liczników. Dodatkowo cc1101 w moim przypadku miało na tyle mały zasięg działania że nie odczytywało licznika w domu obok w którym również monitoruje zużycie, w efekcie musiałem zamontować dwa takie moduły itp.
Natrafiłem na poniższy projekt autorstwa @Krzyszof_K i postanowiłem przetestować. Zakupiłem HELTEC V4 (ceny oszalały ostatnio) i wgrałem przygotowany kod przez autora.
Wszystko na drodze Licznik >> HELTEC V4 >> MQTT wydawało się że działa spoko, ALE dodatek do HA nie odczytywał nic z mqtt. Czyli gdzieś był problem na drodze MQTT > ADDON wM-Bus bridge >> MQTT Sprawdzałem mqtt explorer i odpowiednie wpisy z HELTEC V4 się pojawiały.
Problemem okazały się ACL w brokerze MQTT (mam natywnie instalowane mosquito jako dodatek) który nie miał przyznanych żadnych uprawnień dla usera addons którego używał dodatek. Po dodaniu odpowiednich wpisów wszystko śmiga (Po pojawieniu się encji licznika w MQTT odczekaj chwilkę i pojawi się również odczyt wartości licznika)
Na dodatek HELTEC V4 zbiera odczyty liczników z mojego jak i sąsiadującego licznika na czym mi zależało.
Jedyna rzecz jakiej mi brakuje w to w opcji konfiguracji liczników dodanie offsetu dla odczytu, no ale to można samemu ręcznie ogarnąć.
W każdym razie polecam! Śmiga jak ta lala
PS. Podziękowania dla autora za pomoc na PW.
1 Like
Na ceny wpływu nie mamy. Dlatego na próbe kupiłem XIAOSEED i się sprawdził a kosztuje na dziś nawet na Allegro połowę tego co Heltec na Ali.
Wprawdzie nie ma ładnej obudowy etc. ale działa.
A co do PW : zawsze o ile mogę służę pomocą