Wireless M-Bus für CUL

[kossmann]

Wo kommt denn der AESKey (82B0551191F51D66EFCDAB8967452301) her, den du im Test-Skript setzt? Ist das ggf. der Schlüssel für deine Test-Nachrichten und kann damit gar nicht bei meinen Nachrichten funktionieren?

[kaihs]

Der AESKey ist für diesen Beispieldatensatz aus der Spezifikation

Code: [Auswählen]

# Annex N, water encrypted, page 84
#my $msg = '2E44242344227592290738D17A1F002005059B4D12F7355E4DF6DF4CFF3667BEFB7A5476112FF448BF981AF9064CB7430ACD43A197CBFD';

Der Key wird aber nur verwendet, wenn der Datensatz auch verschlüsselt ist. Ob ein Datensatz verschlüsselt ist kann man an einem Flag im unverschlüsselten Header erkennen.
Deine Datensätze sind nicht verschlüsselt, daher ist das nicht die Ursache für den unbefriedigenden Inhalt.

Kai

[Chelaz]

Hallo,

ich würde auch gerne mal sehen, ob ich meine M-Bus Geräte empfangen kann. Leider habe ich keinen CUL, sondern einen CUNO2. In den Sourcen der FW 1.61 finde ich leider keine Portierung für den CUNO2. Geht das prinzipiell nicht, oder wurde es einfach noch nicht gemacht?

Danke und Grüße
Michael

[kaihs]

Das wurde nur noch nicht gemacht. Ich könnte das machen, kann das Ergebnis aber nicht testen, da ich keinen CUNO habe. Wenn du bereit bist zu gestern könnte ich das am Wochenende machen.

[Chelaz]

Ich habe eine ISTA sensonic II mbus http://www.ista.de/produkte/m_bus_system/sensonic_ii_mbus/index.html für meine Fußbodenheizung und einen Kalt- sowie Warmwasserzähler von ISTA. Nun bin ich mir leider gerade gar nicht mehr sicher, ob diese Geräte wireless auslesbar sind, oder ob die über ne Busleitung zentral im Heizungskeller ausgelesen werden. Bei letzerem nützt mir mein CUNO2 leider wenig.

Grüße
Michael

[kaihs]

ISTA sensonic II mbus ist wohl nicht Wireless M-Bus sondern M-Bus, d.h. drahtgebunden.

Die Protokolle sind zwar sehr ähnlich, die Übetragungsmedien sind aber unterschiedlich.
Für M-Bus braucht man wohl noch einen Konverter auf ein auch Computern übliches Signal wie USB oder so.

Kai

[kaihs]

Die erste Version des Wireless M-BUS Moduls 36_WMBUS.pm ist fertig und steht ab sofort im SVN und morgen per update zur Verfügung.

Es unterstützt WMBus inkl. AES Verschlüsselung.

Es werden zusätzlich die Perl Module Crypt::CBC, Digest::CRC und Crypt::OpenSSL::AES benötigt.

Getestet habe ich bisher nur mit einer EnergyCam als Wasser- und Elektrozähler.

Weitere Tester sind gerne willkommen.

Da die WMBus Spezifikation sehr umfangreich ist habe ich bisher nur die Daten und Werttypen implementiert die wohl am gebräuchlichsten sind.
Bei Bedarf kann ich das Modul aber noch erweitern.

Gruß,

Kai

[kossmann]

Die Integration in FHEM funktioniert, mein neuer CUL868 empfängt auch Daten:

Code: [Auswählen]

2014.08.11 08:13:53.744 3: WMBUS Unknown device b374465B2088222001604A4197A5D000000046D3014CB1801FD0C06326C966CFFFF0DFF5F0C0008553000010613089CAE0BFFFC02FD1700000C7878155559DCAE, please define it
2014.08.11 08:13:53.745 2: autocreate: define WMBUS_lSE_2261512_22_4 WMBUS b374465B2088222001604A4197A5D000000046D3014CB1801FD0C06326C966CFFFF0DFF5F0C0008553000010613089CAE0BFFFC02FD1700000C7878155559DCAE
2014.08.11 08:13:53.748 3: WMBUS_lSE_2261512_22_4: I/O device is CUL868
2014.08.11 08:13:53.756 2: autocreate: define FileLog_WMBUS_lSE_2261512_22_4 FileLog ./log/WMBUS_lSE_2261512_22_4.log WMBUS_lSE_2261512_22_4
2014.08.11 08:15:59.369 3: WMBUS Unknown device b2C446532039470584107C0E27A5D000000046D1207CB1801FD0C0532031F6CFFFF0DFF5F0C0008553000010613089CAE0BFFFC97C6, please define it
2014.08.11 08:15:59.371 2: autocreate: define WMBUS_LSE_1483772931_65_7 WMBUS b2C446532039470584107C0E27A5D000000046D1207CB1801FD0C0532031F6CFFFF0DFF5F0C0008553000010613089CAE0BFFFC97C6
2014.08.11 08:15:59.417 3: WMBUS_LSE_1483772931_65_7: I/O device is CUL868
2014.08.11 08:15:59.423 2: autocreate: define FileLog_WMBUS_LSE_1483772931_65_7 FileLog ./log/WMBUS_LSE_1483772931_65_7.log WMBUS_LSE_1483772931_65_7
2014.08.11 08:19:18.282 3: WMBUS Unknown device b2C4465320594705841073F187A5D000000046D1907CB1801FD0C0532FC1E6CFFFF0DFF5F0C0008553000010613089CAE0BFFFC97C6, please define it
2014.08.11 08:19:18.283 2: autocreate: define WMBUS_LSE_1483772933_65_7 WMBUS b2C4465320594705841073F187A5D000000046D1907CB1801FD0C0532FC1E6CFFFF0DFF5F0C0008553000010613089CAE0BFFFC97C6
2014.08.11 08:19:18.285 3: WMBUS_LSE_1483772933_65_7: I/O device is CUL868
2014.08.11 08:19:18.291 2: autocreate: define FileLog_WMBUS_LSE_1483772933_65_7 FileLog ./log/WMBUS_LSE_1483772933_65_7.log WMBUS_LSE_1483772933_65_7
2014.08.11 08:19:40.541 3: WMBUS Unknown device b2C446532409470584107527B7A5D000000046D1407CB1801FD0C053226506CFFFF0DFF5F0C0008553000010613089CAE0BFFFC97C6, please define it
2014.08.11 08:19:40.544 2: autocreate: define WMBUS_LSE_1483772992_65_7 WMBUS b2C446532409470584107527B7A5D000000046D1407CB1801FD0C053226506CFFFF0DFF5F0C0008553000010613089CAE0BFFFC97C6
2014.08.11 08:19:40.548 3: WMBUS_LSE_1483772992_65_7: I/O device is CUL868
2014.08.11 08:19:40.554 2: autocreate: define FileLog_WMBUS_LSE_1483772992_65_7 FileLog ./log/WMBUS_LSE_1483772992_65_7.log WMBUS_LSE_1483772992_65_7
2014.08.11 08:28:01.479 3: WMBUS Unknown device b2C446532049470584107FE907A5D000000046D2207CB1801FD0C053214026CFFFF0DFF5F0C0008553000010613089CAE0BFFFC97C6, please define it
2014.08.11 08:28:01.481 2: autocreate: define WMBUS_LSE_1483772932_65_7 WMBUS b2C446532049470584107FE907A5D000000046D2207CB1801FD0C053214026CFFFF0DFF5F0C0008553000010613089CAE0BFFFC97C6
2014.08.11 08:28:01.483 3: WMBUS_LSE_1483772932_65_7: I/O device is CUL868
2014.08.11 08:28:01.489 2: autocreate: define FileLog_WMBUS_LSE_1483772932_65_7 FileLog ./log/WMBUS_LSE_1483772932_65_7.log WMBUS_LSE_1483772932_65_7
Die entsprechenden Logfiles sind jedoch leer und Datenstände gibt es nicht. Meldungen, dass die empfangenen Daten nicht dekodiert werden können (da z.B. herstellerspezifisch) finde ich nun jedoch nirgendwo. Ist das richtig?

[wopper]

Habe eine EnergyCam, bekomme über das Logfile aber nur:

Code: [Auswählen]

2014.08.11 14:20:06 3: CUL_0: Unknown code b1944C41838648717010715297AD40000800415C717220002FD083BC0D035, help me!Was mache ich falsch?

[kossmann]

Wie hast du das CUL zum "lauschen" überredet? Mit einem "set <CUL> raw brs" hatte ich gestern noch dasselbe. Heute früh habe ich nach einem Update das CUL nicht mehr im "rfmode SlowRF" lauschen lassen, sondern direkt "rfmode WMBus_S" gesetzt.

Meine autocreate-Logfiles häufen sich nun, die Nachbarschaft lässt grüßen:

Code: [Auswählen]

-rw-r--r-- 1 fhem dialout    0 Aug 11 08:57 log/WMBUS_LSE_1483772562_65_7.log
-rw-r--r-- 1 fhem dialout 1024 Aug 11 12:48 log/WMBUS_LSE_1483772563_65_7.log
-rw-r--r-- 1 fhem dialout 1024 Aug 11 13:30 log/WMBUS_LSE_1483772823_65_7.log
-rw-r--r-- 1 fhem dialout 1024 Aug 11 12:37 log/WMBUS_LSE_1483772824_65_7.log
-rw-r--r-- 1 fhem dialout 1024 Aug 11 13:17 log/WMBUS_LSE_1483772825_65_7.log
-rw-r--r-- 1 fhem dialout    0 Aug 11 12:20 log/WMBUS_LSE_1483772928_65_7.log
-rw-r--r-- 1 fhem dialout 1024 Aug 11 12:24 log/WMBUS_LSE_1483772929_65_7.log
-rw-r--r-- 1 fhem dialout 1024 Aug 11 12:56 log/WMBUS_LSE_1483772930_65_7.log
-rw-r--r-- 1 fhem dialout 1024 Aug 11 12:10 log/WMBUS_LSE_1483772931_65_7.log
-rw-r--r-- 1 fhem dialout 1024 Aug 11 11:56 log/WMBUS_LSE_1483772932_65_7.log
-rw-r--r-- 1 fhem dialout    0 Aug 11 08:19 log/WMBUS_LSE_1483772933_65_7.log
-rw-r--r-- 1 fhem dialout    0 Aug 11 12:25 log/WMBUS_LSE_1483772984_65_7.log
-rw-r--r-- 1 fhem dialout    0 Aug 11 11:25 log/WMBUS_LSE_1483772985_65_7.log
-rw-r--r-- 1 fhem dialout 1024 Aug 11 12:26 log/WMBUS_LSE_1483772992_65_7.log
-rw-r--r-- 1 fhem dialout  976 Aug 11 12:02 log/WMBUS_lSE_2261512_22_4.log
-rw-r--r-- 1 fhem dialout    0 Aug 11 12:21 log/WMBUS_lSE_2261521_22_4.log
-rw-r--r-- 1 fhem dialout  976 Aug 11 12:13 log/WMBUS_lSE_2261522_22_4.log
-rw-r--r-- 1 fhem dialout  976 Aug 11 13:24 log/WMBUS_lSE_2261528_22_4.log
-rw-r--r-- 1 fhem dialout    0 Aug 11 11:36 log/WMBUS_lSE_2262641_22_4.log
-rw-r--r-- 1 fhem dialout    0 Aug 11 11:19 log/WMBUS_lSE_2262679_22_4.log
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)?

In den gefüllten Logfiles habe ich nun übrigens die schon vermissten Meldungen "4:type: MANUFACTURER SPECIFIC"

[wopper]

Bin noch CUL Neuling, habe mir ihn extra für wM-Bus zum Testen zugelegt.
Habe CUL über set <CUL> raw brt gesetzt. Wie kann ich den rfmode direkt setzten?

[kossmann]

Du hast das CUL in der fhem.cfg momentan doch auch schon irgendwie konfiguriert, oder? So sieht es dort bei mir aus:

Code: [Auswählen]

define CUL868 CUL /dev/cul868@9600 0000
  attr CUL868 rfmode WMBus_S
  attr CUL868 room System
/dev/cul868 ist eine Besonderheit (udev-Regel) bei mir und wird bei dir wahrscheinlich /dev/ttyACM0 sein. Entscheidend ist hier die zweite Zeile mit dem "rfmode WMBus_S" (bzw. WMBus_T). Die dritte Zeile ist bei mir nur eine räumliche Zuordnung.

[kaihs]

Bin noch CUL Neuling, habe mir ihn extra für wM-Bus zum Testen zugelegt.
Habe CUL über set <CUL> raw brt gesetzt. Wie kann ich den rfmode direkt setzten?

Wie schon von kossmann geschrieben per Attribut rfmode, siehe auch die Dokumentation http://fhem.de/commandref.html#WMBUS. Das lässt sich auch über die FHEM Oberfläche einstellen, vielleicht besser als direkt in der cfg

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

Das soll so nicht sein, eigentlich sollen schon die Informationen des ersten Pakets ausgewertet werden. Werde ich mir morgen noch mal anschauen.

[wopper]

Hatte Probleme Crypt::OpenSSL::AES über CPAN nach zu installieren.

Code: [Auswählen]

cpan[1]> install Crypt::OpenSSL::AES
Reading '/root/.cpan/Metadata'
  Database was generated on Tue, 12 Aug 2014 08:06:15 GMT
Running install for module 'Crypt::OpenSSL::AES'
Checksum for /root/.cpan/sources/authors/id/T/TT/TTAR/Crypt-OpenSSL-AES-0.02.tar.gz ok
Scanning cache /root/.cpan/build for sizes
........................................................................----DONE
DEL(1/7): /root/.cpan/build/Archive-Extract-0.72-wU3SNH
DEL(2/7): /root/.cpan/build/Archive-Tar-2.00-CBoAei
DEL(3/7): /root/.cpan/build/Attribute-Handlers-0.96-5Bfkuy
DEL(4/7): /root/.cpan/build/AutoLoader-5.74-xWpTCu
DEL(5/7): /root/.cpan/build/B-Debug-1.21-GgPglW
DEL(6/7): /root/.cpan/build/B-Lint-1.17-kAhkx2
DEL(7/7): /root/.cpan/build/CPAN-2.05-_B1Ca4
'YAML' not installed, will not store persistent state
Configuring T/TT/TTAR/Crypt-OpenSSL-AES-0.02.tar.gz with Makefile.PL
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for Crypt::OpenSSL::AES
Writing MYMETA.yml and MYMETA.json
  TTAR/Crypt-OpenSSL-AES-0.02.tar.gz
  /usr/bin/perl Makefile.PL INSTALLDIRS=site -- OK
Running make for T/TT/TTAR/Crypt-OpenSSL-AES-0.02.tar.gz
cp lib/Crypt/OpenSSL/AES.pm blib/lib/Crypt/OpenSSL/AES.pm
Running Mkbootstrap for Crypt::OpenSSL::AES ()
chmod 644 AES.bs
/usr/bin/perl /usr/local/share/perl/5.14.2/ExtUtils/xsubpp  -typemap /usr/share/perl/5.14/ExtUtils/typemap -typemap typemap  AES.xs > AES.xsc && mv AES.xsc AES.c
cc -c  -I. -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fstack-protector -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g   -DVERSION=\"0.02\" -DXS_VERSION=\"0.02\" -fPIC "-I/usr/lib/perl/5.14/CORE"   AES.c
AES.xs:5:25: fatal error: openssl/aes.h: No such file or directory
compilation terminated.
make: *** [AES.o] Error 1
  TTAR/Crypt-OpenSSL-AES-0.02.tar.gz
  /usr/bin/make -- NOT OK
Failed during this command:
 TTAR/Crypt-OpenSSL-AES-0.02.tar.gz           : make NO

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

Code: [Auswählen]

apt-get install libssl-dev