Test Adapter wireless-mbus v0.9.x

[lvogt]

@segapro
Was sagt denn

ls -l /dev/ttyUSB*

?

Die Benutzer und Gruppenzugehörigkeit bei den Symlinks ist ja keine verlässliche Aussage.

[SegaPro]

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

ls -l /dev/ttyUSB*

Hi @lvogt ,

Danke, dass Du mich unterstützt.

ls -l /dev/ttyUSB*
crw-rw---- 1 root dialout 188, 0 27. Mai 15:33 /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 1 30. Mai 11:30 /dev/ttyUSB1

Viele Grüße

[Thomas Braun]

@segapro

sudo -H -u iobroker groups

liefert? Der user muss in der Gruppe 'dialout' drin sein.

[SegaPro]

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

sudo -H -u iobroker groups

@lvogt

sudo -H -u iobroker groups
iobroker tty dialout

[lvogt]

@segapro
Tja...
Evtl mal noch Baudraten durchprobieren. Und sonst mal mit irgendwelcher IMST Software versuchen das Ding zu testen?

[ok1]

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

@ok1
Hi, ich habe gerade v0.8.2 auf npm veröffentlicht die den C Mode für den CUL unterstützen sollte.
Unabhängig davon ob es (hoffentlich) funktioniert oder nicht, wäre es schön wenn du mir ein Debug Log vom Start und evtl 1 oder 2 empfangenen Telegrammen zukommen lassen könntest.

vielen Dank für den schnellen Einbau des C-Modes !
Gerne das debug-Log vom Start:

wireless-mbus.1
2022-05-30 23:44:28.281	debug	connected set to true

wireless-mbus.1
2022-05-30 23:44:28.221	debug	connected set to true

wireless-mbus.1
2022-05-30 23:44:28.206	info	CUL: Receiver set to C-MODE and data reporting with RSSI

wireless-mbus.1
2022-05-30 23:44:28.204	debug	CUL: RX: 434d4f44450d0a

wireless-mbus.1
2022-05-30 23:44:28.194	debug	CUL: TX: 5832310d0a6272630d0a

wireless-mbus.1
2022-05-30 23:44:28.193	info	CUL: Version: V 1.67 CUL868

wireless-mbus.1
2022-05-30 23:44:28.190	debug	CUL: RX: 5620312e36372043554c3836380d0a

wireless-mbus.1
2022-05-30 23:44:28.173	debug	CUL: TX: 560d0a

wireless-mbus.1
2022-05-30 23:44:28.163	debug	Created device of type: CUL

wireless-mbus.1
2022-05-30 23:44:27.988	info	starting. Version 0.8.2 in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v12.18.4, js-controller: 4.0.23

wireless-mbus.1
2022-05-30 23:44:18.940	info	Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason

wireless-mbus.1
2022-05-30 23:44:18.936	info	terminating

wireless-mbus.1
2022-05-30 23:44:18.928	info	Got terminate signal TERMINATE_YOURSELF

wireless-mbus.1
2022-05-30 23:42:44.129	info	List of port: [{"path":"/dev/ttyAMA0"},{"path":"/dev/ttyS0"},{"path":"/dev/ttyACM0","manufacturer":"busware.de","pnpId":"usb-busware.de_CUL868-if00","vendorId":"03eb","productId":"204b"}]

wireless-mbus.1
2022-05-30 23:42:27.170	info	CUL: Receiver set to C-MODE and data reporting with RSSI

wireless-mbus.1
2022-05-30 23:42:27.110	info	CUL: Version: V 1.67 CUL868

wireless-mbus.1
2022-05-30 23:42:26.921	info	starting. Version 0.8.2 in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v12.18.4, js-controller: 4.0.23

und das erste Telegramm:

wireless-mbus.1
2022-05-30 23:48:43.943	debug	Value QDS-29435752.data.7-0-VIF_TIME_POINT_DATE_TIME: 2022-05-30 22:48

wireless-mbus.1
2022-05-30 23:48:43.921	debug	Value QDS-29435752.data.6-0-VIF_TIME_POINT_DATE: 2022-05-18

wireless-mbus.1
2022-05-30 23:48:43.897	debug	Value QDS-29435752.data.5-17-VIF_TIME_POINT_DATE: 2022-04-30

wireless-mbus.1
2022-05-30 23:48:43.873	debug	Value QDS-29435752.data.4-17-VIF_HCA: 0

wireless-mbus.1
2022-05-30 23:48:43.846	debug	Value QDS-29435752.data.3-1-VIF_TIME_POINT_DATE: 2021-12-31

wireless-mbus.1
2022-05-30 23:48:43.822	debug	Value QDS-29435752.data.2-1-VIF_HCA: 0

wireless-mbus.1
2022-05-30 23:48:43.802	debug	Value QDS-29435752.data.1-0-VIF_HCA: 5

wireless-mbus.1
2022-05-30 23:48:43.543	debug	Updating device: QDS-29435752

wireless-mbus.1
2022-05-30 23:48:43.076	debug	Creating device: QDS-29435752

wireless-mbus.1
2022-05-30 23:48:43.072	debug	VIF_TIME_POINT_DATE_TIME: Value raw 635311664 value calc 2022-05-30 22:48

wireless-mbus.1
2022-05-30 23:48:43.070	debug	DIB dataField 4

wireless-mbus.1
2022-05-30 23:48:43.068	debug	VIF_TIME_POINT_DATE: Value raw 9682 value calc 2022-05-18

wireless-mbus.1
2022-05-30 23:48:43.067	debug	DIB dataField 2

wireless-mbus.1
2022-05-30 23:48:43.066	debug	VIF_TIME_POINT_DATE: Value raw 9438 value calc 2022-04-30

wireless-mbus.1
2022-05-30 23:48:43.064	debug	DIB dataField 2

wireless-mbus.1
2022-05-30 23:48:43.063	debug	VIF_HCA: Value 0

wireless-mbus.1
2022-05-30 23:48:43.062	debug	DIB dataField 11

wireless-mbus.1
2022-05-30 23:48:43.059	debug	VIF_TIME_POINT_DATE: Value raw 11455 value calc 2021-12-31

wireless-mbus.1
2022-05-30 23:48:43.057	debug	DIB dataField 2

wireless-mbus.1
2022-05-30 23:48:43.054	debug	VIF_HCA: Value 0

wireless-mbus.1
2022-05-30 23:48:43.053	debug	DIB dataField 11

wireless-mbus.1
2022-05-30 23:48:43.051	debug	VIF_HCA: Value 5

wireless-mbus.1
2022-05-30 23:48:43.049	debug	DIB dataField 11

wireless-mbus.1
2022-05-30 23:48:43.038	debug	Short header

wireless-mbus.1
2022-05-30 23:48:43.027	debug	3144934452574329350830a97a641800200b6e0500004b6e00000042e03e6cbf2ccb086e000000c2086cde24326c1c3ed225046d3016de25803580

wireless-mbus.1
2022-05-30 23:48:43.019	debug	CUL: Message received: 3144934452574329350830a97a641800200b6e0500004b6e00000042e03e6cbf2ccb086e000000c2086cde24326c1c3ed225046d3016de258035803b

wireless-mbus.1
2022-05-30 23:48:43.014	debug	CUL: RX: 623331343439333434353235373433323933353038333041393741363431383030323030423645303530303030344236453030303030303432453033453643424632434342303836453030303030304332303836434445323433323643314333454432323530343644333031364445323538303335383033420d0a

die beiden wichtigsten Nutzdaten "aktueller Wert HKV"

2022-05-30 23:48:43.051	debug	VIF_HCA: Value 5

und Vorjahreswert

2022-05-30 23:48:43.054	debug	VIF_HCA: Value 0

werden korrekt erkannt.

Und das 2. Telegramm:

wireless-mbus.1
2022-05-30 23:56:05.325	debug	Value QDS-29435752.data.7-0-VIF_TIME_POINT_DATE_TIME: 2022-05-30 22:55

wireless-mbus.1
2022-05-30 23:56:05.287	debug	Value QDS-29435752.data.6-0-VIF_TIME_POINT_DATE: 2022-05-18

wireless-mbus.1
2022-05-30 23:56:05.238	debug	Value QDS-29435752.data.5-17-VIF_TIME_POINT_DATE: 2022-04-30

wireless-mbus.1
2022-05-30 23:56:05.199	debug	Value QDS-29435752.data.4-17-VIF_HCA: 0

wireless-mbus.1
2022-05-30 23:56:05.163	debug	Value QDS-29435752.data.3-1-VIF_TIME_POINT_DATE: 2021-12-31

wireless-mbus.1
2022-05-30 23:56:05.129	debug	Value QDS-29435752.data.2-1-VIF_HCA: 0

wireless-mbus.1
2022-05-30 23:56:05.092	debug	Value QDS-29435752.data.1-0-VIF_HCA: 5

wireless-mbus.1
2022-05-30 23:56:05.000	debug	Updating device: QDS-29435752

wireless-mbus.1
2022-05-30 23:56:04.998	debug	VIF_TIME_POINT_DATE_TIME: Value raw 635311671 value calc 2022-05-30 22:55

wireless-mbus.1
2022-05-30 23:56:04.997	debug	DIB dataField 4

wireless-mbus.1
2022-05-30 23:56:04.996	debug	VIF_TIME_POINT_DATE: Value raw 9682 value calc 2022-05-18

wireless-mbus.1
2022-05-30 23:56:04.995	debug	DIB dataField 2

wireless-mbus.1
2022-05-30 23:56:04.993	debug	VIF_TIME_POINT_DATE: Value raw 9438 value calc 2022-04-30

wireless-mbus.1
2022-05-30 23:56:04.992	debug	DIB dataField 2

wireless-mbus.1
2022-05-30 23:56:04.991	debug	VIF_HCA: Value 0

wireless-mbus.1
2022-05-30 23:56:04.990	debug	DIB dataField 11

wireless-mbus.1
2022-05-30 23:56:04.989	debug	VIF_TIME_POINT_DATE: Value raw 11455 value calc 2021-12-31

wireless-mbus.1
2022-05-30 23:56:04.987	debug	DIB dataField 2

wireless-mbus.1
2022-05-30 23:56:04.986	debug	VIF_HCA: Value 0

wireless-mbus.1
2022-05-30 23:56:04.985	debug	DIB dataField 11

wireless-mbus.1
2022-05-30 23:56:04.984	debug	VIF_HCA: Value 5

wireless-mbus.1
2022-05-30 23:56:04.982	debug	DIB dataField 11

wireless-mbus.1
2022-05-30 23:56:04.981	debug	Short header

wireless-mbus.1
2022-05-30 23:56:04.978	debug	3144934452574329350830a97a651800200b6e0500004b6e00000042fec66cbf2ccb086e000000c2086cde24326c1c3ed225046d3716de2521a580

wireless-mbus.1
2022-05-30 23:56:04.977	debug	CUL: Message received: 3144934452574329350830a97a651800200b6e0500004b6e00000042fec66cbf2ccb086e000000c2086cde24326c1c3ed225046d3716de2521a5803b

wireless-mbus.1
2022-05-30 23:56:04.975	debug	CUL: RX: 623331343439333434353235373433323933353038333041393741363531383030323030423645303530303030344236453030303030303432464543363643424632434342303836453030303030304332303836434445323433323643314333454432323530343644333731364445323532314135383033420d0a

Eine Besonderheit der Qundis HKV ist der Versand von Zwischen-Telegrammen mit Qundis-internen Daten.
Beim FHEM Adapter hat man das über ein zusätzliches Attribut "ignoreUnknownDataBlocks" gelöst. Ist das Attribut gesetzt werden die internen Telegramme verworfen und nicht in den Datenpunkt geschrieben. In diesem kurzen Test habe ich noch kein derartiges Telegramm gefangen, lasse den Adapter weiterlaufen und füge es hier umgehend an wenn eins vorliegt.

EDIT 31.05.
Erste interne Telegramme liegen vor. Nachfolgend ein Beispiel:

wireless-mbus.1
2022-05-31 16:29:41.748	debug	Value QDS-29435752.data.2-0-VIF_TIME_POINT_DATE_TIME: 2022-05-31 15:29

wireless-mbus.1
2022-05-31 16:29:41.711	debug	Value QDS-29435752.data.1-0-VIF_TYPE_MANUFACTURER_UNKOWN: /$^,?%Rn0j

wireless-mbus.1
2022-05-31 16:29:41.673	debug	Updating device: QDS-29435752

wireless-mbus.1
2022-05-31 16:29:41.672	debug	VIF_TIME_POINT_DATE_TIME: Value raw 635375389 value calc 2022-05-31 15:29

wireless-mbus.1
2022-05-31 16:29:41.672	debug	DIB dataField 4

wireless-mbus.1
2022-05-31 16:29:41.671	debug	VIF_TYPE_MANUFACTURER_UNKOWN: Value "/\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000$^\u0000\u0000\u0000\u0000,?\u0000\u0000\u0000\u0006%Rn0\u0007\u0000\u0000\u0000\u0018j\u0002\u0000"

wireless-mbus.1
2022-05-31 16:29:41.671	debug	DIB dataField 13

wireless-mbus.1
2022-05-31 16:29:41.670	debug	Unknown manufacturer specific vif: 0x5f

wireless-mbus.1
2022-05-31 16:29:41.669	debug	No header

wireless-mbus.1
2022-05-31 16:29:41.668	debug	494493445257432935085243780dff5f350082ea1800800007b06ed2bbe12506000000bf2c00000000de240000005eb7000080008000800080008000800080009b248000000000000000002f046d1d0fdf25620780

wireless-mbus.1
2022-05-31 16:29:41.667	debug	CUL: Message received: 494493445257432935085243780dff5f350082ea1800800007b06ed2bbe12506000000bf2c00000000de240000005eb7000080008000800080008000800080009b248000000000000000002f046d1d0fdf256207803a

wireless-mbus.1
2022-05-31 16:29:41.666	debug	CUL: RX: 62343934343933343435323537343332393335303835323433373830444646354633353030383245413138303038303030303742303645443242424531323530363030303030304246324330303030303030304445323430303030303035454237303030303830303038303030383030303830303038303030383030303830303039423234383030303030303030303030303030303030324630343644314430464446323536323037383033410d0a

In welche Datenpunkte werden die Werte vom Adapter eingetragen ?
Unter wireless-mbus.1 sind sie noch nicht vorhanden:

EDIT 31.05.
Die Datenpunkte sind jetzt auch da:

[ok1]

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

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

EDIT 31.05.
Die Datenpunkte sind jetzt auch da:

es gibt noch einen Fehler in der Datumsangabe. Monat ist ums "1" erhöht

[lvogt]

@ok1

Danke für die Logs.

Erstmal eine Warnung vorweg: Wenn ein Gerät unterschiedliche Telegramme sendet kann der Adapter damit nicht besonders gut umgehen. Bei dir sieht es so als wäre es (zur Zeit) ok.

Zu deinem interessanten Datum: Ich kann nicht nachvollziehen woher das kommt. Die passende Stelle im Code des Telegramm Parsers prüft explizit auf Monate > 12. Außerdem formatiert der Parser ein Datum eigentlich immer als YYYY-MM-DD - dein State zeigt YYYY.MM.DD (was ich sowieso schon für merkwürdig halte). Und zum Schluss: Im Log sieht man zb

2022-05-30 23:56:05.163	debug	Value QDS-29435752.data.3-1-VIF_TIME_POINT_DATE: 2021-12-31

Das wird mehr oder weniger direkt bevor der State gesetzt wird ins Log geschrieben - und hier ist es noch eine 12.

Da muss mMn irgendeine weitere Komponente seine Finger im Spiel haben. Sei es ioBroker oder Admin selbst, oder ein anderer Adapter oder Skript.

[ok1]

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

Da muss mMn irgendeine weitere Komponente seine Finger im Spiel haben. Sei es ioBroker oder Admin selbst, oder ein anderer Adapter oder Skript.

"Admin" war der richtige Hinweis ! Hier wird aus dem korrekten Wert "12" im Datenpunktbaum eine "13":

Aktuelle Admin-Version v5.3.8.

[gizmodlx]

Hi zusammen! Funzt der Adapter in Version 0.8.2 auch unter nodeJS 16 einwandfrei? Hat das jemand schon geprüft bzw. am laufen?

[lvogt]

@gizmodlx
Nicht dass ich es wirklich ausprobiert hätte, aber die Tests laufen mit node 12/14/16/18:

https://github.com/lvogt/ioBroker.wireless-mbus/actions/runs/2430796316

[gizmodlx]

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

@gizmodlx
Nicht dass ich es wirklich ausprobiert hätte, aber die Tests laufen mit node 12/14/16/18:

https://github.com/lvogt/ioBroker.wireless-mbus/actions/runs/2430796316

Alles klar. Dann werde ich es zumindest einmal versuchen und gebe dann hier Rückmeldung.

[gizmodlx]

Also der Adapter arbeitet auch mit nodeJS 16 problemlos.

@lvogt Was mir noch aufgefallen ist: Die Einstellung zu "blockierten" Zählern scheint nicht zu funktionieren. Ich habe es mit den Werten "Address" und "ID" versucht, aber die Daten anderer Zähler werden weiterhin angezeigt.

[hartwigm]

Hallo,

ich habe 2 NZR Wasserzähler Art. 8109 Mod Wireless M-Bus (OMS) verbaut.

Die Konfiguration dazu:

Im Protokoll erhalte ich keine Fehler .

Die Objekte:

Also keinerlei Daten von den Zähler. Auch nach 2 Std. tut sich da nichts!

Stelle ich den Mode um auf C Mode (frame type A)

bekomme ich Daten, allerdings vermutlich vom Nachbarhaus, Aber die Konfiguration ausser dem Mode dürfte damit eigentlich passen:

Somit wäre die Frage, WARUM bekomme ich keine Daten vom den eigenen Wasserzählern.

Ich habe alle Modis mal durchprobiert. Keine Fehler - nur keine Daten

Nur bei C kommen Daten, aber nie meine Daten.

Bei Mode S und T bekomme ich rawdata ohne einen Fehler im Protokoll.
Allerdings werden diese scheinbar nicht interpretiert bzw,. es wird kein Objekt angelegt

Der Inhalt von rawdata ist

49449344779650953508780dff5f3500821600007e0007b06effff07020000bf2c90040000de26070200000000020001002e002f0049007efe230019002700040000002f046d3a0ec627

Für jeden Tipp wie ich damit zu Zählerdaten komme wäre ich dankbar.

[lvogt]

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

@lvogt Was mir noch aufgefallen ist: Die Einstellung zu "blockierten" Zählern scheint nicht zu funktionieren. Ich habe es mit den Werten "Address" und "ID" versucht, aber die Daten anderer Zähler werden weiterhin angezeigt.

Du musst zum Blockieren die Kombination aus Hersteller und ID nach diesem Muster MAN-XXXXXXXX angeben. So wie auch der Übergeordnete Kanal im Objektbaum heißt.

(Evtl. könnte es aber sein dass du es mit einem Gerät mit "externen" Sender zu tun hast, dann müsstest du die Hersteller-iD Kombination dafür herausbekommen, was der Adapter im Moment leider quasi nicht herausgibt. Wenn das der Fall ist, könntest du mir ein "Rohdaten Telegramm" aus dem Log fischen, dann würde ich dir die ID heraussuchen. - Das müsste ich mal etwas verbessern - aber es wird ja auch scheinbar nicht gebraucht.)

Das ganze müsste auch mal dringend in die README

P.S. Bereits angelegte Daten im Objektbaum werden natürlich nicht gelöscht, können dann aber einfach händisch gelöscht werden.

---

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

Der Inhalt von rawdata ist

49449344779650953508780dff5f3500821600007e0007b06effff07020000bf2c90040000de26070200000000020001002e002f0049007efe230019002700040000002f046d3a0ec627

Das Telegramm gehört zu QDS-95509677, ist also vermutlich aus deinem "C-Mode Test".

Bei Mode S und T bekomme ich rawdata ohne einen Fehler im Protokoll.

Das bezweifle ich. Der rawdata State wird immer nur noch irgendwelchen Fehlern gesetzt.

ich habe 2 NZR Wasserzähler Art. 8109 Mod Wireless M-Bus (OMS) verbaut.

Bist du sicher dass die auch senden? Und was die senden? Ich habe gerade versucht ein Handbuch zu finden - aber NZR finde ich nur ein völlig unbrauchbares Datenblatt. Falls die neu sind, müssen die evtl. erst "scharf" geschaltet werden, damit die nicht in der Verpackung schon unnötig Batterielebenszeit "verfunken"...

[hartwigm]

@lvogt Vielen Dank für das Feedback

Ich haben zwischenzeitlich von NZR die folgende Info bekommen.
a.) das Ding sendet mit Auslieferung
b.)

Mir wurde nun ein optischer Lesekopf empfohlen um die Werte setzten zu können.
Wenn der Preis akzeptabel ist, werde ich mir das kaufen und dann mal schauen, ob ich da irgendwo den Fehler feststellen kann.

Meine Einstellung mit mode T war somit korrekt, allerdings hatte ich meist Abend nach dem Ding geschaut und ab 18 Uhr sendet das Ding ja nicht mehr.
Nachdem ich aber auch einen Tag später keine Objekte sehe, dürfte das Ding wie Du vermutest gar nicht senden.

[lvogt]

@hartwigm
Naja wenn die behaupten der sendet und er neu ist sollte man eigentlich nicht von dir den Lesekopf erwarten dürfen.

Evtl. mal näher am Sender testen? Oder mal den Stick mit offizieller Imst Software testen?
Ich kann natürlich nicht 100% ausschließlich dass es am Ende nicht doch am Adapter liegt...

[gizmodlx]

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

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

@lvogt Was mir noch aufgefallen ist: Die Einstellung zu "blockierten" Zählern scheint nicht zu funktionieren. Ich habe es mit den Werten "Address" und "ID" versucht, aber die Daten anderer Zähler werden weiterhin angezeigt.

Du musst zum Blockieren die Kombination aus Hersteller und ID nach diesem Muster MAN-XXXXXXXX angeben. So wie auch der Übergeordnete Kanal im Objektbaum heißt.

Danke für die Info. Hersteller und ID mit Bindestrich getrennt hat funktioniert.
Statt einer Readme würde da auch ein Einzeiler auf der Konfigurationsseite reichen

[rali2011]

Hallo zusammen,

ich habe es nun endlich hinbekommen Daten von meinem kamstrup multical 21 mit diesem Adapter zu empfangen

Allerdings bekomme ich die Fehlermeldung: "Unknown Kamstrup compact frame format".

Den AES Key hab ich vorher aus einer .kem Datei ausgelesen und im Adapter eingefügt. Mache ich etwas falsch oder muss ich mit einem anderen Programm die Datei weiterverarbeiten?

[lvogt]

@rali2011

In den Adapter Einstellung "Cache für Kompakt-Telegramme" aktivieren. Danach wird die Meldung trotzdem ein paar Mal kommen, weil der Adapter dann erst einmal (pro Adapter Neustart!) ein "nicht-kompakt" Telegramm empfangen muss. Danach werden auch die kompakten korrekt verarbeitet.