Assistance to decode telegram

gllmlbrt commented 6 months ago

Hi, Thanks for your repo, i have managed to go quite a long way, but I seem to be stuck at the very frustrating last step to send the decoded telegram water volume number to HA.

So i ran the test to find my meter. It was successful, and I identified the following log entry: [20:36:15][D][wmbus:188]: Meter ID [*0x6426068B*] RSSI: -51 dBm LQI: 129 Mode: T1 not found in configuration T: 1E4424238B06266408497A880010D264831C4D6C4CCD7EBE27703C53B20068 (31)

Which gets decoded successfully on wmbusmeters.org as follows:

Auto driver  : hydrus
Best driver  : topaseskr 10/10
Using driver : topaseskr 00/00
000   : 1e length (30 bytes)
001   : 44 dll-c (from meter SND_NR)
002   : 2423 dll-mfct (HYD)
004   : 26640849 dll-id (49086426)
008   : 8b dll-version
009   : 06 dll-type (Warm Water (30°C-90°C) meter)
010   : 7a tpl-ci-field (EN 13757-3 Application Layer (short tplh))
011   : 88 tpl-acc-field
012   : 00 tpl-sts-field (OK)
013   : 10d2 tpl-cfg d210 (bidirectional accessibility SPECIFIC_16_31 )
015   : 04 dif (32 Bit Integer/Binary Instantaneous value)
016   : 13 vif (Volume l)
017 C!: A5B10400 ("total_m3":307.621)
021   : 42 dif (16 Bit Integer/Binary Instantaneous value storagenr=1)
022   : 6C vif (Date type G)
023 C!: FF2C ("meter_year_period_start_date":"2023-12-31")
025   : 44 dif (32 Bit Integer/Binary Instantaneous value storagenr=1)
026   : 13 vif (Volume l)
027 C!: 7EAF0400 ("volume_year_period_m3":307.07)

{
    "media":"warm water",
    "meter":"topaseskr",
    "name":"",
    "id":"49086426",
    "total_m3":307.621,
    "volume_year_period_m3":307.07,
    "meter_year_period_start_date":"2023-12-31",
    "timestamp":"2024-01-04T06:47:02Z"
}
Using: wmbusmeters: 1.14.0-48-gc4b9f0d
c4b9f0d10477cb6bb2472e1f2de5eb08ba42e7c4

Now the MeterID 49086426 is also what is on the sticker of the meter. So I assume it is decimal.

My esphome yaml is as follows:

sensor:
 - platform: wmbus
   meter_id: 49086426
   key: ""
   type: topaseskr
   add_prefix: false
   total_water_m3:
     name: "Watermeter display"
     id: "waterdisplay"
     unit_of_measurement: "m³"
     state_class: total_increasing
     device_class: "water"
     accuracy_decimals: 3
     icon: mdi:counter

Now I have tried the same with MeterID: 0x6426068B (From the log above). MeterID: 49086426 (Decimal ID on sticker) and MeterID: 0x2ECFFDA (The Hex conversion of the sticker ID). I went through https://github.com/SzczepanLeon/esphome-components/issues/6 which made me go through various options.

I have tried drivers topaseskr and hydrus as the two suggeted in wmbusmeters.org which both decode successfully.

But I cannot see why I always get "unknown" for the sensor:

Is there something I am missing, is there something which could be wrong (bug) with the driver or wmbus component for this meter ?

SzczepanLeon commented 6 months ago

Try itron

gllmlbrt commented 6 months ago

Thanks, actually I made some progress, and managed to get it to return that it found the meter, by assigning the Hex Idea from the log. So this allows the meter to be found:

sensor:
 - platform: wmbus
   meter_id: 0x6426068B
   key: ""

I have tried with many different drivers, itron, hydrus and topazeskr which were suggested in wmbusmeters.org But it returns this:

[10:39:43][I][wmbus:087]: Using driver 'hydrus' for ID [0x6426068B] RSSI: -31 dBm LQI: 130 Mode: T1 T: 1E4424238B06266408497A020010146433664DD5B68027B000C4A9C2A904FB (31)
[10:39:43][E][wmbus:167]: Can't get value from telegram for ID [0x6426068B] 'hydrus'
[10:39:43][E][wmbus:168]: T : 1E4424238B06266408497A020010146433664DD5B68027B000C4A9C2A904FB (31)

Which I suppose is only a remaining issue with the driver. Could you assit guessing how perhaps edit the driver, so it can extract the right data from the decoded telegram ?

SzczepanLeon commented 6 months ago

Which I suppose is only a remaining issue with the driver.

Use driver itron and share logs (VERY_VERBOSE).

gllmlbrt commented 6 months ago

Here is a cycle that repeats itsef:

[12:55:04][VV][wmbus:057]: have data from CC1101 ...
[12:55:05][VV][wmbus:057]: have data from CC1101 ...
[12:55:10][VV][wmbus:057]: have data from CC1101 ...
[12:55:10][VV][scheduler:226]: Running interval 'update' with interval=60000 last_execution=44473 (now=104474)
[12:55:10][V][sensor:043]: 'wifi_signal_db': Received new state -59.000000
[12:55:10][D][sensor:094]: 'wifi_signal_db': Sending state -59.00000 dBm with 0 decimals of accuracy
[12:55:10][V][sensor:043]: 'Device WLAN RSSI': Received new state -59.000000
[12:55:10][VV][sensor.filter:014]: Filter(0x3ffb2ea0)::input(-59.000000)
[12:55:10][VV][sensor.filter:282]: LambdaFilter(0x3ffb2ea0)::new_value(-59.000000) -> 82.000000
[12:55:10][VV][sensor.filter:021]: Filter(0x3ffb2ea0)::output(82.000000) -> SENSOR
[12:55:10][D][sensor:094]: 'Device WLAN RSSI': Sending state 82.00000 % with 0 decimals of accuracy
[12:55:10][VV][api.service:140]: send_sensor_state_response: SensorStateResponse {
  key: 1969750184
  state: 82
  missing_state: NO
}
[12:55:13][VV][scheduler:226]: Running interval '' with interval=60000 last_execution=47211 (now=107211)
[12:55:14][VV][wmbus:057]: have data from CC1101 ...
[12:55:20][VV][scheduler:226]: Running interval 'update' with interval=60000 last_execution=53767 (now=113768)
[12:55:20][VV][wmbus:057]: have data from CC1101 ...
[12:55:22][VV][wmbus:057]: have data from CC1101 ...
[12:55:23][VV][wmbus:057]: have data from CC1101 ...
[12:55:28][VV][wmbus:057]: have data from CC1101 ...
[12:55:31][VV][wmbus:057]: have data from CC1101 ...
[12:55:36][VV][wmbus:057]: have data from CC1101 ...
[12:55:37][VV][api.connection:132]: Sending keepalive PING...
[12:55:37][VV][api.service:037]: send_ping_request: PingRequest {}
[12:55:37][VV][api.service:567]: on_ping_response: PingResponse {}
[12:55:38][VV][api.service:558]: on_ping_request: PingRequest {}
[12:55:38][VV][api.service:043]: send_ping_response: PingResponse {}
[12:55:38][VV][wmbus:057]: have data from CC1101 ...
[12:55:41][VV][wmbus:057]: have data from CC1101 ...
[12:55:44][VV][wmbus:057]: have data from CC1101 ...
[12:55:48][VV][wmbus:057]: have data from CC1101 ...
[12:55:48][I][wmbus:087]: Using driver 'itron' for ID [0x6426068B] RSSI: -31 dBm LQI: 130 Mode: T1 T: 1E4424238B06266408497A3F001014640539150D3E746ADBD092A25DFFCC8F (31)
[12:55:48][E][wmbus:167]: Can't get value from telegram for ID [0x6426068B] 'itron'
[12:55:48][E][wmbus:168]: T : 1E4424238B06266408497A3F001014640539150D3E746ADBD092A25DFFCC8F (31)
[12:55:52][VV][wmbus:057]: have data from CC1101 ...
[12:55:57][VV][wmbus:057]: have data from CC1101 ...
[12:56:00][VV][scheduler:226]: Running interval 'update' with interval=60000 last_execution=93707 (now=153707)
[12:56:00][V][sensor:043]: 'Device Boot counter': Received new state 13.000000
[12:56:00][D][sensor:094]: 'Device Boot counter': Sending state 13.00000  with 0 decimals of accuracy
[12:56:00][VV][api.service:140]: send_sensor_state_response: SensorStateResponse {
  key: 3926447723
  state: 13
  missing_state: NO
}
[12:56:00][VV][wmbus:057]: have data from CC1101 ...
[12:56:05][VV][wmbus:057]: have data from CC1101 ...
[12:56:10][VV][wmbus:057]: have data from CC1101 ...
[12:56:10][VV][scheduler:226]: Running interval 'update' with interval=60000 last_execution=104473 (now=164474)
[12:56:10][V][sensor:043]: 'wifi_signal_db': Received new state -59.000000
[12:56:10][D][sensor:094]: 'wifi_signal_db': Sending state -59.00000 dBm with 0 decimals of accuracy
[12:56:10][V][sensor:043]: 'Device WLAN RSSI': Received new state -59.000000
[12:56:10][VV][sensor.filter:014]: Filter(0x3ffb2ea0)::input(-59.000000)
[12:56:10][VV][sensor.filter:282]: LambdaFilter(0x3ffb2ea0)::new_value(-59.000000) -> 82.000000
[12:56:10][VV][sensor.filter:021]: Filter(0x3ffb2ea0)::output(82.000000) -> SENSOR
[12:56:10][D][sensor:094]: 'Device WLAN RSSI': Sending state 82.00000 % with 0 decimals of accuracy
[12:56:10][VV][api.service:140]: send_sensor_state_response: SensorStateResponse {
  key: 1969750184
  state: 82
  missing_state: NO

SzczepanLeon commented 6 months ago

That kind of telegram is not supported.

gllmlbrt commented 6 months ago

OK, you mean not supported by the Esphome component then ? Because it decodes perfectly in wmbusmeters:

{ "media":"warm water", "meter":"topaseskr", "name":"", "id":"49086426", "total_m3":307.621, "volume_year_period_m3":307.07, "meter_year_period_start_date":"2023-12-31", "timestamp":"2024-01-04T06:47:02Z" } Would you have any recommendation as to how to decode and send the json into HA or MQTT ?

SzczepanLeon commented 6 months ago

Yes, not supported by esphome component. Seems that there is extra layer inside but it should be easy to add that code from wmbusmeters.

gllmlbrt commented 6 months ago

Yes, not supported by esphome component. Seems that there is extra layer inside but it should be easy to add that code from wmbusmeters.

Do you mean that adding a new driver item would be possible? Is there any documentation?

Or update the Component with a more recent version of wmbusmeters?

SzczepanLeon commented 6 months ago

I mean implement code from this part:

https://github.com/wmbusmeters/wmbusmeters/blob/331c5a4018ac75bf4a0f0be4571b061836a6bf7c/src/wmbus.cc#L1750

probably - this is my quick guess

gllmlbrt commented 6 months ago

Never mind I actually decided to change strategy and tested the method of sending the telegram to Home Assistant add on where the decoding and publishing to MQTT happens: https://gist.github.com/KrzysztofHajdamowicz/199c815c3a7fe7d2b445ee801d70f90e

I would say a big less elegant than the pure esphome method but it works for all my water and heat meters. Thansk for the help in progressing my projet.

SzczepanLeon commented 6 months ago

I use the same approach: https://github.com/SzczepanLeon/esphome-components/blob/main/docs%2Fwmbus.md

zibous / ha-watermeter

Assistance to decode telegram #35