NEWS
Test Adapter wireless-mbus v0.10.x
-
@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 ProblemMan 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
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 ProblemMan 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
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...
)
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 ... -
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...
)
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 ...@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?
-
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
-
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...
)
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 ...@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? -
@gizmodlx
Kannst du mir sagen welche Baudrate du beim dem Imst Stick benutzt?@marsmännchen said in Test Adapter wireless-mbus v0.7.x:
2022-04-16 08:40:32.019 error Unsupported CI Field a2, remaining payload is 211a00136d7417074c0dcb9661a3ab
Die Kommunikation mit dem Stick war hier völlig ok. Der PRIOS Decoder versteht das Telegramm aber nicht. Vermutlich kann ich das implementieren (da wbusmeters es ja vermutlich kann). Könnte aber was dauern.
Meine Bitte um Logs ist schon ins Rollen gekommen
Schon mal vielen Dank.- CUL 1/2
- IMST 1/2
- Amber 0/2
- Embit 0/2 (hier bin ich mir nicht sicher ob das hier im Forum tatsächlich jemand verwendet...)
Ich hab den "Zwischenstand" mal im ersten Post ergänzt.
-
@marsmännchen said in Test Adapter wireless-mbus v0.7.x:
2022-04-16 08:40:32.019 error Unsupported CI Field a2, remaining payload is 211a00136d7417074c0dcb9661a3ab
Die Kommunikation mit dem Stick war hier völlig ok. Der PRIOS Decoder versteht das Telegramm aber nicht. Vermutlich kann ich das implementieren (da wbusmeters es ja vermutlich kann). Könnte aber was dauern.
Meine Bitte um Logs ist schon ins Rollen gekommen
Schon mal vielen Dank.- CUL 1/2
- IMST 1/2
- Amber 0/2
- Embit 0/2 (hier bin ich mir nicht sicher ob das hier im Forum tatsächlich jemand verwendet...)
Ich hab den "Zwischenstand" mal im ersten Post ergänzt.
@lvogt
Danke, das wäre super. Das Log von mir mit deiner neuen Version wird dir in meinem Fall nicht helfen denk ich. -
@gizmodlx
Kannst du mir sagen welche Baudrate du beim dem Imst Stick benutzt?@marsmännchen said in Test Adapter wireless-mbus v0.7.x:
@gizmodlx
Kannst du mir sagen welche Baudrate du beim dem Imst Stick benutzt?57600
-
@marsmännchen said in Test Adapter wireless-mbus v0.7.x:
@gizmodlx
Kannst du mir sagen welche Baudrate du beim dem Imst Stick benutzt?57600
-
@ivogt Nach der Installation von der Beta 0.7.9 hab ich im Log jetzt die folgenden Meldungen:
Die Datenpunkte werden offenbar nicht mehr automatisch vom Adapter angelegt.
Kann man das irgendwie fixen?@gizmodlx
Evtl reicht ein Adapter Neustart. Evtl ist die Ursache dass das Gerät ein verändertes Telegramm gesendet hat. Damit kann der Adapter nämlich nicht wirklich umgehen.(Also verändert im Sinne der Struktur - geänderte Zahlenwerte sind natürlich ok
) -
@gizmodlx
Evtl reicht ein Adapter Neustart. Evtl ist die Ursache dass das Gerät ein verändertes Telegramm gesendet hat. Damit kann der Adapter nämlich nicht wirklich umgehen.(Also verändert im Sinne der Struktur - geänderte Zahlenwerte sind natürlich ok
)@lvogt said in Test Adapter wireless-mbus v0.7.x:
@gizmodlx
Evtl reicht ein Adapter Neustart. Evtl ist die Ursache dass das Gerät ein verändertes Telegramm gesendet hat. Damit kann der Adapter nämlich nicht wirklich umgehen.(Also verändert im Sinne der Struktur - geänderte Zahlenwerte sind natürlich ok
)Leider hilft weder ein Adapter-Neustart, noch ein Reboot, noch eine Neuinstallation
Update: Nachdem ich den Objektbaum komplett gelöscht und den Adapter neu installiert habe, wurden die Einträge wieder erzeugt.
-
@lvogt said in Test Adapter wireless-mbus v0.7.x:
@gizmodlx
Evtl reicht ein Adapter Neustart. Evtl ist die Ursache dass das Gerät ein verändertes Telegramm gesendet hat. Damit kann der Adapter nämlich nicht wirklich umgehen.(Also verändert im Sinne der Struktur - geänderte Zahlenwerte sind natürlich ok
)Leider hilft weder ein Adapter-Neustart, noch ein Reboot, noch eine NeuinstallationUpdate: Nachdem ich den Objektbaum komplett gelöscht und den Adapter neu installiert habe, wurden die Einträge wieder erzeugt.
-
@gizmodlx
Das wäre gerade noch mein nächster Vorschlag gewesen. An v 0.7.9 kann das eigentlich nicht gelegen haben. Aber das Log, dass du mir geschickt hast, zeigt zumindest teilweise den Tathergang. Das werde ich mir bei Gelegenheit näher anschauen.@gizmodlx
Ich habe mal durch das Log geguckt. Darin sind ein paar (unter anderem deiner) Quandis Zähler zu finden. Interessanterweise senden die alle zwei unterschiedliche Telegramme. Eins was nur aus viel "Manufacturer specific" Daten und einem Zeitstempel besteht. Und eins mit "sinnvollen" Daten.Wie ich oben schon sagte, kann der Adapter nicht damit umgehen, wenn sich die Datenpunkte in einem Telegramm ändern. Als Grundlage nimmt er immer das erste Telegramm, das er nach einem (Neu)Start empfängt. Du hattest dann nach dem Neustart einfach "Pech" und hast als erstes das Telegramm mit dem Hersteller-spezifischen Krempel empfangen.
Wie man so eine Situation im Adapter "ordentlich" handhabt ist eine gute Frage... Der "workaround" im Moment wäre halt Adapter neustarten und auf das passenden Telegramm als erstes hoffen (und evtl. die unbrauchbaren Datenpunkte im Objektbaum löschen).
-
@gizmodlx
Ich habe mal durch das Log geguckt. Darin sind ein paar (unter anderem deiner) Quandis Zähler zu finden. Interessanterweise senden die alle zwei unterschiedliche Telegramme. Eins was nur aus viel "Manufacturer specific" Daten und einem Zeitstempel besteht. Und eins mit "sinnvollen" Daten.Wie ich oben schon sagte, kann der Adapter nicht damit umgehen, wenn sich die Datenpunkte in einem Telegramm ändern. Als Grundlage nimmt er immer das erste Telegramm, das er nach einem (Neu)Start empfängt. Du hattest dann nach dem Neustart einfach "Pech" und hast als erstes das Telegramm mit dem Hersteller-spezifischen Krempel empfangen.
Wie man so eine Situation im Adapter "ordentlich" handhabt ist eine gute Frage... Der "workaround" im Moment wäre halt Adapter neustarten und auf das passenden Telegramm als erstes hoffen (und evtl. die unbrauchbaren Datenpunkte im Objektbaum löschen).
@lvogt
Ahhh...das erklärt es in der Tat Hatte mich schon gewundert, was der eigentliche Auslöser dafür war. Denn ich hatte eigentlich nichts im Objektbaum verändert.Derzeit bekomme ich immer wieder folgende Logeinträge...
error invalid date: 65535
warn State "wireless-mbus.0.QDS-51000006.data.5-0-VIF_TYPE_MANUFACTURER_UNKOWN" has no existing object, this might lead to an error in future versions
warn State "wireless-mbus.0.QDS-51000006.data.4-0-VIF_RES_E01111xx" has no existing object, this might lead to an error in future versions
warn State "wireless-mbus.0.QDS-51000006.data.3-0-VIF_TIME_POINT_DATE_TIME" has no existing object, this might lead to an error in future versions
warn State "wireless-mbus.0.QDS-51000006.data.2-0-VIF_MODEL_VERSION" has no existing object, this might lead to an error in future versions
warn State "wireless-mbus.0.QDS-51000006.data.1-0-VIF_TIME_POINT_DATE_TIME" has no existing object, this might lead to an error in future versions -
@gizmodlx
Ich habe mal durch das Log geguckt. Darin sind ein paar (unter anderem deiner) Quandis Zähler zu finden. Interessanterweise senden die alle zwei unterschiedliche Telegramme. Eins was nur aus viel "Manufacturer specific" Daten und einem Zeitstempel besteht. Und eins mit "sinnvollen" Daten.Wie ich oben schon sagte, kann der Adapter nicht damit umgehen, wenn sich die Datenpunkte in einem Telegramm ändern. Als Grundlage nimmt er immer das erste Telegramm, das er nach einem (Neu)Start empfängt. Du hattest dann nach dem Neustart einfach "Pech" und hast als erstes das Telegramm mit dem Hersteller-spezifischen Krempel empfangen.
Wie man so eine Situation im Adapter "ordentlich" handhabt ist eine gute Frage... Der "workaround" im Moment wäre halt Adapter neustarten und auf das passenden Telegramm als erstes hoffen (und evtl. die unbrauchbaren Datenpunkte im Objektbaum löschen).
Ich versuche die Daten nun über SourceAnalytix auszuwerten. Dabei tritt folgender Fehler in SourceAnalytix auf:
Input value for wireless-mbus.0.QDS-50000007.data.1-0-VIF_VOLUME, type = string but should be a number, cannot handle calculation
Man kann das wohl über sog. Alias-Datenpunkte lösen. Aber wäre es nicht sinnvoll den Datenpunkt grundsätzlich als Zahl zu führen?
-
Vielen Dank für die Hilfe, ich hab das schon abgebrochen, und wmbusmeters deinstalliert. Ich warte jetzt erst mal auf :
"eQ3 INNOGY RWE SmartHome USB Empfangseinheit Stromzähler Empfangs Einheit iM871A"
Wenn's damit nicht geht bau ich mir einen Durchflussmesser in die Leitung der in die Wago PFC200 geht. Damit geht's dann sicher. Die Konstellation vom Smartmeter Adapter - Landis+Gyr E450 - Hichi USB Lesekopf hat auch nie funktioniert, musste dann auch auf Eigenbau umsteigen.
Aber mal abwarten ob das mit dem iM871A was bringt.
Danke trotzdem: @marsmännchen said in Test Adapter wireless-mbus v0.7.x:
Landis+Gyr E450 - Hichi USB Lesekopf hat auch nie funktioniert, musste dann auch auf Eigenbau umsteigen.
Wie hast du das denn genau lösen können?
Mit welcher Baudrate Start/Stop-Bit und Parität sendet der Zähler denn eigentlich standardmäßig?
Support us
533
Online32.4k
Users81.4k
Topics1.3m
Posts