Dziękuję za pomoc. Czyli problem jest po stronie ESPHome. Ja próbowałem na wersji (Python) uruchamianej w wirtualnym środowisku pod systemem Ubuntu.
Może prościej było by postawić kontener dockera w tym Ubuntu. Mogę pomóc szybko to wykonać w Twoim temacie. Tu proponuję to zakończyć.
EDIT:
Aczkolwiek sprawdził bym czy na pewno płytka ma tyle pamięci ile deklaruje sprzedawca. To chyba załatwi polecenie z esptool w terminalu Ubuntu.
cezary@Lenovo ~> esptool.py --port /dev/ttyUSB0 --baud 115200 flash_id
esptool.py v2.8
Serial port /dev/ttyUSB0
Connecting....
Detecting chip type... ESP32
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: ac:67:b2:36:04:4c
Uploading stub...
Running stub...
Stub running...
Manufacturer: d8
Device: 4016
Detected flash size: 4MB
Hard resetting via RTS pin...
cezary@Lenovo ~>
Ale czy kontener na Ubuntu przejmie pory USB hosta aby podłączyć płytkę? Jeśli mogę prosić o szybką instrukcję odnośnie postawienia kontenera to będę wdzięczny. Jak szybko mogę sprawdzić parametry płytki? - już widzę ![]()
Oto parametry mojej płytki:
esptool.py v2.8
Serial port /dev/ttyUSB0
Connecting....
Detecting chip type... ESP32
Chip is ESP32D0WDQ5 (revision 3)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 28:05:a5:6f:f2:f4
Enabling default SPI flash mode...
Manufacturer: 20
Device: 4016
Detected flash size: 4MB
Hard resetting via RTS pin...
To nie jest żaden problem, najważniejsze żeby mieć co wgrywać po tym USB. A do tego jest wiele opcji. Ja preferuję sprawdzony i minimalistyczny ESP_Flasher
Na początek potrzebujesz Docker w swoim Ubuntu. Wybacz ale nie będę robił poradnika w tej kwestii, Internet jest ich pełen.
A jak już będziesz miał Docker, to przeczytaj proszę co tu opisywałem:
Dziękuję za wskazówki.
Powalczyłem trochę z inną wersją (czystą) Ubuntu i udało mi się skonfigurować ESPHome. Potrzebuję pomocy aby zobaczyć czy moja płytka złapie pakiety wysyłane przez mój licznik. Jak ma wyglądać YAML abym tylko zobaczył telegramy nawet te zaszyfrowane wysyłane przez mój licznik o znanym ID. Chcę tylko zobaczyć w logach aby mieć pewność, że wszystko działa.
Zwykle wystarczało wyrzucić wszystkie sensory.
Już prawie widziałem koniec a tu błąd:
Compiling .pioenvs/multical21/src/esphome/components/wmbus/manufacturer_specificities.cpp.o
Compiling .pioenvs/multical21/src/esphome/components/wmbus/mbus.cpp.o
Compiling .pioenvs/multical21/src/esphome/components/wmbus/meters.cpp.o
Compiling .pioenvs/multical21/src/esphome/components/wmbus/rf_cc1101.cpp.o
In file included from src/esphome/components/wmbus/rf_cc1101.h:9,
from src/esphome/components/wmbus/rf_cc1101.cpp:1:
src/esphome/components/wmbus/cc1101_rf_settings.h:3:10: fatal error: ELECHOUSE_CC1101_SRC_DRV.h: No such file or directory
****************************************************************************************
* Looking for ELECHOUSE_CC1101_SRC_DRV.h dependency? Check our library registry!
*
* CLI > platformio lib search "header:ELECHOUSE_CC1101_SRC_DRV.h"
* Web > https://registry.platformio.org/search?q=header:%1B%5Bm%1B%5BKELECHOUSE_CC1101_SRC_DRV.h
*
****************************************************************************************
3 | #include <ELECHOUSE_CC1101_SRC_DRV.h>
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
*** [.pioenvs/multical21/src/esphome/components/wmbus/rf_cc1101.cpp.o] Error 1
========================= [FAILED] Took 178.90 seconds =========================
Debug już masz włączony.
logger:
level: DEBUG
Ustawił bym all_drivers na True (tak dla pewności).
Wywalił bym sekcję clients oraz sensor (na czas testów).
Czyli w sumie zrobił tak jak to jest w dokumentacji.
Zmieniałeś coś w YAMLu (w szczególności framework)?
Zrobiłem z ciekawości trzecią próbę, tym razem ESPHome zainstalowany na moim Linux Mint (bazuje na Ubuntu)
cezary@Lenovo ~> pipx install esphome
installed package esphome 2025.12.6, installed using Python 3.12.3
These apps are now globally available
- esphome
done! ✨ 🌟 ✨
cezary@Lenovo ~> esphome version
which esphome
Version: 2025.12.6
/home/cezary/.local/bin/esphome
cezary@Lenovo ~> ls -l ~/.local/bin/esphome
lrwxrwxrwx 1 cezary cezary 56 sty 15 21:06 /home/cezary/.local/bin/esphome -> /home/cezary/.local/share/pipx/venvs/esphome/bin/esphome*
cezary@Lenovo ~> mkdir -p ~/esphome
cezary@Lenovo ~> cd ~/esphome
cezary@Lenovo ~/esphome> esphome dashboard .
I jak by to powiedzieć
u mnie działa.
Kod dokładnie taki jak poniże na każdej platformie, ESPHome z pakietów pipx, kontener Docker na NAS i AddOn w HAOS.
esphome:
name: licznikwoda
friendly_name: licznikwoda
esp32:
board: esp32dev
framework:
type: arduino
external_components:
- source: github://SzczepanLeon/esphome-components@version_4
refresh: 0d
components: [ wmbus ]
# Enable logging
logger:
level: DEBUG
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
time:
- platform: sntp
id: my_time
wmbus:
mosi_pin: GPIO13
miso_pin: GPIO12
clk_pin: GPIO14
cs_pin: GPIO2
gdo0_pin: GPIO5
gdo2_pin: GPIO4
all_drivers: False
log_all: True
sync_mode: True
# mqtt:
# broker: 192.168.0.254
clients:
- name: "wmbusmeters"
ip_address: "192.168.0.254"
port: 7227
sensor:
- platform: wmbus
type: multical21
- platform: wmbus
meter_id: 57199574
type: multical21
key: "9368D8464A53D2FBF953CD9A597F9889"
sensors:
- name: "Multical Cold Water Total"
field: "total"
unit_of_measurement: "m³"
device_class: "water"
state_class: "total_increasing"
icon: "mdi:water"
- name: "Multical RSSI"
field: "rssi"
unit_of_measurement: "dBm"
device_class: "signal_strength"
state_class: "measurement"
entity_category: "diagnostic"
- name: "Multical Cold Water Target"
field: "target"
accuracy_decimals: 3
unit_of_measurement: "m³"
device_class: "water"
state_class: "total_increasing"
icon: "mdi:water"
Uprościłem YAML według wskazówek (wszystkie drivery i bez sensorów) i kompiluję.
Wcześniejsza wersja po skompilowaniu - sensory widoczne w HA i płytka też osiągalna ale nic nie czytała z pasma 868MHz.
Bazując na tym obrazku z oferty
zrezygnowałbym z używania GPIO2 jeśli chodzi o jakiekolwiek podłączenie do CC1101 (tam jest podłączony wewnętrznie LED, który swoją drogą możesz użyć do sygnalizacji czegokolwiek) więc wybierz inny pin, bo ten LED może przeszkadzać w działaniu (nie ma to żadnego wypływu na kompilację ale mówisz, że moduł jest głuchy).
Nie ma co się bać wykorzystania RX2(=GPIO16) ani TX2(=GPIO17) bo to jest drugi serial tylko jeśli go tam zamapujemy.
GPIO12, GPIO13 i GPIO14 są OK, bo to jest domyślne miejsce dla jednej z magistral SPI
W ogóle w tym module masz mnóstwo uniwersalnych GPIO, a uparłeś się na wykorzystanie niektórych kontrowersyjnych…
tu masz bryk ułatwiający korzystanie ze sprzętu jak należy
edit
swoją drogą wrzuciłem ten YAML do kompilacji na mojej testowej instalacji HAOS i na dzień dobry w logach masz ostrzeżenia (akurat nie do końca tutaj miarodajne, bo MCU Ci bootuje, czyli sprzętowo nie zmieniłeś im stanu na jakiś który by przeszkadzał, ale to o czym pisałem wyżej to nieco inne kwestie)
WARNING GPIO12 is a strapping PIN and should only be used for I/O with care.
Attaching external pullup/down resistors to strapping pins can cause unexpected failures.
See https://esphome.io/guides/faq/#why-am-i-getting-a-warning-about-strapping-pins
WARNING GPIO2 is a strapping PIN and should only be used for I/O with care.
Attaching external pullup/down resistors to strapping pins can cause unexpected failures.
See https://esphome.io/guides/faq/#why-am-i-getting-a-warning-about-strapping-pins
WARNING GPIO5 is a strapping PIN and should only be used for I/O with care.
Attaching external pullup/down resistors to strapping pins can cause unexpected failures.
See https://esphome.io/guides/faq/#why-am-i-getting-a-warning-about-strapping-pins
a z innej beczki - kupiłeś wielopak tych CC1101 ?
jeśli tak to weź inny egzemplarz, bo chińskie kwadratowe płytki z tym transceiverem są wyjątkowo często wadliwe
Poprawiłem pinout ale jeszcze ma problem z CS i GDO2…wyrzuca mi taki warrning jak wyżej
wmbus:
mosi_pin: GPIO23
miso_pin: GPIO19
clk_pin: GPIO18
cs_pin: GPIO5
gdo0_pin: GPIO4
gdo2_pin: GPIO15
all_drivers: True
log_all: True
sync_mode: True
Będę wdzięczny za sugestie.
Sugestia była już wyżej - MOŻESZ UŻYĆ GPIO12, GPIO13 i GPIO14 dla magistrali SPI (bo ma wtedy optymalną wydajność - to jest jej domyślna lokalizacja…), a masz NIE UŻYWAĆ GPIO2 (jest podciągnięte LEDem do zasilania), natomiast GPIO5 jest dyskusyjne, więc może warto podmienić na coś innego (niekoniecznie w tej sytuacji), a tu widzę zmiany w jakąś inną stronę… (znaczy druga magistrala SPI też jest OK, ale nie musiałeś ruszać niczego z magistrali HSPI na VSPI)
Jakkolwiek domyśle piny CS nie kolidują z niczym (bo to sygnał wystawiany z ESP, a nie przychodzący z zewnątrz), więc sytuacyjnie używanie GPIO5 jako CS VSPI lub GPIO15 jako CS HSPI nie ma negatywnych skutków.
logs_multical21_run.zip (45,3 KB)
Wrzucam plik z logami. Sugerując się informacjami jakie wyszukałem na forum i Waszymi wskazówkami wygląda na to, że moja płytka ma za mało pamięci. Będę wdzięczny za rzucenie sprawnym i doświadczonym okiem na moje wymęczone logi.
Kontynuując moje boje - płytka C1101 jest sprawna - na prostym snifferze pod 868MHz działa. Nie bardzo już wiem, w którą stronę iść…na pewno z stronę licznika aby odczytać ale naocznie ![]()
Szczerze mówiąc w ciemno (bo nie mam teraz czasu na logi) nie sądzę, jakkolwiek wykopałem wczoraj w dokumentacji Espressif, że
ESP32D0WDQ5 (revision 3)
być może jest “o włos” słabszy od
ESP32D0WDQ6 (revision 1)
ale dotyczy to co najwyżej RAMu a nie flasha
edit z ciekawości zajrzałem do loga i z niego kompletnie nic nie wynika, bo się kończy tam, gdzie coś się w końcu powinno zacząć dziać…
być może jest to opisywany kiedyś problem ze zbyt wysokim poziomem loggera (poziom debug powodował przepełnienie RAMu)
No właśnie zatrzymał się i nic…wariant konfigu był na wszystkie ramki co w eterze fruwają a mam w zasięgu 2 liczniki. Czyli mam ograniczyć logi - może do samych errorów?
Nie pamiętam jak starą wersję komponentu używałem jako ostatnią z CC1101, ale nie używam tego rozwiązania od dawna, co więcej nawet obecnie nie mam tego sprzętu, więc nie czuję się na siłach pomagać…
@angler z tego co widzę sprzęt ma, więc mógłby organoleptycznie sprawdzić jaki najniższy poziom logowania wystarcza by zobaczyć w logach telegramy przechwycone z eteru.



