Test Adapter wireless-mbus v0.10.x
-
@thomas-braun said in Test Adapter wireless-mbus v0.7.x:
@gizmodlx Was ist denn konkret dein Problem?
Nun ich würde den Stick gerne ebenfalls in Verbindung mit dem Adapter nutzen. Es ist ein Stick von RWE, der den gleichen Chip (iMST iM871A) hat, aber eine andere ProductID (87ED). Und ich bin etwas "lost" wie ich diesen Stick nun mit Treibern versorgen kann.
Unter welchem Device Link findet sich der Stick denn?
Siehels -l /dev/serial/by-idda erhalte ich nur folgende Fehlermeldung:
ls: Zugriff auf '/dev/serial/by-id' nicht möglich: Datei oder Verzeichnis nicht gefundenGruppenzugehörigkeiten i.O.?
Kannst du das etwas ausführlicher erklären?
sudo -u iobroker groups iobroker tty dialout audio video bluetooth gpio i2c@gizmodlx sagte in Test Adapter wireless-mbus v0.7.x:
Und ich bin etwas "lost" wie ich diesen Stick nun mit Treibern versorgen kann.
Die Treiber sind im Linux-Kernel enthalten. Die Erkennung erfolgt i. d. R. über die ProductID bei USB-Geräten. Kann sein, das dein Stick da etwas exotisch ist. Wenn du Glück hast kann man die Erkennung aber etwas 'zurecht biegen'. Das ist aber wohl eher was für einen eigenen Thread.
-
@thomas-braun said in Test Adapter wireless-mbus v0.7.x:
@gizmodlx Was ist denn konkret dein Problem?
Nun ich würde den Stick gerne ebenfalls in Verbindung mit dem Adapter nutzen. Es ist ein Stick von RWE, der den gleichen Chip (iMST iM871A) hat, aber eine andere ProductID (87ED). Und ich bin etwas "lost" wie ich diesen Stick nun mit Treibern versorgen kann.
Unter welchem Device Link findet sich der Stick denn?
Siehels -l /dev/serial/by-idda erhalte ich nur folgende Fehlermeldung:
ls: Zugriff auf '/dev/serial/by-id' nicht möglich: Datei oder Verzeichnis nicht gefundenGruppenzugehörigkeiten i.O.?
Kannst du das etwas ausführlicher erklären?
sudo -u iobroker groups iobroker tty dialout audio video bluetooth gpio i2c -
Bei mir exakt das gleiche wie bei @gizmodlx . Gleiche Ausgaben in der Konsole.
lsusb -t -
lsusb -t[694216.283345] usb 1-1.3: USB disconnect, device number 5 [694222.324999] device eth0 entered promiscuous mode [694228.253947] device eth0 left promiscuous mode [694252.331385] device eth0 entered promiscuous mode [694257.892408] usb 1-1.1: new full-speed USB device number 6 using xhci_hcd [694258.000219] usb 1-1.1: New USB device found, idVendor=10c4, idProduct=87ed, bcdDevice= 1.00 [694258.000239] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [694258.000253] usb 1-1.1: Product: IMST USB-Stick for Smart Meter [694258.000266] usb 1-1.1: Manufacturer: Silicon Labs [694258.000278] usb 1-1.1: SerialNumber: 005FD795 [694258.243526] device eth0 left promiscuous mode [694282.322992] device eth0 entered promiscuous modelsusb -t /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 1: Dev 6, If 0, Class=Vendor Specific Class, Driver=, 12MRaspberry Pi 4 8GB, Debian 11, js-controller: 5.0.12, Nodejs: v18.18.2, NPM: 9.8.1 (Multihost),
Wago PFC200 mit Dali Lichtsteuerung. -
[694216.283345] usb 1-1.3: USB disconnect, device number 5 [694222.324999] device eth0 entered promiscuous mode [694228.253947] device eth0 left promiscuous mode [694252.331385] device eth0 entered promiscuous mode [694257.892408] usb 1-1.1: new full-speed USB device number 6 using xhci_hcd [694258.000219] usb 1-1.1: New USB device found, idVendor=10c4, idProduct=87ed, bcdDevice= 1.00 [694258.000239] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [694258.000253] usb 1-1.1: Product: IMST USB-Stick for Smart Meter [694258.000266] usb 1-1.1: Manufacturer: Silicon Labs [694258.000278] usb 1-1.1: SerialNumber: 005FD795 [694258.243526] device eth0 left promiscuous mode [694282.322992] device eth0 entered promiscuous modelsusb -t /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 1: Dev 6, If 0, Class=Vendor Specific Class, Driver=, 12M -
lsusb && lsusb -t Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 006: ID 10c4:87ed Silicon Labs IMST USB-Stick for Smart Meter Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 1: Dev 6, If 0, Class=Vendor Specific Class, Driver=, 12M -
lsusb && lsusb -t Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 006: ID 10c4:87ed Silicon Labs IMST USB-Stick for Smart Meter Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 1: Dev 6, If 0, Class=Vendor Specific Class, Driver=, 12MKann man den irgendwie nachinstallieren, oder stelle ich mir das zu einfach vor?
Raspberry Pi 4 8GB, Debian 11, js-controller: 5.0.12, Nodejs: v18.18.2, NPM: 9.8.1 (Multihost),
Wago PFC200 mit Dali Lichtsteuerung. -
Kann man den irgendwie nachinstallieren, oder stelle ich mir das zu einfach vor?
@marsmännchen sagte in Test Adapter wireless-mbus v0.7.x:
Kann man den irgendwie nachinstallieren, oder stelle ich mir das zu einfach vor?
Wenn du entsprechenden Code findest...
-
@marsmännchen sagte in Test Adapter wireless-mbus v0.7.x:
Kann man den irgendwie nachinstallieren, oder stelle ich mir das zu einfach vor?
Wenn du entsprechenden Code findest...
@thomas-braun
Ok, wohl eher nicht. Danke trotzdemRaspberry Pi 4 8GB, Debian 11, js-controller: 5.0.12, Nodejs: v18.18.2, NPM: 9.8.1 (Multihost),
Wago PFC200 mit Dali Lichtsteuerung. -
@thomas-braun
Ok, wohl eher nicht. Danke trotzdemHier scheint es was zu geben. Aber nicht freizugänglich.
https://www.silabs.com/developers/usb-to-uart-bridge-vcp-drivers
-
Hier scheint es was zu geben. Aber nicht freizugänglich.
https://www.silabs.com/developers/usb-to-uart-bridge-vcp-drivers
@thomas-braun
Hatte ich natürlich nicht gefunden auf SiliconLabs.
Ich werde mal versuchen wie weit ich damit komme.danke sehr. -
@thomas-braun
Hatte ich natürlich nicht gefunden auf SiliconLabs.
Ich werde mal versuchen wie weit ich damit komme.danke sehr.sudo modprobe cp210x sudo bash -c "echo 10c4 87ed > /sys/bus/usb-serial/drivers/cp210x/new_id"oder so änhlich. Danach bitte
dmesgum zu gucken ob ein/dev/ttyUSBndevice angelegt wurde. -
@thomas-braun
Hatte ich natürlich nicht gefunden auf SiliconLabs.
Ich werde mal versuchen wie weit ich damit komme.danke sehr.@Ivogt oh...du hattest die gleiche Lösung. Warst etwas schneller :-)
@marsmännchen ich hab die Lösung für unser Problem :-)Man muss die PID für den Treiber anpassen. Und dafür gibt es eine ziemlich elegante Lösung:
$ sudo modprobe cp210x $ sudo sh -c 'echo 10c4 87ed > /sys/bus/usb-serial/drivers/cp210x/new_id'Durch diesen Befehl wird dem Treiber (cp210x) mitgeteilt, dass er auch unter der Kombination VID 10c4 / PID 87ed einen Stick suchen soll. Ein Aufruf von dmseg zeigt dann auch den erkannten Stick:
cp210x 1-1.4:1.0: cp210x converter detected usb 1-1.4: cp210x converter now attached to ttyUSB0Hinterlegt man dann im Adapter die richtige Konfiguration, werden Werte ausgelesen und angezeigt :clap:
Ich muss noch ergänzen, dass ich zuvor die neuste Firmware von iMST auf den Stick geflasht hatte. Keine Ahnung ob das zwingend nötig gewesen wäre - vermute nein.Eine Sache bleibt allerdings noch offen. Diese Änderung greift nur bis zum nächsten Boot. Man müsste sie daher in ein Bootskript aufnehmen um sie dauerhaft zu aktivieren. Es scheint auch eine Lösung zu geben, mit der man die PID dauerhaft schreiben kann. Da muss ich aber nochmal genauer schauen. Denn setzt man sie falsch, ist der Stick wohl hin.
-
@Ivogt oh...du hattest die gleiche Lösung. Warst etwas schneller :-)
@marsmännchen ich hab die Lösung für unser Problem :-)Man muss die PID für den Treiber anpassen. Und dafür gibt es eine ziemlich elegante Lösung:
$ sudo modprobe cp210x $ sudo sh -c 'echo 10c4 87ed > /sys/bus/usb-serial/drivers/cp210x/new_id'Durch diesen Befehl wird dem Treiber (cp210x) mitgeteilt, dass er auch unter der Kombination VID 10c4 / PID 87ed einen Stick suchen soll. Ein Aufruf von dmseg zeigt dann auch den erkannten Stick:
cp210x 1-1.4:1.0: cp210x converter detected usb 1-1.4: cp210x converter now attached to ttyUSB0Hinterlegt man dann im Adapter die richtige Konfiguration, werden Werte ausgelesen und angezeigt :clap:
Ich muss noch ergänzen, dass ich zuvor die neuste Firmware von iMST auf den Stick geflasht hatte. Keine Ahnung ob das zwingend nötig gewesen wäre - vermute nein.Eine Sache bleibt allerdings noch offen. Diese Änderung greift nur bis zum nächsten Boot. Man müsste sie daher in ein Bootskript aufnehmen um sie dauerhaft zu aktivieren. Es scheint auch eine Lösung zu geben, mit der man die PID dauerhaft schreiben kann. Da muss ich aber nochmal genauer schauen. Denn setzt man sie falsch, ist der Stick wohl hin.
Du kannst auch eine Regel für udev anlegen
(Als root bzw. mit sudo) Die Datei
/etc/udev/rules.d/99-imst.rulesanlegen und das muss rein:ACTION=="add", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="87ed", RUN+="/sbin/modprobe cp210x" RUN+="/bin/sh -c 'echo 10c4 87ed > /sys/bus/usb-serial/drivers/cp210x/new_id'"Ohne Garantie dass das so 100% korrekt ist.
EDIT: Ich hatte da ursprünglich auch einen Einzeiler stehen - aber der entfernt wohl die Anführungszeichen - dann ist udev damit glaube ich nicht mehr zufrieden.
EDIT2: Das scheint zu funktionieren:
sudo bash -c "echo \$'ACTION==\"add\", ATTRS{idVendor}==\"10c4\", ATTRS{idProduct}==\"87ed\", RUN+=\"/sbin/modprobe cp210x\" RUN+=\"/bin/sh -c \\'echo 10c4 87ed > /sys/bus/usb-serial/drivers/cp210x/new_id\\'\"' > /etc/udev/rules.d/99-imst.rules" -
Du kannst auch eine Regel für udev anlegen
(Als root bzw. mit sudo) Die Datei
/etc/udev/rules.d/99-imst.rulesanlegen und das muss rein:ACTION=="add", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="87ed", RUN+="/sbin/modprobe cp210x" RUN+="/bin/sh -c 'echo 10c4 87ed > /sys/bus/usb-serial/drivers/cp210x/new_id'"Ohne Garantie dass das so 100% korrekt ist.
EDIT: Ich hatte da ursprünglich auch einen Einzeiler stehen - aber der entfernt wohl die Anführungszeichen - dann ist udev damit glaube ich nicht mehr zufrieden.
EDIT2: Das scheint zu funktionieren:
sudo bash -c "echo \$'ACTION==\"add\", ATTRS{idVendor}==\"10c4\", ATTRS{idProduct}==\"87ed\", RUN+=\"/sbin/modprobe cp210x\" RUN+=\"/bin/sh -c \\'echo 10c4 87ed > /sys/bus/usb-serial/drivers/cp210x/new_id\\'\"' > /etc/udev/rules.d/99-imst.rules" -
Hallo zusammen,
ich habe gerade v0.7.9 auf npm publiziert. Die Version bringt nichts neues für euch - aber für mich ;)
Und zwar werden im Debug Log nun sämtliche "Nachrichten" zw. Adapter und "USB Stick" geloggt. Ich hätte gerne von den 4 unterstützten Empfängsmodulen jeweils von 1 oder 2 Nutzern das Log vom Adapterstart und wenn es geht auch noch von einem empfangenen Telegramm. Gerne als PN (oder Chat wie es hier im Forum heißt) direkt an mich.
Warum das ganze? Wie ich ja schon mal erwähnt habe, besitze ich kein einziges dieser Geräte selber. Ich möchte aber gerne mal den Code der die Kommunikation zw Adapter und USB Gerät handhabt aufräumen. (Teilweise sind da wirklich furchtbare Konstrukte drin... :see_no_evil: )
Dazu habe ich bereits angefangen Simulatoren für die Geräte zu schreiben. Um sicher zu gehen, dass ich da keine falschen Annahmen einbauen hätte ich gerne noch mal einen abgleich mit der Realität.
Gestern beim Lesen des Codes für den gerade diskutierten IMST Stick zB konnte ich mir bei einigen Teilen gar nicht vorstellen, dass es funktioniert :see_no_evil: ... -
Hallo zusammen,
ich habe gerade v0.7.9 auf npm publiziert. Die Version bringt nichts neues für euch - aber für mich ;)
Und zwar werden im Debug Log nun sämtliche "Nachrichten" zw. Adapter und "USB Stick" geloggt. Ich hätte gerne von den 4 unterstützten Empfängsmodulen jeweils von 1 oder 2 Nutzern das Log vom Adapterstart und wenn es geht auch noch von einem empfangenen Telegramm. Gerne als PN (oder Chat wie es hier im Forum heißt) direkt an mich.
Warum das ganze? Wie ich ja schon mal erwähnt habe, besitze ich kein einziges dieser Geräte selber. Ich möchte aber gerne mal den Code der die Kommunikation zw Adapter und USB Gerät handhabt aufräumen. (Teilweise sind da wirklich furchtbare Konstrukte drin... :see_no_evil: )
Dazu habe ich bereits angefangen Simulatoren für die Geräte zu schreiben. Um sicher zu gehen, dass ich da keine falschen Annahmen einbauen hätte ich gerne noch mal einen abgleich mit der Realität.
Gestern beim Lesen des Codes für den gerade diskutierten IMST Stick zB konnte ich mir bei einigen Teilen gar nicht vorstellen, dass es funktioniert :see_no_evil: ...@lvogt Super! der Stick wird erkannt.
Jetzt erwarte ich natürlich nicht das ich anstecke und Werte vom Diehl Wasserzähler bekomme.
Daher meine nächste Frage:
Bei Baudrate 57600wireless-mbus.0 2022-04-16 08:40:49.252 debug Device is blocked: DME-32270778 wireless-mbus.0 2022-04-16 08:40:47.618 debug Device is blocked: DME-32340778 wireless-mbus.0 2022-04-16 08:40:40.393 debug Device is blocked: DME-32270778 wireless-mbus.0 2022-04-16 08:40:39.399 debug Device is blocked: DME-32340778 wireless-mbus.0 2022-04-16 08:40:32.020 warn Device DME-32270778 is now blocked until adapter restart! wireless-mbus.0 2022-04-16 08:40:32.019 debug Parser failed to parse telegram from device DME-32270778 wireless-mbus.0 2022-04-16 08:40:32.019 error Unsupported CI Field a2, remaining payload is 211a00136d7417074c0dcb9661a3ab wireless-mbus.0 2022-04-16 08:40:32.019 error CI Field 162 is currently not supported by PRIOS Decoder wireless-mbus.0 2022-04-16 08:40:32.018 debug retVal CI Field 162 is currently not supported by PRIOS Decoder wireless-mbus.0 2022-04-16 08:40:32.018 debug Trying to decode using Diehl PRIOS module wireless-mbus.0 2022-04-16 08:40:32.017 debug 1944a511780727324120a2211a00136d7417074c0dcb9661a3ab wireless-mbus.0 2022-04-16 08:40:30.742 debug Device is blocked: DME-32340778 wireless-mbus.0 2022-04-16 08:40:23.868 debug Parser failed to parse telegram from device DME-32270778 wireless-mbus.0 2022-04-16 08:40:23.867 error Unsupported CI Field a2, remaining payload is 111a00136d4d66ddb16fbffc0c88ac wireless-mbus.0 2022-04-16 08:40:23.866 error CI Field 162 is currently not supported by PRIOS Decoder wireless-mbus.0 2022-04-16 08:40:23.865 debug retVal CI Field 162 is currently not supported by PRIOS Decoder wireless-mbus.0 2022-04-16 08:40:23.864 debug Trying to decode using Diehl PRIOS moduleUnd bei Baudrate 115200:
wireless-mbus.0 2022-04-16 08:47:18.385 error IMST: 7e001e86e0609e867e60809e007e7878061e78600698e0001ee0e69e98e6869860f898e0f898e09e6678e606f8f8e6e0f81e667e001e86e0609e867e60809e00607878061e7860061e1e001ee0861e669886067e001e780680789e60989e0618e6667e001e86e0609e867e60809e00607878061e786006e698e0001ee0869e009e068098fefee07e069e wireless-mbus.0 2022-04-16 08:47:18.384 error IMST: Data but no callback! wireless-mbus.0 2022-04-16 08:47:08.904 error IMST: e0609e867e60809e00607878061e786006781e001ee0861e1886f8609e7efee0e0fe98e606e0669efe00e6667e001e86e0609e867e60809e007e7878061e7860061e1e001ee0e69efe7806809e9e989ee67ee6808678fef8fe1e7e9ef8667e001e86e0609e867e60809e00607878061e786006781e001ee0869e7878e69800e09efefe866678e01e807e1e9898fe66 wireless-mbus.0 2022-04-16 08:47:08.903 error IMST: Data but no callback! wireless-mbus.0 2022-04-16 08:46:53.055 error IMST: e6807e067e9e06667e001e86 wireless-mbus.0 2022-04-16 08:46:53.053 error IMST: Data but no callback! wireless-mbus.0 2022-04-16 08:46:50.686 debug connected set to true wireless-mbus.0 2022-04-16 08:46:50.684 debug connected set to true wireless-mbus.0 2022-04-16 08:46:50.633 debug Created device of type: IMST iM871AUnd jetzt? :face_with_rolling_eyes:
-
Du kannst auch eine Regel für udev anlegen
(Als root bzw. mit sudo) Die Datei
/etc/udev/rules.d/99-imst.rulesanlegen und das muss rein:ACTION=="add", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="87ed", RUN+="/sbin/modprobe cp210x" RUN+="/bin/sh -c 'echo 10c4 87ed > /sys/bus/usb-serial/drivers/cp210x/new_id'"Ohne Garantie dass das so 100% korrekt ist.
EDIT: Ich hatte da ursprünglich auch einen Einzeiler stehen - aber der entfernt wohl die Anführungszeichen - dann ist udev damit glaube ich nicht mehr zufrieden.
EDIT2: Das scheint zu funktionieren:
sudo bash -c "echo \$'ACTION==\"add\", ATTRS{idVendor}==\"10c4\", ATTRS{idProduct}==\"87ed\", RUN+=\"/sbin/modprobe cp210x\" RUN+=\"/bin/sh -c \\'echo 10c4 87ed > /sys/bus/usb-serial/drivers/cp210x/new_id\\'\"' > /etc/udev/rules.d/99-imst.rules"@lvogt said in Test Adapter wireless-mbus v0.7.x:
EDIT2: Das scheint zu funktionieren:
sudo bash -c "echo \$'ACTION==\"add\", ATTRS{idVendor}==\"10c4\", ATTRS{idProduct}==\"87ed\", RUN+=\"/sbin/modprobe cp210x\" RUN+=\"/bin/sh -c \\'echo 10c4 87ed > /sys/bus/usb-serial/drivers/cp210x/new_id\\'\"' > /etc/udev/rules.d/99-imst.rules"So...getestet. Funktioniert und überlebt einen Reboot einwandfrei :-) :+1:
-
Hallo zusammen,
ich habe gerade v0.7.9 auf npm publiziert. Die Version bringt nichts neues für euch - aber für mich ;)
Und zwar werden im Debug Log nun sämtliche "Nachrichten" zw. Adapter und "USB Stick" geloggt. Ich hätte gerne von den 4 unterstützten Empfängsmodulen jeweils von 1 oder 2 Nutzern das Log vom Adapterstart und wenn es geht auch noch von einem empfangenen Telegramm. Gerne als PN (oder Chat wie es hier im Forum heißt) direkt an mich.
Warum das ganze? Wie ich ja schon mal erwähnt habe, besitze ich kein einziges dieser Geräte selber. Ich möchte aber gerne mal den Code der die Kommunikation zw Adapter und USB Gerät handhabt aufräumen. (Teilweise sind da wirklich furchtbare Konstrukte drin... :see_no_evil: )
Dazu habe ich bereits angefangen Simulatoren für die Geräte zu schreiben. Um sicher zu gehen, dass ich da keine falschen Annahmen einbauen hätte ich gerne noch mal einen abgleich mit der Realität.
Gestern beim Lesen des Codes für den gerade diskutierten IMST Stick zB konnte ich mir bei einigen Teilen gar nicht vorstellen, dass es funktioniert :see_no_evil: ...@lvogt said in Test Adapter wireless-mbus v0.7.x:
Hallo zusammen,
ich habe gerade v0.7.9 auf npm publiziert. Die Version bringt nichts neues für euch - aber für mich ;)
Und zwar werden im Debug Log nun sämtliche "Nachrichten" zw. Adapter und "USB Stick" geloggt. Ich hätte gerne von den 4 unterstützten Empfängsmodulen jeweils von 1 oder 2 Nutzern das Log vom Adapterstart und wenn es geht auch noch von einem empfangenen Telegramm. Gerne als PN (oder Chat wie es hier im Forum heißt) direkt an mich.
So...bin deiner Bitte nachgekommen. Mein Log kommt gleich per PN.
Es sind mehrere Telegramme zu Qundis Wasserzählern (qwater 5.5) enthalten.
Die Fehler "invalid date: 65535" dürften meiner Einschätzung nach daher rühren, dass die Wasserzähler neu sind, bisher nie ausgelesen wurden und daher noch kein aktuelles Datum haben. -
@lvogt said in Test Adapter wireless-mbus v0.7.x:
Hallo zusammen,
ich habe gerade v0.7.9 auf npm publiziert. Die Version bringt nichts neues für euch - aber für mich ;)
Und zwar werden im Debug Log nun sämtliche "Nachrichten" zw. Adapter und "USB Stick" geloggt. Ich hätte gerne von den 4 unterstützten Empfängsmodulen jeweils von 1 oder 2 Nutzern das Log vom Adapterstart und wenn es geht auch noch von einem empfangenen Telegramm. Gerne als PN (oder Chat wie es hier im Forum heißt) direkt an mich.
So...bin deiner Bitte nachgekommen. Mein Log kommt gleich per PN.
Es sind mehrere Telegramme zu Qundis Wasserzählern (qwater 5.5) enthalten.
Die Fehler "invalid date: 65535" dürften meiner Einschätzung nach daher rühren, dass die Wasserzähler neu sind, bisher nie ausgelesen wurden und daher noch kein aktuelles Datum haben.@gizmodlx
Kannst du mir sagen welche Baudrate du beim dem Imst Stick benutzt?
Support us
427
Online32.7k
Users82.5k
Topics1.3m
Posts