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

[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?

[Nord]

@lvogt
Habe mit dem Kundendienst von Allmess gesprochen und eine mögliche Lösung für das Wechseln auf OMS in Arbeit. Ich werde berichten.

[Nord]

@lvogt
Allmess liefert ab Werk die RF-Module im EquaScan V2-Modus (EN 13757), damit kommt der Parser vermutlich nicht klar. Für das Umprogrammieren in den OMS-Funkbetriebsmodus braucht man den induktiven Kopf (habe ich gekauft) und die EquaScan-Software (Allmess hat freundlicherweise und unkompliziert eine zeitlich befristete Testlizenz zur Verfügung gestellt). Damit kann man auf OMS umschalten, der Adapter arbeitet sofort, sowohl im CA- als auch im CB-Mode. Es werden folgende Objekte angelegt

Es gibt leider keine Ausgabe von Momentanwerten (Vor-/Rücklauftemperatur, Leistung, Volumenstrom), die sind nur am WMZ-Display ablesbar. Das scheint auch bei anderen Herstellern (z.B. Kamstrup) so zu sein.
Mir ist aufgefallen, dass bei der Einstellung "Energieeinheiten auf kWh setzen" zwar 3 Dezimalstellen gekürzt werden, die Maßeinheit aber bei "Wh"bleibt. Kann man aber im zugehörigen Script ändern.
Hier noch der Log:
log_Allmess_OMS.txt
Viele Grüße
Nord

[lvogt]

@nord

Mir ist aufgefallen, dass bei der Einstellung "Energieeinheiten auf kWh setzen" zwar 3 Dezimalstellen gekürzt werden, die Maßeinheit aber bei "Wh"bleibt. Kann man aber im zugehörigen Script ändern.

Das ist ein bekanntes Problem. Wenn ein State existiert wird er nicht neu angelegt, sondern nur sein Wert upgedatet. Die Einheit bleibt also unverändert. Da der State ohne diese Option angelegt wurde, wurde die Einheit auf Wh gesetzt.

Um das zu korrigieren, könntest du also zb den ITR-xxxxxx Objektbaum löschen und den Adpater neustarten, dann sollte die Einheit auch in kWh gesetzt werden, oder du könntest direkt den State bearbeiten.

[pille0557]

@felidsche so bin jetzt erst zu weiteren Tests gekommen
es geht immer noch um den iPerl ...

hatte jetzt erstmals diese Meldung:

wireless-mbus.0
2023-08-28 16:27:52.677	debug	Parser failed to parse telegram from device SEN-21779609

wireless-mbus.0
2023-08-28 16:27:52.676	error	5807ebda7b5abcfc234349f544277c10

wireless-mbus.0
2023-08-28 16:27:52.674	debug	decrypted payload 5807ebda7b5abcfc234349f544277c10

wireless-mbus.0
2023-08-28 16:27:52.670	debug	IV: ae4c0996772168073636363636363636

wireless-mbus.0
2023-08-28 16:27:52.667	debug	encrypted payload: d868635fe9ba42e9a55824bbe0780650

wireless-mbus.0
2023-08-28 16:27:52.665	debug	Short header

wireless-mbus.0
2023-08-28 16:27:52.657	debug	1e44ae4c099677216807488d7a36001005d868635fe9ba42e9a55824378bbbe078065000b580

wireless-mbus.0
2023-08-28 16:27:52.655	debug	Found AES key: 3B6DB3EF29F75878A1B8F379C493EB08

wireless-mbus.0
2023-08-28 16:27:52.650	debug	CUL: Message received: 1e44ae4c099677216807488d7a36001005d868635fe9ba42e9a55824378bbbe078065000b58040

wireless-mbus.0
2023-08-28 16:27:52.648	debug	CUL: RX: 303130303544383638363335464539424134324539413535383234333738424242453037383036353030304235383034300d0a

wireless-mbus.0
2023-08-28 16:27:52.632	debug	CUL: RX: 623145343441453443303939363737323136383037343838443741333630

wireless-mbus.0
2023-08-28 16:26:49.354	debug	connected set to true

wireless-mbus.0
2023-08-28 16:26:49.300	info	CUL: Receiver set to T-MODE and data reporting with RSSI

wireless-mbus.0
2023-08-28 16:26:49.297	debug	CUL: RX: 544d4f44450d0a

wireless-mbus.0
2023-08-28 16:26:49.270	debug	CUL: TX: 5832310d0a6272740d0a

wireless-mbus.0
2023-08-28 16:26:49.266	info	CUL: Error getting CUL version: Timeout waiting for response

wireless-mbus.0
2023-08-28 16:26:46.273	debug	connected set to false

wireless-mbus.0
2023-08-28 16:26:46.256	debug	CUL: TX: 560d0a

wireless-mbus.0
2023-08-28 16:26:46.251	debug	Created device of type: CUL

habe mir jetzt aber nochmal einen anderen Adapter von Schlauhaus bestellt

[lvogt]

@pille0557 said in Test Adapter wireless-mbus v0.9.x:

1e44ae4c099677216807488d7a36001005d868635fe9ba42e9a55824378bbbe078065000b58040

Ich sehe 2 Möglichkeiten: Der AES Key stimmt nicht - oder der iPerl sendet ebenfalls keine OMS kompatiblen Daten. Vl. mal als Anhaltspunkt: Bei dem Verschlüsselungsmodus den der Header angibt, müssten die entschlüsselten Daten mit 2f2f beginnen. (Das wird auch vom Adapter geprüft)