Mam Magic Reader v5 (ESP32-POE + SX1276) z komponentem IoTLabs (main branch, wmbusmeters 1.20.0). Liczniki wody apator162 działają bez problemu. Problem dotyczy licznika prądu Elgama Gama 350.
Objawy
Radio odbiera ramki 191 bajtów z Gama 350 (Try to make frame from packet t1 of size 191)
Ale nigdy nie pojawia się Frame created — ramka jest cicho odrzucana
Drivery ładują się poprawnie: amiplus + apator162
Ten sam telegram dekoduje się bezbłędnie na wmbusmeters.org — klucz OK, driver amiplus 66/91 match
Bez zdefiniowanego metera amiplus (same wodomierze) ramka 191 bajtów parsuje się poprawnie: Frame created (191 bytes), Telegram handled by 0 handlers — problem pojawia się dopiero po dodaniu metera amiplus
[C][wmbus_common:028]: - amiplus
[C][wmbus_common:028]: - apator162
[D][wmbus:181]: Try to make frame from packet t1 of size 191 ← Gama 350, brak "Frame created"
[D][wmbus:181]: Try to make frame from packet t1 of size 110
[I][wmbus:047]: Frame created (63 bytes) [RSSI: -63, mode:t1] ← apator162 działa OK
[S][sensor]: 'Main water meter - value' >> 1746.67 m³
Pomysł na ultrimis jest dość prosty: w generatorze xmq->cpp jest jakiś błąd. Niestety nie mam możliwości się nim zająć w jakimś przewidywalnym okresie czasu: priorytetem jest jednak wsparcie własnych urządzeń plus tysiąc innych rzeczy którymi muszę się zająć w bieżącej pracy. Zawsze możesz spróbować napuścić na to jakiegoś Codexa czy innego Claude Code. Prawdopodobnie pomoże, ale będziesz prawdopodobnie musiał sobie zestawić lokalne środowisko do jego odpalenia, żeby pooglądać wygenerowane pliki cpp.
Konfig do amiplusa jest prawdopodobnie okej, tak jak napisał Krzysztof, ale tak na sto procent, to ciężko przewidzieć go nie widząc.
Przyczyną może być dużo różnych rzeczy: pamięć zaalokowana w SPIRAM zamiast w środku ESPa, wysoko priorytetowe operacje które trzeba wykonać na porcie ETH żeby nie utracić połączenia internetowego, które muszą być zrobione w określonym czasie i dowolne inne rzeczy o których pewnie tak na pierwszy rzut oka ciężko powiedzieć.
Mogę potwierdzić jedynie, że szybki test z konfigiem amiplus+apator162, po jednej encji z każdego, na biurku przechodzi mi bez problemów. Ale to biurko, konkretne ramki testowe, konkretny soft, urządzenie i tak dalej.
Chat sugeruje, że to problem z wyścigiem/timeoutem. Zdarzyło mi się odczytać ramkę, jeśli był włączony VERBOSE. Chat sugeruje, że przez to działanie było spowolnione i był w stanie dostać całość… A ile to ma sensu, to nie wiem
Wcześniej w tym wątku opisywałem problemy z driverem elf2, ale po poprawkach wszystko działa prawidłowo. Z pewnymi obawami wczoraj zabrałem się za licznik prądu i poszło prawie od strzału. To ‘prawie’ to konieczność wyczyszczenia projektu bo driver amiplus się nie ładował — po esphome clean ... natychmiast ruszyło. A do licznika prądu mam ok. 10m i RSSI ok. -84 dBm. Odbiornik to Magic Reader v5 z radiem SX1276.
Sama aktualizacja komponentu nie spowodowała u mnie żadnych problemów. Konfiguracja skompilowała się prawidłowo, urządzenie uruchomiło się, a wszystkie trzy liczniki — ciepła, wody i energii elektrycznej — były poprawnie odbierane i dekodowane.
Problemy pojawiły się dopiero po aktualizacji ESPHome z 2026.5.2 do 2026.7.3.
Kompilacja nadal kończyła się sukcesem, ale pojawiło się kilka ostrzeżeń kompilatora dotyczących kodu komponentu i wmbusmeters. Znacznie ważniejsze było jednak zachowanie urządzenia po wgraniu firmware.
W logu zaczęły pojawiać się niemal bez przerwy komunikaty:
[W][wmbus:091][radio_recv]: Failed to read data
Czasami występowały po kilka razy w ciągu jednej sekundy.
Jednocześnie wyraźnie pogorszyła się skuteczność odbioru telegramów:
ciepłomierz, normalnie odbierany mniej więcej co 16 sekund, zaczął mieć przerwy po 30–60 sekund, a czasami znacznie dłuższe;
licznik energii elektrycznej, normalnie odbierany raz na minutę, był odbierany tylko sporadycznie;
wodomierz również pojawiał się rzadziej;
wartości RSSI poprawnie odebranych telegramów pozostawały normalne;
urządzenie nie wykazywało problemów z pamięcią, a uptime rósł bez restartów.
Dla sprawdzenia wróciłem do ESPHome 2026.5.2 (komponent IoTLabs w wersji v1.2.4).
Po ponownej kompilacji i wgraniu firmware problem zniknął natychmiast:
nie pojawiały się komunikaty Failed to read data;
ciepłomierz był odbierany przeważnie co około 16 sekund, sporadycznie po około 32 sekundach;
licznik prądu był odbierany niemal zawsze co 60 sekund; w kilkunastominutowym logu wypadł jeden telegram;
wodomierz również był odbierany w marę regularnie — kilka razy w ciągu kilkunastu minut, choć odstępy między telegramami nie były stałe;
nie było restartów ani rollbacku OTA.
Podsumowując: przejście z komponentu v1.2.2 na v1.2.4 przebiegło u mnie bezproblemowo. Kłopoty z odbiorem pojawiły się po aktualizacji ESPHome do 2026.7.3, natomiast po powrocie do ESPHome 2026.5.2 odbiór ponownie działa prawidłowo.
