openhabforum.de

ich schaffe es mit rtl433 projekt am Raspberrypi 3 den diel hydrus 2.0 auszulesen und das json zu erhalten:
root:>rtl_433 -f 868.95M -F json | head

Code: Alles auswählen

{
  "time": "2026-01-30 07:23:52",
  "model": "Wireless-MBus",
  "mode": "T",
  "M": "DME",
  "id": 10105053,
  "version": 118,
  "type": 7,
  "type_string": "Water",
  "C": 68,
  "data_length": 63,
  "data": "3c44a5115350101076077aa7003005ade7e683204ab5b138ab57205b060b2c53ae60c937457330091f31461928764ba817c1a1a1b8d178d0fc5215fdbcfb3f4fc8",
  "mic": "CRC",
  "CI": 122,
  "AC": 167,
  "ST": 0,
  "CW": 1328,
  "payload_encrypted": 0
}

Ich brauch jetzt den zählerstand aus dem json. gehe ich der Annahme richtig, dass mit payload_encrypted: 0 das ganze unverschlüsselt ist ? wie extrahiere ich aus dem data Block die Daten?

ich habe mosquitto laufen am raspberrypi und auf der anderen Seite openhab wo ich diese MQTT daten auswerte in items.
Jemand eine Idee ?
danke,

Laut Herstellerinformation sind die Daten immer verschlüsselt, und zwar mit einem individuellen Code pro Zähler.

Es gibt einen umfangreichen Thread von der freundlichen Konkurrenz

https://forum.iobroker.net/topic/51163/ ... -von-diehl
Der AES-Key kann individuell gesetzt sein, muss aber wohl nicht, das müsstest Du mit Deinem Wasserversorger klären. Falls die Keys bei Euch individuell sind, müsstest Du lediglich den Key erhalten und könntest mit der entsprechenden Software die Daten entschlüsseln. am Einfachsten könnte man das z.B. als Python Script bauen, welches die Daten über mqtt empfangen und den Zählerstand anschließend ebenfalls über mqtt versenden könnte.
Falls der Key aber nicht individuell gesetzt ist, wirst Du auf Granit beißen, denn dann könntest Du mit dem Key alle Zähler auslesen...

Unterm Strich muss man sagen, vermutlich muss man die BundesNetzAgentur bitten, sich des Problems anzunehmen.
Es wird nur durch Zwang vom Gesetzgeber durchsetzbar sein, dass die Messstellenbetreiber die Daten raus rücken, so wie auch schon bei den Energieversorgern, da war das ja auch lange Zeit ein Thema.

Die Alternative wäre entweder der Abgriff des Zählerstands per Foto (Display schaltet bei Wechsel von dunkel nach hell automatisch ein, also könnte man das recht gut automatisieren) oder, falls Du das Glück hast, einen Zähler mit angeschlossenem Kabel zu haben könntest Du dort auch den Open-Drain Impulsausgang nutzen, das ist zwar nicht so fancy wie ein absoluter Zahlenwert, aber immer noch besser als gar nichts.

Wie die Datenkrake doch funktioniert... Hier ein Youtube Video exakt zu dem Zählertyp, der vor zwei Tagen hochgeladen wurde

https://www.youtube.com/watch?v=ritHxyx3vDk

ist mir gerade in die Timeline gespült worden...

Habe bereits eine Lösung!
Man kann den data Stream mit wmbusmeters auslesen, der ist nicht verschlüsselt!

Code: Alles auswählen

root@raspberrypi:~# wmbusmeters --analyze
3c44a5115350101076077aa7003005ade7e683204ab5b138ab57205b060b2c53ae60c937457330091f31461928764ba817c1a1a1b8d178d0fc5215fdbcfb3f4fc8

(wmbus) telegram length byte (the first) 0x3c (60) is probably wrong. Expected 0x40 (64) based on the length of the telegram.
(TPL) warning: aes-cbc-iv decryption received less bytes than expected for decryption! Got 16 bytes but expected at least 48 bytes since num encr blocks was 3.
Auto driver : hydrus
Similar driver : aventieswm 12/22
Using driver : hydrus 00/00
000 : 3c length (60 bytes)
001 : 44 dll-c (from meter SND_NR)
002 : a511 dll-mfct (DME)
004 : 53501010 dll-id (10105053)
008 : 76 dll-version
009 : 07 dll-type (Water meter)
010 : 7a tpl-ci-field (EN 13757-3 Application Layer (short tplh))
011 : a7 tpl-acc-field
012 : 00 tpl-sts-field (OK)(OK)
013 : 3005 tpl-cfg 0530 (AES_CBC_IV nb=3 cntn=0 ra=0 hc=0 )
015 : 2f2f decrypt check bytes (OK)
017 : 0C dif (8 digit BCD Instantaneous value)
018 : 14 vif (Volume 10⁻² m³)
019 C!: 66000000 ("total_m3":0.66)
023 : 0A dif (4 digit BCD Instantaneous value)
024 : 5A vif (Flow temperature 10⁻¹ °C)
025 C!: 0901 ("flow_temperature_c":10.9)
027 : 02 dif (16 Bit Integer/Binary Instantaneous value)
028 : FD vif (Second extension FD of VIF-codes)
029 : 74 vife (Reserved)
030 C!: 3513 ("remaining_battery_life_y":13.462289)
032 : 04 dif (32 Bit Integer/Binary Instantaneous value)
033 : FD vif (Second extension FD of VIF-codes)
034 : 17 vife (Error flags (binary))
035 C?: 00000000
039 : 84 dif (32 Bit Integer/Binary Instantaneous value)
040 : 04 dife (subunit=0 tariff=0 storagenr=8)
041 : 6D vif (Date and time type)
042 C?: 3B373F3C
046 : 8C dif (8 digit BCD Instantaneous value)
047 : 04 dife (subunit=0 tariff=0 storagenr=8)
048 : 14 vif (Volume 10⁻² m³)
049 C?: 20000000
053 : 2F skip
054 : 2F skip
055 : 2F skip
056 : 2F skip
057 : 2F skip
058 : 2F skip
059 : 2F skip
060 : 2F skip
061 : 2F skip
062 : 2F skip
063 C?: 4F unknown dif treating remaining data as mfct specific C8

{
"_":"telegram",
"media":"water",
"meter":"hydrus",
"name":"",
"id":"10105053",
"flow_temperature_c":10.9,
"remaining_battery_life_y":13.462289,
"total_m3":0.66,
"status":"OK",
"timestamp":"2026-01-30T16:22:35Z"
}
root@raspberrypi:~#

Und siehe da man erhält Zählerstand, Temperatur und Batterie Lebensdauer.
Da ich bereits RTL433 am Laufen habe (auf 433MHZ), unterbreche ich den Dienst 1x in der Stunde, greife mit Frequenz 868.95M ein Telgram vom Wasserzähler ab, das alle 8sec. daher kommt, hole mir JSON Nutzdaten mit wmbusmeters raus, und schicke die Daten an mein MQTT, sodass ich auf einem TOPIC in openhab dann alles abgreifen kann.

Laut Auskünften Diehl und der Wasserwerke sind ALLE Daten verschlüsselt.

Ah, dann ist in dem Programm wmbusmeters offensichtlich eine Passwortanalyse integriert, prima.

openhabforum.de

Wasserzähler Diehl hydrus 2.0

Wasserzähler Diehl hydrus 2.0

Re: Wasserzähler Diehl hydrus 2.0

Re: Wasserzähler Diehl hydrus 2.0

Re: Wasserzähler Diehl hydrus 2.0

Re: Wasserzähler Diehl hydrus 2.0