Wartung am 15.11. – Forum ab 22:00 Uhr nicht erreichbar

[lvogt]

Hallo zusammen

ich habe vorhin v0.9.0 des Adapters auf npm publiziert. Die einzige Neuerung ist, dass man nun auch USB Sticks deren serielle Schnittstelle per TCP Socket im Netzwerk erreichbar ist, verwenden kann.

Dazu muss in der Konfiguration die Benutzerdefinierte Schnittstelle ausgewählt werden und dann die Adresse in Form von tcp://host:port eingegeben werden.

[Nord]

@lvogt
Hallo Forum,
ich versuche momentan, einen Wärmemengenzähler in den ioBroker einzubinden:
Typ: Allmess UltraMaxx mit wMBusmodul EquaScan hMIU RF V2; AES bekannt
Empfänger: IM871A-USB an Raspi4
ioBroker Node.js v18.17.0 npm 9.6.7 mit Wireless M-Bus-Adapter v0.9.1
Der WMZ sendet alle 5min ein CB-Telegramm,das erfolgreich entschlüsselt wird.
RAW-Daten werden angezeigt, da "...if parser failed" Beispiel:
444497260501122300047a130030a5cee4d5236ac1f055df19d551906e82b9497b731b5e59a694
cdbd4e3cab34f57fb18c5fc40d03b73fe757265f1e473a170c7947573822
Dann geht es nicht weiter, im Log kommen Fehlermeldungen:
CRC for frame type B block 1+2 failed! calc: 274d read: 3822
CRC for frame type B block 1+2 failed! calc: d2c7 read: 3822 usw.
Da ich kein IT-Fachmann bin: Gibt es Abhilfe?
VG Nord

[lvogt]

@nord
Hi, ich habe gerade keinen PC zur Hand, aber schon mal zwei Dinge vorne weg:

1. Mein Tipp wäre, dass du als Mode CA auswählen musst statt CB.

2. Der CRC Check kommt vor jedweglicher Verschlüsselung, d.h. ob der Schlüssel korrekt ist, ist nicht klar.

Falls der CA Mode nicht hilft müsste ich mal näher nach gucken - weiß aber nicht genau wann ich dazu Zeit habe.

[Nord]

Danke für die schnelle Antwort!
Ich hatte die anderen Modi schon getestet:

info: host.iobroker instance system.adapter.wireless-mbus.0 started with pid 149149
info: wireless-mbus.0 (149149) starting. Version 0.9.1 in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v18.17.0, js-controller: 4.0.24
info: wireless-mbus.0 (149149) IMST: Receiver set to CA-MODE
error: wireless-mbus.0 (149149) cd351bfefcb9f5d7f788f6e0aa04740ef7ede78238d30df9efbbc8624985b6833997bd72c5a067c0c75c4acc213d513d0c7947573822

info: host.iobroker instance system.adapter.wireless-mbus.0 started with pid 151210
info: wireless-mbus.0 (151210) starting. Version 0.9.1 in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v18.17.0, js-controller: 4.0.24
info: wireless-mbus.0 (151210) IMST: Receiver set to CB-MODE
error: wireless-mbus.0 (151210) CRC for frame type B block 1+2 failed! calc: 88f7 read: 3822

info: host.iobroker instance system.adapter.wireless-mbus.0 started with pid 151991
info: wireless-mbus.0 (151991) starting. Version 0.9.1 in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v18.17.0, js-controller: 4.0.24
info: wireless-mbus.0 (151991) IMST: Receiver set to T-MODE
error: wireless-mbus.0 (151991) encrypted message and no aeskey provided

(Auf S kommt gar nichts)

Der Key war im Lieferumfang des Moduls. Ich habe zuerst direkt an meiner CCU3/CuxD probiert. Dort wird der Zählertyp "Heat" erkannt und der RSSI angezeigt. Wäre das ein Indiz für die Richtigkeit des Keys?

[lvogt]

@nord
Ok, ich rate nochmal: Der T Mode wäre eigentlich korrekt. Bitte mal folgendes machen:

Adapter im T Mode starten und nach der "key missing" Fehlermeldung in die Adapter Einstellungen gehen und im AES Schlüssel Tab schauen ob ein neuer Eintrag mit "UNKNOWN" Key aufgetaucht ist.
Falls ja, bei diesem Eintrag UNKNOWN durch deinen Schlüssel ersetzen, Einstellungen speichern und gucken was passiert.

Ansonsten wäre es auch besser wenn du den Adapter auf Debug Log Ausgabe umschaltetest damit wir mehr Informationen bekommen

[Nord]

@lvogt
Sorry, mein Fehler. Die T-Mode sind Diehl-Wasserzähler, nach dem Blockieren keine Signale mehr.
Im Datenblatt des Funkmoduls steht:
Protokoll: Bidirektional EN 13757-3/-4 wireless M-BUS oder Unidirektional OMS V4
Betriebsart: C2- oder C1-Mode

[lvogt]

@nord
Dann muss vermutlich was anpassen.
Mein Tipp wäre dass dieses Issue jetzt tatsächlich aufgetaucht ist. Wie gesagt, ich bin mir nicht ganz sicher wann ich dazu komme, aber Debug Log wäre immer noch gut zu haben.

[Nord]

@lvogt
Hoffe, der Logauszug (nach Neustart der Instanz) pass so. Sonst bitte Anweisung.
230808 Log wMBus WMZ CB-Mode.txt

[Nord]

@lvogt
Und hier nochmal der gleiche log erweitert um einen Neustart im CA-Mode
230808 Log wMBus WMZ CB+CA-Mode.txt

[lvogt]

@nord
Hm... okay, das Log sagt, dass der Stick auch empfängt wenn man den CA Mode auswählt - damit lässt sich ein Bug im eigentlich Telegram Parser umschiffen. (s.u.)
Das Log dazu sieht für mich als erstes mal danach aus, dass der Key vl. doch nicht korrekt, ist?

Ich habe gerade aber auch v0.9.2 (aktuell nur bei GitHub noch nicht auf npm) veröffentlicht. Die Version sollte jetzt auch bei Auswahl des CB-Mode grundsätzlich funktionieren.
(Ich glaube aber weiterhin, dass sich ein kleiner Fehler in deinem AES Schlüssel eingeschlichen hat...)

[Nord]

@lvogt
Da muss ich passen. Ich habe das Modul über Internet bestellt und lt. Lieferschein direkt von Allmess samt Key geliefert bekommen. Da gehe ich erstmal davon aus, dass der stimmt. Wenn dem nicht so wäre, wie kann CuxD Typ/RSSI extrahieren? Oder werden die anders übermittelt, sozusagen außerhalb des verschlüsselten Telegramms?

[Nord]

@lvogt
Bin am Testen

[lvogt]

@nord
Ja der Teil ist unverschlüsselt.

Ich meinte eher auch, dass du vl ein Zeichen falsch angetippt hast oä.

Falls der Key 100%ig stimmt kann ich nochmal gucken was da los ist.

[Nord]

@lvogt
kein CRC-Fehler mehr
230808 Log wMBus WMZ CB+CA-Mode v0.9.2.txt
Ist der Buchstabe "O" in Key zulässig? Verwechslungsgefahr mit Zahl "0" beim Ablesen vom Lieferschein, glaube ich aber nicht.
Scannen0088.pdf

[Nord]

@lvogt
Es sind natürlich nur Hex-Werte zulässig. Ein Test mit Buchstabe O killed den Adapter, musste ihn neu installieren

[Nord]

@lvogt
Ich habe jetzt mehrfach geprüft, ob ich den Key richtig abgeschrieben habe. Entweder ich mache dabei jedes Mal einen Fehler oder der Key gehört nicht zu meinem Zähler. Beides möglich, aber imho unwahrscheinlich. Bleibt der Parser??

[lvogt]

@nord
Ja ich denke ich muss mir das dann nochmal im Detail anschauen. Dazu komme ich aber frühestens am Wochenende.

[Nord]

@lvogt
Danke, das wäre super.
Brauchst Du noch weitere Daten/Logs?

[lvogt]

@nord
Neuer Tipp
Dein Modul sendet in "EquaScan V2" Modus:

Ich muss zugeben, dass ich eigentlich erwarten würde, dass der "EquaScan V2" Modus auch wenigstens etwas besser vom Adapter "verstanden" werden müsste, aber ich vermute dass es sich im Grunde hier um ein proprietäres Protokoll handelt.

Wenn du es schaffst den Modus auf OMS zu wechseln, sollte der Adapter damit was anfangen können.

(Noch als Kommentar zum Stand jetzt: Ich habe mir aus deinem Log oben 3 aufeinander folgende Telegramme angeschaut - die Daten nach dem Entschlüsseln sehen nicht annäherungsweise ähnlich aus, was mich glauben lässt, dass hier irgendeine grundsätzliche Abweichung von der OMS Spezifikation vorliegt. "Falsches Entschlüsseln" halte ich auch für nahezu unmöglich, da hier Standardbibliotheken zum Einsatzen kommen und es damit auch noch nie Probleme gab.)

[Nord]

@lvogt
Da ich momentan nur im Adapter quasi empfängerseitig auf CA (=unidirektional?) umstellen kann, hat das keinen Einfluss auf den Sender. In der Hoffnung, dass ein speziell bestelltes OMS-Modul kein proprietäres Protokoll verwendet, müsste ich mal mit dem Kundendienst reden. Evtl. könnte auch das vorhandene Modul mit einem neuen Key versehen werden können?