Support (Driver) for encrypted Watermeter Diehl Hydrus

[DidiH2]

Is it possible to add a driver for Diehl Hydrus (encrypted) (analogue: https://github.com/wmbusmeters/wmbusmeters/blob/master/src/driver_hydrus.cc). The counter works with this driver and wmbusmeters on rassperry pi. The current installation with ESPHOME has the following output for this counter:

[14:28:14]wMBus-lib: Error during decoding '3 out of 6'[D][wmbus:158]: Meter ID [0x75720392] RSSI: -55 dBm LQI: 128 not found in configuration T: 5344A5119203727576078C00DE900F002C25DAD903006C6F02D21B578D407A6A0031071010F9C7D90DFDEF40B912D1C99E12B132033C8BA9878F4E5BAFC597304667522956F710816EB6310C4D498E81E455D725 (84)

[babajun12]

+1 -same situation here. hydrus driver would need to be implemented/ported for ESP devices (if there are enough resources for decryption on ESP8266?)

[SzczepanLeon]

Hydrus added in 2.1.0, but without encryption.

[meyer-chris]

Hi Leon, any plans to add the support for encrypted telegrams? I'd be highly interested!

[babajun12]

Hi DidiH2, I gave the esphome another try this day including the latest wmbusmeters updates. The result is pretty nice:

[16:13:24][D][sensor:109]: '0x71035750 cold water': Sending state 36.35200 m³ with 3 decimals of accuracy [16:15:49]wMBus-lib: Error during decoding '3 out of 6'wMBus-lib: Error during decoding '3 out of 6'wMBus-lib: Error during decoding '3 out of 6'wMBus-lib: Error during decoding '3 out of 6'wMBus-lib: Error during decoding '3 out of 6'[I][wmbus:065]: Using driver 'hydrus' for ID [0x71035750] RSSI: -81 dBm LQI: 132 Mode: T1 T: 3E44A5115057037170077A780030050EB4F280119FEE79DE56CCDE526BB35D2DB60C82F241F8F6B7D48E898C5F7454FA27C2FAC747307233CA8C7E8844505C (63) [16:16:07][D][wmbus:077]: Decrypted T : 3E44A5115057037170077A780030052F2F01FD08C50C1352630300025AAA0002FD17000002FD74A413C4016D3B17FF25CC0113654603002F2F2F2F2F2F2F2F (63) [16:16:07][D][sensor:109]: '0x71035750 RSSI': Sending state -81.00000 dBm with 0 decimals of accuracy [16:16:08][D][sensor:109]: '0x71035750 cold water': Sending state 36.35200 m³ with 3 decimals of accuracy

Next nice feature would be to exctract the other parameters such as flow temperature, remaining battery life, totat_at_date_m3...

021 : 0C dif (8 digit BCD Instantaneous value) 022 : 13 vif (Volume l) 023 C!: 52630300 ("total_m3":36.352) 027 : 02 dif (16 Bit Integer/Binary Instantaneous value) 028 : 5A vif (Flow temperature 10⁻¹ °C) 029 C!: AC00 **("flow_temperature_c":17.2)** 031 : 02 dif (16 Bit Integer/Binary Instantaneous value) 032 : FD vif (Second extension FD of VIF-codes) 033 : 17 vife (Error flags (binary)) 034 C?: 0000 036 : 02 dif (16 Bit Integer/Binary Instantaneous value) 037 : FD vif (Second extension FD of VIF-codes) 038 : 74 vife (Reserved) 039 C!: A413 ("remaining_battery_life_y":13.766196) 041 : C4 dif (32 Bit Integer/Binary Instantaneous value storagenr=1) 042 : 01 dife (subunit=0 tariff=0 storagenr=3) 043 : 6D vif (Date and time type) 044 C!: 3B17FF25 (**"at_datetime":"2023-05-31 23:59")** 048 : CC dif (8 digit BCD Instantaneous value storagenr=1) 049 : 01 dife (subunit=0 tariff=0 storagenr=3) 050 : 13 vif (Volume l) 051 C!: 65460300 **("total_at_date_m3":34.665)**

[meyer-chris]

Hi DidiH2, I gave the esphome another try this day including the latest wmbusmeters updates. The result is pretty nice:

[16:13:24][D][sensor:109]: '0x71035750 cold water': Sending state 36.35200 m³ with 3 decimals of accuracy [16:15:49]wMBus-lib: Error during decoding '3 out of 6'wMBus-lib: Error during decoding '3 out of 6'wMBus-lib: Error during decoding '3 out of 6'wMBus-lib: Error during decoding '3 out of 6'wMBus-lib: Error during decoding '3 out of 6'[I][wmbus:065]: Using driver 'hydrus' for ID [0x71035750] RSSI: -81 dBm LQI: 132 Mode: T1 T: 3E44A5115057037170077A780030050EB4F280119FEE79DE56CCDE526BB35D2DB60C82F241F8F6B7D48E898C5F7454FA27C2FAC747307233CA8C7E8844505C (63) [16:16:07][D][wmbus:077]: Decrypted T : 3E44A5115057037170077A780030052F2F01FD08C50C1352630300025AAA0002FD17000002FD74A413C4016D3B17FF25CC0113654603002F2F2F2F2F2F2F2F (63) [16:16:07][D][sensor:109]: '0x71035750 RSSI': Sending state -81.00000 dBm with 0 decimals of accuracy [16:16:08][D][sensor:109]: '0x71035750 cold water': Sending state 36.35200 m³ with 3 decimals of accuracy

Next nice feature would be to exctract the other parameters such as flow temperature, remaining battery life, totat_at_date_m3...

021 : 0C dif (8 digit BCD Instantaneous value) 022 : 13 vif (Volume l) 023 C!: 52630300 ("total_m3":36.352) 027 : 02 dif (16 Bit Integer/Binary Instantaneous value) 028 : 5A vif (Flow temperature 10⁻¹ °C) 029 C!: AC00 **("flow_temperature_c":17.2)** 031 : 02 dif (16 Bit Integer/Binary Instantaneous value) 032 : FD vif (Second extension FD of VIF-codes) 033 : 17 vife (Error flags (binary)) 034 C?: 0000 036 : 02 dif (16 Bit Integer/Binary Instantaneous value) 037 : FD vif (Second extension FD of VIF-codes) 038 : 74 vife (Reserved) 039 C!: A413 ("remaining_battery_life_y":13.766196) 041 : C4 dif (32 Bit Integer/Binary Instantaneous value storagenr=1) 042 : 01 dife (subunit=0 tariff=0 storagenr=3) 043 : 6D vif (Date and time type) 044 C!: 3B17FF25 (**"at_datetime":"2023-05-31 23:59")** 048 : CC dif (8 digit BCD Instantaneous value storagenr=1) 049 : 01 dife (subunit=0 tariff=0 storagenr=3) 050 : 13 vif (Volume l) 051 C!: 65460300 **("total_at_date_m3":34.665)**

This indeed looks great! Can you please provide guidance on how to get there, I'd like to give it a shot as well - all i need is total_m3 and this seems to work...

[babajun12]

Chris(?), I just had to change ports for Wemos D1 mini as following and insert the key. Not sure why it works, becaus I cannot see any decryption in the driver_hydrus.h file ? But maybe bcs my watermeter uses a widely known/default key.

time:
  - platform: sntp
    id: time_sntp

external_components:
  - source: github://SzczepanLeon/esphome-components@main
    components: [ wmbus ]

wmbus:
  mosi_pin: GPIO13
  miso_pin: GPIO12
  clk_pin:  GPIO14
  cs_pin:   GPIO15
  gdo0_pin: GPIO0
  gdo2_pin: GPIO4

#  led_pin: GPIO2
#  led_blink_time: "1s"

#  clients:
#    - name: "wmbusmeters"
#      ip_address: "192.168.1.30"
#      port: 7227

sensor:
  - platform: wmbus
    meter_id: 0x71035750
    type: hydrus
    key: "your-32-bit-key-here"
#   lqi:
#      name: "My lqi"
    rssi:
      name: "RSSI"
    total_water_m3:
      name: "cold water"```

[babajun12]

...and https://wmbusmeters.org/analyze/3e44a5115057037170077a780030050eB4f280119fee79de56ccde526BB35d2dB60c82f241f8f6B7d48e898c5f7454fa27c2fac747307233ca8c7e8844505c:hydrus

decrypts the datastream without any key. Maybe give it a try there first.

[meyer-chris]

Hi, nope, I can confirm... it's not working with encrypted telegrams, yet. I tried it with mine and the correct key. I can successfully decrypt on wmbusmeters.org with the key, but on the d1 still the same:

[22:07:24][E][wmbus:088]: Something was not OK during decrypting telegram for ID [0x71283126] 'hydrus' key: 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' [22:07:24][E][wmbus:092]: T : 5344A5112631287176078C00EB900F002C25D5910100708124FA99FFADEB7AD800310710B9C8C27A26AA051A7FEA3D3FDCA8E7E4FA4BB3F898541BBEABE1E96D40120894B65F490AFADC05D1448AA8DBBE774226 (84) [22:07:24][E][wmbus:093]: T': 5344A5112631287176078C00EB900FF5B70C649A92B338DDDCB670C2055E777D90050D92A00969D3B8C6A582786F7C5359688A5CA7E35C057670CC086662D66D40120894B65F490AFADC05D1448AA8DBBE774226 (84) [22:07:24][E][wmbus:116]: Can't get value from telegram for ID [0x71283126] 'hydrus' [22:07:24][E][wmbus:119]: T : 5344A5112631287176078C00EB900FF5B70C649A92B338DDDCB670C2055E777D90050D92A00969D3B8C6A582786F7C5359688A5CA7E35C057670CC086662D66D40120894B65F490AFADC05D1448AA8DBBE774226 (84)

But anyway, thanks for checking! Best, Chris

[meyer-chris]

just checking if there is anything we can help out with to fix this issue? I'm happy to provide telegrams, logs or whatever is needed - happy to help out :-)

[SzczepanLeon]

just checking if there is anything we can help out with to fix this issue? I'm happy to provide telegrams, logs or whatever is needed - happy to help out :-)

Only extra time is needed. :-( And maybe example key if You can share it.

[meyer-chris]

I hear you... I can help out with a sample message, key as well as the decrypted telegram (used https://wmbusmeters.org/). i'll provide it to you out of band...

[BeryBurnout]

similar situation here:

Hydrus Type 173 20:34:09][E][wmbus:161]: Can't get value from telegram for ID [0x81035812] 'hydrus' [20:34:09][E][wmbus:164]: T : 3E44A5111258038176077AE6803005D9266E83636276A689CBEFC0CDE06CE04CDB82CFD8200E1E37F4D95BBEB34D6EEF74C5D3762E82D9D5872BB1124F3229 (63) [20:34:11][E][wmbus:161]: Can't get value from telegram for ID [0x81035812] 'hydrus' [20:34:11][E][wmbus:164]: T : 3E44A5111258038176077AE7803025436358D96A0E6455EFBF7CB32A0DE6A4A74E959441F1EFF7EF2BA400842EE92F32C9BD7A1DD2C8D71D3454A3E32731DA (63)

for me the total water amount would be enough

[SzczepanLeon]

You need key.

[geeuz]

Hello,

as mentioned here https://github.com/SzczepanLeon/esphome-components/issues/77 - my CC1101 receives correct unencrypted Telegrams from my Hydrus.

I can read them with the Wmbusmeters Analyzer, but in Esphome the log shows "Can't get value(s) from telegram for ID"

Any idea?

Examples: Link1 Link2

Any help would be appreciated.

[18:18:36][V][rxLoop:167]: Have 110 bytes from CC1101 Rx, RSSI: -48 dBm LQI: 130
[18:18:36][D][mbus:034]: Processing T1 A frame
[18:18:36][V][mbus:045]: Frame: 2F271C99934DB0E39394E4D64D65935AC3634E6D1A5962D65993B199634DCB4C63C56956B263634D66A6D268D92D6B1C3A5D1A68B2CBB0EA6C2D96A959CC6C36C6B469A5AC64BC8EC5AC969A64CB372D3464DC9A3B46B18F298B64BD198E636370EC8D996CB298D94DB319636634 (110) [RAW]
[18:18:36][V][mbus:052]: Frame: 3E44A511822792707007081B7AC60030052DA011ECDBD0908A1B706ACAB5308429C6633382F8356F04D8186C660853E2D6E0AA731ECC51E62C6DBEA353C5BA1B42E1A0EEA1918D9B5B (73) [with CRC]
[18:18:36][V][mbus:095]: Validating CRC for Block1
[18:18:36][V][crc:031]:     calculated: 0x081B, read: 0x081B
[18:18:36][V][mbus:115]: Validating CRC for Block2
[18:18:36][V][crc:031]:     calculated: 0xCAB5, read: 0xCAB5
[18:18:36][V][mbus:115]: Validating CRC for Block3
[18:18:36][V][crc:031]:     calculated: 0x53E2, read: 0x53E2
[18:18:36][V][mbus:115]: Validating CRC for Block4
[18:18:36][V][crc:031]:     calculated: 0x42E1, read: 0x42E1
[18:18:36][V][mbus:115]: Validating CRC for Block5
[18:18:36][V][crc:031]:     calculated: 0x9B5B, read: 0x9B5B
[18:18:36][V][mbus:062]: Frame: 3E44A5118227927070077AC60030052DA011ECDBD0908A1B706A308429C6633382F8356F04D8186C6608D6E0AA731ECC51E62C6DBEA353C5BA1BA0EEA1918D (63) [without CRC]
[18:18:36][D][wmbus:097]: Using driver 'hydrus' for ID [0x70922782] RSSI: -48 dBm LQI: 130 Frame: T1 A T: 3E44A5118227927070077AC60030052DA011ECDBD0908A1B706A308429C6633382F8356F04D8186C6608D6E0AA731ECC51E62C6DBEA353C5BA1BA0EEA1918D (63)
[18:18:36][D][wmbus:161]: Can't get value(s) from telegram for ID [0x70922782]
[18:18:36][W][component:214]: Component wmbus took a long time for an operation (0.14 s).
[18:18:36][W][component:215]: Components should block for at most 20-30ms.

[SzczepanLeon]

Any idea?

You need key. Default one from the internet should be OK.

[geeuz]

Found it, thank you very much!

This is the second time you have helped me, tell me how I can invite you for a beer and a coffee, I haven't found anything here that I can donate to you.

And if you could add more data as described in https://github.com/SzczepanLeon/esphome-components/issues/77, it would be awesome.

[SzczepanLeon]

beer and a coffee, I haven't found anything here that I can donate to you.

https://github.com/SzczepanLeon/esphome-components?tab=readme-ov-file#szczepans-esphome-custom-components

[chrismeyerde]

Just checking if there's any progress for encrypted telegrams? I'd be highly interested... still getting the following even if I set the correct key:

[19:38:51][D][mbus:034]: Processing T1 A frame [19:38:51][D][wmbus:090]: Using driver 'hydrus' for ID [0x71283126] RSSI: -62 dBm LQI: 128 Frame: T1 A T: 5344A5112631287176078C0085900F002C2537091800B5F50C2A95CFDF867A3D00310710E5995B140028D6D6D4FFEFC451F3FB4AA02FF852340BFF2F2B7544B998F81FDF68E9E7826EFC373A7714C5A033378B87 (84) [19:38:51][E][utils:214]: (TPL) unknown CI field [8C]

[geeuz]

Damn I'm blind :) Done.

[SzczepanLeon]

Just checking if there's any progress for encrypted telegrams?

In progress. Due to lack of time I can't predict exact date. Next version should be with part of wmbusmeters ported to ESP32. So everything (I hope so) will be supported.

[chrismeyerde]

awesome! this is great news!!!! cheers!

[matscheck]

Unfortunately, my English is not so good. Did I understand correctly that this error will no longer occur with the next version?

16:01:00 [E] [utils:214] (TPL) unknown CI field [8C]

Thank you very much in advance.

[SzczepanLeon]

Yes, You are right.

[ThomDietrich]

Hey guys! I am a new user of this library and ran into the same issue

[E][utils:214]: (TPL) unknown CI field [8C]

If I understand correctly, you did not yet commit/publish the version with the fix? Thanks in advance!

My relevant config:

esphome:
  platformio_options:
    board_build.flash_mode: dio
    board_build.mcu: esp32c3

esp32:
  board: esp32-c3-devkitm-1
  variant: esp32c3
  framework:
    type: arduino

external_components:
  - source: github://SzczepanLeon/esphome-components@main
    refresh: 0s
    components: [wmbus]

[ThomDietrich]

I tried my luck and inserted the "8C" ci field under switch(ci_field) -> "short TPL" and "long TPL". I have to admit that I didn't know what I am doing. I spent two seconds reading the open metering system specs but didn't get much further. In both versions the library ends with invalid decrypted data ("2F2F check after decrypting !!!"). It occurred to me that there is a ELL routine in parallel to TPL. I did also try that route but I am simply speaking not sure what we are aiming for 🙈

What else can I test or do to get this working? Thanks!

Auto driver    : hydrus
Similar driver : unknown 00/00
Using driver   : hydrus 00/00
000   : 53 length (83 bytes)
001   : 44 dll-c (from meter SND_NR)
002   : a511 dll-mfct (DME)
004   : 99557581 dll-id (81755599)
008   : 76 dll-version
009   : 07 dll-type (Water meter)
010   : 8c ell-ci-field (ELL: Extended Link Layer I (2 Byte))
011   : 00 ell-cc (slow_resp)
012   : 74 ell-acc
013   : 90 afl-ci-field (AFL: Authentication and Fragmentation Sublayer)
014   : 0f afl-len (15)
015   : 002c afl-fc (0 MACInFragment MessCounterInFragment MessControlInFragment LastFragment)
017   : 25 afl-mcl (AES_CMAC_128_8 MessCounter)
018   : f16a0000 afl-counter (27377)
022   : A5FD6B4839C19A9A afl-mac 8 bytes
030   : 7a tpl-ci-field (EN 13757-3 Application Layer (short tplh))
031   : bd tpl-acc-field
032   : 00 tpl-sts-field (OK)(OK)
033   : 3107 tpl-cfg 0731 (AES_CBC_NO_IV )
035   : 10 tpl-cfg-ext (KDFS=1)
036 CE: DCA364EB8012DF2705052A5D4BA9B714B0EB159E940104C163E3DD93138796A4999E9665D9B663B91DB0A5AF8D3981FD encrypted mac failed

[ThomDietrich]

Any hint would be much appreciated. I can invest the time to resolve this issue myself but need a bit more context. In my particular case offset = 36 seems to select the correct encrypted message (confirmed via wmbusmeters.org) but I am not able to build a correct iv vector or something else is wrong going into the decryption routine. What am I missing?

[11:08:35][VV][utils:272]: (TPL) AES CBC IV decrypting: AD0AEC373D010AC0CC26FF754F01226A603A4E419120ED2160B154AD7DC192F557489526AFCE7744F757064F2CA285CE (48)
[11:08:35][VV][utils:302]: (TPL) AES CBC IV  decrypted: B61573E262EF4A006F02D4193E2E8CA3BF851046C5836E421B34D561BBFF6774270AC94BD04FC8802FBFB79183F5AAF2 (48)
[11:08:35][D][utils:314]: 2F2F check after decrypting - failed!
[11:08:35][VV][wmbus:298]: Decrypting TPL AES CBC IV failed!