Test Adapter wireless-mbus v0.10.x

[sonnenschein]

@sonnenschein
Es gibt neues zu berichten.
Nach unendlichen Mailverkehr mit verschiedene Stellen habe ich am Ende einen super Support von Würth Elektronik bekommen.
Mein Amberstick war nicht zu überreden zu funktionieren bzw zu flashen. Ich habe heute einen neuen Metis-I USB stick erhalten. Den wireless mbus Adapter habe ist deinstalliert und den aktuellen in der Version 0.7.6 installiert.
Der Stick wurde als USB0 vom Raspberry Pi erkannt.
Im Adapter habe ich 9600 baud und C/T Mode eingetragen.
Nach dem Adapterstart dauerte es nicht lange und es wurde ein Telegramm empfangen.
Dann den AES Schlüssel eingetragen und beobachtet.
Und siehe da es wurden Daten in die Objekte geschrieben.
Im Protokoll bekomme ich jetzt noch einen Fehler.

2022-01-19 17:54:43.252 - debug: wireless-mbus.0 (2744) Found AES key: xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
2022-01-19 17:54:43.252 - debug: wireless-mbus.0 (2744) 4744372c238665233a168d203352003d20c910a5a60ced758c369c38d95ec73c0a72f0e45be8f864e6318d7630c16c1bf1f854b0e2a04f89bb1ff7eddf8ebd478ad66704b4e0d225
2022-01-19 17:54:43.253 - debug: wireless-mbus.0 (2744) Extended Link Layer
2022-01-19 17:54:43.253 - debug: wireless-mbus.0 (2744) crc 10c9, calculated d097
2022-01-19 17:54:43.253 - debug: wireless-mbus.0 (2744) IV: 372c238665233a162052003d20000000
2022-01-19 17:54:43.254 - debug: wireless-mbus.0 (2744) Added padding: 7
2022-01-19 17:54:43.254 - debug: wireless-mbus.0 (2744) Dec: 237b7804ff23000000004413343d0000523b790306ff1b056000056000426cc12161670d516711023b00000413d25600008101e7ff0f0f
2022-01-19 17:54:43.254 - debug: wireless-mbus.0 (2744) No header
2022-01-19 17:54:43.254 - error: wireless-mbus.0 (2744) WARNING: Unkown manufacturer specific vif: 0x23
2022-01-19 17:54:43.255 - debug: wireless-mbus.0 (2744) DIB dataField 4
2022-01-19 17:54:43.255 - debug: wireless-mbus.0 (2744) VIF_TYPE_MANUFACTURER_UNKOWN: Value 0
2022-01-19 17:54:43.255 - debug: wireless-mbus.0 (2744) DIB dataField 4
2022-01-19 17:54:43.256 - debug: wireless-mbus.0 (2744) VIF_VOLUME: Value raw 15668 value calc 15.668
2022-01-19 17:54:43.256 - debug: wireless-mbus.0 (2744) DIB dataField 2
2022-01-19 17:54:43.256 - debug: wireless-mbus.0 (2744) VIF_VOLUME_FLOW: Value raw 889 value calc 0.889
2022-01-19 17:54:43.256 - error: wireless-mbus.0 (2744) WARNING: Unkown manufacturer specific vif: 0x1b
2022-01-19 17:54:43.257 - debug: wireless-mbus.0 (2744) DIB dataField 6
2022-01-19 17:54:43.257 - debug: wireless-mbus.0 (2744) VIF_TYPE_MANUFACTURER_UNKOWN: Value 412400771077
2022-01-19 17:54:43.257 - debug: wireless-mbus.0 (2744) DIB dataField 2
2022-01-19 17:54:43.258 - debug: wireless-mbus.0 (2744) VIF_TIME_POINT_DATE: Value raw 8641 value calc 2022-01-01
2022-01-19 17:54:43.258 - debug: wireless-mbus.0 (2744) DIB dataField 1
2022-01-19 17:54:43.258 - debug: wireless-mbus.0 (2744) VIF_EXTERNAL_TEMP: Value raw 13 value calc 13
2022-01-19 17:54:43.258 - debug: wireless-mbus.0 (2744) DIB dataField 1
2022-01-19 17:54:43.259 - debug: wireless-mbus.0 (2744) VIF_EXTERNAL_TEMP: Value raw 17 value calc 17
2022-01-19 17:54:43.259 - debug: wireless-mbus.0 (2744) DIB dataField 2
2022-01-19 17:54:43.259 - debug: wireless-mbus.0 (2744) VIF_VOLUME_FLOW: Value raw 0 value calc 0
2022-01-19 17:54:43.259 - debug: wireless-mbus.0 (2744) DIB dataField 4
2022-01-19 17:54:43.260 - debug: wireless-mbus.0 (2744) VIF_VOLUME: Value raw 22226 value calc 22.226
2022-01-19 17:54:43.260 - error: wireless-mbus.0 (2744) WARNING: Unkown manufacturer specific vif: 0xf
2022-01-19 17:54:43.260 - debug: wireless-mbus.0 (2744) DIB dataField 1
2022-01-19 17:54:43.260 - debug: wireless-mbus.0 (2744) VIF_EXTERNAL_TEMP: Value raw 15 value calc 15
2022-01-19 17:54:43.261 - debug: wireless-mbus.0 (2744) Updating device: KAW-23658623
2022-01-19 17:54:43.282 - debug: wireless-mbus.0 (2744) Value KAW-23658623.data.1-0-VIF_TYPE_MANUFACTURER_UNKOWN: 0
2022-01-19 17:54:43.288 - debug: wireless-mbus.0 (2744) Value KAW-23658623.data.2-1-VIF_VOLUME: 15.668
2022-01-19 17:54:43.292 - debug: wireless-mbus.0 (2744) Value KAW-23658623.data.3-1-VIF_VOLUME_FLOW: 0.889
2022-01-19 17:54:43.298 - debug: wireless-mbus.0 (2744) Value KAW-23658623.data.4-0-VIF_TYPE_MANUFACTURER_UNKOWN: 412400771077
2022-01-19 17:54:43.303 - debug: wireless-mbus.0 (2744) Value KAW-23658623.data.5-1-VIF_TIME_POINT_DATE: 2022-01-01
2022-01-19 17:54:43.308 - debug: wireless-mbus.0 (2744) Value KAW-23658623.data.6-1-VIF_EXTERNAL_TEMP: 13
2022-01-19 17:54:43.312 - debug: wireless-mbus.0 (2744) Value KAW-23658623.data.7-1-VIF_EXTERNAL_TEMP: 17
2022-01-19 17:54:43.317 - debug: wireless-mbus.0 (2744) Value KAW-23658623.data.8-0-VIF_VOLUME_FLOW: 0
2022-01-19 17:54:43.322 - debug: wireless-mbus.0 (2744) Value KAW-23658623.data.9-0-VIF_VOLUME: 22.226
2022-01-19 17:54:43.326 - debug: wireless-mbus.0 (2744) Value KAW-23658623.data.10-2-VIF_EXTERNAL_TEMP: 15

...den AES Schlüssel rausgeixt.

Den nanoculstick hatte ich auch versucht um Laufen u bringen. Leider ohne Erfolg. Anscheinend ist auf dem Stick einer dieser Fake Chips. Und der WMBus ist evtl auch nicht lauffähig auf dem Stick.
Da ich jetzt einen funktionierenden Amberstick AMB8465-M habe werde, ich mich erst mal damit weiter beschäftigen.
In wie weit der Fehler mit dem Field 79 behindert weiß ich noch nicht. Evtl hat hier jemand eine Idee was das bedeutet und wie ich es evtl. beseitigen kann.

[ratte-rizzo]

Moin

Könnte man den Adapter bitte nochmal etwas optimieren, dass die Fehlermeldung "WARNING: Unkown manufacturer specific vif: 0x5f" nicht als Error kommen, sondern als Warning, wie es im Namen auch steht? Mein Log ist etwas überfüllt mit rot. Und ein anderes Log-Level als Error kann man meines Wissens nach nicht einstellen...

Dank & Gruß
Daniel

[MartyBr]

@sonnenschein
Ich habe eine Verständnisfrage zu dem AES Key. Ist der im Telegram aufgefundene AES Key dieser Key, der im Adapter unter AES-Key eingetragen werden muss? Oder wird, so habe ich es bisher verstanden, dort der vom "Provider" abgefragte Key eingegeben?

Ich habe am Dienstag einen neuen Wasserzähler HYDRUS 2.0 von Diehl bekommen. Dieser wird von dem Wasserwerk per W-MBUS von der Strasse aus ausgelesen. Scheinbar nutzen sie für die gesamte Stadt den gleichen Verschlüsselungs-Key. Die Chance, den Key zu bekommen, liegt damit fast bei Null.

[BananaJoe]

@martybr sagte in Test Adapter wireless-mbus v0.7.x:

Die Chance, den Key zu bekommen, liegt damit fast bei Null.
Willkommen im Club ...

Nach intensiven Mailverkehr mit dem Datenschutzbeauftragen der Wasserwerke kam das Argument das die Batterie im Zähler ja 12 Jahre hält, ich in der Zeit das Haus ja verkaufen könnte und dann unberechtigter weise weiter den Wasserstand auslesen könnte.

Ich nutze sonst das Auslesen per Kamera, der digitale hat aber ein sehr schlechtes LCD Display so das dies nicht mehr klappt.

Einfachste Lösung: Bau dir einen eigenen Zähler dahinter. Kannst ja sogar einen digitalen nehmen, der AES Key wird dann mitgeliefert.

[MartyBr]

@bananajoe
Ja, das ist schon echt frustrierend. Da sind wir nun in der digitalen Zeit angekommen und hat nun einen digitalen Zähler im Haus, der lange erwartet wurde, und kommen nicht mehr (digital) an die Daten.

Dann kann ich mir nun den dritten Zähler (neben Haus und Garten) einbauen lassen. Ich bin doch kein Wasserwerk

[sonnenschein]

@martybr sagte in Test Adapter wireless-mbus v0.7.x:

@sonnenschein
Ich habe eine Verständnisfrage zu dem AES Key. Ist der im Telegram aufgefundene AES Key dieser Key, der im Adapter unter AES-Key eingetragen werden muss? Oder wird, so habe ich es bisher verstanden, dort der vom "Provider" abgefragte Key eingegeben?

Ich habe am Dienstag einen neuen Wasserzähler HYDRUS 2.0 von Diehl bekommen. Dieser wird von dem Wasserwerk per W-MBUS von der Strasse aus ausgelesen. Scheinbar nutzen sie für die gesamte Stadt den gleichen Verschlüsselungs-Key. Die Chance, den Key zu bekommen, liegt damit fast bei Null.

bei mir steht da der AES Key aus dem Adapter drin
Den Key vom Versorger zu bekommen war bei mir vollkommen unproblematisch. Eine Unterschrift und der Key war per Mail geliefert.

[MartyBr]

@sonnenschein Das klingt gut, aber jeder Versorger hat hier seine eigene Policy.
Ich bin mal auf die Antwort gespannt......

[andibr]

@martybr said in Test Adapter wireless-mbus v0.7.x:

@bananajoe
Ja, das ist schon echt frustrierend. Da sind wir nun in der digitalen Zeit angekommen und hat nun einen digitalen Zähler im Haus, der lange erwartet wurde, und kommen nicht mehr (digital) an die Daten.

Genau das gleich habe ich bei meinem EVU erlebt. Nach 3 Monaten Diskussion habe ich vom CEO die Antwort erhalten: "Denn geben wir nicht AES geben wir nicht heraus, Sie könnten damit ja die Daten manipulieren". Soviel zum Thema "Smartmeter soll das Leben einfacher machen", für die welche Rechnungen stellen dürfen, wird es einfacher, für uns aber nur teurer weil der neue Zähler kostet sogar mehr in der Miete.

Ich habe mir für die Elektro nun einen Shelly dazwischen gehängt.

Vom Wasserwerk bekam ich den den Hinweis ich solle doch beim Wasserzählerhersteller anrufen und dort eine speziellen Herrn verlangen, danach bekamm ich den Code per Mail. (da ist auch jeder Zähler einzeln Codiert)

So habe ich bei mir nun halt 2 Systeme am laufen. Als Verbraucher muss man leider meistens das nehmen was "ab dem Wagen fällt", oder niemand merkt.

[MartyBr]

@andibr
Das ist interessant. Hast du auch den Diehl Hydrus? Kannst du mir den Ansprechpartner per PIN schicken?

[lvogt]

@ratte-rizzo

Hi ja, ich werde das in nächste Zeit mal nach anpassen. Ich glaube ich hatte das schon mal angekündigt, aber dann leider vergessen

@MartyBr

Vor einer Weile hat Diehl mal bei allen Zählern den selben Key verwendet. Wenn man passend sucht findet man dazu auch was. Ich möchte den nicht gerne hier posten, da er zB im FHEM Forum auf "Nachfrage" gelöscht wurde...
Aber mal ganz hypothetisch, wenn man jetzt zb Loxone statt ioBroker verwenden würde und man sich zB fragen würde "HowTo Diehl Hydrus mit loxone" dann hätte man vl. weniger Probleme den Key zu finden...

Ob der Key (immer noch) funktioniert weiß ich natürlich nicht. Ein Versuch wäre es aber wert...

[MartyBr]

@lvogt
Na, ich setze ja kein Loxone ein

Ich kann mich aber mal dazu informieren

[andibr]

@martybr said in Test Adapter wireless-mbus v0.7.x:

@andibr
Das ist interessant. Hast du auch den Diehl Hydrus? Kannst du mir den Ansprechpartner per PIN schicken?

Leider darf ich das nicht (habe ich meinem Wasserwerk mündlich versprochen), und zusätzlich wird dir der Ansprechpartner aus der Schweiz kaum was nützen.

[MartyBr]

@andibr
Beide Gründe sind verständlich.

[MartyBr]

@lvogt
Ich will mir nun den im871a USB Adapter besorgen. Kann ich den USB Adapter per ser2net dem ioBroker Adapter zuordnen? Oder benötigt der Adapter direkten Zugriff auf die USB-Schnittstelle mit dem im871a?

[lvogt]

@martybr

Damit habe ich keinerlei Erfahrung. Wenn du auf dem "ioBroker Sytem" da wieder mit socat oä. einen "regularen seriellen Port" draus machst geht das vermutlich. Sonst nicht. Oder umgekehrt: Der Adapter darf nichts von der Umsetzung (außer vl. minimaler Verzögerung) merken. Da kommt einfach die serialport Bibliothek zum Einsatz.

[MartyBr]

@lvogt
ich nehme erstmal meinen Raspi, an dem der IR-Lesekopf für den Stromzähler hängt. Da ist ein USB noch frei. Dann kann ich dort auch den WMBUS-Adapter installieren. Bisher laufen dort nur der Smartmeter und der BLE-Adapter. Da sollten genug Reserven sein.
Jetzt warte ich mal auf meinen IM871a USB-Stick.

[Michi_Pi]

Hallo @lvogt , ich habe deinen Adapter heute mal installiert. Ich habe einen NanoCul im Einsatz und habe gelesen dass du diesen hier auch einbinden möchtest.
Zurzeit verwende ich wmbusmeters, wo der auch ohne Probleme seinen Dienst verrichtet.

Nun ja, ich habe den Adapter installiert und konfiguriert. Beim Start kommt aber gleich ein Serialport fehler. Kannst du mir hier weiterhelfen?

wireless-mbus.0 2022-01-30 10:05:59.485	error	Serialport error: Port is not open
wireless-mbus.0 2022-01-30 10:05:59.482	error	Serialport error: Error Resource temporarily unavailable Cannot lock port
wireless-mbus.0 2022-01-30 10:05:59.338	info	starting. Version 0.7.6 in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v14.18.3, js-controller: 3.3.22

[lvogt]

@michi_pi

Da verwendet "jemand" anderes bereits den seriellen Port. Vl wmbusmeters...

[Michi_Pi]

@lvogt das wars. da hätte ich selbst auch drauf kommen können.

jetzt bekomm ich allerdings diese Meldungen, scheint als erkennt er das Gerät nicht, oder?

wireless-mbus.0 2022-01-30 21:40:51.820	debug	Parser failed to parse telegram from device DME-19790778
wireless-mbus.0 2022-01-30 21:40:51.818	error	Unsupported CI Field a1, remaining payload is 711500131b68a00580a599a1d57d3a
wireless-mbus.0 2022-01-30 21:40:51.810	debug	1944a5117807791948204635a1711500131b68a00580a599a1d57d3aaf9198
wireless-mbus.0 2022-01-30 21:40:39.999	debug	connected set to true
wireless-mbus.0 2022-01-30 21:40:39.993	debug	connected set to true
wireless-mbus.0 2022-01-30 21:40:39.983	debug	CUL: Receiver set to T-MODE and data reporting with RSSI
wireless-mbus.0 2022-01-30 21:40:39.947	debug	Created device of type: CUL (untested)
wireless-mbus.0 2022-01-30 21:40:39.826	info	starting. Version 0.7.6 in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v14.18.3, js-controller: 3.3.22

hab einen Diehl IZAR RC868

[lvogt]

@michi_pi

Jepp. Diehl hat wohl keinen Bock auf Standard und OMS. Vl versuche ich da im Laufe der Woche mal Unterstützung für einzubauen. Aber keine Garantie, dass ich die Zeit finde oder zu einem Ergebnis komme...
Vermutlich müsste ja wmbusmeters das Diehl Format kennen - es sei denn da werden nur einzelne Werte aus der Suppe gefischt... das würde ich nur ungern einbauen...