UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[lvogt]

So ich habe mal noch ein paar Kleinigkeiten angepasst. Es wird im Moment weiterhin die "normale" serialport Bibliothek verwendet. Falls die weiterhin keine Symlinks unterstützt, dann funktioniert das hier gerade auch nicht.

Falls der Adapter jetzt tatsächlich doch schon wieder läuft, dann könnte ich evtl. auch noch versuchen die Symlinks wieder einzubauen, falls gewünscht.

Falls es immer noch nicht funktioniert, müsste ich mal gucken was man so machen könnte...

EDIT: Ich habe auch mal noch versucht ein paar Fehler im "cul-test" Branch zu fixen. Vielleicht funktioniert das jetzt (wenn der Rest denn wieder funktioniert...)

[Lenny.CB]

@lvogt sagte in Test Adapter wmbus v0.5.x:

So ich habe mal noch ein paar Kleinigkeiten angepasst. Es wird im Moment weiterhin die "normale" serialport Bibliothek verwendet. Falls die weiterhin keine Symlinks unterstützt, dann funktioniert das hier gerade auch nicht.

Falls der Adapter jetzt tatsächlich doch schon wieder läuft, dann könnte ich evtl. auch noch versuchen die Symlinks wieder einzubauen, falls gewünscht.

Falls es immer noch nicht funktioniert, müsste ich mal gucken was man so machen könnte...

EDIT: Ich habe auch mal noch versucht ein paar Fehler im "cul-test" Branch zu fixen. Vielleicht funktioniert das jetzt (wenn der Rest denn wieder funktioniert...)

grad die letzte Version installiert. Klappt wieder. Installation OK, Daten kommen wieder an!
Erst einmal vielen Dank. Wenn ich noch etwas testen soll, sag bescheid.

[Lenny.CB]

@lvogt vielleicht ist das noch interessant:

wmbus.0
2021-08-11 21:38:54.575	warn	Object of state "wmbus.0.ESY-61015893.data.8-0-VIF_ELECTRIC_POWER" is missing the required property "common.type"

wmbus.0
2021-08-11 21:38:54.545	warn	Object of state "wmbus.0.ESY-61015893.data.7-0-VIF_ELECTRIC_POWER" is missing the required property "common.type"

wmbus.0
2021-08-11 21:38:54.543	warn	Object of state "wmbus.0.ESY-61015893.data.6-0-VIF_ELECTRIC_POWER" is missing the required property "common.type"

wmbus.0
2021-08-11 21:38:54.541	warn	Object of state "wmbus.0.ESY-61015893.data.5-0-VIF_ELECTRIC_POWER" is missing the required property "common.type"

wmbus.0
2021-08-11 21:38:54.539	warn	Object of state "wmbus.0.ESY-61015893.data.4-0-VIF_ENERGY_WATT" is missing the required property "common.type"

wmbus.0
2021-08-11 21:38:54.537	warn	Object of state "wmbus.0.ESY-61015893.data.3-0-VIF_ENERGY_WATT" is missing the required property "common.type"

wmbus.0
2021-08-11 21:38:54.535	warn	Object of state "wmbus.0.ESY-61015893.data.2-0-VIF_ENERGY_WATT" is missing the required property "common.type"

wmbus.0
2021-08-11 21:38:54.533	warn	Object of state "wmbus.0.ESY-61015893.data.1-0-VIF_ENERGY_WATT" is missing the required property "common.type"

wmbus.0
2021-08-11 21:38:54.531	warn	Object of state "wmbus.0.ESY-61015893.info.Updated" is missing the required property "common.type"

wmbus.0
2021-08-11 21:38:54.528	warn	Object of state "wmbus.0.ESY-61015893.info.AccessNumber" is missing the required property "common.type"

[lvogt]

@lenny-cb Danke für den Hinweis. Ich habe gerade mal noch einen "mini-fix" dafür eingebaut, der allerdings nur greift für States die neu erstellt werden. Da wird dann der Typ auf 'mixed' gesetzt.

Außerdem bin ich recht überzeugt, dass der CUL Support funktionieren müssste. Es wäre also schön wenn es mal jemand ausprobieren würde.

Ich habe das ganze jetzt auch als v0.6.0 getaggt und im ersten Post verlinkt. Aber Achtung das "original" ISFH git enthält weiterhin die "alte" 0.5.2er Version!

[Lenny.CB]

@lvogt sagte in Test Adapter wmbus v0.5.x:

@lenny-cb Danke für den Hinweis. Ich habe gerade mal noch einen "mini-fix" dafür eingebaut, der allerdings nur greift für States die neu erstellt werden. Da wird dann der Typ auf 'mixed' gesetzt.

Außerdem bin ich recht überzeugt, dass der CUL Support funktionieren müssste. Es wäre also schön wenn es mal jemand ausprobieren würde.

Ich habe das ganze jetzt auch als v0.6.0 getaggt und im ersten Post verlinkt. Aber Achtung das "original" ISFH git enthält weiterhin die "alte" 0.5.2er Version!

Grad mal den Adapter neu installiert. Klappt wunderbar. Vielen Dank, die Warnungen sind weg.
CUL-kann ich leider nicht testen. Habe da, glaube ich, nicht die richtigen Gerätschaften da.

[lvogt]

Aktuelle Version ist nun 0.7.0. Dabei handelt es sich hauptsächlich nur um interne Anpassungen.

Das Ziel sollte eigentlich sein, die Version auch bei npm zu veröffentlichen, allerdings musste ich feststellen, dass es "so" nicht geht. Das Paket wird abgewiesen, da es einen zu ähnlichen Namen zu anderen Paketen hat.

Antwort von NPM:

403 Forbidden - PUT https://registry.npmjs.org/iobroker.wmbus - Package name too similar to existing packages; try renaming your package to '@lvogt/iobroker.wmbus' and publishing with 'npm publish --access=public' instead

Hat damit jemand Erfahrung? Oder was wäre generell jetzt das "ioBroker empfohlene Vorgehen"? Umbennenung in ioBroker.wireless-mbus vl.?

P.S. Ich würde mich immer noch sehr über Rückmeldungen zur CUL Unterstützung freuen.

[apollon77]

Hi lvogt,

Ja das ist blöd von npm. Ich hatte schonmal so einen "Name ist sehr nah" Thema ... Du kannst versuchen npm anzuschreiben ob Sie den Namen freigeben. Ich hatte damals kein Glück.

Von daher ist es wohl eher die "npm empfohlene Vorgehensweise" so eine blöde umbenennung vorzunehmen :-( Du kannst ggf den originalen Dev anschreiben wegen npm rechten oder halt wieder npm das Du den Namen übernehmen kannst. Das dauert dann paar Wochen hat aber schon mehrfach geklappt - habe aber gelesen das aktuell die Regeln wieder schärfer sind.

Generell hatte ich auch schon überlegt das zu tun was Du getan hast fand es aber wegen der LGPL v2 schwierig ... also bitte sei vorsichtig bezüglich der Verpflichtungen. Ich denke es "sollte" gecovered sein da der Quellcode weiter offen ist aber DU darfst keine Originalen Copyright Infos oder so entfernen und so weiter ...

[lvogt]

@apollon77
Ich habe vor knapp zwei Wochen soef angeschrieben, ob er vl. bereit wäre sein npm Paket auf- / abzugeben, bisher aber leider keine Antwort erhalten.

Falls ich nicht ca. innerhalb der nächsten Woche eine Antwort erhalte, würde ich stattdessen den Adapter in ioBroker.wireless-mbus umbenennen. Laut der ioBroker.live Badge existieren momentan ~ 16 Installationen des Adapters, denen würde ich dann die Migration / Neu-installation zumuten.

[apollon77]

@lvogt Bennene um. Von soef hat bisher leider noch keiner eine Antwort erhalten

[andibr]

Hallo Leute

Ich habe hier 3stk Elektrozähler vom EasyMeter mit W Mbus drauf und möchte die Daten in den Iobroker bekommen.
Bevor ich etwas kaufe darum die Frage: habe ich mit dem Adapter hier und dem Amber Stick eine Chance das zu realisieren? Ist mir schon klar braucht dann vermutlich von EVU noch den Schlüssel zum Auslesen.

Danke für einen Hinweis
Andi

[lvogt]

@andibr

Das sollte vermutlich gehen. Wenn du dir den Thread anschaust, wirst du feststellen, dass Lenny.CB mit genau diesem Setup arbeitet.

---

Ich habe den Adapter nun umbenannt auch auf npm veröffentlicht. Außerdem gab's nen Bugfix zu blockierten Sendern.
Das heißt für alle die den Adapter bereits nutzen und updaten wollen, dass sie leider ihre vorhanden States nicht weiter nutzen können, da sich der "Pfad" im Objektbaum ändern wird. Aus wmbus.0.*** wird wireless-mbus.0.***.

EDIT: Eine Frage zu https://github.com/ioBroker/ioBroker.repositories#requirements-for-adapter-to-get-added-to-the-latest-repository
Da steht die ioBroker organization auf npm soll als maintainer/owner zum Paket hinzugefügt werden. Soweit ich das sehe existiert immer noch keine ioBroker Organisation auf npm. Ändert sich das irgendwann mal?
Ich halte nämlich bluefox als Maintainer zu ergänzen ungefähr so "gut" wie keinen weiteren User hinzu zu fügen. Denn wenn aus irgendwelchen Gründen bluefox aus dem Projekt verschwindet, ist das Problem wieder mehr oder weniger das gleiche...

[apollon77]

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

EDIT: Eine Frage zu https://github.com/ioBroker/ioBroker.repositories#requirements-for-adapter-to-get-added-to-the-latest-repository
Da steht die ioBroker organization auf npm soll als maintainer/owner zum Paket hinzugefügt werden. Soweit ich das sehe existiert immer noch keine ioBroker Organisation auf npm. Ändert sich das irgendwann mal?
Ich halte nämlich bluefox als Maintainer zu ergänzen ungefähr so "gut" wie keinen weiteren User hinzu zu fügen. Denn wenn aus irgendwelchen Gründen bluefox aus dem Projekt verschwindet, ist das Problem wieder mehr oder weniger das gleiche...

Jupp, auch ein Thema ...

[andibr]

@lvogt
Vielen Dank für den Hinweis. Ich habe den ganzen Thread angeschaur aber leider nicht mal die hälfte verstanden, darum habe ich die Frage gestellt.

Nun habe ich mir mal den i817 Stick bestellt und schaue mal was ich damit hinkriege.
Vielen Dank für die Arbeit am Adapter.

Soeben habe ich den Adapter installiert, verstehe ich das richtig, das ich für zwei verschiedene Mode auch verschiedene Stick brauche? Hintergrund der Frage ist eben das ich auch noch Wasserzähler mit WMbus habe. Die haben ein GWF RCM montiert. Da habe ich aber noch keine Ahnung welchen Mode verwendet wird.

Ideal währe wenn ich dann natürlich gleich alle Zähler auf dem iobroker anzeigen kann.

Gruss Andi

[lvogt]

@andibr

Wenn du wirklich zwei Modi brauchst, dann brauchst du vermutlich auch zwei Sticks. Die Ausnahme ist der Amber Stick, der hat einen Modus der C und T Mode gleichzeitig (empfangen) kann. Die meisten Geräte senden aber im T Mode.

[Al Bundy]

@lvogt Vielen Dank für den Adapter 😊
Musste lange warten, bis ich den AES Key für meinen Wasserzähler bekommen habe.
Jetzt hat es geklappt und die Daten kommen an!

Infos von mir (evtl. hilfreich für andere User):
Zähler: Apator ultrimis W UL4 Q3 (NeoVac rebranding)
Modus : T
iobroker v5.1.25 auf RasPi 4 (Master)
Node.js: v12.22.6
NPM: 6.14.15
wireless-mbus: v0.7.2
Stick: IMST iM871A

Adapter Einstellung:

Zähler und die Daten dazu:

[ratte-rizzo]

Moin

Ich habe meinen CUL nun testweise von meinem FHEM System auf den ioBroker mit dem neuen Adapter umgestöpselt. Es trudeln auch Nachrichten ein, aber die verursachen Fehlermeldungen. Ich habe ein paar Zeilen heraus kopiert. Vermutlich fehlt für einige Geräte noch die Decodierung. Meine eigenen Geräte sind bisher noch nicht aufgetaucht. Die wurden zumindest bei FHEM korrekt angezeigt.

wireless-mbus.0
	2021-10-05 18:59:31.776	error	Frame type null is not implemented!
wireless-mbus.0
	2021-10-05 18:59:31.775	debug	3f20283f20697320756e6b6e6f776e2920557365206f6e65206f66204120422062204320652046204720682069204b206b204c206c204d206d204e205220542074205520752056205720582078205920
wireless-mbus.0
	2021-10-05 18:59:21.649	error	Frame type null is not implemented!
wireless-mbus.0
	2021-10-05 18:59:21.649	debug	3f20283f20697320756e6b6e6f776e2920557365206f6e65206f66204120422062204320652046204720682069204b206b204c206c204d206d204e205220542074205520752056205720582078205920
wireless-mbus.0
	2021-10-05 18:59:08.523	error	Frame type null is not implemented!
wireless-mbus.0
	2021-10-05 18:59:08.523	debug	3f20283f20697320756e6b6e6f776e2920557365206f6e65206f66204120422062204320652046204720682069204b206b204c206c204d206d204e205220542074205520752056205720582078205920
wireless-mbus.0
	2021-10-05 18:59:03.645	error	Frame type null is not implemented!
wireless-mbus.0
	2021-10-05 18:59:03.642	debug	4f4465b20192342533073f5f780dff5f350082388035f23fa3547dfa4cc943120a2caa906818c98e1b348863115eefe40d34fc5abb6250fbfb70191b8e4a0e5e829a4871d0f51afc9390b8d4046d3b11a52ade7e0c7830064935c90e80
wireless-mbus.0
	2021-10-05 18:57:02.521	error	Frame type null is not implemented!
wireless-mbus.0
	2021-10-05 18:57:02.517	debug	3246463337314236433431413141333534423830303331424633354142344143453632453832313331413942393531304641394543443930463433413334453962344634343635423230313932333432353333303733463546373830444646354633353030383233383830333536383741443443423237374444383336424536623446343436354232303532393334323533333037414535303738304446463546333530303832344338303335443732434539364232433334393043464633346234463434363542323031393233343235333330373346354637383044464635463335303038323338383033354545334242453839314334443334354446344432343839313442464242384544464546453843463439443239373944444636314244353838364439373343333032453939394430433937313941413544333734393036414237393543413234443444433441433243393030343034364433393131413532413230393830433738333030363439333543393045383030370a0a3f202832343839313442464242384544464546393036414237393543413234443444435620697320756e6b6e6f776e2920557365206f6e65206f66204120422062204320652046204720682069204b206b204c206c204d206d204e205220542074205520752056205720582078205920
wireless-mbus.0
	2021-10-05 18:44:07.411	error	Frame type null is not implemented!
wireless-mbus.0
	2021-10-05 18:44:07.410	debug	38464332454243324238384446393035353130303943443637383842323931353536443334313941453331373544323838464644423445354432363236424446413142344646343635304242343834434643363944463035303034364432433131413532413542383830433738333030363439333543393045383030

Lieben Gruß
Daniel

[lvogt]

@ratte-rizzo
Schon mal super, dass du den Adapter mit einem CUL testest. Danke.

Da ist aber anscheinend immer noch irgendwas nicht mit der Kommunikation zw. Adapter und CUL in Ordnung. Mit dem Geräten bzw. den eigentlichen Telegrammen dürfte das nichts zu tun haben.

Damit ich helfen kann brauche ich mehr Infos: Wie sieht die Konfiguration des Adapters aus? Und wie sieht der "Anfang" des Logs aus?

[ratte-rizzo]

Moin @lvogt

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:

Ü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:

Heizungszähler

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).