Wireless M-Bus für CUL

[kaihs]

Was mich wundert: Die Logfiles werden leer angelegt. Beim ersten Empfang sind doch aber auch schon Daten dabei, die ausgewertet werden müssten. Kann es sein, dass die verschlampt werden und erst ab dem zweiten Datensatz ausgewertet wird (wenn das Gerät schon existiert)?

Ich habe das noch mal analysiert. Die Daten des ersten empfangenden Pakets eine neues Devices werden schon richtig analysiert und stehen auch in den Readings.
Im Logfile sind sie noch nicht, da dieses erst nach dem Device angelegt wird. Da das alles automatisch durch die fhem Kernfunktionalität geschieht kann ich daran nicht viel machen.
Ist aber auch nicht so tragisch denke ich, die Werte sind ja in fhem  als Reading vorhanden, und ab dem nächsten Paket werden die Daten auch protokolliert.

Kai

[kaihs]

Ich musste dann noch libssl-dev nach installieren und dann konnte ich Crypt::OpenSSL::AES builden und installieren.

Danke für den Hinweis, ich werde die Dokumentation entsprechend ergänzen.

Kai

[kaihs]

In WMBus.pm war leider noch ein Bug, so dass die IdentNumber falsch dekodiert wurde.
Das habe ich gerade korrigiert.

In der Konsequenz heißt das aber, dass alle Geräte bisher falsch angelegt wurden.
Nach dem Update werden daher die bisher angelegten devices nicht mehr den dafür eintreffenden Paketen zugeordnet sondern es werden neue devices angelegt.

Empfehlung: Vor dem Update alle WMBUS Geräte inkl. Logs löschen, config speichern, update durchführen, shutdown restart

Tut mir leid falls das zu Unannehmlichkeiten führt. Aber ich denke, dass das Modul bisher noch so wenig benutzt wird, dass ich so eine inkompatible Änderung noch durchführen kann.

Gruß,

Kai 

[kossmann]

Kein Problem, ich betrachte das Modul noch als "noch im Beta-Stadium". Es wurde heute wieder alles brav angelegt.

Mir würde es jedoch wahnsinnig helfen, wenn die Auswertung der Qundis-Datensätze funktionieren würde. Gibt es hier schon etwas neues? Qundis hat mir leider (noch) nicht geantwortet. Ich kann hiermit ja mal 2 Kisten Bier als Prämie aufrufen

[kaihs]

Mir hat Qundis auch nicht geantwortet was ich als nicht besonders kundenorientiert empfinde. Irgendeine Antwort, und sei es eine ablehnende, hätte ich schon erwartet.

Aber Qundis scheint nicht der einzige Hersteller zu sein, der sein eigenes Süppchen kocht.
Ich habe hier Datensätze von Techem Zählern, bei denen ist noch nicht mal der Zählertyp in der Norm spezifiziert 

Wenn du mit deinen Zählern weiter kommen willst musst du wohl reichlich Datensätze mit den dazu gehörigen, manuell abgelesenen, Zählerständen sammeln.
Dann kann man evtl. die bisher unbekannten Daten entschlüsseln.
Es schadet dabei sicher nicht, wenn du dich selbst ein wenig in das WMBus Datenformat einarbeitest.

Kai

[kossmann]

Mir ist gerade noch aufgefallen, dass die Wärmemengenzähler der Heizung mit dem Hersteller 'lSE' angelegt werden, die Wasserzähler jedoch alle mit 'LSE'. Muss/Sollte das 'l' der Wärmemengenzähler nicht auch groß sein? Zumindest wird das kleine 'l' an gemeckert, wenn ich ein Device manuell mit diesem Hersteller anlege.

[mdewendt]

Hallo.

Ich bin heute über den Artikel gestolpert und habe gleich einen alten 433MHz CUL dafür "abgestellt". Den scheint die Verbiegug auf 868,3MHz nicht wirklich zu sören. Bekomme Werte aus allen Ecken des Hauses.
Verbaut sind hier Wärmemengenzähler und Funkerweiterungen an den Wasserzählern. Bisher sind hier einige Wärmemengenzähler aufgetaucht - als LSE. Alles von Qundis.
Ich hätte gedacht das diese am Sonntag gar nicht senden aber nach einem Blick auf die Zeit die in Fhem angezeigt wird, wundert mich nichts: 2014-8-17 00:04 und das um 13:01. Oder muss ich mir da ein PM dazudenken?
VIF_FLOW_TEMP ist interessant - da kann man sich im Sommer ja fast die Thermometer in den Räumen sparen.
Leider kommt danach ein MANUFACTURER SPECIFIC - ich werde durch manuellen Vergleich mal schauen, ob ich etwas zu den weiteren Datenfeldern beitragen kann. Verschlüsselung scheint hier zu viel Arbeit zu machen und ist abgestellt?! is_encrypted 0


Martin

[kossmann]

Kai, könntest du den WMBus-Devices ggf. noch das Attribut ignore spendieren, so dass man die Zähler der Nachbar von FHEM ignorieren lassen kann?

[kossmann]

Zu dem lSE-LSE Unterschied ist mir noch folgendes aufgefallen:

Wenn ich meinen Heizungszähler in einer separaten Konfigurationsdatei (welche per include in der fhem.cfg eingelesen wird) wie folgt definiere

Code Auswählen Erweitern

define Zaehler_Heizung WMBUS LSE 228211 22 4
  attr Zaehler_Heizung IODev CUL868

wird der Zähler per autocreate weiterhin neu angelegt

Code Auswählen Erweitern

define WMBUS_lSE_228211_22_4 WMBUS lSE 228211 22 4
  attr WMBUS_lSE_228211_22_4 IODev CUL868

Versuche ich nun aber, den Zähler in meiner separaten Konfigurationsdatei mit lSE anzulegen, meckert FHEM beim Start herum:

Code Auswählen Erweitern

2014.08.18 16:29:58.188 1: define WMBUS_lSE_228211_22_4 WMBUS_lSE_228211_22_4 WMBUS lSE 228211 22 4: lSE is not a valid WMBUS manufacturer id

Steht die Konfiguration (mit lSE statt LSE direkt in der fhem.cfg, wird nicht gemeckert. Irgendwas stimmt da noch nicht.

[kaihs]

Zu dem lSE-LSE Unterschied ist mir noch folgendes aufgefallen:

Tja, da kommt der Unterschied zwischen Theorie und Praxis zum tragen. Laut der Beschreibung des M-Bus Protokolls

The field manufacturer is coded unsigned binary with 2 bytes. This manufacturer ID is
calculated from the ASCII code of EN 61107 manufacturer ID (three uppercase letters) with
the following formula:

darf die Manufacturer ID nur aus Großbuchstaben bestehen.
Bei deinen Wärmemengenzählern ist das wohl falsch implementiert.
Ist jetzt die Frage wie ich damit umgehen soll.

- Kleinbuchstaben immer in Großbuchstaben konvertieren?
- Auch Kleinbuchstaben als Eingabe zulassen?

[kaihs]

Ich hätte gedacht das diese am Sonntag gar nicht senden aber nach einem Blick auf die Zeit die in Fhem angezeigt wird, wundert mich nichts: 2014-8-17 00:04 und das um 13:01. Oder muss ich mir da ein PM dazudenken?

Welche Zeit meinst du genau?
Kannst du mal die Rohdaten einer Meldung (also die Hex-Daten die mit b beginnen) posten? Dann kann ich mir das mal im Detail anschauen.

is_encrypted 0

Das bedeutet, dass die Daten unverschlüsselt sind.

[mdewendt]

Hallo kaihs.

Ich habe gerade mal angefangen den Standard zu lesen - wie immer warum einfach wenn es auch verschachtelt geht
Vielleicht kannst du mir einen kurzen Hinweis geben wie die Pakete die aus dem CUL kommen überhaupt anfangen:

b3444653 26277806 0180 8 8DC27A2D0000000 ...

Was sind die ersten Zeichen? Wo finde ich die Grundstruktur? 26277806 ist schonmal die Nummer des Zählers.

Auf Seite 22 in MBDOC48.PDF steht was von den Telegrammformaten. Ich finde aber keins der Startzeichen e5h, 10h, 68h. Ich nehme mal an das sind meistens alles long frames?
Wäre super wenn du mir etwas Starthilfe geben könntest. Dann würde ich die bekannten Daten meiner Qundiszähler mal etwas mit den MANUFACTURER SPECIFIC "abgleichen".
Danke.

Gibt es eine Möglichkeit die einzelnen Telegramme beginnend mit b irgendwie komplett ins Logfile zu bekommen falls die aktuelle Dekodierung fehlschlägt?

Martin

[kaihs]

Kai, könntest du den WMBus-Devices ggf. noch das Attribut ignore spendieren, so dass man die Zähler der Nachbar von FHEM ignorieren lassen kann?

Das ignore Attribut ist jetzt implementiert.
Kommt morgen per update oder sofort aus dem svn.

[kossmann]

Ist jetzt die Frage wie ich damit umgehen soll.

- Kleinbuchstaben immer in Großbuchstaben konvertieren?
- Auch Kleinbuchstaben als Eingabe zulassen?

Ich würde versuchen, mich an den Standard zu halten und notfalls die Fehler der Hersteller korrigieren. So können Entwickler, die mit ihrer Software auf FHEM zugreifen, immerhin von einem gültigen Standard ausgehen. Des weiteren hätten die Devices innerhalb von FHEM auch alle eine gleich lesbare Form, wenn man bei den Autocreate-Namen bleibt.

=> Ich würde auf Großbuchstaben konvertieren.

Kann es sein, dass Qundis hier innerhalb der Nutzdaten auch auf eine solche Art vom Standard abweicht und daher die Nachrichten nicht vollständig zu dekodieren sind?

Ich wäre dir auch für die Martin gewünschte "Starthilfe" dankbar. Ich habe in der Doku zwar teilweise schon gesehen, wie da irgendwo was zu entziffern wäre, kann mit dem String, welcher vom CUL kommt aber auch noch nicht viel anfangen.

[kaihs]

Ich habe gerade folgende Änderungen/Korrekturen vorgenommen:

- Dekodierung der Stunden im Timestamp korrigiert
- Manufacturer ID wird jetzt immer in Großbuchstaben konvertiert

@kossmann, d.h. das Device das bisher mit lSE angelegt ist wird dann nochmal mit LSE angelegt, das alte kannst du dann löschen.