Test Adapter wireless-mbus v0.10.x
-
@lvogt
Und hier nochmal der gleiche log erweitert um einen Neustart im CA-Mode
230808 Log wMBus WMZ CB+CA-Mode.txt -
@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...) -
@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? -
@lvogt
Bin am Testen -
@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.
-
@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 -
@lvogt
Es sind natürlich nur Hex-Werte zulässig. Ein Test mit Buchstabe O killed den Adapter, musste ihn neu installieren -
@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?? -
@nord
Ja ich denke ich muss mir das dann nochmal im Detail anschauen. Dazu komme ich aber frühestens am Wochenende. -
@lvogt
Danke, das wäre super.
Brauchst Du noch weitere Daten/Logs? -
@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.)
-
@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? -
@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. -
@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 -
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.
-
@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: CULhabe mir jetzt aber nochmal einen anderen Adapter von Schlauhaus bestellt
-
@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
2f2fbeginnen. (Das wird auch vom Adapter geprüft) -
@lvogt ok danke
dann werde ich erstmal die Kontrolle des AES-Key erbetteln
was ich habe, habe ich schon 3x kontrolliert bzw. neu eingegeben -
@pille0557
Um was für ein genaues Modell handelt es sich denn? Die (online verfügbaren) Datenblätter sind ja auch manchmal hilfreich.... -
@lvogt said in Test Adapter wireless-mbus v0.9.x:
@pille0557
Um was für ein genaues Modell handelt es sich denn? Die (online verfügbaren) Datenblätter sind ja auch manchmal hilfreich....von Amazon
nanoCUL USB Stick FTDI CC1101 868MHz
Hersteller : smart-home-komponente ?
ASIN : B0BG3JD6FV
