będzie wersja 1.1.2? Nadal swoi na 1.1.1
Przepraszam za dość znaczną obsuwę. Wydane wczoraj w nocy.
Oprócz nowych komponentów z podfiksowaną ścieżką obsługi odbiornika doszło kilka zmian poprawiających stabilność działania pompy ładunku w wyświetlaczu. Na ok. 10% urządzeń które wyjechały od nas z warsztatu zdarzało się, że mimo wciśnięcia przycisku, wyświetlacz się nie wybudzał. Problem prawdopodobnie jest rozwiązany.
Mam dziwny problem z tym komponentem. Działa poprawnie czyta i dekoduje 3 wodomierze natomiast 1 jest odczytany ale chyba nie zdekodowany.
[23:22:06.038][D][wmbus:181]: Try to make frame from packet t1 of size 191
[23:22:06.044][I][wmbus:047]: Frame created (111 bytes) [RSSI: -101, mode:t1]
[23:22:06.051][W][main:057]: Meter ID: 06200401.M=APA.V=05.T=07
[23:22:06.055][W][main:060]: Frame: WMBusmeters Analyze Telegram
[23:22:06.068][I][wmbus:054]: Telegram handled by 0 handlers
Będę wdzięczny za pomoc
no key to decrypt payload!
Nie wpisałeś klucza dekodującego
klucz mam podany to ciąg 000000000000 i trzy wodomierze na tym są odczytywane a czwarty juz nie
Policz te zera, może jest ich za mało…
Na stronie dekoduje z kluczem 12 zer więc problem musi leżeć gdzie indziej.
Auto driver : apator162
Similar driver : apator162 94/94
Using driver : apator162 00/00
000 : 6e length (110 bytes)
001 : 44 dll-c (from meter SND_NR)
002 : 0106 dll-mfct (APA)
004 : 01042006 dll-id (06200401)
008 : 05 dll-version
009 : 07 dll-type (Water meter)
010 : 7a tpl-ci-field (EN 13757-3 Application Layer (short tplh))
011 : 82 tpl-acc-field
012 : 00 tpl-sts-field (OK)
013 : 6085 tpl-cfg 8560 (bidirectional AES_CBC_IV nb=6 cntn=0 ra=0 hc=0 )
015 : 2f2f decrypt check bytes (OK)
017 C!: 0F manufacturer specific data C5AAB49A080200436C04830014E363AD3904C1A11410532A00007B01172A0000442900003F2800004A2700009D260000AE250000782400006D230000452200003421000002200000011F0000A0CA47A504FFFFFFFFFFFFFFFFFFFF2C28
decode(off = 0)
{
'0F'
status(off = 2) = C5AAB49A080200
days(off = 16) = 6C04
woot_8x(off = 20) = 0014E363AD3904C1A114
total(dvk = 0413
off = 40) = 532A0000
woot_7B(off = 48) = 01172A0000442900003F2800004A2700009D260000AE250000782400006D230000452200003421000002200000011F0000
woot_A0(off = 146) = CA47A504
pad_FF(off = 154) = FFFFFFFFFFFFFFFFFFFF
checksum(off = 174) = 2C28
}
037 C!: *** 532A0000 ("total_m3":10.835)
{
"_":"telegram",
"media":"water",
"meter":"apator162",
"name":"",
"id":"06200401",
"total_m3":10.835,
"timestamp":"2026-04-11T05:11:31Z"
Ok - wiem gdzie jest problem .
U mnie też to się nie chce dekodować więc @angler ma racje.
Dopiero jak wpisałem : 00000000000000000000000000000000
To mi zdekodował :).
Zresztą w dokumentacji dodatku jest przykład :
wmbus_meter:
id: my_water_meter
radio_id: radio_component
meter_id: 12345678
type: apator162
key: "00000000000000000000000000000000"
mode: T1
on_telegram:
- socket_transmitter.send:
id: transmitter
data: !lambda return meter.as_json();
- wmbus_meter.send_telegram_with_mqtt:
topic: test/topic
Niestety to nie to 
jak by się uparł na ten jeden konkretny wodomierz
[08:51:33.825][D][wmbus:181]: Try to make frame from packet t1 of size 191
[08:51:53.468][D][wmbus:181]: Try to make frame from packet t1 of size 191
[08:51:53.478][I][wmbus:047]: Frame created (111 bytes) [RSSI: -99, mode:t1]
[08:51:53.480][W][main:057]: Meter ID: 06200467.M=APA.V=05.T=07
[08:51:53.499][W][main:060]: Frame: WMBusmeters Analyze Telegram
[08:51:53.506][I][wmbus:054]: Telegram handled by 0 handlers
[08:51:53.506][D][status_led:050]: ‘wmbus_gateway_status_led’: Setting state ON
[08:51:53.536][D][status_led:050]: ‘wmbus_gateway_status_led’: Setting state OFF…
[08:52:30.306][D][status_led:050]: ‘wmbus_gateway_status_led’: Setting state OFF
[08:52:38.578][D][wmbus:181]: Try to make frame from packet t1 of size 191
[08:52:38.589][I][wmbus:047]: Frame created (111 bytes) [RSSI: -95, mode:t1]
[08:52:38.589][W][main:057]: Meter ID: 06289472.M=APA.V=05.T=07
[08:52:38.594][W][main:060]: Frame: WMBusmeters Analyze Telegram
[08:52:38.610][I][wmbus:054]: Telegram handled by 1 handlers
[08:52:38.614][D][status_led:050]: ‘wmbus_gateway_status_led’: Setting state ON
[08:52:38.618][D][sensor:124]: ‘Stan licznika wody kuchnia zimna’ >> 4.670 m³
[08:52:38.622][D][sensor:124]: ‘Kuchnia zimna RSSI’ >> -95 dBm
[08:52:38.634][D][status_led:050]: ‘wmbus_gateway_status_led’: Setting state OFF
licz zera - mają być 32.
Dla testu zahashuj/skomentuj pozostałe i zobacz czy wtedy przeczyta.
Ja nie używam tego dodatku.
Twój licznik to 06200467 więc musisz mieć błąd w YAML.
Poprzednio był to 06200401.
EDIT:
Masz tu trzy różne ID:
- 06200401 → handled by 0 handlers
- 06200467 → handled by 0 handlers
- 06289472 → handled by 1 handlers <= i tylko ten został poprawnie przeczytany.
YAML wrzuć bo tak sobie możemy zgadywać do jutra.
Apator 162 ma domyślny klucz 32 zera, więc albo złe id licznika albo źle klucz podajesz
to mój yaml
packages:
wmbus_gateway: github://IoTLabs-pl/wM-Bus-Gateway/packages/wmbus_gateway.yaml@v1.1.3
esphome:
friendly_name: wM-Bus Gateway
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Wmbus-Gateway Fallback Hotspot"
password: "xxxxxxxxxxxxxx"
# If you want to connect with HA, you need to enable API.
api:
encryption:
key: "xxxxxxxxxxxxxxxxxxxxx"
# If you want to use OTA updates, you need to enable OTA.
ota:
- platform: esphome
password: "xxxxxxxxxxxxxxxxxxxxxxxxxxx"
captive_portal:
# Enable web server
web_server:
port: 80
version: 3
# If you want to use MQTT, you need to enable MQTT.
# mqtt:
# broker: mqtt.example.com
# username: !secret mqtt_username
# password: !secret mqtt_password
wmbus_radio:
# This part of config is responsible for listening to any wM-Bus frames.
# The same part of config is present in the factory firmware.
# Using links appear in the logs, you will be redirected to the wM-Bus Meters Analyzer
# allowing you inspect the received frames, identify proper driver,
# check your decryption key and identify available fields in datagrams.
# You may comment out this section if your meters are already configured
# and you don't want to see the frames in the logs.
on_frame:
- then:
- logger.log:
level: WARN
format: "Meter ID: %s"
args: ["frame->meter_id().c_str()"]
- logger.log:
level: WARN
format: "Frame: https://wmbusmeters.org/analyze/%s"
args: ["frame->as_hex().c_str()"]
wmbus_meter:
# This part of config is responsible for handling the received frames
# for the specified meter. You may send whole decoded datagram everywhere
# You may specify multiple meters.
#- id: my_meter
# meter_id: 12345678
# type: apator162
# key: 00112233445566778899aabbccddeeff # Optional, if your meter is encrypted. May be specified as ASCII or HEX string.
# mode: C1 # or T1 if you want to filter specific modes. When not specified, all modes are accepted.
# on_telegram:
# Sending telegram to MQTT topic as JSON. MQTT component must be configured in your config.
# - then:
# - wmbus_meter.send_telegram_with_mqtt:
# topic: some_topic
# Sending telegram to HTTP endpoint as JSON.
# - then:
# - http_request.post:
# url: http://example.com/api
# headers:
# Content-Type: application/json
# body: !lambda |-
# return meter.as_json();
- id: kcw
meter_id: 06195765
type: apator162
key: "00000000000000000000000000000000"
- id: kzw
meter_id: 06289472
type: apator162
key: "00000000000000000000000000000000"
- id: lcw
meter_id: 06200467
type: apator162
key: "00000000000000000000000000000000"
- id: lzw
meter_id: 06289232
type: apator162
key: "00000000000000000000000000000000"
sensor:
# This part of config is responsible for extracting specific fields
# from the meter data and making them available as sensors.
# By default, unit of measurement is determined from the field.
# You may specify unit of measurement to override it.
# All parameters from https://esphome.io/components/sensor/index.html are supported.
# - platform: wmbus_meter
# id: total_water_sensor
# field: total_m3
# parent_id: my_meter
# name: Water Consumption
# state_class: total_increasing
# device_class: water
# - platform: wmbus_meter
# id: water_meter_rssi
# field: rssi_dbm
# parent_id: my_meter
# name: RSSI
# device_class: signal_strength
# state_class: measurement
- platform: wmbus_meter
parent_id: kcw
field: total_m3
name: Stan licznika wody kuchnia ciepła
accuracy_decimals: 3
unit_of_measurement: "m³"
device_class: "water"
state_class: "total_increasing"
icon: "mdi:water"
- platform: wmbus_meter
parent_id: kcw
field: rssi_dbm
name: Kuchnia ciepła RSSI
- platform: wmbus_meter
parent_id: kzw
field: total_m3
name: Stan licznika wody kuchnia zimna
accuracy_decimals: 3
unit_of_measurement: "m³"
device_class: "water"
state_class: "total_increasing"
icon: "mdi:water"
- platform: wmbus_meter
parent_id: kzw
field: rssi_dbm
name: Kuchnia zimna RSSI
- platform: wmbus_meter
parent_id: lcw
field: total_m3
name: Stan licznika wody łazienka ciepła
accuracy_decimals: 3
unit_of_measurement: "m³"
device_class: "water"
state_class: "total_increasing"
icon: "mdi:water"
- platform: wmbus_meter
parent_id: lcw
field: rssi_dbm
name: Łazienka ciepła RSSI
- platform: wmbus_meter
parent_id: lzw
field: total_m3
name: Stan licznika wody łazienka zimna
accuracy_decimals: 3
unit_of_measurement: "m³"
device_class: "water"
state_class: "total_increasing"
icon: "mdi:water"
- platform: wmbus_meter
parent_id: lzw
field: rssi_dbm
name: Łazienka zimna RSSI
wmbus_gateway:
# If you want to set specific pages on the display, you may use the following config.
# By default, all defined sensor are displayed.
# pages:
# - total_water_sensor
# - water_meter_rssi
to mój tabliczka mojej nakładki
bede wdzięczny za sprawdzenie może gdzieś cos oczywistego przegapiłem
na próbę zmień z:
meter_id: 06200467
Na :
meter_id: "06200467"
Sam telegram wygląda poprawnie, bo jest widoczny i możliwy do analizy. To wskazuje, że odbiór ramki jest zasadniczo OK, więc problem najpewniej pojawia się dopiero później, przy dopasowaniu lub obsłudze w konfiguracji.
Started config hextty on stdin listening on any
No meters configured. Printing id:s of all telegrams heard!
Received telegram from: 06200467
manufacturer: (APA) Apator, Poland (0x601)
type: Water meter (0x07) encrypted
ver: 0x05
driver: apator162
[wmbus-bridge][WARN] === NEW METER CANDIDATE DETECTED ===
[wmbus-bridge][WARN] Received telegram from: 06200467
[wmbus-bridge][WARN] Suggested driver: apator162
[wmbus-bridge][WARN] Add to options.json meters[] (example):
[wmbus-bridge][WARN] {"id":"meter_06200467","meter_id":"06200467","type":"auto","type_other":"","key":"NOKEY"}
[wmbus-bridge][WARN] ==================================
Wielkie dzięki pomogło 
na to bym nie wpadł. Wszystkie id licznika tak pozmieniać dla bezpiecznstwa?
Tak 
- pozmieniaj sobie wszystkie.
Wygląda na to, że zawiodło automatyczne dopasowanie typów zmiennych, bo z tych czterech id tylko ten może nie zostać rozpoznany jako liczba dziesiętna.
1 Like
Kazałem pokopać GPT i …dał ciekawą teorię ( wszystko poniżej to już GPT - mocno skróciłem ) :
Właśnie dlatego wywaliło się tylko na tej jednej.
06200467 ma dwie cechy naraz:
zaczyna się od 0
składa się wyłącznie z cyfr 0–7
I to jest dokładnie taki kształt, który w starych regułach YAML wygląda jak liczba „ósemkowa”. W nowszym YAML 1.2 octal powinien mieć prefiks 0o, a samo 010 ma być już zwykłą liczbą 10, ale różne stosy/parsery nadal potrafią inaczej traktować niecytowane wartości wyglądające jak liczby.
Ta jedna linia padła, bo tylko ten numer wyglądał dla parsera jak „specjalna liczba”, a nie zwykły tekst.
Po dodaniu cudzysłowu:
meter_id: "06200467"
parser dostał jasny sygnał: to jest tekst, nie kombinuj. ESPHome też wprost rozróżnia stringi w cudzysłowie od niecytowanych wartości, które mogą zostać potraktowane jako liczby lub booleany.