Test Adapter wireless-mbus v0.9.x

[lvogt]

@gerald123
Nur mal zur Sicherheit: Dein Logauszug war auf debug Level? Falls nicht, bitte mal noch prüfen ob es damit ein paar mehr Ausgaben gibt.

[hg6806]

@gerald123

Hier das Log im Debug Modus. Sieht meiner Meinung nach auch unauffällig aus.

wireless-mbus.0	2022-03-21 20:04:02.241	debug	(15755) connected set to true
wireless-mbus.0	2022-03-21 20:04:02.193	debug	(15755) connected set to true
wireless-mbus.0	2022-03-21 20:04:02.163	debug	(15755) CUL: Receiver set to T-MODE and data reporting with RSSI
wireless-mbus.0	2022-03-21 20:04:02.107	debug	(15755) Created device of type: CUL (untested)
wireless-mbus.0	2022-03-21 20:04:01.984	info	(15755) starting. Version 0.7.7 in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v14.19.1, js-controller: 4.0.21
wireless-mbus.0	2022-03-21 20:04:01.970	warn	(15755) This object will not be created in future versions. Please report this to the developer.
wireless-mbus.0	2022-03-21 20:04:01.968	warn	(15755) Object wireless-mbus.0.info.rawdata is invalid: Default value has to be type "string" but received type "boolean"
wireless-mbus.0	2022-03-21 20:04:01.215	debug	(15755) States connected to redis: 127.0.0.1:9000
wireless-mbus.0	2022-03-21 20:04:01.108	debug	(15755) States create User PubSub Client
wireless-mbus.0	2022-03-21 20:04:01.106	debug	(15755) States create System PubSub Client
wireless-mbus.0	2022-03-21 20:04:01.041	debug	(15755) Redis States: Use Redis connection: 127.0.0.1:9000
wireless-mbus.0	2022-03-21 20:04:00.960	debug	(15755) Objects connected to redis: 127.0.0.1:9001
wireless-mbus.0	2022-03-21 20:04:00.935	debug	(15755) Objects client initialize lua scripts
wireless-mbus.0	2022-03-21 20:04:00.756	debug	(15755) Objects create User PubSub Client
wireless-mbus.0	2022-03-21 20:04:00.754	debug	(15755) Objects create System PubSub Client
wireless-mbus.0	2022-03-21 20:04:00.740	debug	(15755) Objects client ready ... initialize now
wireless-mbus.0	2022-03-21 20:04:00.598	debug	(15755) Redis Objects: Use Redis connection: 127.0.0.1:9001

[lvogt]

@hg6806
Sieht in der Tat unauffällig aus. Und die Kommunikation zum Stick scheint auch ok zu sein. Dann wäre halt die Anschlussfrage: Du bist sicher, dass auch irgendwas in deinem "Testzeitraum" empfangen werden müsste?

[hg6806]

@lvogt

Eigentlich ja, denn ich hatte es einige Stunden am Laufen.
Mit wmbusmeters hatte ich grob alle 1-3 Stunden etwas empfangen.

Es ist doch so, sobald etwas empfangen wird, wird ein Datenpunkt neben "wireless-mbus.0.info" erstellt, oder?
Das ist bis jetzt noch nicht erfolgt.

[lvogt]

@hg6806 Ja da sollte dann ein "Device" im Objektbaum auftauchen - oder eine Logausgabe falls es Probleme gibt.

Mein letzter Rateversuch: Sendet das Gerät auf das du wartest vl nicht im T Mode sondern im S Mode?

[hg6806]

@lvogt

Ja, ich warte immer auf Übertragung und kann auch mal S Mode versuchen.

Nochmal die Frage ob es bei @kiste01 nun läuft?

[HKF8770]

@hkf8770

O.K., hab da folgende Informationen und auch den Fehler im debug log

[HKF8770]

Hab auch den Fehler dass rawdata string sein sollte, aber die Daten boolen sind. Aber wie gesagt Der wichtige Wert der Wasseruhr kommt rein. Ist eher zur Info für die Entwickler

In io sieht das wie folgt aus

Also gar net so schlecht

[lvogt]

Ich habe vorhin v0.7.8 veröffentlicht. Hauptsächliche Änderung ist, dass die Warnung über den Defaultwert des States beim Adapterstart nun verschwunden sein sollte und das kritische Probleme bei der Kommunikation mit dem "USB Stick" nun auch als ERROR geloggt werden sollten.

Kurze Warnung: Dadurch musste ich natürlich in den entsprechenden Klassen für die Kommunikation mit den USB Sticks kleine Änderungen machen. Diese Klassen haben aber leider null Testabdeckung... Also falls mit der neuen Version plötzlich "gar nichts" mehr gehen sollte, bitte melden!

---

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

@hkf8770

O.K., hab da folgende Informationen und auch den Fehler im debug log

Der entscheidenden Teil fehlt aber leider in deinem Screenshot(!). Die Rohdaten des Telegramms sind unvollständig da dein Screenshot da abgeschnitten ist. Logauszüge immer besser auch als Text posten. Das sollte die eigentlich weniger Arbeit machen wenn du dir den Screenshot sparst und "der Empfänger" muss nicht anfangen (fehleranfällig!) von Hand was abzutippen...

Alternativ würde vl. das genaue Modell des Wasserzählers vl. auch schon helfen - zumindest falls der Hersteller nett genug ist was zu den verwendenten Telegrammen im Handbuch zu schreiben.

[Simps]

Hallo zusammen,

ich würde mir gerne einen Stick zulegen, aber alles ist ausverkauft. Hat jemand einen Tipp?

Ich habe Heizkostenverteiler an den Heizkörpern, manche haben keine AES Verschlüsselung (Qundis) auf dem OMS Kanal. Was denkt ihr, kann ich davon ausgehen, dass zB der Nano-Cul da funktioniert?

Aber ich sehe gerade, selbst der scheint ausverkauft zu sein?

Danke Euch für die erste Hilfe. Super Threat

[kiste01]

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

@lvogt

Ja, ich warte immer auf Übertragung und kann auch mal S Mode versuchen.

Nochmal die Frage ob es bei @kiste01 nun läuft?

Update: Hat sich geklärt. Mehrere Neustarts und ein kurzes Entfernen des Sticks haben Wunder bewirkt.

Das letzte Adapterupdate hat irgendwas verändert, so dass ich den Adapter nicht mehr grün bekomme, davor lief es top. Da ich zeitgleich aber auch sonst das System (iob auf 4.0.21 und node.js auf 14.19.1) aktualisiert habe, kann ich das nicht voneinander trennen.

Aktuell steht das im log

wireless-mbus.0
2022-03-28 18:04:19.841	debug	connected set to false
wireless-mbus.0
2022-03-28 18:04:19.803	debug	connected set to false
wireless-mbus.0
2022-03-28 18:04:19.800	debug	connected set to false
wireless-mbus.0
2022-03-28 18:04:19.786	error	Serialport error: Port is not open
wireless-mbus.0
2022-03-28 18:04:19.784	error	Serialport error: Error Resource temporarily unavailable Cannot lock port
wireless-mbus.0
2022-03-28 18:04:19.775	debug	Created device of type: CUL (untested)
wireless-mbus.0
2022-03-28 18:04:19.691	info	starting. Version 0.7.7 (non-npm: lvogt/ioBroker.wireless-mbus#32679a612e4f3c02184035bd12d7fcaad4840ff1) in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v14.19.1, js-controller: 4.0.21
wireless-mbus.0
2022-03-28 18:04:19.673	warn	This object will not be created in future versions. Please report this to the developer.
wireless-mbus.0
2022-03-28 18:04:19.671	warn	Object wireless-mbus.0.info.rawdata is invalid: Default value has to be type "string" but received type "boolean"

[Michi_Pi]

@lvogt bei mir funktioniert nach wie vor der Adapter mit dem neuen Update.

[Simps]

Servus @lvogt

Du suchst ja Tester für CUL, ich hab einen Mini-Cul, die Firmware ist upgedatet auf WMBUs-fähig.

Über Github installiere ich Deinen Adapter, aber er taucht nicht unter den Adaptern auf, er legt aber zwei Objekt-Verzeichnisse an (wmbus/admin, aber keine Ziffer). Beim Installieren kommt (Debug-Fenster). Die Script Depency WARN ist sicher die Lösung, finde durch googlen nichts, was mir hilft, ist es die NPM Version?

url https://github.com/lvogt/ioBroker.wireless-mbus --host pii --debug
install lvogt/ioBroker.wireless-mbus#ece83640b64ef90971e96e03b229f236dd2d2b0a
NPM version: 6.14.16Installing lvogt/ioBroker.wireless-mbus#ece83640b64ef90971e96e03b229f236dd2d2b0a... (System call)
iobroker npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@2.3.2 (node_modules/fsevents):
iobroker npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@2.3.2: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"arm"})

+ iobroker.wireless-mbus@0.7.8added 2 packages from 2 contributors in 11.038s

46 packages are looking for funding run `npm fund` for details
upload [2] wireless-mbus.admin /opt/iobroker/node_modules/iobroker.wireless-mbus/admin/index_m.html index_m.html text/html
iobroker upload [1] wireless-mbus.admin /opt/iobroker/node_modules/iobroker.wireless-mbus/admin/wireless-mbus.png wireless-mbus.png image/png
iobroker upload [0] wireless-mbus.admin /opt/iobroker/node_modules/iobroker.wireless-mbus/admin/words.js words.js application/javascript
iobroker exit 0

npm fund hat kein nennenswertes Ergebnis.
Javascript version ist 5.2.21
NPM ist 6.14.16
Alla Adapter sind upgedated (via stable repository).

ABER: Wenn ich nicht den Link aus Github installiere, sondern den WMBUS Adapter 0.7.8 aus dem beta Repository (ist das denn deiner?) bekomme ich im System einen funktionierenden Adapter, ausserdem auch irgendwelche Daten (siehe Screenshot), aber keine Objekte ausm funk. Es müssten aber ein paar funken.

Danke fürs Helfen

Stefan

[lvogt]

@simps
Vorweg: Der wireless-mbus Adapter ist natürlich genau der selbe.

Die Warnung kommt glaube ich von serialport und ist kein Problem sofern ich das gerade richtig im Kopf habe.

Ich vermute mal du hast nur den Adapter installiert aber keine Instanz erzeugt. Du musst jetzt halt im Adapter "Tab" noch eine Instanz anlegen...

Edit: Das was du zeigst sind ja die technischen "Interna" wie sie für jeden Adapter existieren.

Wenn ich irgendwie helfen können soll brauche ich min. ein Debug Log. Und "es m üssten aber ein paar funken" klingt schon nach der Ursache. Wie sicher bist du dir dass was funkt und in welchem Intervall? Und vl auch verschlüsselt?

[Simps]

@lvogt vielen Dank!

Anbei ein Debug-Log, ist das ausreichend? Derzeit hängt er in folgender Schleife fest

wireless-mbus.0
10401	2022-04-04 08:36:08.180	info	starting. Version 0.7.8 (non-npm: lvogt/ioBroker.wireless-mbus#ece83640b64ef90971e96e03b229f236dd2d2b0a) in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v12.22.11, js-controller: 4.0.21
host.pii
2022-04-04 08:36:06.752	info	instance system.adapter.wireless-mbus.0 started with pid 10401
host.pii
2022-04-04 08:35:36.646	info	Restart adapter system.adapter.wireless-mbus.0 because enabled
host.pii
2022-04-04 08:35:36.645	info	instance system.adapter.wireless-mbus.0 terminated with code NaN ()
host.pii
2022-04-04 08:35:36.645	warn	instance system.adapter.wireless-mbus.0 terminated due to SIGABRT
host.pii
2022-04-04 08:35:36.641	error	Caught by controller[0]: FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

wireless-mbus.0
10027	2022-04-04 08:24:50.165	info	starting. Version 0.7.8 (non-npm: lvogt/ioBroker.wireless-mbus#ece83640b64ef90971e96e03b229f236dd2d2b0a) in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v12.22.11, js-controller: 4.0.21
host.pii
2022-04-04 08:24:48.732	info	instance system.adapter.wireless-mbus.0 started with pid 10027
host.pii
2022-04-04 08:24:18.631	info	Restart adapter system.adapter.wireless-mbus.0 because enabled
host.pii
2022-04-04 08:24:18.631	info	instance system.adapter.wireless-mbus.0 terminated with code NaN ()
host.pii
2022-04-04 08:24:18.630	warn	instance system.adapter.wireless-mbus.0 terminated due to SIGABRT
host.pii
2022-04-04 08:24:18.630	error	Caught by controller[0]: FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

"Adapter aus der Beta installiert" führt natürlich dann zu einer Instanz. Nur der Github-Link nicht. Die technischen Interna hatte ich gescreenshottet, weil ich mir nicht sicher war, ob das helfen könnte.

Derzeit läuft er auf /dev/ttyAMA0 wenn ich den Port wechsle auf /dev/ttyUSB0 kommt:

wireless-mbus.0
10849	2022-04-04 08:47:42.147	error	CUL: Error setting wMBus mode: Timeout waiting for response

wireless-mbus.0
10849	2022-04-04 08:47:42.144	error	CUL: Message response timeout

Das bedeutet, das er auf dem ttyUSB0 nicht ansprechbar ist oder?

Und es "funkt" auf jeden Fall Ich habe hier Test-Heizkostenverteiler verschiedener Marken als Testgeräte, auf der richtigen Frequenz und im richtigen OMS WMBUS Format, einige sind AES verschlüsselt, andere nicht, aber keiner kommt an in den Objekten.

Was denkst Du? Und Danke nochmal!

[lvogt]

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

Anbei ein Debug-Log, ist das ausreichend?

Eigentlich nicht. Da ist ja nicht mal drin dass der Adapter ein korrekte Antwort vom CUL nach dem Setzen des T- oder S-Modes bekommen hat. Aber: (s.u.)

Derzeit hängt er in folgender Schleife fest

wireless-mbus.0
10401	2022-04-04 08:36:08.180	info	starting. Version 0.7.8 (non-npm: lvogt/ioBroker.wireless-mbus#ece83640b64ef90971e96e03b229f236dd2d2b0a) in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v12.22.11, js-controller: 4.0.21
host.pii
2022-04-04 08:36:06.752	info	instance system.adapter.wireless-mbus.0 started with pid 10401
host.pii
2022-04-04 08:35:36.646	info	Restart adapter system.adapter.wireless-mbus.0 because enabled
host.pii
2022-04-04 08:35:36.645	info	instance system.adapter.wireless-mbus.0 terminated with code NaN ()
host.pii
2022-04-04 08:35:36.645	warn	instance system.adapter.wireless-mbus.0 terminated due to SIGABRT
host.pii
2022-04-04 08:35:36.641	error	Caught by controller[0]: FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

wireless-mbus.0
10027	2022-04-04 08:24:50.165	info	starting. Version 0.7.8 (non-npm: lvogt/ioBroker.wireless-mbus#ece83640b64ef90971e96e03b229f236dd2d2b0a) in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v12.22.11, js-controller: 4.0.21
host.pii
2022-04-04 08:24:48.732	info	instance system.adapter.wireless-mbus.0 started with pid 10027
host.pii
2022-04-04 08:24:18.631	info	Restart adapter system.adapter.wireless-mbus.0 because enabled
host.pii
2022-04-04 08:24:18.631	info	instance system.adapter.wireless-mbus.0 terminated with code NaN ()
host.pii
2022-04-04 08:24:18.630	warn	instance system.adapter.wireless-mbus.0 terminated due to SIGABRT
host.pii
2022-04-04 08:24:18.630	error	Caught by controller[0]: FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

Wenn das wirklich eine Schleife ist, sollte es dich nicht wundern wenn der Adapter nichts empfängt, da er offensichtlich ununterbrochen neu gestartet wird. Die Fehlermeldung deutet auf ein Memoryleak hin, aber ich weiß nicht wirklich woher das kommen soll. Insbesondere da ja offensichtlich die meisten keine Probleme mit überfülltem Speicher haben. (Und es ja scheinbar quasi direkt nach dem Adapter Start bereits auftritt.) Weiter oben im Thread hatte jemand anderes schon dasselbe oder wenigstens ein ähnliches Problem was bisher nicht gelöst ist.

Wenn du etwas experimentieren willst kannst du mal versuchen andere Adapter / Skripte zu stoppen und gucken ob es hilft.

"Adapter aus der Beta installiert" führt natürlich dann zu einer Instanz. Nur der Github-Link nicht.

Wie ich geschrieben habe, ist der Unterschied dass ioBroker nicht automatisch eine Instanz anlegt wenn du den Adapter aus dem Git Repository installierst, das müsstest du halt "manuell" machen. Ist aber ja auch egal, der du am Ende sowieso mit dem selben Stand wie aus dem "beta Repository" raus kommst.

Derzeit läuft er auf /dev/ttyAMA0 wenn ich den Port wechsle auf /dev/ttyUSB0 kommt:

wireless-mbus.0
10849	2022-04-04 08:47:42.147	error	CUL: Error setting wMBus mode: Timeout waiting for response

wireless-mbus.0
10849	2022-04-04 08:47:42.144	error	CUL: Message response timeout

Das bedeutet, das er auf dem ttyUSB0 nicht ansprechbar ist oder?

Im Grunde ja. Welches der richtige Port musst du schon selber wissen / rausfinden. (Zb. in dmesg nach dem Verbinden des CULs gucken...) Auf Dauer würde ich dir aber empfehlen, einen Symlink durch udev anlegen zu lassen, damit du nicht auf die ttyUSB Nummerierung vertrauen musst. Wenn du mehr als ein Serialdevice hast, kann die sich (am RPi) nämlich je nach Neustart ändern. (Dazu gibt's keine Anleitung von mir - aber mehr als genug quer durchs Internet verteilt...)

Mal geraten: /dev/ttyAMA0 klingt (in meiner Erinnerung) für den Raspi eher unplausibel - ist je nach Config glaube ich ein Debug Port. Evtl. kommen da Berge von anderen Daten/Müll an. Der Adapter sammelt alles auf (weil er darauf wartet ein vollständiges Telegramm oder eine Antwort auf einen Befehl zu bekommen und schreibt ruckzuck den RAM voll. Vor dem Hintergrund sollte ich mal noch ein Limit für den Puffer einbauen, das ist bisher nämlich noch nicht der Fall...
Wenn ich da richtig gereaten hätte, dann gäbe es kein Problem außer dass du den korrekten Port auswählen musst...

Und es "funkt" auf jeden Fall Ich habe hier Test-Heizkostenverteiler verschiedener Marken als Testgeräte, auf der richtigen Frequenz und im richtigen OMS WMBUS Format, einige sind AES verschlüsselt, andere nicht, aber keiner kommt an in den Objekten.

Das ist schon mal gut - aber natürlich musst du trotzdem darauf warten dass die Geräte auch tatsächlich was versenden. Gerade Heizkostenverteiler sind nicht gerade die Geräte die am häufigsten Senden... (kenne aber natürlich deine konkreten Geräte und deren Konfiguration aber nicht.)

[marsmännchen]

Ich habe scheinbar das gleiche Problem.
Ich versuchte schon lange mit dem Git-Projekt https://github.com/weetmuts/wmbusmeters
eine Verbindung mit MQTT zum IoBroker zu bekommen.
Ich hatte es schon geschafft wunderschöne Werte per Shell von Diehl zu bekommen. Jedoch habe ich es nie geschafft es per MQTT zu versenden.
Jetzt versuche ich es wieder mal mit dem wireless-mbus Adapter.
Meine Hardware:
Ein selbst gebauter CUL mit ArduinoNano mit einem TI-CC1101. Die Firmware ist die von wmbusmeters: https://weetmuts.github.io/wmbusmeterswiki/nanoCUL.html
Wenn ich dmesg:

[    6.798812] usb 1-1.3: ch341-uart converter now attached to ttyUSB0

wenn ich ls -l /dev/ttyUSB*

crw-rw---- 1 root dialout 188, 0  6. Apr 19:41 /dev/ttyUSB0

Aber leider habe ich mit der Konfiguration:

Die Fehlermeldung:

wireless-mbus.0
2022-04-06 20:09:23.651	error	CUL: Error setting wMBus mode: Timeout waiting for response

wireless-mbus.0
2022-04-06 20:09:23.650	error	CUL: Message response timeout

wireless-mbus.0
2022-04-06 20:09:20.732	debug	connected set to true

wireless-mbus.0
2022-04-06 20:09:20.690	debug	connected set to true

wireless-mbus.0
2022-04-06 20:09:20.640	debug	Created device of type: CUL (untested)

wireless-mbus.0
2022-04-06 20:09:20.561	info	starting. Version 0.7.8 (non-npm: lvogt/ioBroker.wireless-mbus#ece83640b64ef90971e96e03b229f236dd2d2b0a) in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v14.19.0, js-controller: 4.0.19

Muss man etwas in Raspi-Config für den Adapter ändern?

Oder ist das ein Problem der Firmware?
Vielleicht hat jemand einen Tipp wie ich da weitermachen kann.
Gruß
Patrick

[lvogt]

@marsmännchen
Wenn du die Firmware verwendet hast, die du verlinkst, dann musst du 38400 als Baudrate verwenden.

[hg6806]

Leider bekomme ich noch immer keine Daten.
NanoCUL iPerl Wasserzähler.

Ich habe parallel wmbusmeters erfolgreich laufen und dies vorher per

 sudo systemctl stop wmbusmeters.service

 sudo systemctl stop wmbusmeters

gestoppt. Müsste doch ausreichen, oder?

Nach dem Starten sieht es auch gut aus:

wireless-mbus.0
2022-04-07 11:33:27.659	debug	connected set to true

wireless-mbus.0
2022-04-07 11:33:27.656	debug	connected set to true

wireless-mbus.0
2022-04-07 11:33:27.580	debug	CUL: Receiver set to T-MODE and data reporting with RSSI

wireless-mbus.0
2022-04-07 11:33:27.555	debug	Created device of type: CUL (untested)

wireless-mbus.0
2022-04-07 11:33:27.402	info	starting. Version 0.7.8 in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v14.19.1, js-controller: 4.0.21

wireless-mbus.0
2022-04-07 11:33:26.164	debug	States connected to redis: 127.0.0.1:9000

wireless-mbus.0
2022-04-07 11:33:26.028	debug	States create User PubSub Client

wireless-mbus.0
2022-04-07 11:33:26.026	debug	States create System PubSub Client

wireless-mbus.0
2022-04-07 11:33:25.948	debug	Redis States: Use Redis connection: 127.0.0.1:9000

wireless-mbus.0
2022-04-07 11:33:25.796	debug	Objects connected to redis: 127.0.0.1:9001

wireless-mbus.0
2022-04-07 11:33:25.778	debug	Objects client initialize lua scripts

wireless-mbus.0
2022-04-07 11:33:25.392	debug	Objects create User PubSub Client

wireless-mbus.0
2022-04-07 11:33:25.389	debug	Objects create System PubSub Client

wireless-mbus.0
2022-04-07 11:33:25.327	debug	Objects client ready ... initialize now

wireless-mbus.0
2022-04-07 11:33:25.161	debug	Redis Objects: Use Redis connection: 127.0.0.1:9001

wireless-mbus.0
2022-04-07 11:33:17.472	info	Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason

wireless-mbus.0
2022-04-07 11:33:17.470	info	terminating

wireless-mbus.0
2022-04-07 11:33:17.467	info	Got terminate signal TERMINATE_YOURSELF

Aber es kommen einfach keine Daten. Da müssten alle 1-3h Daten kommen.

Ich habe folgende Firmware geflashed:
https://github.com/smarthomeagentur/culfw1/releases/tag/180dcb5

Datenpunkte werden angelegt, connected is auch:

Hier sind die Settings:

Als "Geräte Adresse" habe ich die ID eingetragen. Ist das überhaupt richtig?

[Michi_Pi]

@hg6806 verwende mal eine andere baudrate, ich musste die 57600 einstellen.