Licznik S34U28 od Taurona

No i po wielu moich testach okazało się, że klucz jest ok, tylko nagłówki wiadomości są inne. Powoduje to, że w ogole nie chce odszyfrowywać. Na szczęście claude zrobiło mi poprawki do wersji Szczepan 5.0.4. Wszystkie dane są zgodne z amiplus poza nagłówkiem.

Problem był w weryfikacji deszyfrowania w wmbus.cc:1550.

Standardowy przepływ wMBus:

  1. Telegram przychodzi zaszyfrowany AES CBC

  2. potentiallyDecrypt() deszyfruje payload

  3. Sprawdza czy pierwsze 2 bajty odszyfrowanych danych to 2F 2F — to standardowy “check bytes” potwierdzający że klucz był prawidłowy

  4. Jeśli nie 2F 2F → uznaje że klucz jest zły → decryption_failed = true → t.parse() zwraca false

  5. handleTelegram() kończy się przedwcześnie — żadne pola nie są wyciągane, processContent() nigdy nie jest wywoływany

Problem z KPL/Tauron:
Licznik KPL po deszyfracji zamiast standardowych 2F 2F wstawia 60 9B jako prefix. Deszyfracja jest poprawna (widać sensowne dane za prefixem), ale weryfikacja tego nie wie i odrzuca telegram.

Fix — jedna linijka w potentiallyDecrypt(), zaraz po udanej deszyfracji AES:

if ((dll_mfct & 0x7fff) == 0x2E0C && *(pos+0) == 0x60 && *(pos+1) == 0x9B)
{
    *(pos+0) = 0x2F;
    *(pos+1) = 0x2F;
}

Podmienia 60 9B na 2F 2F dla manufacturer KPL (0x2E0C) — weryfikacja przechodzi, parseDV() dostaje czyste dane, pola się parsują normalnie.

Tak, nowy driver (driver_tauronkpl.cc) był potrzebny — ale nie z powodu deszyfrowania, tylko z powodu detekcji.

Bez nowego drivera licznik KPL trafiał do amiplus (albo auto), który:

  • nie miał addDetection(MANUFACTURER_KPL, 0x02, 0x01) — więc nie rozpoznawał producenta KPL (0x2E0C)

  • nie miał usesProcessContent() — więc nawet gdyby fix w wmbus.cc przepuścił telegram, nie byłoby zapasowego mechanizmu reparsowania

1 Like

Hej, jestem na etapie tego problemu i nie udało mi sie dalej przejść. Zmodyfikowałem wmbus.cc ale bezskutecznie. Byłbyś w stanie nakierować jak to dokładnie zrobić albo podesłać poprawiony plik?

BLAD: 609b decrypt check bytes (ERROR should be 2f2f)

Masz, możesz użyć w swoim projekcie, to fragment mojego wmbus.yaml


external_components:
  # - source:
  #     type: git
  #     url: 
# alternatively
 #- source: github://SzczepanLeon/esphome-components@5.0.4  #or @5.0.4 
 - source: github://zelo66/wmbusmeterCustom@main
   components:
     - socket_transmitter
     - wmbus_common
     - wmbus_radio
     - wmbus_meter

      

Pobierz sobie z mojego githuba, zrób forka czy co tam chcesz. Pamiętaj, że to jest dodane przez AI “tak żeby działało”. Na pewno nie powinno się tak tego robić.

Chyba coś robie nie tak :\

  1. Zrobiłem fork

Dałem external_components na mój fork

I przy kompilacji:

src/esphome/components/wmbus_common/driver_compact5.cc: In member function ‘virtual void {anonymous}::Driver::processContent(Telegram*)’:
src/esphome/components/wmbus_common/driver_compact5.cc:84:9: error: ‘Explanation’ was not declared in this scope

84 | Explanation pe(offset, 2, prevs, KindOfData::CONTENT, Understanding::FULL);
| ^~~~~~~~~~~
src/esphome/components/wmbus_common/driver_compact5.cc:85:12: error: ‘struct Telegram’ has no member named ‘explanations’; did you mean ‘setExplanation’?

85 | t->explanations.push_back(pe);
| ^~~~~~~~~~~~
| setExplanation
src/esphome/components/wmbus_common/driver_compact5.cc:85:35: error: ‘pe’ was not declared in this scope

85 | t->explanations.push_back(pe);
| ^~
src/esphome/components/wmbus_common/driver_compact5.cc:96:20: error: expected ‘;’ before ‘ce’

96 | Explanation ce(offset, 2, currs, KindOfData::CONTENT, Understanding::FULL);
| ^~~
| ;
src/esphome/components/wmbus_common/driver_compact5.cc:97:12: error: ‘struct Telegram’ has no member named ‘explanations’; did you mean ‘setExplanation’?
97 | t->explanations.push_back(ce);
| ^~~~~~~~~~~~
| setExplanation
src/esphome/components/wmbus_common/driver_compact5.cc:97:35: error: ‘ce’ was not declared in this scope

97 | t->explanations.push_back(ce);
| ^~
*** [.pioenvs/tauron-meter-22/src/esphome/components/wmbus_common/driver_compact5.cc.o] Error 1
========================== [FAILED] Took 4.57 seconds ==========================

Spotkałeś sie z tym? Próbowałem wyrzucić ten plik (ChatGPT sugerował), zmieniałem na twoje repo i bez zmian :\

Fork jest niespójny, problem nie dotyczy KPL tylko kompilacji całego komponentu.

Co może byc powodem? Pierwszy raz bawie sie w ‘edycje’ componentów do esphome :\

Kod komponentu nie nadąża ze zmianami zachodzącymi w ESP HOME. Dziś wyszła nowa wersja 2026.4.0 która pokazała problem.

Jestem na 2025.6.3 (Robiłem downgrade z racji problemów z najnowszą). Sprobowac na najnowszej?

Nie. Właśnie to Ci napisałem. Każda wyższa wersja ESP to co raz więcej kłopotów.

Okej, to jakie mozee byc rozwiazanie z takiej sytuacji? Zwykły @main od SzczepanLeon budduje sie poprawnie. Problem pojawia sie przy fork’u :thinking:

jak masz SX1276 to spróbuj tego : https://github.com/IoTLabs-pl/ESPHome-Components.git

Samo oprogramowanie w czystej formie działa mi poprawnie. Udało mi sie dobrać do ramek wysyłanych przez licznik ale problem mam z tym co opisywał wcześniej @zelo66 czyli

Problem z KPL/Tauron:
Licznik KPL po deszyfracji zamiast standardowych 2F 2F wstawia 60 9B jako prefix. Deszyfracja jest poprawna (widać sensowne dane za prefixem), ale weryfikacja tego nie wie i odrzuca telegram.

@zelo66 zrobił poprawke na swoim Fork’u do tego ale niestety w moim przypadku esphome nie wstaje, bład kompilacji mam :\

Clean Build Files zrób ( 3 kropeczki )

Robiłem, bezskutecznie. :\ Robiłem juz restarty, czyściłem cache z poziomu terminala bezskutecznie :\ Mimo ze pliku juz nie ma w moim main to magicznie ESPHome go dalej tam widzi (ChatGPT zalecił usuniecie) :\

Wyczyscilem “build files” i na wersji 2026.4 mi sie skompilowało bez problemu.

Może problem z yamlem?
Zobacz ten, tylko podmień swoje hasła.

W ogóle ten esphome dziwnie działa. Czasem mam wrazenie ze lepiej dodać to jako nowe urządzenie niż jakieś aktualizacje robić.

Zapytałem claude o ten problem:

To nie jest błąd z naszych zmian. Kolega wysłał pliki z innej wersji biblioteki niż ma zainstalowaną.

Błąd mówi że Explanation i t->explanations nie istnieją — to znaczy że jego wersja wmbus_common jest starsza i nie ma tych struktur, a plik driver_compact5.cc jest z nowszej wersji gdzie Explanation zostało dodane.

Rozwiązanie: Niech użyje kompletnego, spójnego zestawu plików z jednej wersji — albo całą wersję 5.0.4 (jak masz Ty), albo całą jego wcześniejszą wersję. Nie można mieszać plików z różnych wersji.

Ale z czego to powstaje

Z tego że driver_compact5.cc używa Explanation i t->explanations, ale ta struktura jest zdefiniowana/usuwana w wmbus.h lub wmbus.cc — i w jego wersji po prostu jej nie ma.

Sprawdź w swoich plikach:

Grep “struct Explanation|class Explanation“ (in c:\\\\\\\\Users\\\\\\\\Adrian\\\\\\\\Downloads\\\\\\\\esphome-components-5.0.4\\\\\\\\esphome-components-5.0.4\\\\\\\\components\\\\\\\\wmbus_common)

1 line of output

Read c:\\\\\\\\Users\\\\\\\\Adrian\\\\\\\\Downloads\\\\\\\\esphome-components-5.0.4\\\\\\\\esphome-components-5.0.4\\\\\\\\components\\\\\\\\wmbus_common\\\\\\\\wmbus.h (lines 329-338)

Właśnie — struct Explanation jest zakomentowana w wersji 5.0.4 (ta którą masz). Jej kolega ma starszą wersję biblioteki gdzie Explanation jeszcze istniała jako aktywny kod, a driver_compact5.cc który mu wysłałeś pochodzi z wersji gdzie ten struct jest zakomentowany i t->explanations nie istnieje.

Krótko: wysłałeś mu driver_compact5.cc z wersji 5.0.4, a on używa starszej wersji reszty biblioteki — struktury nie pasują. Niech pobierze całą wersję 5.0.4 albo nie używa tego pliku.

Po przejściu na 2026.04.0 i skorzystaniu z twojego Yaml/Fork ruszyło. Dzięki wielkie!

No i super! Fajnie gdyby ktoś dodał ten licznik do oficjalnego wmbus. To by bardzo ułatwiło

W tej chwili chyba włączają wszystkim HAN.

Napisałem proszę o włączenie usługi HAN na liczniku xxxx i na drugi dzień dostałem maila z info o włączeniu.

W opisie usługi jest, oprócz mieszkańców Wrocławia, itp drugi punkt:

  • dla wszystkich klientów TAURON Dystrybucja z zainstalowanymi po 2024 roku licznikami zdalnego odczytu. Liczniki posiadają 13 znakowy numer seryjny oraz typ MA309 lub ST34U.

Niestety również ja mam problem ze zdekodowaniem telegramu, raczej ciężko mi będzie przejść kroki opsane przez Zelo66. Ale będę próbował.

Mam nadzieję, że uda się komuś dodać to do oficjalnej dystrybucji.

Pzdr. Tomek.

Hej. Mam ten sam licznik i próbuje go odpalić pod CC1101.

Niestety ale na wstępnie już mam error:
Failed config

wmbus_radio: [source /config/esphome/han-transmitter.yaml:49]

'reset_pin' is a required option for [wmbus_radio].
-
Unknown value 'CC1101', valid options are 'SX1276'.
radio_type: CC1101
cs_pin: GPIO4
irq_pin: GPIO3
on_frame:
- then:
- logger.log:
format: Frame received: RSSI=%ddBm, Mode=%s, Data=%s
args:
- frame->rssi()
- toString(frame->link_mode())

Próbowałem sam to ogarnąc, wg opisu ale driver jest niewidoczny tauronkpl dalej jest niewidoczny i nie wiem gdzie jego definicja ma być.

Ktoś nakieruje co zmodyfikować by driver był widoczny w:

wmbus_meter:

   - id: electricity_meter

     meter_id: 0xxxxxxxx

     type: tauronkpl

     key: zzzzz

     mode: 

       - T1

       - C1

Hej, też mam ten licznik. Napisałem maila do Tauron żeby włączyli mi usługę HAN, ponieważ na stronie eLicznika nie miałem takiej opcji. Po kilku dniach dostałem odpowiedź, że usługa została uruchomiona.
Na LilyGo T3-S3 zainstalowałem kod z tego wątku używając wersji ESPHome z 2025.8.0. Kod działa, w logach widzę, że odnajduje ramki z okolicznych wodomierzy ale nie odnajduje ramek z tego licznika energii Taurona.
Jakieś pomysły co jest nie tak? Próbowałem z innymi kodami - zawsze jest ten sam efekt - odnajduje tylko ramki z wodomierzy. Zakładam że płytka oraz kod działa poprawnie skoro znajduje jakieś ramki. Kładłem płytke obok licznika, również bez efektu.
Wymieniłem też kilka maili z Tauronem, cały czas twierdzą że połączenie wmbus i licznik działają poprawnie. Nie mam już pomysłu jak to uruchomić.