Test Adapter wireless-mbus v0.9.x

ratte-rizzo

Ich wusste gar nicht, dass ich der erste CUL-Testkandidat bin. Ich fühle mich geehrt und geb mein bestes. Und erst einmal tausend Dank überhaupt für Deine Arbeit!!!

Also vorweg: Der Adapter funktioniert ziemlich gut, er hat über Nacht auch schon fleißig Geräte gesammelt. Da ich in einem Mietshaus wohne, habe ich einen bunten Strauß an Geräten, die mir zum größten Teil nicht gehören, aber meine eigenen sind alle dabei.

Meine Adapter-Konfiguration ist ziemlich einfach:
Screenshot 2021-10-06 at 07-25-48 instances - himbeere.png

Über die undefinierten Geräte von oben mache ich mir wenig sorgen. Die hatte ich in der FHEM-Welt ebenfalls. Ich bekomme folgende Werte gelistet:
Wasserzähler:
Screenshot 2021-10-06 at 07-27-35 objects - himbeere.png

Heizungszähler
Screenshot 2021-10-06 at 07-28-18 objects - himbeere.png

Was mir fehlt, bei FHEM aber dabei war: Stromzähler und Rauchmelder (?) Zumindest irgendwas mit Luft. Aber vielleicht kommen die ja auch noch.

Nun zu den Logs. Ich weiß nicht, ob Dir genau dieser Schnippsel hilft. Sag einfach, wenn Du etwas anderes brauchst.

Ich habe den Verdacht, dass manchmal nach dem Start des Adapters es zu einem Timeout kommt und dann aber nicht weiter versucht wird, ein weiteres Mal zu starten. Aber da ich den Adapter erst seit 12 Stunden nutze, ist es vielleicht noch etwas früh, darüber zu spekulieren.

Dank & Gruß
Daniel

ratte-rizzo

Verflixt... Logs vergessen!

2021-10-05 18:30:04.938  - info: wireless-mbus.0 (20405) starting. Version 0.7.1 in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v12.21.0, js-controller: 3.3.18
2021-10-05 18:30:04.977  - debug: wireless-mbus.0 (20405) Created device of type: CUL (untested)
2021-10-05 18:30:04.987  - debug: wireless-mbus.0 (20405) CUL: Receiver set data reporting with RSSI
2021-10-05 18:30:05.034  - debug: wireless-mbus.0 (20405) connected set to true
2021-10-05 18:30:05.034  - debug: wireless-mbus.0 (20405) connected set to true
2021-10-05 18:30:07.993  - debug: wireless-mbus.0 (20405) CUL: Message response timeout
2021-10-05 18:30:43.152  - debug: wireless-mbus.0 (20405) sendTo "listReceiver" to system.adapter.admin.0 from system.adapter.wireless-mbus.0
2021-10-05 18:30:43.153  - debug: wireless-mbus.0 (20405) sendTo "needsKey" to system.adapter.admin.0 from system.adapter.wireless-mbus.0
2021-10-05 18:30:43.219  - info: wireless-mbus.0 (20405) List of port: [{"manufacturer":"busware.de","pnpId":"usb-busware.de_CUL868-if00","vendorId":"03eb","productId":"204b","path":"/dev/ttyACM0"},{"path":"/dev/ttyS0"},{"path":"/dev/ttyS1"},{"path":"/dev/ttyS2"},{"path":"/dev/ttyS3"}]
2021-10-05 18:30:43.220  - debug: wireless-mbus.0 (20405) sendTo "listUart" to system.adapter.admin.0 from system.adapter.wireless-mbus.0
2021-10-05 18:32:14.688  - debug: wireless-mbus.0 (20405) 443043313030343644323031314135324142304534383032
2021-10-05 18:32:14.688  - error: wireless-mbus.0 (20405) Frame type null is not implemented!
2021-10-05 18:32:19.804  - debug: wireless-mbus.0 (20405) 23446532390012893508546e7aeb0000008b046e05000082046cbe2995d301fd0c10046d2011a52ab0e480
2021-10-05 18:32:19.804  - error: wireless-mbus.0 (20405) Frame type null is not implemented!
2021-10-05 18:34:03.771  - info: host.himbeere stopInstance system.adapter.wireless-mbus.0 (force=false, process=true)
2021-10-05 18:34:03.777  - info: wireless-mbus.0 (20405) Got terminate signal TERMINATE_YOURSELF
2021-10-05 18:34:03.815  - info: host.himbeere stopInstance system.adapter.wireless-mbus.0 send kill signal
2021-10-05 18:34:03.779  - info: wireless-mbus.0 (20405) terminating
2021-10-05 18:34:03.779  - info: wireless-mbus.0 (20405) Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason
2021-10-05 18:34:04.362  - info: host.himbeere instance system.adapter.wireless-mbus.0 terminated with code 11 (ADAPTER_REQUESTED_TERMINATION)
2021-10-05 18:34:06.870  - info: host.himbeere instance system.adapter.wireless-mbus.0 started with pid 24588
2021-10-05 18:34:07.199  - debug: wireless-mbus.0 (24588) Redis Objects: Use Redis connection: 127.0.0.1:9001
2021-10-05 18:34:07.216  - debug: wireless-mbus.0 (24588) Objects client ready ... initialize now
2021-10-05 18:34:07.270  - debug: wireless-mbus.0 (24588) Objects create System PubSub Client
2021-10-05 18:34:07.271  - debug: wireless-mbus.0 (24588) Objects create User PubSub Client
2021-10-05 18:34:07.271  - debug: wireless-mbus.0 (24588) Objects client initialize lua scripts
2021-10-05 18:34:07.280  - debug: wireless-mbus.0 (24588) Objects connected to redis: 127.0.0.1:9001
2021-10-05 18:34:07.283  - debug: wireless-mbus.0 (24588) objectDB connected
2021-10-05 18:34:07.284  - debug: wireless-mbus.0 (24588) Redis States: Use Redis connection: 127.0.0.1:9000
2021-10-05 18:34:07.289  - debug: wireless-mbus.0 (24588) States create System PubSub Client
2021-10-05 18:34:07.289  - debug: wireless-mbus.0 (24588) States create User PubSub Client
2021-10-05 18:34:07.339  - debug: wireless-mbus.0 (24588) States connected to redis: 127.0.0.1:9000
2021-10-05 18:34:07.339  - debug: wireless-mbus.0 (24588) statesDB connected
2021-10-05 18:34:07.505  - info: wireless-mbus.0 (24588) starting. Version 0.7.1 in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v12.21.0, js-controller: 3.3.18
2021-10-05 18:34:07.535  - debug: wireless-mbus.0 (24588) Created device of type: CUL (untested)
2021-10-05 18:34:07.541  - debug: wireless-mbus.0 (24588) CUL: Receiver set data reporting with RSSI
2021-10-05 18:34:07.579  - debug: wireless-mbus.0 (24588) connected set to true
2021-10-05 18:34:07.623  - debug: wireless-mbus.0 (24588) connected set to true
2021-10-05 18:34:10.542  - debug: wireless-mbus.0 (24588) CUL: Message response timeout
2021-10-05 18:44:07.410  - debug: wireless-mbus.0 (24588) 38464332454243324238384446393035353130303943443637383842323931353536443334313941453331373544323838464644423445354432363236424446413142344646343635304242343834434643363944463035303034364432433131413532413542383830433738333030363439333543393045383030
2021-10-05 18:44:07.411  - error: wireless-mbus.0 (24588) Frame type null is not implemented!
2021-10-05 18:57:02.517  - debug: wireless-mbus.0 (24588) 3246463337314236433431413141333534423830303331424633354142344143453632453832313331413942393531304641394543443930463433413334453962344634343635423230313932333432353333303733463546373830444646354633353030383233383830333536383741443443423237374444383336424536623446343436354232303532393334323533333037414535303738304446463546333530303832344338303335443732434539364232433334393043464633346234463434363542323031393233343235333330373346354637383044464635463335303038323338383033354545334242453839314334443334354446344432343839313442464242384544464546453843463439443239373944444636314244353838364439373343333032453939394430433937313941413544333734393036414237393543413234443444433441433243393030343034364433393131413532413230393830433738333030363439333543393045383030370a0a3f202832343839313442464242384544464546393036414237393543413234443444435620697320756e6b6e6f776e2920557365206f6e65206f66204120422062204320652046204720682069204b206b204c206c204d206d204e205220542074205520752056205720582078205920
2021-10-05 18:57:02.521  - error: wireless-mbus.0 (24588) Frame type null is not implemented!
2021-10-05 18:59:03.642  - debug: wireless-mbus.0 (24588) 4f4465b20192342533073f5f780dff5f350082388035f23fa3547dfa4cc943120a2caa906818c98e1b348863115eefe40d34fc5abb6250fbfb70191b8e4a0e5e829a4871d0f51afc9390b8d4046d3b11a52ade7e0c7830064935c90e80
2021-10-05 18:59:03.645  - error: wireless-mbus.0 (24588) Frame type null is not implemented!
2021-10-05 18:59:08.523  - debug: wireless-mbus.0 (24588) 3f20283f20697320756e6b6e6f776e2920557365206f6e65206f66204120422062204320652046204720682069204b206b204c206c204d206d204e205220542074205520752056205720582078205920
2021-10-05 18:59:08.523  - error: wireless-mbus.0 (24588) Frame type null is not implemented!
2021-10-05 18:59:21.649  - debug: wireless-mbus.0 (24588) 3f20283f20697320756e6b6e6f776e2920557365206f6e65206f66204120422062204320652046204720682069204b206b204c206c204d206d204e205220542074205520752056205720582078205920
2021-10-05 18:59:21.649  - error: wireless-mbus.0 (24588) Frame type null is not implemented!
2021-10-05 18:59:31.775  - debug: wireless-mbus.0 (24588) 3f20283f20697320756e6b6e6f776e2920557365206f6e65206f66204120422062204320652046204720682069204b206b204c206c204d206d204e205220542074205520752056205720582078205920
2021-10-05 18:59:31.776  - error: wireless-mbus.0 (24588) Frame type null is not implemented!
2021-10-05 19:20:01.541  - debug: wireless-mbus.0 (24588) sendTo "listReceiver" to system.adapter.admin.0 from system.adapter.wireless-mbus.0
2021-10-05 19:20:01.548  - debug: wireless-mbus.0 (24588) sendTo "needsKey" to system.adapter.admin.0 from system.adapter.wireless-mbus.0
2021-10-05 19:20:01.692  - info: wireless-mbus.0 (24588) List of port: [{"manufacturer":"busware.de","pnpId":"usb-busware.de_CUL868-if00","vendorId":"03eb","productId":"204b","path":"/dev/ttyACM0"},{"path":"/dev/ttyS0"},{"path":"/dev/ttyS1"},{"path":"/dev/ttyS2"},{"path":"/dev/ttyS3"}]
2021-10-05 19:20:01.692  - debug: wireless-mbus.0 (24588) sendTo "listUart" to system.adapter.admin.0 from system.adapter.wireless-mbus.0
2021-10-05 19:24:49.567  - debug: wireless-mbus.0 (24588) 4f4465b20192342533073f5f780dff5f350082388035188832437978a38e9a8b4f4465b20192342533073f5f780dff5f350082388035b1f7fb406a65829f675d0c10046d0412a52a9b8482

lvogt

@ratte-rizzo
Es gab schon mal an paar wenige andere Tester, aber da ich den CUL Support ohne eigene Hardware ausprobiert habe, gestaltet es sich etwas schwierig (und ich habe auch sehr lange nichts am Adapter gemacht...)

Um ehrlich zu sein, bin ich überrascht, dass bei den Logausgaben überhaupt Geräte angelegt werden... Ich muss mir das nochmal in Ruhe angucken, könnte evtl. aber bis zum Wochenende dauern.

Ich hätte noch eine Frage: Du willst wirklich den S-Mode (und nicht den T-Mode)?

Und könntest du mal gucken ob du im Log eine Stelle findest wo korrekt ein Telegram verarbeitet wurde. Da müsste dann so eine Zeile ala Updating device: XXX-12345678 auftauchen. Einen Logausschnitt ab ca .5 Sekunden früher bis eine Sekunde später wäre nicht schlecht (nur Ausgaben von wireless-mbus reichen natürlich).

ratte-rizzo

@lvogt
Also ich bin bisher sehr zufrieden mit dem Adapter. Alles, was in meiner Wohnung verbaut ist, wird korrekt angezeigt. Ich habe zur Zeit aber nur Heizungsmessgeräte. Wobei angeblich die Rauchmelder auch funken, aber die hab ich in FHEM auch nicht gesehen. Aber die funken auch seltener, laut Broschüre.

Und ja, der S-Mode ist der richtige (ich habe ehrlich gesagt den T-Mode gar nicht probiert, weil der S-Mode schon das ausspuckt, was ich suchte). Mein Einstiegspunkt war das FHEM Forum mit diesem Beitrag, wo meine Heizungszähler auch mit S-Mode ausgelesen wurden. Ich hab da halt nach der Marke geschaut.
https://forum.fhem.de/index.php/topic,24517.msg990047.html#msg990047

Ich habe Dir mal das Log von 3 Geräteupdates mitgeschickt. Die waren zufälligerweise alle 3 direkt hintereinander. Und die waren auch erfolgreich mit Updating device.

Egal wie lang es dauert: Dankeschön!

2021-10-06 14:56:17.468 - debug: wireless-mbus.0 (18920) 23446532899611893508a6027af00000008b046e00000082046cbe29531001fd0c10046d380da62acd7c80
2021-10-06 14:56:17.469 - debug: wireless-mbus.0 (18920) Short header
2021-10-06 14:56:17.469 - debug: wireless-mbus.0 (18920) VIF_HCA: Value 0
2021-10-06 14:56:17.469 - debug: wireless-mbus.0 (18920) VIF_TIME_POINT_DATE: Value raw 10686 value calc 2021-09-30
2021-10-06 14:56:17.469 - debug: wireless-mbus.0 (18920) VIF_MODEL_VERSION: Value 16
2021-10-06 14:56:17.469 - debug: wireless-mbus.0 (18920) VIF_TIME_POINT_DATE_TIME: Value raw 715525432 value calc 2021-10-06 13:56
2021-10-06 14:56:17.469 - debug: wireless-mbus.0 (18920) Updating device: LSE-89119689
2021-10-06 14:56:17.474 - debug: wireless-mbus.0 (18920) Value LSE-89119689.data.1-8-VIF_HCA: 0
2021-10-06 14:56:17.475 - warn: wireless-mbus.0 (18920) State "wireless-mbus.0.LSE-89119689.data.1-8-VIF_HCA" has no existing object, this might lead to an error in future versions
2021-10-06 14:56:17.519 - debug: wireless-mbus.0 (18920) Value LSE-89119689.data.2-8-VIF_TIME_POINT_DATE: 2021-09-30
2021-10-06 14:56:17.520 - warn: wireless-mbus.0 (18920) State "wireless-mbus.0.LSE-89119689.data.2-8-VIF_TIME_POINT_DATE" has no existing object, this might lead to an error in future versions
2021-10-06 14:56:17.563 - debug: wireless-mbus.0 (18920) Value LSE-89119689.data.3-0-VIF_MODEL_VERSION: 16
2021-10-06 14:56:17.564 - warn: wireless-mbus.0 (18920) State "wireless-mbus.0.LSE-89119689.data.3-0-VIF_MODEL_VERSION" has no existing object, this might lead to an error in future versions
2021-10-06 14:56:17.607 - debug: wireless-mbus.0 (18920) Value LSE-89119689.data.4-0-VIF_TIME_POINT_DATE_TIME: 2021-10-06 13:56
2021-10-06 14:56:17.608 - warn: wireless-mbus.0 (18920) State "wireless-mbus.0.LSE-89119689.data.4-0-VIF_TIME_POINT_DATE_TIME" has no existing object, this might lead to an error in future versions
2021-10-06 14:56:21.443 - debug: wireless-mbus.0 (18920) 234465329288118935085d537af00000008b046e12000082046cbe297c9001fd0c10046d390da62af64c80
2021-10-06 14:56:21.444 - debug: wireless-mbus.0 (18920) Short header
2021-10-06 14:56:21.444 - debug: wireless-mbus.0 (18920) VIF_HCA: Value 12
2021-10-06 14:56:21.444 - debug: wireless-mbus.0 (18920) VIF_TIME_POINT_DATE: Value raw 10686 value calc 2021-09-30
2021-10-06 14:56:21.444 - debug: wireless-mbus.0 (18920) VIF_MODEL_VERSION: Value 16
2021-10-06 14:56:21.444 - debug: wireless-mbus.0 (18920) VIF_TIME_POINT_DATE_TIME: Value raw 715525433 value calc 2021-10-06 13:57
2021-10-06 14:56:21.444 - debug: wireless-mbus.0 (18920) Updating device: LSE-89118892
2021-10-06 14:56:21.462 - debug: wireless-mbus.0 (18920) Value LSE-89118892.data.1-8-VIF_HCA: 12
2021-10-06 14:56:21.463 - warn: wireless-mbus.0 (18920) State "wireless-mbus.0.LSE-89118892.data.1-8-VIF_HCA" has no existing object, this might lead to an error in future versions
2021-10-06 14:56:21.507 - debug: wireless-mbus.0 (18920) Value LSE-89118892.data.2-8-VIF_TIME_POINT_DATE: 2021-09-30
2021-10-06 14:56:21.507 - warn: wireless-mbus.0 (18920) State "wireless-mbus.0.LSE-89118892.data.2-8-VIF_TIME_POINT_DATE" has no existing object, this might lead to an error in future versions
2021-10-06 14:56:21.551 - debug: wireless-mbus.0 (18920) Value LSE-89118892.data.3-0-VIF_MODEL_VERSION: 16
2021-10-06 14:56:21.551 - warn: wireless-mbus.0 (18920) State "wireless-mbus.0.LSE-89118892.data.3-0-VIF_MODEL_VERSION" has no existing object, this might lead to an error in future versions
2021-10-06 14:56:21.595 - debug: wireless-mbus.0 (18920) Value LSE-89118892.data.4-0-VIF_TIME_POINT_DATE_TIME: 2021-10-06 13:57
2021-10-06 14:56:21.596 - warn: wireless-mbus.0 (18920) State "wireless-mbus.0.LSE-89118892.data.4-0-VIF_TIME_POINT_DATE_TIME" has no existing object, this might lead to an error in future versions
2021-10-06 14:56:50.318 - debug: wireless-mbus.0 (18920) 234465320389118935086ea97af00000008b046e02000082046cbe29759d01fd0c10046d390da62af64c80
2021-10-06 14:56:50.318 - debug: wireless-mbus.0 (18920) Short header
2021-10-06 14:56:50.319 - debug: wireless-mbus.0 (18920) VIF_HCA: Value 2
2021-10-06 14:56:50.319 - debug: wireless-mbus.0 (18920) VIF_TIME_POINT_DATE: Value raw 10686 value calc 2021-09-30
2021-10-06 14:56:50.319 - debug: wireless-mbus.0 (18920) VIF_MODEL_VERSION: Value 16
2021-10-06 14:56:50.319 - debug: wireless-mbus.0 (18920) VIF_TIME_POINT_DATE_TIME: Value raw 715525433 value calc 2021-10-06 13:57
2021-10-06 14:56:50.319 - debug: wireless-mbus.0 (18920) Updating device: LSE-89118903
2021-10-06 14:56:50.324 - debug: wireless-mbus.0 (18920) Value LSE-89118903.data.1-8-VIF_HCA: 2
2021-10-06 14:56:50.325 - warn: wireless-mbus.0 (18920) State "wireless-mbus.0.LSE-89118903.data.1-8-VIF_HCA" has no existing object, this might lead to an error in future versions
2021-10-06 14:56:50.367 - debug: wireless-mbus.0 (18920) Value LSE-89118903.data.2-8-VIF_TIME_POINT_DATE: 2021-09-30
2021-10-06 14:56:50.368 - warn: wireless-mbus.0 (18920) State "wireless-mbus.0.LSE-89118903.data.2-8-VIF_TIME_POINT_DATE" has no existing object, this might lead to an error in future versions
2021-10-06 14:56:50.411 - debug: wireless-mbus.0 (18920) Value LSE-89118903.data.3-0-VIF_MODEL_VERSION: 16
2021-10-06 14:56:50.412 - warn: wireless-mbus.0 (18920) State "wireless-mbus.0.LSE-89118903.data.3-0-VIF_MODEL_VERSION" has no existing object, this might lead to an error in future versions
2021-10-06 14:56:50.455 - debug: wireless-mbus.0 (18920) Value LSE-89118903.data.4-0-VIF_TIME_POINT_DATE_TIME: 2021-10-06 13:57
2021-10-06 14:56:50.456 - warn: wireless-mbus.0 (18920) State "wireless-mbus.0.LSE-89118903.data.4-0-VIF_TIME_POINT_DATE_TIME" has no existing object, this might lead to an error in future versions

lvogt

@ratte-rizzo
Hm ich verstehe immer noch nicht wie das ganze zusammenhängt. Ich habe aber mal noch ein paar Kleinigkeiten angepasst (und hoffentlich verbessert ).

Das ist jetzt als v0.7.3 auf github und npm zu finden. Mit der Version nehme ich dann nochmal gerne einen Logauszug vom Start des Adapters.

Noch was (vermutlich) anderes:
In deinen letzten Log gab es Meldunge dieses Typs:

2021-10-06 14:56:21.507 - warn: wireless-mbus.0 (18920) State "wireless-mbus.0.LSE-89118892.data.2-8-VIF_TIME_POINT_DATE" has no existing object, this might lead to an error in future versions

Das spricht auch dafür dass zwischendurch mal irgendwas schief gelaufen ist. Wenn die auch nach einen Adapter Neustart weiterhin auftauchen - und auch nach Löschen der Geräte im Objektbaum (falls das für dich in Frage kommt und nicht irgendwelche Skript oä. zerlegt) weiterhin auftaucht, muss ich da auch nochmal nach gucken.

P.S. Die ganzen "Nachbarschaftsgeräte" kannst du in der Konfiguration ja auch blockieren, wenn du sie nicht "haben" willst.

ratte-rizzo

Moin @lvogt

Irgendwie war das WE voller als gedacht, daher komme ich erst Heute zum Aktualisieren des Adapters. Vielen Dank dafür! Update verlief problemlos. Beim Starten gabs allerdings einen kleinen Fehler im Debug (drittletzte Zeile):

2021-10-11 07:50:49.338 - info: host.himbeere "system.adapter.wireless-mbus.0" enabled
2021-10-11 07:50:49.396 - info: host.himbeere instance system.adapter.wireless-mbus.0 started with pid 28005
2021-10-11 07:50:49.745 - debug: wireless-mbus.0 (28005) Redis Objects: Use Redis connection: 127.0.0.1:9001
2021-10-11 07:50:49.763 - debug: wireless-mbus.0 (28005) Objects client ready ... initialize now
2021-10-11 07:50:49.764 - debug: wireless-mbus.0 (28005) Objects create System PubSub Client
2021-10-11 07:50:49.767 - debug: wireless-mbus.0 (28005) Objects create User PubSub Client
2021-10-11 07:50:49.768 - debug: wireless-mbus.0 (28005) Objects client initialize lua scripts
2021-10-11 07:50:49.778 - debug: wireless-mbus.0 (28005) Objects connected to redis: 127.0.0.1:9001
2021-10-11 07:50:49.781 - debug: wireless-mbus.0 (28005) objectDB connected
2021-10-11 07:50:49.781 - debug: wireless-mbus.0 (28005) Redis States: Use Redis connection: 127.0.0.1:9000
2021-10-11 07:50:49.787 - debug: wireless-mbus.0 (28005) States create System PubSub Client
2021-10-11 07:50:49.787 - debug: wireless-mbus.0 (28005) States create User PubSub Client
2021-10-11 07:50:49.835 - debug: wireless-mbus.0 (28005) States connected to redis: 127.0.0.1:9000
2021-10-11 07:50:49.835 - debug: wireless-mbus.0 (28005) statesDB connected
2021-10-11 07:50:50.031 - info: wireless-mbus.0 (28005) starting. Version 0.7.3 in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v12.21.0, js-controller: 3.3.18
2021-10-11 07:50:50.063 - debug: wireless-mbus.0 (28005) Created device of type: CUL (untested)
2021-10-11 07:50:50.074 - debug: wireless-mbus.0 (28005) CUL: Error setting wMBus mode: response was 69BAACC8C788C9A322DFA9BB3046D2E06AB2A6C380C7830064935C90E8002
bSMODE
2021-10-11 07:50:50.108 - debug: wireless-mbus.0 (28005) connected set to true
2021-10-11 07:50:50.151 - debug: wireless-mbus.0 (28005) connected set to true

Ferner habe ich alle "fremden" Geräte gelöscht. Wenn sie im Laufe des Tages neu angelegt werden, schaue ich mal, ob es noch zu den Fehlermeldungen kommt. Danach werde ich sie dann auf die Blacklist setzen (Danke für den Tipp!!!).

Bis später
Daniel

Thomas Braun

@ratte-rizzo

node: v12.21.0

Halt das aktuell.

andibr

@lvogt Hallo zusammen
Soeben habe ich meinen heute erhaltenen Stick am Raspberry Pi 3+ eingesteckt und den Adapter auf 0.7.3 aktualisiert. Mein Raspberry ist ein Slave in einem Multihost und sollte eigentlich die Schnittstellen bedienen. Aus irgendwelchen Gründen hat der Adapter alle Einstellungen direkt gefunden und auch bereit etliche Zähler gefunden. Aber nach einem erneuten öffnen der Adaptereinstellungen ist alles wieder leer und ich kann keine Auswahl mehr machen.

Es ist scheint irgendwie, wie wenn der Adapter eingefroren ist. Das einzige was man noch auswählen kann, ist die Baudrate. Was mache ich falsch?

Edit: ich denke ich habe da was gefunden, mein Raspberry kann nicht IM817 und 1Wire Stick zusammen. Soweit ich bis jetzt gesehen habe gibt es da ein Konflikt mit dem ttyUSB0.

lvogt

@andibr

Dein "original" Post ist ja so, dass ich im Grunde gar keine Aussage treffen kann. Ein Log(auszug) oder sonst irgendwas wäre schon nötig. Durch deinen Post alleine hätte ich auch darauf getippt dass auf "Systemebene" irgendwas mit den Serialports hängt.

Deine Ergänzung legt das nahe. Ich denke aber nicht dass nicht beide zusammen können, sondern du merkst gerade wie viele andere vor dir, dass die Nummerierung der /dev/ttyUSBn Devices nach einen Reboot sich ändern kann (ohne dass einer der USB Geräte aus- und wieder eingesteckt wurde).
Ich würde dir daher empfehlen, in der Liste der Ports "Benutzerdefinierte Schnittstelle" auszuwählen und dann händisch einen Pfad anzugeben, der sich nicht ändert. Z.b was passendes unter /dev/serial/by-id/... oder einen Symlink der explizit für den wMBus Stick angelegt wird. Der 1-Wire Stick müsste dann natürlich auch entsprechend angesprochen werden...

@ratte-rizzo
Genau. Der für mich spannende Teil ist die Fehlermeldung. Allerdings werde ich nur bedingt schlau daraus.
Das ist ja die Antwort die der CUL schickt: 69BAACC8C788C9A322DFA9BB3046D2E06AB2A6C380C7830064935C90E8002 und bSMODE.
Erwartet hätte ich eigentlich nur SMODE. Wenn ich den Parser noch etwas verbessere, könnte ich den ersten Teil einfach verwerfen, aber das b vor SMODE verwundert mich schon etwas. Woher ist die Firmware die auf deinem CUL läuft?
Im Zweifelsfall muss ich doch mal versuchen mich durch den culfw Code zu lesen...

ratte-rizzo

Moin @lvogt

So, 24 Stunden später. Ich habe gestern ja alle "fremden" Objekte gelöscht. Ich stelle Heute Morgen jedoch fest, dass keine neuen (alten) Objekte angelegt wurden. Ich habe nichts in die Blacklist gesetzt. Soll das so? Meine Geräte werden nach wie vor brav aktualisiert.

[Edit] Mittlerweile sind doch alle möglichen anderen Geräte da. Falscher Alarm!

Zu den Logs. Beim Datum ärgert er sich immer noch etwas. Da gibts noch eine Fehlermeldung. Das ist bei glaub ich (fast) allen Geräten sehr ähnlich.

2021-10-11 06:54:52.257 - debug: wireless-mbus.0 (18920) 2644653204891189350885047a0c0000000b6e0000004b6e000000428c576cbe26326cffff046d3705ab2aae1280
2021-10-11 06:54:52.257 - debug: wireless-mbus.0 (18920) Short header
2021-10-11 06:54:52.257 - debug: wireless-mbus.0 (18920) VIF_HCA: Value 0
2021-10-11 06:54:52.257 - debug: wireless-mbus.0 (18920) VIF_HCA: Value 0
2021-10-11 06:54:52.257 - debug: wireless-mbus.0 (18920) VIF_TIME_POINT_DATE: Value raw 9918 value calc 2021-06-30
2021-10-11 06:54:52.257 - error: wireless-mbus.0 (18920) invalid date: 65535
2021-10-11 06:54:52.257 - debug: wireless-mbus.0 (18920) VIF_TIME_POINT_DATE: Value raw 65535 value calc 2128-03-31
2021-10-11 06:54:52.257 - debug: wireless-mbus.0 (18920) VIF_TIME_POINT_DATE_TIME: Value raw 715851063 value calc 2021-10-11 05:55
2021-10-11 06:54:52.257 - debug: wireless-mbus.0 (18920) Updating device: LSE-89118904
2021-10-11 06:54:52.262 - debug: wireless-mbus.0 (18920) Value LSE-89118904.data.1-0-VIF_HCA: 0
2021-10-11 06:54:52.264 - debug: wireless-mbus.0 (18920) Value LSE-89118904.data.2-1-VIF_HCA: 0
2021-10-11 06:54:52.266 - debug: wireless-mbus.0 (18920) Value LSE-89118904.data.3-1-VIF_TIME_POINT_DATE: 2021-06-30
2021-10-11 06:54:52.268 - debug: wireless-mbus.0 (18920) Value LSE-89118904.data.4-0-VIF_TIME_POINT_DATE: 2128-03-31
2021-10-11 06:54:52.270 - debug: wireless-mbus.0 (18920) Value LSE-89118904.data.5-0-VIF_TIME_POINT_DATE_TIME: 2021-10-11 05:55

Es gibt aber auch Meldungen, die laufen problemlos durch:

2021-10-11 05:04:50.017 - debug: wireless-mbus.0 (18920) 2644653235001289350843207a0c1800000b6e3200004b6e00000042c9ce6cbe26326ca326046d0504ab2a14a680
2021-10-11 05:04:50.017 - debug: wireless-mbus.0 (18920) Short header
2021-10-11 05:04:50.017 - debug: wireless-mbus.0 (18920) VIF_HCA: Value 32
2021-10-11 05:04:50.017 - debug: wireless-mbus.0 (18920) VIF_HCA: Value 0
2021-10-11 05:04:50.017 - debug: wireless-mbus.0 (18920) VIF_TIME_POINT_DATE: Value raw 9918 value calc 2021-06-30
2021-10-11 05:04:50.017 - debug: wireless-mbus.0 (18920) VIF_TIME_POINT_DATE: Value raw 9891 value calc 2021-06-03
2021-10-11 05:04:50.017 - debug: wireless-mbus.0 (18920) VIF_TIME_POINT_DATE_TIME: Value raw 715850757 value calc 2021-10-11 04:05
2021-10-11 05:04:50.017 - debug: wireless-mbus.0 (18920) Updating device: LSE-89120035
2021-10-11 05:04:50.022 - debug: wireless-mbus.0 (18920) Value LSE-89120035.data.1-0-VIF_HCA: 32
2021-10-11 05:04:50.024 - debug: wireless-mbus.0 (18920) Value LSE-89120035.data.2-1-VIF_HCA: 0
2021-10-11 05:04:50.027 - debug: wireless-mbus.0 (18920) Value LSE-89120035.data.3-1-VIF_TIME_POINT_DATE: 2021-06-30
2021-10-11 05:04:50.030 - debug: wireless-mbus.0 (18920) Value LSE-89120035.data.4-0-VIF_TIME_POINT_DATE: 2021-06-03
2021-10-11 05:04:50.033 - debug: wireless-mbus.0 (18920) Value LSE-89120035.data.5-0-VIF_TIME_POINT_DATE_TIME: 2021-10-11 04:05

Dann noch die, wo der Hersteller unbekannt ist:

2021-10-11 07:02:04.173 - debug: wireless-mbus.0 (18920) 4f4465b20192342533073f5f780dff5f3500825980356eae350e0a06af207c58030f89d077d7dd8e5929c22b6077f1bad917894aab852b8cb9b532100e026e201f5b09070f30c1bfdb708f84046d0206ab2af3690c7830064935c90e80
2021-10-11 07:02:04.173 - debug: wireless-mbus.0 (18920) No header
2021-10-11 07:02:04.173 - error: wireless-mbus.0 (18920) WARNING: Unkown manufacturer specific vif: 0x5f
2021-10-11 07:02:04.174 - debug: wireless-mbus.0 (18920) VIF_TYPE_MANUFACTURER_UNKOWN: Value p[?A0 n259++J Yw`+B)Y]WwP X|
5.n5Y
2021-10-11 07:02:04.174 - debug: wireless-mbus.0 (18920) VIF_TIME_POINT_DATE_TIME: Value raw 715851266 value calc 2021-10-11 06:02
2021-10-11 07:02:04.174 - debug: wireless-mbus.0 (18920) VIF_FABRICATION_NO: Value 35490630
2021-10-11 07:02:04.174 - debug: wireless-mbus.0 (18920) Updating device: LSE-25349201
2021-10-11 07:02:04.180 - debug: wireless-mbus.0 (18920) Value LSE-25349201.data.1-0-VIF_TYPE_MANUFACTURER_UNKOWN: p[?A0 n259++J Yw`+B)Y]WwP X|
5.n5Y
2021-10-11 07:02:04.180 - warn: wireless-mbus.0 (18920) State "wireless-mbus.0.LSE-25349201.data.1-0-VIF_TYPE_MANUFACTURER_UNKOWN" has no existing object, this might lead to an error in future versions
2021-10-11 07:02:04.223 - debug: wireless-mbus.0 (18920) Value LSE-25349201.data.2-0-VIF_TIME_POINT_DATE_TIME: 2021-10-11 06:02
2021-10-11 07:02:04.223 - warn: wireless-mbus.0 (18920) State "wireless-mbus.0.LSE-25349201.data.2-0-VIF_TIME_POINT_DATE_TIME" has no existing object, this might lead to an error in future versions
2021-10-11 07:02:04.267 - debug: wireless-mbus.0 (18920) Value LSE-25349201.data.3-0-VIF_FABRICATION_NO: 35490630
2021-10-11 07:02:04.268 - warn: wireless-mbus.0 (18920) State "wireless-mbus.0.LSE-25349201.data.3-0-VIF_FABRICATION_NO" has no existing object, this might lead to an error in future versions

Und schließlich noch ein Gerät, was im Log etwas gesprächiger war:

2021-10-11 07:10:34.173 - debug: wireless-mbus.0 (18920) 4f4465b20192342533073f5f780dff5f350082598035b6690e87ccbca67ac13a3a8801b3d3a57ee758ced083b2238726e1ada80de29dc7652d9fe565fe5b11cd5d4dc5a3626f72ba8c061331046d0a06ab2affd60c7830064935c90e80
2021-10-11 07:10:34.173 - debug: wireless-mbus.0 (18920) No header
2021-10-11 07:10:34.173 - error: wireless-mbus.0 (18920) WARNING: Unkown manufacturer specific vif: 0x5f
2021-10-11 07:10:34.173 - debug: wireless-mbus.0 (18920) VIF_TYPE_MANUFACTURER_UNKOWN: Value 1:rob#EM[~ee-eGb
(-a#2PNXg~%S3::Adebug:="" wireless-mbus.0="" (18920)="" vif_time_point_date_time:="" value="" raw="" 715851274="" calc="" 06:10="" vif_fabrication_no:="" 35490630="" updating="" device:="" lse-25349201="" 07:10:34.177="" lse-25349201.data.1-0-vif_type_manufacturer_unkown:="" 1="" :rob#em[~ee-egb="" (-a#2pnxg~%s3::a:="" state="" "wireless-mbus.0.lse-25349201.data.1-0-vif_type_manufacturer_unkown"="" has="" no="" existing="" object,="" this="" might="" lead="" to="" an="" error="" in="" future="" versions="" 07:10:34.223="" lse-25349201.data.2-0-vif_time_point_date_time:="" 07:10:34.225="" "wireless-mbus.0.lse-25349201.data.2-0-vif_time_point_date_time"="" 07:10:34.267="" lse-25349201.data.3-0-vif_fabrication_no:="" "wireless-mbus.0.lse-25349201.data.3-0-vif_fabrication_no"="" 07:12:43.673="" 4f4465b20192342533073f5f780dff5f3500825980353c6ac1a62271a1390569a9f914af441c42d65eefd0e68d19c79636bf322177137deb64fb1383e6c1752d60d24973bbc32c07b94a59eb046d0c06ab2af1c70c7830064935c90e81="" 07:12:43.674="" header="" [31merror:="" warning:="" unkown="" manufacturer="" specific="" vif:="" 0x5f="" vif_type_manufacturer_unkown:="" kyj9,c;si-uaf{dk}w!2?6="" fpo^vbd="" y)iq"&aj<5�y�="" 715851276="" 06:12="" 07:12:43.678="" 07:12:43.679="" 07:12:43.723="" 07:12:43.724="" 07:12:43.767="" 07:12:43.768="" 07:14:53.673="" 4f4465b20192342533073f5f780dff5f350082598035c7a34607f6cce78aacc5f23deaabcedfac3f0495e387b1ea6dc96ebf11a037b78781211d86a9a808e1be20257f2c9c149254f51cd7ef046d0e06ab2affc20c7830064935c90e80="" owut,="">a()!77 ?nj1c?,_N+j=rE,LvF#G5Y
2021-10-11 07:14:53.673 - debug: wireless-mbus.0 (18920) VIF_TIME_POINT_DATE_TIME: Value raw 715851278 value calc 2021-10-11 06:14
2021-10-11 07:14:53.673 - debug: wireless-mbus.0 (18920) VIF_FABRICATION_NO: Value 35490630
2021-10-11 07:14:53.673 - debug: wireless-mbus.0 (18920) Updating device: LSE-25349201
2021-10-11 07:14:53.677 - debug: wireless-mbus.0 (18920) Value LSE-25349201.data.1-0-VIF_TYPE_MANUFACTURER_UNKOWN: oWuT,>a()!77 ?nj1c?,_N+j=rE,LvF#G5Y
2021-10-11 07:14:53.678 - warn: wireless-mbus.0 (18920) State "wireless-mbus.0.LSE-25349201.data.1-0-VIF_TYPE_MANUFACTURER_UNKOWN" has no existing object, this might lead to an error in future versions
2021-10-11 07:14:53.719 - debug: wireless-mbus.0 (18920) Value LSE-25349201.data.2-0-VIF_TIME_POINT_DATE_TIME: 2021-10-11 06:14
2021-10-11 07:14:53.720 - warn: wireless-mbus.0 (18920) State "wireless-mbus.0.LSE-25349201.data.2-0-VIF_TIME_POINT_DATE_TIME" has no existing object, this might lead to an error in future versions
2021-10-11 07:14:53.763 - debug: wireless-mbus.0 (18920) Value LSE-25349201.data.3-0-VIF_FABRICATION_NO: 35490630
2021-10-11 07:14:53.764 - warn: wireless-mbus.0 (18920) State "wireless-mbus.0.LSE-25349201.data.3-0-VIF_FABRICATION_NO" has no existing object, this might lead to an error in future versions

Und abschließend noch meine CUL FW Version: V 1.67 CUL868. Das ist angeblich die neueste "offizielle" Version.

Dank & Gruß
Daniel

andibr

@lvogt
Das merkwürdigste am ganzen ist eben, dass ich mit lsusb beide sehe. Noch kritischer finde ich aber das im syslog beide erkannt und protokoliert wird, das bei den Port ttyUSB0 zugewiesen bekommen haben sollen. Das kann kaum sein, obwohl es funktioniert eben beides nicht mehr. Kann es sein, dass der Rpi 3+ zuwenig RAM hat um beide Schnittstellen zu verwalten und ich auf einen Rpi4 wechseln muss?
Ich versuche gerade die Sache mit dem Symlink zu machen, nur ist das etwas doof mit 1Wire hat keine Seriennummer um den Link zu fixieren.

Gibt es eine Alternative um die 1Wire Fühler einzulesen. Ich weiss ich könnte ein ESP8266 nehmen, aber das ist im Keller neben dem iobroker Master auch etwas doof. Es sind 13 Fühler und 2 Impulszähler. Beim fhem konnte man direkt auf eine IP zugreifen ohne owserver, dafür habe ich mir eben mit einem DS24.. RS232to1w ein Interface gebaut.

Andi

lvogt

@ratte-rizzo

2021-10-11 06:54:52.257 - error: wireless-mbus.0 (18920) invalid date: 65535

Ich denke das liegt einfach daran, dass das Gerät das so sendet... ist halt ein undefiniertes oder maximal in der Zunkunft liegendes Datum...

Dann noch die, wo der Hersteller unbekannt ist:

Der Hersteller ist nicht unbekannt, sondern der Hersteller hat sich entschieden die Daten mit Typen abseits der Spezifikation zu codieren. Manchmal gibt's in Handbuch Angaben zum Format - oft aber nicht...
Falls das Geräte "von dir" sind, könnte ich evtl. bei Gelegenheit mal gucken ob ich was finde.

2021-10-11 07:02:04.180 - warn: wireless-mbus.0 (18920) State "wireless-mbus.0.LSE-25349201.data.1-0-VIF_TYPE_MANUFACTURER_UNKOWN" has no existing object, this might lead to an error in future versions

Hm das taucht ja wieder auf. Hast du im Objektbaum Geräte gelöscht und dann den Adapter nicht neugestartet? Dann passiert sowas nämlich auch. Ich sollte das unbedingt mal in die README aufnehmen, dass man nach "herum löschen" im Objektbaum den Adapter neu starten sollte...

Und schließlich noch ein Gerät, was im Log etwas gesprächiger war:

Das ist ja interessant. Hast du das Log aus der Weboberfläche kopiert oder direkt aus der Datei? Werde ich mir bei Gelegenheit auf jeden Fall mal gucken, damit die Ausgaben nicht das Format zerschießen. Ansonsten halt wie oben auch: Der Hersteller kocht sein eigenes Süppchen.

Und abschließend noch meine CUL FW Version: V 1.67 CUL868. Das ist angeblich die neueste "offizielle" Version.

Merkwürdig. Ich habe mittlerweile auch mal in den CUL Sourcecode geguckt und bin immer noch nicht ganz schlau geworden... Im Zweifelsfall werde ich den "Initialisierungskrempel" einfach recht tolerant machen und dann passt das schon...

Vielen Dank für deine ganzen Tests

P.S.: Aus Neugier: Du wohnst nicht in Mitteleuropa, oder?

@andibr

Noch kritischer finde ich aber das im syslog beide erkannt und protokoliert wird, das bei den Port ttyUSB0 zugewiesen bekommen haben sollen.

Wenn das wirklich so ist, dann hat dein zugrunde liegendes Linux System (oder zumindest udev) ein ernstes Problem. Wenn überhaupt kann ich mir vorstellen, dass irgendwo ein Hardware Problem vorliegt, wodurch erst nur das eine und dann nur das andere USB Gerät gefunden wird und daher beides (kurzzeitig) als ttyUSB0 zugewiesen wird. (Defekt könnte ja sowohl auf Seite der USB Geräte als auch auf Seite der Schnittstelle liegen...)

Kann es sein, dass der Rpi 3+ zuwenig RAM hat um beide Schnittstellen zu verwalten und ich auf einen Rpi4 wechseln muss?

Grundsätzlich ist das mit Sicherheit nicht der Fall. KA was du alles so auf dem RPI laufen hast...

Beim fhem konnte man direkt auf eine IP zugreifen ohne owserver, dafür habe ich mir eben mit einem DS24.. RS232to1w ein Interface gebaut.

Ich habe den 1-wire Adapter schon eine Weile nicht mehr verwendet, aber in meiner Erinnerung kann der auch auf einen 1-wire Server zugreifen.

Grundsätzlich scheint dein Problem gerade aber eher allgemeiner Natur als spezifisch zum wireless-mbus Adapter zu sein.

ratte-rizzo

Moin @lvogt

Ich wohne in Hamburg. Weiß nicht, wie mittig das in Europa ist

Also, ich hab gerade nochmal den gesamten (!) Objektbaum gelöscht und dann den Adapter neu gestartet. Mal gucken, ob er jetzt noch meckert. Ist ja etwas nervig, dass das immer so lange dauert, aber ich will mal dankbar sein.

Ein Gerät von mir ist unter den unknown Meldungen glücklicherweise nicht dabei. Von daher musst Du Dir meinetwegen keine Arbeit machen. Allerdings habe ich auch (noch) keine Wasserzähler. Aber da ich in meinem Baum auch schon welche sehe, gehe ich davon aus, dass wir das selbe Modell bekommen.

Zum Abschluss noch einmal das Log vom gesprächigen Gerät. Ich meine, ich hatte es beim letzten Mal auch direkt aus der Datei kopiert, aber zur Sicherheit noch einmal. Wenn die Forensoftware das hier verdriesknaddelt, schicke ich es Dir sonst noch auf anderen Kanälen.

2021-10-11 07:10:34.173 - debug: wireless-mbus.0 (18920) 4f4465b20192342533073f5f780dff5f350082598035b6690e87ccbca67ac13a3a8801b3d3a57ee758ced083b2238726e1ada80de29dc7652d9fe565fe5b11cd5d4dc5a3626f72ba8c061331046d0a06ab2affd60c7830064935c90e80
2021-10-11 07:10:34.173 - debug: wireless-mbus.0 (18920) No header
2021-10-11 07:10:34.173 - error: wireless-mbus.0 (18920) WARNING: Unkown manufacturer specific vif: 0x5f
2021-10-11 07:10:34.173 - debug: wireless-mbus.0 (18920) VIF_TYPE_MANUFACTURER_UNKOWN: Value 1:rob#EM[~ee-eGb
(-a#2PNXg~%S3::Adebug:="" wireless-mbus.0="" (18920)="" vif_time_point_date_time:="" value="" raw="" 715851274="" calc="" 06:10="" vif_fabrication_no:="" 35490630="" updating="" device:="" lse-25349201="" 07:10:34.177="" lse-25349201.data.1-0-vif_type_manufacturer_unkown:="" 1="" :rob#em[~ee-egb="" (-a#2pnxg~%s3::a:="" state="" "wireless-mbus.0.lse-25349201.data.1-0-vif_type_manufacturer_unkown"="" has="" no="" existing="" object,="" this="" might="" lead="" to="" an="" error="" in="" future="" versions="" 07:10:34.223="" lse-25349201.data.2-0-vif_time_point_date_time:="" 07:10:34.225="" "wireless-mbus.0.lse-25349201.data.2-0-vif_time_point_date_time"="" 07:10:34.267="" lse-25349201.data.3-0-vif_fabrication_no:="" "wireless-mbus.0.lse-25349201.data.3-0-vif_fabrication_no"="" 07:12:43.673="" 4f4465b20192342533073f5f780dff5f3500825980353c6ac1a62271a1390569a9f914af441c42d65eefd0e68d19c79636bf322177137deb64fb1383e6c1752d60d24973bbc32c07b94a59eb046d0c06ab2af1c70c7830064935c90e81="" 07:12:43.674="" header="" [31merror:="" warning:="" unkown="" manufacturer="" specific="" vif:="" 0x5f="" vif_type_manufacturer_unkown:="" kyj9,c;si-uaf{dk}w!2?6="" fpo^vbd="" y)iq"&aj<5�y�="" 715851276="" 06:12="" 07:12:43.678="" 07:12:43.679="" 07:12:43.723="" 07:12:43.724="" 07:12:43.767="" 07:12:43.768="" 07:14:53.673="" 4f4465b20192342533073f5f780dff5f350082598035c7a34607f6cce78aacc5f23deaabcedfac3f0495e387b1ea6dc96ebf11a037b78781211d86a9a808e1be20257f2c9c149254f51cd7ef046d0e06ab2affc20c7830064935c90e80="" owut,="">a()!77 ?nj1c?,_N+j=rE,LvF#G5Y
2021-10-11 07:14:53.673 - debug: wireless-mbus.0 (18920) VIF_TIME_POINT_DATE_TIME: Value raw 715851278 value calc 2021-10-11 06:14
2021-10-11 07:14:53.673 - debug: wireless-mbus.0 (18920) VIF_FABRICATION_NO: Value 35490630
2021-10-11 07:14:53.673 - debug: wireless-mbus.0 (18920) Updating device: LSE-25349201
2021-10-11 07:14:53.677 - debug: wireless-mbus.0 (18920) Value LSE-25349201.data.1-0-VIF_TYPE_MANUFACTURER_UNKOWN: oWuT,>a()!77 ?nj1c?,_N+j=rE,LvF#G5Y
2021-10-11 07:14:53.678 - warn: wireless-mbus.0 (18920) State "wireless-mbus.0.LSE-25349201.data.1-0-VIF_TYPE_MANUFACTURER_UNKOWN" has no existing object, this might lead to an error in future versions
2021-10-11 07:14:53.719 - debug: wireless-mbus.0 (18920) Value LSE-25349201.data.2-0-VIF_TIME_POINT_DATE_TIME: 2021-10-11 06:14
2021-10-11 07:14:53.720 - warn: wireless-mbus.0 (18920) State "wireless-mbus.0.LSE-25349201.data.2-0-VIF_TIME_POINT_DATE_TIME" has no existing object, this might lead to an error in future versions
2021-10-11 07:14:53.763 - debug: wireless-mbus.0 (18920) Value LSE-25349201.data.3-0-VIF_FABRICATION_NO: 35490630
2021-10-11 07:14:53.764 - warn: wireless-mbus.0 (18920) State "wireless-mbus.0.LSE-25349201.data.3-0-VIF_FABRICATION_NO" has no existing object, this might lead to an error in future versions

Dank & Gruß
Daniel

lvogt

@ratte-rizzo

Hm, ich hatte irgendwie aus den Uhrzeiten und Inhalt deiner Posts auf "weiter weg" geschlossen

Es gibt jetzt eine Version 0.7.4 die deutlich großzügiger mit der Initialisierung des CULs umgeht und nicht mehr das Log zerschießen sollte
Auch wenn es sich anders liest, sind das beides eigentlich nur visuelle Änderungen. Aber es wirkt ja so, als ob der Adapter mit dem CUL auch funktioniert...

Nochmal vielen Dank für deine ganzen Tests und Logauszüge. Und ich hoffe mal der Adapter läuft stabil

ratte-rizzo

Moin @lvogt

Also, erst einmal vielen Dank für das letzte Update. Das Starten funktioniert nun reibungslos!

Eine Frage habe ich aber noch bezüglich der Blockierliste: Was genau muss ich dort eintragen? Und was muss ich sonst beachten? Welche Geräteadresse muss da genau rein?

LSE-25342905
wireless-mbus.0.LSE-25342905
etwas anderes?
Und wenn ich den Eintrag dann gemacht habe? Datenpunkt löschen und dann Adapter neu starten?

Und noch eine Verbesserungsidee: Könnte man die "Unkown manufacturer specific" und "invalid date" Meldungen vielleicht als Warning machen und nicht als Error? Dann könnte ich nämlich das Log-Level auf Error setzen und diese (bei mir) ständigen Meldungen herausfiltern.

Ist nur so eine Idee, weiß ja nicht, wie das Log bei anderen Nutzern aussieht.

Ein schönes WE wünscht
Daniel

andibr

@lvogt
Alles Richtig, ich habe ein Hardware-Problem mit dem 1-Wire USB-Adapter. Da ich es bis jetzt nicht geschafft habe, diesen doofen blauen 1Wire-Adapter so einzubinden, dass er kein Ärger mit dem IM871 macht, läuft da nun halt ein alter Ppi2 mit Raspian und owfs zusätzlich. Ich denke das 1-Wire Zeugs werde ich nach und nach ersetzen und rauswerfen, ausser die Temperaturfühler, die werde ich dann wohl mit einem ESP und ESPEasy und MQTT in den Iobroker übernehmen.

Der W-Mbus läuft einwandfrei und erkennt nun auch die Zähler, jetzt muss ich nur noch auf den AES Schlüssel vom EVU/Wasserwerk warten.

Vielen Dank für die Arbeit am Adapter.

Gruss aus der Schweiz
Andi

lvogt

@ratte-rizzo

Hi,

ja die Einträge müssen wie die Keys vom Typ LSE-25342905 sein. Wenn du die Blockliste speicherst wird der Adapter ja sowieso neugestartet. Danach kannst du dann einfach den LSE-25342905 Knoten im Objektbaum löschen und es sollte nie wieder auftauchen.

Eine Hinweis bzw eine Ausname gibt es noch: Manche Telegramme senden unter der ID eines externen wMBus Sendemoduls die Telegramm und erst im "Application Layer" steht die eigentlich ID des Geräts. Im Objektbaum taucht die "eigentliche ID" auf, aber zum blockieren muss die "erste ID" angegeben werden. (Das gilt übrigens auch für AES Schlüssel.)
Der Haken: Im Moment kann man ohne selbst Hand anzulegen die ID nicht in ioBroker sehen. (Bei AES Schlüsseln ist das einfacher - da wird ja automatisch der "UNKNOWN" Key Eintrang angelegt...)

Die geänderten Loglevel sind wahrscheinlich keine schlechte Idee. Werde mir bei Gelegenheit nochmal insgesamt die Logausgabe vornehmen.

andibr

@lvogt
Also ich habe jetzt auch die AES Schlüssel bekommen, und die Daten aus dem Wasserzähler (GWF Encoder mit RCM) bekomme ich auch angezeigt. Bis jetzt habe ich aber noch keine Muster gesehen, dass er Werte automatisch aktualisieren würde. Kann man mit dem Adapter auch explizit ein Aufrufen anstossen?

@Lenny-CB
Ich habe hier auch einen Easymeter mit aufgesetztem W-Mbus Adapter, dazu habe ich einen Metering Code mit 33 Stellen bekommen, aber damit verabschiedet sich der iob-Adapter gleich. Darf ich dich fragen wieviele Stellen hat das bei dir? Auf nachfrage bei meinem EVU bekamm ich zur Antwort: "Ach, das wissen wir auch nicht, das haben wir als funktionierendes System eingekauft". Nur damit weiss ich noch nicht wieviele Stellen es nun wirklich braucht.

Bei mir gibt es sehr viele Fehler, sprich mein Slave (Mutlihost) mit dem IM871A dran, sagt was von Fehler beim AES Code. Ist ja aber logisch, denn der AES vom Easymeter wir ja nicht erkannt. Ich hoffe das damit nachher fertig ist.
Gruss Andi

Al Bundy

@andibr
Hi Andi
Ich habe auch ein GWF Wireless M-Bus Modul bei meinem Gaszähler, den ich mit dem IM871A bei meinem RasPi4 (Master) auslese (ebenfalls das RCM Funkmodul):

Sowohl bei diesem, wie such bei dem Wasserzähler (Apator ultrimis W UL4, siehe Post weiter oben) sind die Sendeintervalle aufgrund des Batteriebetriebs eingeschränkt. Für Durchflüsse wäre dies ungeeignet, diese werden bei mir aber schon gar nicht ausgegeben (also nur m³ und nicht ³/h).

Der Wasserzähler sendet etwa alle 1-5 min Daten. Das GWF Funkmodul aber ist da deutlich unregelmässiger und sendet von 1min Intervall, aber auch schon mal 3 Tage nichts. Da ich den Gasverbrauch auch bei meiner Heizung sehe, habe ich bislang noch nicht wirklich genau dahin geschaut oder Auswertungen gemacht. Das werde ich aber bei Gelegenheit auch mal nachholen (z.B. Tagesverbräuche, Visualisierung in Grafana und ähnliches).

lvogt

@andibr

Die meisten Geräte können sowieso keine Nachrichten empfangen. Manche S-Mode Geräte lassen sich tatsächlich auf "Anfrage" auslesen - aber der Adapter kann das nicht.

Es gibt einige Zähler (meistens ältere) die zwar "oft" senden aber zB nur einmal am Tag auch wirklich neue Daten liefern...

Zum AES Key. Der muss 16 Byte lang sein. Heißt also das es entweder ein 32 Zeichen langer Hexstring oder als 16 Zeichen langer "ASCII String" sein muss. 33 Zeichen ist definitv falsch.

NEWS

Test Adapter wireless-mbus v0.9.x

Support us

1.7k
Online

30.5k
Users

76.8k
Topics

1.2m
Posts

NEWS

Test Adapter wireless-mbus v0.9.x

Support us

1.7kOnline

30.5kUsers

76.8kTopics

1.2mPosts

1.7k
Online

30.5k
Users

76.8k
Topics

1.2m
Posts