Działa SX1262, brak aktualizacji encji w HA wynikał z faktu, że przeoczyłem zmianę definicji pół field oraz UoM z v4, które połączyły się w v5 w jedno pole field:
field: "total"
unit_of_measurement: "m³"
na
field: "total_m3"
@kniazio jadę na najnowszym wczorajszym wydaniu z main.
Czy wersji 5.x jest możliwość ograniczenia ładowania sterowników?
Próbowałem różnych zapisów:
wmbus_common:
drivers:
- amiplus
wmbus_common:
drivers: ["amiplus"]
I zawsze zwraca błąd przy próbie kompilacji.
Na dzień dzisiejszy nie ma dopóki Szczepan tego nie poprawi
Próbujesz różnych zapisów, a powinieneś takich jak są w dokumentacji komponentu. Repozytorium Github to pierwsze miejsce gdzie należy szukać informacji, czyli u źródła. Tym bardziej, że projekt wciąż się zmienia, dostosowuje i rozwija.
Przepraszam może nie jasno sformułowaniem zapytanie.
Ale to co podajesz to jest definicja licznika, a dokładnie w jaki sposób ma przetworzyć przechwycona ramkę danych. Czyli ma ja obsłużyć jako “amiplus” z odpowiednim kluczem i danym ID licznika.
Ja pytałem czy jest sposób aby nie ładować do kompilacji wszystkich możliwych liczników.
I wyczyszczenie środowiska z poprzednich kompilacji + kawałek kodu:
wmbus_common:
drivers: !!set
amiplus: null
Spowodowało że użycie pamięci FLASH spadło z ~80% do ~60%.
A odpowiadając na Twoje zarzuty, to czytam dokumentację, stąd nawet moje pytanie bo w poprzednich wersjach była taka możliwość, a w tej najnowszej już takiego zapisu w przykładzie nie znalazłem.
Wydaje mi się, że ta zmiana wprowadza właśnie taką funkcjonalność.
Use FILTER_SOURCE_FILES to exclude unused drivers and transceivers · SzczepanLeon/esphome-components@249d1e5
W definicji type jest powiązanie jaki driver ma iść do kompilacji.
Use FILTER_SOURCE_FILES to exclude unused drivers and transceivers
Replace the fragile WMBusComponentManifest class-swap hack with
ESPHome's official FILTER_SOURCE_FILES hook for excluding unused
driver_*.cc files. Add the same mechanism to wmbus_radio to exclude
unused transceiver_*.cpp/.h files based on the configured radio_type.
Przetłumacz sobie dokładnie ten tekst. Bo według mnie to oznacza to tyle że musisz w komponencie wmbus_common dodać wykluczenia (aby właśnie nie ładował wszystkich bibliotek liczników) i to samo zrobić w komponencie wmbus_radio aby nie próbował deszyfrować wszystkiego jak leci.
Ja tak to rozumiem. Kod komponentu na podstawie określonego typu w sekcji wmbus_meter sam zawęża wybór drivera dla danej kompilacji. Może najlepiej jak @_Szczepan potwierdzi to sam.
Dokładnie to było rozkminione w wątku i sam Szczepan napisał wprost, że „jest bug do poprawy w kodzie”.
I tak: wygląda na to, że nie poprawił — oficjalny issue „Error when specifying drivers” (#259) jest nadal Open (założony 4 Sep 2025) i opisuje dokładnie ten przypadek; działa tylko drivers: all.
W wersji 5.0.4 wystarczy dodać jak pisałem wyżej:
wmbus_common:
drivers: !!set
amiplus: null
I wtedy pozostałe biblioteki liczników ignoruje przy kompilacji.
To jest właśnie hack pod źle zrobiony schemat w komponencie.
To jest akurat dość banalne - skompiluj w starej wersji i pobierz wsad w obu formatach (dla nowego urządzenia i dla OTA) - to jest ostatnia opcja do wyboru (Install → Manual Download), nazwij sobie te pliki jakoś sensownie, będziesz mógł sobie przywrócić działający wsad, nawet jeśli kompilacja w nowej wersji wyprodukuje coś co się kompiluje, a nie działa.
Jest tak jak piszesz. Dla klasycznych użytkowników napisałem to tak, że ładowane są tylko te drivery, które są deklarowane jako używane w którymś z meterów.
Jeśli podasz pod wmbus_common drivers: all lub listę (w przypadku repo Szczepana set), to nadpisujesz sobie automatyczny dobór sterowników ręcznym. I wtedy ładuje Ci dokładnie te które zażądałeś.
Jesteśmy w trakcie portowania/testowania wmbusmeters 1.20.0: GitHub - IoTLabs-pl/ESPHome-Components at wmbusmeters-1.20.0 co pozwoli na rozszerzenie listy dostępnych sterowników o te deklarowane w plikach xmq, ale nie wypuścimy tej wersji pod tagiem przez jeszcze pewien czas, bo mamy jeszcze pomysł, jak dość znacznie odciążyć komponent pamięciowo i wtedy zmiany wyjechałyby razem do mastera.
W tejże nowej wersji też jest wykorzystanie natywnego filtrowania plików źródłowych: jest to dość nowy feature w esphome. Wcześniej to filtrowanie również działało/działa w repo Szczepana, ale było robione w zdecydowanie bardziej rzeźbiarski sposób, bo nie było możliwości prostego powiedzenia loaderowi ESPHome które pliki ma ładować: domyślnie ładuje wszystkie z directory z danym komponentem jeśli zgadzają mu się rozszerzenia.
A z jeszcze kolejnych planów, to pewnie pierwsze do repo wjedzie wiszący PR na CC1101, SX1262 dokleję, gdy będę miał dużo dłuższą wolną chwilę by napisać driver tak, by móc łapać komunikaty nielimitowanej długości. Przeoranie driverów radiowych średnio mi się widzi dla SXa z zabitą na stałe maksymalną długością by pewnie w niedalekiej przyszłości znowu je przeorać żeby zrobić tego SX1262 na finalnie
Dziękujemy za wyjaśnienie. Cieszę się, że mnie logika nie zawodzi (jeszcze) i dobrze zrozumiałem ten mechanizm.
@kubasa a wyjaśnisz jak to wszystko działa?
Rozumiem, że istnieje główny projekt wmbusmeters rozwijany przez autora ze Szwecji, natomiast w przypadku mikrokontrolerów ESP powstało kilka niezależnych implementacji i komponentów.
Korzystam z komponentu SzczepanLeon na GitHubie do ESPHome i próbuję zrozumieć zależności między projektami.
Czy Twoje PR (pull requesty) trafiają do tego właśnie repozytorium, czy rozwijasz osobny fork lub zupełnie niezależny projekt?
Link, który podałeś, prowadzi do IoT-LabsPL, więc nie jestem pewien, jak to się ma do komponentu Szczepana, z którego obecnie korzystam.
Kojarzę też projekt Mariusza Woszczyńskiego, ale z tego co pamiętam, on bazował na rozwiązaniu Szczepana.
Czy mógłbyś krótko wyjaśnić, jak wygląda struktura tych projektów, kto jest maintainerem którego repozytorium i jakie są między nimi zależności?
Rzadko śledzę tu dyskusje, więc trudno mi zorientować się, kto jest deweloperem, a kto tylko użytkownikiem.
PS. CC1101 w v5 już działa u SzczepanLeon (choć w moim przypadku v5 vs v4 gubi masę ramek i zostaję przy SX1262), a XMQ to jest coś za czym czekam, więc trzymam kciuki 
Historia jest dość skomplikowana i nie znam jej w całości:
Któregoś razu zmieniłem mieszkanie i mogłem poprosić operatora energetycznego o odpalenie wM-Busa i postanowiłem to jakoś dopiąć do HA. Dość szybko znalazłem komponent Szczepana w wersji v4. Generalnie średnio mi się podobała jakość kodu, wszystko było jedną wielką funkcją, bez delegacji odpowiedzialności, a to mi bardzo przeszkadzało w uruchomieniu tego na SX1276, z którym płytki akurat miałem.
Napisałem do Szczepana, z pytaniem, czy jest sens i warto właściwie przepisać dużą część kodu od nowa i czy nie miałby nic przeciw, żebym trochę kosztów (czasu) pracy nad softem odbił sobie sprzedażą gotowych modułów. Powiedział mi, że generalnie komponent rzeźbił sam, w postaci odbiornika 868, który przesyłał dane dalej, do dockerowego wmbusmetersa, który to rozkodowywał i przez mqtt pchał do HA, potem znalazł się ktoś kto odchudzonego wmbusmetersa do tego dokleił i uruchomił na ESP i tak jakoś to wszystko powstało (mogę się mylić, tu by się Szczepan musiał wypowiedzieć). Powiedział, że są też inni którzy sprzedają gotowe moduły i w żaden sposób nie ma nic przeciw, żebym spróbował sobie coś czasem sprzedać.
Usiadłem więc któregoś razu i przepisałem właściwie całą logikę komponentu, w szczególności tak, by na przykład móc w miarę sensownie doklejać kolejne sterowniki do transceiverów. Przejrzałem też sporo wmbusmetersa, tak, by zintegrować go wycinając z niego jak najmniej, by przy kolejnych jego wydaniach, łatwiej robiło się merdże.
I tak powstał komponent, który kiedyś był opisany jako dirty fork i jest podlikowany w README repo Szczepana.
Potem któregoś razu, Szczepan podciągnął całe moje repo tagując je jako V5 i taka nazwa się chyba przyjęła, a gałęzie się nieco rozbiegły.
Ogólnie staram się w miarę możliwości czasowych, zarządzać sobie tym moim repozytorium (przeniosłem je do mojej firmowej organizacji (IoTLabs)) i dodawać nowe featuresy, mam jednak nieco odmienną politykę developmentu niż w repo Szczepana. W oryginalnym repo, jest dość duża liczba współautorów i dość duża liczba nowych zmian psuje coś, co działa w jakiejś poprzedniej wersji, co rodzi pewne problemy, bo większość użytkowników binduje się na gałąź master, która może być nieco niestabilna.
U mnie to wszystko idzie wolniej, w dużej części priorytety developmentu są dyktowane przez aktualnych/przyszłych użytkowników modułów które staramy się jakoś sprzedawać (choć i tak, gdyby chcieć to robić fulltime, to byśmy się nie utrzymali), a kolejne zmiany nie są scalane do mastera i wydawane pod tagiem póki nie mam pewności, że nie wywróci to działania na urządzeniach które działają dotychczas z dość standardową konfiguracją.
Pewnie dałoby się z powrotem to jakoś scalić, ale wymagałoby to wprowadzenia jakiejś sensownej polityki wydawniczej, by ustabilizować działanie w różnych wersjach ESPHome i tak dalej.
W jaki sposób skonfigurowałeś CC1101 w V5? Próbowałem przed chwilą i poległem.
dzięki @kubasa za wyjaśniania i trzymam kciuki za dalszy rozwój, szczególni XMQ
Jednocześnie rozumiem że, twój projekt idzie swoją ścieżką, a Szczepana inna i jeśli pojawi się u Ciebie np. wsparcie xmq to u Szczapana może się pojawi się, ale po przeróbkach, bo wprost zmergować chyba się nie będzie dało ze względu na PR wprowadzone w między czasie. I to samo w drugą stronę, u Szczapana jest SX1262 i CC1101 (oba dodane w w ostatnim tygodniu), a u Ciebie tylko SX1276.
Czy nie lepiej wspólnie pracować nad jednym projektem?
Kiedyś kupiłem od Mariusza W. gotowca z v3, ale poszedłem w PoE i moduł ten leżał w szufladzie do tego tygodnia.
Testowo uruchomiłem na nim v5, mój kod poniżej, ale gubi masę ramek (tj w ogóle ich nie rejestruje w logu, może jedną na 50 złapie). Sprawdziłem ten sam moduł z v4 i wszystko czyta. Być może coś źle skonfigurowałem lub te CC1101 w v5 jeszcze nie działa jak należy, nie wiem, nie wnikam, przesiadłem się na SX1262 i jestem bardzo zadowolony.
esphome:
name: wmbus-wifi
friendly_name: WMBus WiFi
platformio_options:
upload_speed: 921600
external_components:
- source: github://SzczepanLeon/esphome-components@main
esp32:
board: lolin_s2_mini
flash_size: 4MB
framework:
type: esp-idf
psram:
mode: quad
time:
platform: homeassistant
id: homeassistant_time
# Enable logging
logger:
#task_log_buffer_size: 1500B
id: component_logger
level: DEBUG #VERY_VERBOSE #VERBOSE #VERY_VERBOSE #DEBUG #INFO #
# Enable Home Assistant API
api:
encryption:
key: "mykey"
ota:
- platform: esphome
wifi:
#power_save_mode: LIGHT #none
#reboot_timeout: 10min
output_power: 19.5dB
#fast_connect: true
networks:
- ssid: !secret wifi_ssid_ha
password: !secret wifi_password_ha
# static IP configuration (instead of data from the secret file)
manual_ip:
static_ip: 192.168.13.108
gateway: 192.168.13.1
subnet: 255.255.255.0
- ssid: !secret wifi_ssid_fritz
password: !secret wifi_password_fritz
#fast_connect: true
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "WMBUS Reader v2"
# password: "password_12345678"
captive_portal:
web_server:
version: 3
spi:
clk_pin:
number: GPIO36
# ignore_strapping_warning: true
mosi_pin: GPIO35
miso_pin: GPIO37
# mqtt:
# broker: !secret mqtt_broker
# port: 1883
# username: !secret mqtt_user
# password: !secret mqtt_password
wmbus_radio:
radio_type: CC1101
cs_pin: GPIO34
reset_pin: GPIO1
irq_pin: GPIO2
on_frame:
- then:
- logger.log:
format: "RSSI: %ddBm T: %s (%d)"
args:
- frame->rssi()
- frame->as_hex().c_str()
- frame->data().size()
# - then:
# - mqtt.publish:
# topic: wmbusmeters/PoE_Poznan/telegram_rtl
# payload: !lambda return frame->as_hex(); // frame->as_rtlwmbus();
- mark_as_handled: True
then:
wmbus_common:
drivers: !!set
apatorna1: null
apator162: null
wmbus_meter:
- id: ZW_MAIN_WIFI
meter_id: 0x04913581
type: apatorna1
key: "00000000000000000000000000000000"
mode:
- T1
- C1
# on_telegram:
# then:
# - wmbus_meter.send_telegram_with_mqtt:
# topic: wmbus-test/telegram
sensor:
- platform: wmbus_meter
parent_id: ZW_MAIN_WIFI
name: "Adapr NA 1 total RSSI"
field: "rssi_dbm"
accuracy_decimals: 0
unit_of_measurement: "dBm"
device_class: "signal_strength"
state_class: "measurement"
entity_category: "diagnostic"
- platform: wmbus_meter
parent_id: ZW_MAIN_WIFI
name: "Adapr NA 1 total"
field: "total_m3"
accuracy_decimals: 3
unit_of_measurement: "m³"
device_class: "water"
state_class: "total_increasing"
icon: "mdi:water"
# filters:
# - offset: 0.0
Tak wygląda log:
INFO ESPHome 2026.1.5
INFO Reading configuration /config/esphome/wifi-test-v5.yaml...
INFO Detected timezone 'Europe/Warsaw'
INFO Starting log output from 192.168.13.108 using esphome API
INFO Successfully resolved wmbus-wifi @ 192.168.13.108 in 0.000s
INFO Successfully connected to wmbus-wifi @ 192.168.13.108 in 0.199s
INFO Successful handshake with wmbus-wifi @ 192.168.13.108 in 0.082s
[13:34:24.331][I][app:210]: ESPHome version 2026.1.5 compiled on 2026-02-11 20:07:45 +0100
[13:34:24.335][I][app:217]: ESP32 Chip: ESP32-S2 r1.0, 1 core(s)
[13:34:24.335][C][logger:316]: Logger:
[13:34:24.335][C][logger:316]: Max Level: DEBUG
[13:34:24.335][C][logger:316]: Initial Level: DEBUG
[13:34:24.347][C][logger:322]: Log Baud Rate: 115200
[13:34:24.347][C][logger:322]: Hardware UART: USB_CDC
[13:34:24.347][C][logger:332]: Task Log Buffer Size: 768 bytes
[13:34:24.358][C][spi:066]: SPI bus:
[13:34:24.370][C][spi:152]: CLK Pin: GPIO36
[13:34:24.370][C][spi:152]: SDI Pin: GPIO37
[13:34:24.370][C][spi:152]: SDO Pin: GPIO35
[13:34:24.370][C][spi:074]: Using HW SPI: SPI2_HOST
[13:34:24.370][C][psram:016]: PSRAM:
[13:34:24.370][C][psram:019]: Available: YES
[13:34:24.373][C][psram:021]: Size: 2048 KB
[13:34:24.385][C][homeassistant.time:010]: Home Assistant Time
[13:34:24.386][C][time:028]: Timezone: 'CET-1CEST,M3.5.0,M10.5.0/3'
[13:34:24.393][C][wmbus.transceiver:149]: Transceiver: CC1101
[13:34:24.397][C][wmbus.transceiver:152]: Reset Pin: GPIO1
[13:34:24.398][C][wmbus.transceiver:152]: IRQ Pin: GPIO2
[13:34:24.404][C][wmbus.transceiver:155]: RX Gain: Boosted
[13:34:24.405][C][wmbus.transceiver:160]: Sync Mode: Normal
[13:34:24.405][C][wmbus.transceiver:163]: TCXO: DIO3
[13:34:24.426][C][wmbus_common:013]: wM-Bus Component v5.1.7-1.19.0-fe1b1e0:
[13:34:24.431][C][wmbus_common:015]: Loaded drivers:
[13:34:24.432][C][wmbus_common:017]: apator162
[13:34:24.434][C][wmbus_common:017]: apatorna1
[13:34:24.438][C][wmbus_meter:028]: wM-Bus Meter:
[13:34:24.438][C][wmbus_meter:029]: ID: 0x04913581
[13:34:24.441][C][wmbus_meter:030]: Driver: apatorna1
[13:34:24.451][C][wmbus_meter:031]: Key: 00000000000000000000000000000000
[13:34:24.451][C][wmbus_meter.sensor:014]: wM-Bus Sensor:
[13:34:24.454][C][wmbus_meter.sensor:015]: Parent meter ID: 0x04913581
[13:34:24.472][C][wmbus_meter.sensor:017]: Field: 'rssi_dbm'
[13:34:24.472][C][wmbus_meter.sensor:016]: Name: 'Adapr NA 1 total RSSI'
[13:34:24.472][C][wmbus_meter.sensor:016]: State Class: 'measurement'
[13:34:24.472][C][wmbus_meter.sensor:016]: Unit of Measurement: 'dBm'
[13:34:24.472][C][wmbus_meter.sensor:016]: Accuracy Decimals: 0
[13:34:24.472][C][wmbus_meter.sensor:026]: Device Class: 'signal_strength'
[13:34:24.472][C][wmbus_meter.sensor:014]: wM-Bus Sensor:
[13:34:24.472][C][wmbus_meter.sensor:015]: Parent meter ID: 0x04913581
[13:34:24.473][C][wmbus_meter.sensor:017]: Field: 'total_m3'
[13:34:24.473][C][wmbus_meter.sensor:016]: Name: 'Adapr NA 1 total'
[13:34:24.473][C][wmbus_meter.sensor:016]: State Class: 'total_increasing'
[13:34:24.473][C][wmbus_meter.sensor:016]: Unit of Measurement: 'm³'
[13:34:24.473][C][wmbus_meter.sensor:016]: Accuracy Decimals: 3
[13:34:24.473][C][wmbus_meter.sensor:026]: Device Class: 'water'
[13:34:24.477][C][wmbus_meter.sensor:030]: Icon: 'mdi:water'
[13:34:24.497][C][captive_portal:128]: Captive Portal:
[13:34:24.497][C][wifi:1304]: WiFi:
[13:34:24.497][C][wifi:1304]: Local MAC: 80:65:99:E2:30:6C
[13:34:24.497][C][wifi:1304]: Connected: YES
[13:34:24.501][C][wifi:1037]: IP Address: 192.168.13.108
[13:34:24.514][C][wifi:1048]: SSID: [redacted]
[13:34:24.514][C][wifi:1048]: BSSID: [redacted]
[13:34:24.514][C][wifi:1048]: Hostname: 'wmbus-wifi'
[13:34:24.514][C][wifi:1048]: Signal strength: -82 dB ▂▄▆█
[13:34:24.514][C][wifi:1048]: Channel: 8
[13:34:24.514][C][wifi:1048]: Subnet: 255.255.255.0
[13:34:24.514][C][wifi:1048]: Gateway: 192.168.13.1
[13:34:24.514][C][wifi:1048]: DNS1: 0.0.0.0
[13:34:24.514][C][wifi:1048]: DNS2: 0.0.0.0
[13:34:24.516][C][web_server:416]: Web Server:
[13:34:24.516][C][web_server:416]: Address: 192.168.13.108:80
[13:34:24.524][C][esphome.ota:075]: Over-The-Air updates:
[13:34:24.524][C][esphome.ota:075]: Address: 192.168.13.108:3232
[13:34:24.524][C][esphome.ota:075]: Version: 2
[13:34:24.547][C][safe_mode:021]: Safe Mode:
[13:34:24.547][C][safe_mode:021]: Successful after: 60s
[13:34:24.547][C][safe_mode:021]: Invoke after: 10 attempts
[13:34:24.547][C][safe_mode:021]: Duration: 300s
[13:34:24.547][C][web_server.ota:231]: Web Server OTA
[13:34:24.557][C][api:221]: Server:
[13:34:24.557][C][api:221]: Address: 192.168.13.108:6053
[13:34:24.557][C][api:221]: Listen backlog: 4
[13:34:24.557][C][api:221]: Max connections: 8
[13:34:24.563][C][api:228]: Noise encryption: YES
[13:34:24.563][C][mdns:177]: mDNS:
[13:34:24.563][C][mdns:177]: Hostname: wmbus-wifi
Zdecydowanie byłoby lepiej, ale na ten moment, są tu nieco rozbieżne priorytety:
W szczególności jest to dość problematyczne, że sporo kodu wlatuje teraz spod Claude’a i innych podobnych, a użytkownicy są dość mocno zorientowani na to, żeby ich konkretne urządzenie działało w ich konkretnych warunkach. Mam w swoim repo na przykład otwarty PR na cc1101, ale trzebaby przy nim jeszcze trochę ogarnąć, żeby jakoś uprzątnąć kod. Tak samo z SX1262: przymierzam się do tego już od dłuższego czasu, bo będę pewnie kiedyś w przyszłości migrować swoje urządzenia, ale mało kto jest zainteresowany zrobieniem tego globalnie, a nie tylko dla siebie, na konkretną długość ramki mechanizmem pakietowym i tak dalej.
Ten sam case był z CCem: Szczepan niejako porzucił support dla niego w V5, który teraz pojawił się po czasie. Ja niestety nie mogę sobie na to pozwolić: ktoś zapłacił mi złotówki za urządzenie, a ja obiecałem, że będę o nie dbał. Nie mogę użytkownikowi powiedzieć: nie aktualizuj ESPHome, albo przywracaj do wersji sprzed pół roku, albo kup ode mnie kolejne urządzenie z nowym TRXem, bo stare jest już stare, a ja chcę zarobić więcej.
Z tego względu, chyba lepiej jest, przynajmniej na razie, robić to tak jak jest: w repo Szczepana jest powiedzmy wersja eksperymentalna, na którą sobie na bieżąco patrzę i pewnie niektóre rzeczy stamtąd pomerdżuję do siebie, a u mnie możesz się zapiąć sie na konkretny tag i liczyć na to, że jeśli stracimy zgodność z konkretną nową wersją ESPHome, to podfiksuję to szybko, a Ty w yamlu przebijesz tylko taga na nowo wydany.
