NEWS
Test Adapter wireless-mbus v0.10.x
-
@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.23und 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: 623331343439333434353235373433323933353038333041393741363431383030323030423645303530303030344236453030303030303432453033453643424632434342303836453030303030304332303836434445323433323643314333454432323530343644333031364445323538303335383033420d0adie beiden wichtigsten Nutzdaten "aktueller Wert HKV"
2022-05-30 23:48:43.051 debug VIF_HCA: Value 5und Vorjahreswert
2022-05-30 23:48:43.054 debug VIF_HCA: Value 0werden 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: 623331343439333434353235373433323933353038333041393741363531383030323030423645303530303030344236453030303030303432464543363643424632434342303836453030303030304332303836434445323433323643314333454432323530343644333731364445323532314135383033420d0aEine 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: 62343934343933343435323537343332393335303835323433373830444646354633353030383245413138303038303030303742303645443242424531323530363030303030304246324330303030303030304445323430303030303035454237303030303830303038303030383030303830303038303030383030303830303039423234383030303030303030303030303030303030324630343644314430464446323536323037383033410d0aIn 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 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
-
@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
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-31Das 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.
-
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-31Das 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.
@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
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
@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.
-
@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.
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.
-
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 angelegtDer Inhalt von rawdata ist
49449344779650953508780dff5f3500821600007e0007b06effff07020000bf2c90040000de26070200000000020001002e002f0049007efe230019002700040000002f046d3a0ec627
Für jeden Tipp wie ich damit zu Zählerdaten komme wäre ich dankbar.
-
@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-XXXXXXXXangeben. 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 :see_no_evil:
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"...
-
@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-XXXXXXXXangeben. 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 :see_no_evil:
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"...
@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 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.@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 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-XXXXXXXXangeben. 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 :see_no_evil:
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"...
@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-XXXXXXXXangeben. 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 :-) -
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?
-
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?
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.
-
Hallo, ich möchte mit meinem System umziehen und hab mir dazu einen neuen iobroker aufgesetzt. Leider bekomme ich den Adapter dort nicht installiert. Im Expertenmodus habe ich den github link zum installieren eingefügt. Was mache ich falsch?
$ iobroker url https://github.com/lvogt/ioBroker.wireless-mbus.git --host iobroker-kreuser
install lvogt/ioBroker.wireless-mbus#78f62f0c4704420cfebc9d689c721222af66c247
NPM version: 6.14.17
Installing lvogt/ioBroker.wireless-mbus#78f62f0c4704420cfebc9d689c721222af66c247... (System call)
- iobroker.wireless-mbus@0.8.2updated 1 package in 793.631s
48 packages are looking for funding run
npm fundfor detailsupload [2] wireless-mbus.admin /opt/iobroker/node_modules/iobroker.wireless-mbus/admin/index_m.html index_m.html text/html
upload [1] wireless-mbus.admin /opt/iobroker/node_modules/iobroker.wireless-mbus/admin/wireless-mbus.png wireless-mbus.png image/png
upload [0] wireless-mbus.admin /opt/iobroker/node_modules/iobroker.wireless-mbus/admin/words.js words.js application/javascript
Process exited with code 0
Danke für eure Antworten!
-
Hallo, ich möchte mit meinem System umziehen und hab mir dazu einen neuen iobroker aufgesetzt. Leider bekomme ich den Adapter dort nicht installiert. Im Expertenmodus habe ich den github link zum installieren eingefügt. Was mache ich falsch?
$ iobroker url https://github.com/lvogt/ioBroker.wireless-mbus.git --host iobroker-kreuser
install lvogt/ioBroker.wireless-mbus#78f62f0c4704420cfebc9d689c721222af66c247
NPM version: 6.14.17
Installing lvogt/ioBroker.wireless-mbus#78f62f0c4704420cfebc9d689c721222af66c247... (System call)
- iobroker.wireless-mbus@0.8.2updated 1 package in 793.631s
48 packages are looking for funding run
npm fundfor detailsupload [2] wireless-mbus.admin /opt/iobroker/node_modules/iobroker.wireless-mbus/admin/index_m.html index_m.html text/html
upload [1] wireless-mbus.admin /opt/iobroker/node_modules/iobroker.wireless-mbus/admin/wireless-mbus.png wireless-mbus.png image/png
upload [0] wireless-mbus.admin /opt/iobroker/node_modules/iobroker.wireless-mbus/admin/words.js words.js application/javascript
Process exited with code 0
Danke für eure Antworten!
@rali2011 sagte in Test Adapter wireless-mbus v0.7.x:
Process exited with code 0
0 = Adapter wurde installiert.
Und warum bitte die github-Version? Nimm halt das Beta-Repository dafür her und lass den github-Sumpf außen vor.
wireless-mbus github: 0.8.2 latest: 0.8.2 for 52 days stable: -.-.- -
Moin @lvogt
Ich musste meinen Server mal wieder neu starten und dann habe ich immer Anfangsschwierigkeiten, den CUL zum Leben zu erwecken. Adapter Version 0.8.2
Kann es sein, dass die Timeout Limits etwas knapp gefasst sind? Zwischen dem ersten TX und dem Tm Timeout liegt ja nicht einmal eine Sekunde:
wireless-mbus.0 2022-08-02 06:32:07.237 error Timeout waiting for response wireless-mbus.0 2022-08-02 06:32:07.237 error Error opening serial port /dev/ttyACM0 with baudrate 38400 wireless-mbus.0 2022-08-02 06:32:07.236 error CUL: Failed to init device: Timeout waiting for response wireless-mbus.0 2022-08-02 06:32:04.235 debug CUL: TX: 5832310d0a6272730d0a wireless-mbus.0 2022-08-02 06:32:04.234 error CUL: Error getting CUL version: Timeout waiting for response wireless-mbus.0 2022-08-02 06:32:01.280 debug connected set to false wireless-mbus.0 2022-08-02 06:32:01.230 debug CUL: TX: 560d0a wireless-mbus.0 2022-08-02 06:32:01.227 debug Created device of type: CUL wireless-mbus.0 2022-08-02 06:32:01.174 info starting. Version 0.8.2 (non-npm: lvogt/ioBroker.wireless-mbus#a5b274111e95f62d28b7179f7d0f29f2ea87b0b7) in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v14.19.3, js-controller: 4.0.23Ferner ist es ja nicht so, dass der CUL gar nicht antworten würde. Ich hab auch so etwas im Log:
wireless-mbus.0 2022-08-02 07:13:03.332 error Timeout waiting for response wireless-mbus.0 2022-08-02 07:13:03.332 error Error opening serial port /dev/ttyACM0 with baudrate 38400 wireless-mbus.0 2022-08-02 07:13:03.331 error CUL: Failed to init device: Timeout waiting for response wireless-mbus.0 2022-08-02 07:13:01.916 debug CUL: RX: 38433131334646464644453236343438303030303044463237323739323835353230303030303030303030303030303030303330303746303037443030373430 wireless-mbus.0 2022-08-02 07:13:00.329 debug CUL: TX: 5832310d0a6272730d0a wireless-mbus.0 2022-08-02 07:13:00.329 error CUL: Error getting CUL version: Timeout waiting for response wireless-mbus.0 2022-08-02 07:12:57.377 debug connected set to false wireless-mbus.0 2022-08-02 07:12:57.326 debug CUL: TX: 560d0a wireless-mbus.0 2022-08-02 07:12:57.324 debug Created device of type: CUL wireless-mbus.0 2022-08-02 07:12:57.291 info starting. Version 0.8.2 (non-npm: lvogt/ioBroker.wireless-mbus#a5b274111e95f62d28b7179f7d0f29f2ea87b0b7) in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v14.19.3, js-controller: 4.0.23Hast Du vielleicht einen Tipp?
Dank & Gruß
Daniel -
Moin @lvogt
Ich musste meinen Server mal wieder neu starten und dann habe ich immer Anfangsschwierigkeiten, den CUL zum Leben zu erwecken. Adapter Version 0.8.2
Kann es sein, dass die Timeout Limits etwas knapp gefasst sind? Zwischen dem ersten TX und dem Tm Timeout liegt ja nicht einmal eine Sekunde:
wireless-mbus.0 2022-08-02 06:32:07.237 error Timeout waiting for response wireless-mbus.0 2022-08-02 06:32:07.237 error Error opening serial port /dev/ttyACM0 with baudrate 38400 wireless-mbus.0 2022-08-02 06:32:07.236 error CUL: Failed to init device: Timeout waiting for response wireless-mbus.0 2022-08-02 06:32:04.235 debug CUL: TX: 5832310d0a6272730d0a wireless-mbus.0 2022-08-02 06:32:04.234 error CUL: Error getting CUL version: Timeout waiting for response wireless-mbus.0 2022-08-02 06:32:01.280 debug connected set to false wireless-mbus.0 2022-08-02 06:32:01.230 debug CUL: TX: 560d0a wireless-mbus.0 2022-08-02 06:32:01.227 debug Created device of type: CUL wireless-mbus.0 2022-08-02 06:32:01.174 info starting. Version 0.8.2 (non-npm: lvogt/ioBroker.wireless-mbus#a5b274111e95f62d28b7179f7d0f29f2ea87b0b7) in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v14.19.3, js-controller: 4.0.23Ferner ist es ja nicht so, dass der CUL gar nicht antworten würde. Ich hab auch so etwas im Log:
wireless-mbus.0 2022-08-02 07:13:03.332 error Timeout waiting for response wireless-mbus.0 2022-08-02 07:13:03.332 error Error opening serial port /dev/ttyACM0 with baudrate 38400 wireless-mbus.0 2022-08-02 07:13:03.331 error CUL: Failed to init device: Timeout waiting for response wireless-mbus.0 2022-08-02 07:13:01.916 debug CUL: RX: 38433131334646464644453236343438303030303044463237323739323835353230303030303030303030303030303030303330303746303037443030373430 wireless-mbus.0 2022-08-02 07:13:00.329 debug CUL: TX: 5832310d0a6272730d0a wireless-mbus.0 2022-08-02 07:13:00.329 error CUL: Error getting CUL version: Timeout waiting for response wireless-mbus.0 2022-08-02 07:12:57.377 debug connected set to false wireless-mbus.0 2022-08-02 07:12:57.326 debug CUL: TX: 560d0a wireless-mbus.0 2022-08-02 07:12:57.324 debug Created device of type: CUL wireless-mbus.0 2022-08-02 07:12:57.291 info starting. Version 0.8.2 (non-npm: lvogt/ioBroker.wireless-mbus#a5b274111e95f62d28b7179f7d0f29f2ea87b0b7) in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v14.19.3, js-controller: 4.0.23Hast Du vielleicht einen Tipp?
Dank & Gruß
DanielNoch ein Nachtrag (und vielleicht sogar die Lösung):
Ich war jetzt mal faul und hab den ganzen Tag mal eine "Brute Force" Lösung probiert: Adapter-Neustart alle 5 Minuten...
Und tatsächlich hat es nach gut 8 Stunden zum Erfolg geführt! Kommunikation mit dem CUL läuft (und ich vermute auch mal stabil, weil ich bisher immer nur Probleme beim ersten Start nach einem Booten hatte, danach nie wieder).
Daher vermute ich mal als naiver Nutzer: Kann es vielleicht wirklich ein Timing-Problem sein?
Danke fürs nachschauen sagt
Daniel -
Noch ein Nachtrag (und vielleicht sogar die Lösung):
Ich war jetzt mal faul und hab den ganzen Tag mal eine "Brute Force" Lösung probiert: Adapter-Neustart alle 5 Minuten...
Und tatsächlich hat es nach gut 8 Stunden zum Erfolg geführt! Kommunikation mit dem CUL läuft (und ich vermute auch mal stabil, weil ich bisher immer nur Probleme beim ersten Start nach einem Booten hatte, danach nie wieder).
Daher vermute ich mal als naiver Nutzer: Kann es vielleicht wirklich ein Timing-Problem sein?
Danke fürs nachschauen sagt
Daniel@ratte-rizzo
Der Timeout kommt nach 3 Sekunden. Du musst das Log chronologisch - also von unten nach oben - lesen.Die Antwort, die der Stick in deinem 2. Logauszug schickt, kann ich zu nichts zuordnen.
Ich denke nicht, dass ich da ohne Hardware viel machen kann. Und soweit ich das den Einträgen hier entnehmen kann ist es jetzt auch nicht der Normalfall, dass man 8h lang den Adapter neu starten muss...
Edit: Ich kenne mich mit dem CUL ja wirklich nicht gut aus, aber hast du die Möglichkeit zu beeinflussen in welchem Mode und mit welchen Einstellungen der per default startet, wenn er neu bootet? Evtl. hilft es ja da direkt "bessere" Einstellungen zu setzen?
-
@ratte-rizzo
Der Timeout kommt nach 3 Sekunden. Du musst das Log chronologisch - also von unten nach oben - lesen.Die Antwort, die der Stick in deinem 2. Logauszug schickt, kann ich zu nichts zuordnen.
Ich denke nicht, dass ich da ohne Hardware viel machen kann. Und soweit ich das den Einträgen hier entnehmen kann ist es jetzt auch nicht der Normalfall, dass man 8h lang den Adapter neu starten muss...
Edit: Ich kenne mich mit dem CUL ja wirklich nicht gut aus, aber hast du die Möglichkeit zu beeinflussen in welchem Mode und mit welchen Einstellungen der per default startet, wenn er neu bootet? Evtl. hilft es ja da direkt "bessere" Einstellungen zu setzen?
Moin @lvogt
Dass ich das Log von unten her lesen muss, ist klar. Meine Idee war halt, den Timeout von 3s etwas zu vergrößern. Vielleicht 5s oder 10s. Solltest Du den Adapter bei Gelegenheit nochmal anfassen, kannst Du ja mal dran denken. Eilt ja nicht.
Immerhin steht jetzt fest, dass dieser (für mich) nervige Linux Kram mit Rechten, Durchreichen zu VM und so korrekt ist. Die Baustelle ist weiter eingekreist. Vielleicht hilfts ja anderen CUL Nutzern.
Letzte Frage: Was für eine Hardware nutzt / empfiehlst Du denn? Weihnachten kommt ja bald und die CUL HW und SW ist ja auch nicht gerade brandneu.
Dank & Gruß
Daniel
Support us
286
Online32.4k
Benutzer81.4k
Themen1.3m
Beiträge