Hallo guten Tag ,
ich habe einen CUL auf FHEM auf einem Raspberry eingebunden. Nun habe ich ein Sontex 868 HKV ( Heizkostenverteiler)
https://www.sontex.eu/download/pdf/565_566_868_Datenblatt.pdf.
Ist es irgendwie möglich mit dem CUL die 868 MHz -OMS Daten zu empfangen/auszuwerten ?
Bezüglich des WMBUS kann man ja lesen: https://wiki.fhem.de/wiki/WMBUS
"Daher werden bisher erst die EnergyCam der Firma Q-loud, Zähler von Easymeter und der Kamstrup Multical 21 vollständig unterstützt. "
Also ist es bis jetzt nicht möglich den Sontex 868 auf irgendeine Art einzubinden ?
Danke :D
Habe auch gerade mit Sontex gesprochen,
die meinten für den Sontex 868 ist der Key bekannt mit dem der wMBUS verschlüsselt ist. Nach deren Aussage braucht man nur diesen Key und der Rest ist OMS komform.
Den Key konnte er mir für mein 2018er Sontex Gerät auch schon durchsagen.
Was sagt Ihr dazu ? !
Kann man mit dem CUL die Sontex868 empfangen und mit Hilfe des Keys dann die Nachricht entschlüsseln ?
Hat das schon jemand gemacht ?
:D
Wenn die Daten wirklich OMS konform sind sollte es klappen.
Falls es da noch Probleme geben sollte werde ich versuchen das WMBUS Modul entsprechend anzupassen.
Wenn es sich aber entgegen der Aussage des Herstellers doch um ein undokumentiertes Datenformat handelt wird es schwierig.
Vielen Dank für die Antwort,
genau der Hersteller meinte es ist OMS komform.
Ist denn die implementierung der Decodierung mit dem gegebenen Key ein Problem ?
Also in diesem Fall wurde 32 mal die 0 als Key angegeben.
In Fhem müsste man diesen ja zur Decodierung der OMS Nachrichten hinterlegen oder ?
( werde jetzt erst mal das WMBUS Modul versuchen einzubinden ;D)
Vielen Dank :D
ah sehe gerade einen versteckten Abschnitt in der commandref_DE:
https://fhem.de/commandref_DE.html
Zitat"Voraussetzungen
Dieses Modul benötigt die perl Module Digest::CRC, Crypt::Mode::CBC, Crypt::ModeL::CTR und Digest::CMAC (die letzten drei Module werden nur benötigt wenn verschlüsselte Nachrichten verarbeitet werden sollen).
Bei einem Debian basierten System können diese so installiert werden
sudo apt-get install libdigest-crc-perl
sudo cpan -i Crypt::Mode::CBC Crypt::Mode::CTR Digest::CMAC
Define
define <name> WMBUS [<manufacturer id> <identification number> <version> <type> [<MessageEncoding>]]|<b[]HexCode>"
:DHabe mich mit dem WMBUS Modul beschäftigt, man findet in der commandref folgendes:
ZitatExplictly specify the information that uniquely identifies a WMBus device.
The manufacturer code, which is is a three letter shortcut of the manufacturer name. See dlms.com for a list of registered ids.
dlms.com findet sontex nicht ?! Was tun
ZitatThe identification number is the serial no of the meter.
es sind 2 angegeben . kann man aber nachfragen
Zitatversion is the version code of the meter
kann man evtl. nachfragen
Zitattype is the type of the meter, e.g. water or electricity encoded as a number.
woher soll man denn den typ bekommen ?! ist der wichtig ?
ZitatMessageEncoding is either CUL or AMB, depending on which kind of IODev is used.
CUL !
Hat jemand eine Idee wie man hier weiter kommt ? :D :D
Viele Dank
Das brauchst du alles gar nicht wissen. Sobald eine Nachricht empfangen wird holt sich das Modul alles nötige aus den Daten. Steht auch so in der commandref.
Zitat von: scp am 21 August 2019, 14:28:46
Vielen Dank für die Antwort,
genau der Hersteller meinte es ist OMS komform.
Ist denn die implementierung der Decodierung mit dem gegebenen Key ein Problem ?
Also in diesem Fall wurde 32 mal die 0 als Key angegeben.
In Fhem müsste man diesen ja zur Decodierung der OMS Nachrichten hinterlegen oder ?
( werde jetzt erst mal das WMBUS Modul versuchen einzubinden ;D)
Vielen Dank :D
Evtl. sind die Daten gar nicht verschlüsselt. Ein Schlüssel aus nur Nullen wäre zumindest ungewöhnlich.
Das erkennt das Modul aber alles selber und gibt ggf. Fehler aus.
Am besten installierst du mal den CUL, schaltet den in den passenden rfmode und wartest mal bis neue Devices angelegt werden.
Nochmal der aktuelle Stand:
Der Sontex Mitarbeiter teilte mir mit, dass mein Model 32 mal die 0 habe und neuere Modelle komplexere
CUL ist eingebunden in FHEM
Sontex steht neben CUL und ist (über Schalter) angeschaltet.
CUL im T-Mode getestet - kein Ergebnis
CUL im S-Mode - kein Ergbnis
Weiß jemand, wo man sieht ob der Sontex irgendetwas schickt ?
Anhang: Logfile, FHEM Bildschirmausschnitt,Ausschnitt Sontex Datenblatt OMS
Danke sehr !
06074 919790
Habe gerade nochmal nachgefragt, der Mitarbeiter von Sontex meinte gerade dieser Key (32 mal die 0 ) ist der AES 128 Bit code. Bei den neueren ist es ein komplexerer.
Es muss doch wenigstens das WMBUS Modul installiert werden oder ?
Habe gerade noch mal da wo der Sontex bestellt wurde (ZÄHLER Plattform) den eingestellten Modus , den AES Key angefordert !
Bitte teilt mir mit falls ihr weitere Ideen und Tipps habt !
Da hat jmd. auch ein ähniches Thema gehabt:
https://forum.fhem.de/index.php/topic,33068.msg737335.html#msg737335
Das konnte man uns schicken :
Funkeinstellungen Gerät 23275669
AES 128 BIT (C51331429B378FEADBCBAC2B0EC55143)
Mode 5
OMS (kurzes Telegramm)
alle 5 Minuten 24/7
Mit freundlichen Grüßen
Geschäftsführer
commandref - WMBUS
https://fhem.de/commandref.html##
"WMBus messages can be optionally encrypted. In that case the matching AESkey must be specified with attr AESkey. Otherwise the decryption will fail and no relevant data will be available. The module can decrypt messages encrypted according to security profile A or B (mode 5 and 7"
ok es handelt sich ja um Mode 5 hier, dann weiß man schon mal dass der unterstützt wird
Der beschreibt ja auch einige Schritte zum einfügen des WMBUS Moduls:
*CUL das WMBUS-Protokoll beibringen, indem man andere Protokolle aus der Headerdatei auskommentiert
* Den Empfangspuffer auf 190 Bytes erhöhen, damit die recht großen Datagramme Platz haben
*Die AES-Bibliothek auf dem Raspi installieren, und die Fehlermeldung ob des zu geringen RAMs beim entpacken umgehen (sudo cpan -i Crypt/OpenSSL/AES.pm anstatt von sudo cpan -i Crypt::OpenSSL::AES)
* Den AES-Key aus dem Forum hier eingetragen (XXX) der aus der Windows-SW extrahiert wurde
Es tritt ein Fehler auf ( Anhang) wenn man sudo cpan -i Crypt/OpenSSL/AES.pm eingibt in die Bash.
Admin-Edit: AES-Key nach Bitte des Herstellers entfernt.
der befehl hat doch funktioniert ;D
Du bist ein bisschen hyperaktiv, oder?
Gehe mal systematisch vor. Es sieht mir so aus als ob der CUL noch gar nicht richtig funktioniert.
Der muss im Status initialized sein.
Versuch mal 38400 als Baudrate statt 9600.
Dann sollte in den internals ein CMDS auftauchen, in dessen Wert muss ein b stehen.
Dann sollte auch der Empfang klappen.
Laut dem Datenblattausschnitt sendet der Zähler im T-Mode, d.h. der muss auch in den T-Modus geschaltet werden:
attr CUL1 rfmode WMBus_T
Vielen Dank für die Antwort ! :)
Nun habe ich über
delete CUL1
den CUL1 gelöscht um ihn wieder mit
Define CUL1 CUL /dev/ttyUSB0@38400 1234
hinzuzufügen.
Wenn ich nun den WMBUS T Modus einstellen möchte erscheint dort die Meldung, dass dieser Modus nicht unterstützt wird von CUL1 ! Siehe Anhang
In den internals fehlt das von dir angesprochene b
CMDS: ABCEeFfGhiKklMmRTtUVWXxYZz
Woran könnte das nun liegen ?
Unten beim CUL steht noch
ZitatModule: 00_CUL.pm Maintainer: rudolfkoenig Forum: SlowRF
Und bei der Hilfe weiter unten etwas zu den cmds
Zitatcmds
Depending on the firmware installed, CULs have a different set of possible commands. Please refer to the README of the firmware of your CUL to interpret the response of this command. See also the raw command.
http://culfw.de/commandref.html
ah deswegen ist das Commando b so wichtig ;D
Zitatb<cmd><data>
Wireless M-Bus:
r<mode>
start receiving messages. <mode> bust be either s or t for desired mode
s<data>
send data (tbd)
returns always the actual receiving mode
Wurde der CUL nicht korrekt geflasht ?
WMBUS ist in der culfw auf deinem CUL nicht aktiviert. WMBUS braucht ziemlich viel Speicher und ist daher oft ausgeschaltet.
Was genau für einen CUL hast du? Ein Original von busware, wenn ja, welche Version?
Oder einen Selbstbau nanoCUL?
Je nachdem brauchst du eine andere Version der culfw.
Vielen Dank,
habe wohl den nanoCUL.
Habe mal den Hersteller gefragt. Tatsächlich hat er mittgeteilt, dass man WMBUS ausgeklammert hat. ( steht ja auch online wo die dateien zu finden sind )
Daraufhin hat er einen Leitfaden zugesandt, mit der man die Firmware aufpielen kann. https://www.smart-home-komponente.de/2018/03/09/nanocul-und-jeelink-am-pc-flashen/ (https://www.smart-home-komponente.de/2018/03/09/nanocul-und-jeelink-am-pc-flashen/)
Was ich vorher wohl nicht beachtet habe ist, dass es ja verschiedene Transceiver/CULs gibt. Beim Nano CUL kann man einfach im FHEM WIKI Teil selbstauCUL nachschauen.
Ich bin unter Linux in meinen nanoCUL-Ordner navigiert und habe dann den CUL Flashen können mit
Zitatmake program
. Zuerst als Test, dann mit veränderter board.h undzwar, so , dass dort sowohl 868 MHz aktiviert ist, als auch die MBUS Funktion.
Ich konnte daraufhin das "b" in den CMDs sehen !
Screenshot schicke ich nächste Woche.
Auch eine Nachricht vom Gerät ist erschienen. Da kommt jetzt noch der Fehler, dass die TTY Buffergröße zu klein ist. Da werde ich aber noch mal hier Forum schauen. Habe gerade schon TTY_BUFSIZE auf 256 gestellt, aber dann kommen keine Nachrichten mehr. ;D
Mal schauen, man muss wirklich tief in die Matiere eintauchen.
Vielen Dank für die Unterstützung :D.
https://www.ebay.de/itm/nanoCUL-USB-Stick-FTDI-CC1101-868MHz-FW-1-67-FHEM-CCU-CUL-868-inkl-Adapter/372216852633?hash=item56a9da7099%3Ag%3AZkwAAOSwLuBb5Htc&_trkparms=pageci%3A2d32be33-c969-11e9-a779-74dbd1807373%7Cparentrq%3Ad738c5a916c0ad305840e6deffe2f44d%7Ciid%3A1
(https://www.ebay.de/itm/nanoCUL-USB-Stick-FTDI-CC1101-868MHz-FW-1-67-FHEM-CCU-CUL-868-inkl-Adapter/372216852633?hash=item56a9da7099%3Ag%3AZkwAAOSwLuBb5Htc&_trkparms=pageci%3A2d32be33-c969-11e9-a779-74dbd1807373%7Cparentrq%3Ad738c5a916c0ad305840e6deffe2f44d%7Ciid%3A1)
Wie groß der Puffer sein musst kannst du aus der Fehlermeldung entnehmen, da sollte "message too short, expected xxx" stehen.
Den Puffer dann mindestens ein Byte größer machen.
Zu groß ist auch nicht gut, dann kann die culfw durch Stackoverflow abstürzen. Der nanoCUL hat nur 2KB RAM.
Wenn du ganz tief in die Thematik einsteigen willst: Unter https://github.com/thomas2403/a-culfw.git (https://github.com/thomas2403/a-culfw.git) gibt es einen Fork der culfw bei der Speicherverbrauch in Bezug auf WMBUS optimiert wurde.
sehr gut vielen Dank für den Hinweis :
habe ihm Code nämlich zuerst tty_Buffsize von 128 auf 256 verdoppelt. Dann wurde der CUL nicht mehr initialisiert. Nachdem ich deinen Post gelesen habe , ist mir gedämmert, dass ich den Wert besser mal langsamer erhöhe, zuerst auf 130, dann auf 200 . Daraufhin konnte ich dann auch die Nachricht empfangen. Dann ging es noch darum , dass dort stand, dass kein AES Key hinterlegt ist. Glücklicherweise habe ich den Key vom Hersteller erhalten und konnte ihn über attr <name>AESkey einfügen.
Spätestens da wurde, wohl über das Autodetect , ein WMBUS Room eröffnet und das Gerät dort angezeigt. Es werden nun alle 5 Minuten Nachrichten erhalten ;D
Danke , jetzt werde ich mal weiterschauen. Was möglich ist. Evtl, mehrere wMBussteilenehmer , oder Daten weiterschicken. :D :D :D :D
Anhang Bild von angezeigten Messwerten/ Daten von Sontex
Also auf dem Display des Heizkostenverteilers steht z.B. u4 , nach Erhitzen wurde der Wert langsam auf u6 inkrementiert.
Man findet das aber gar nicht in den Readings !
Ich empfange jetzt alle 5 Minuten zuverlässig meine Readings.
Ich verstehe noch nicht wo da der relevante Wert drin stehen soll...
Da wird ja sogar ein Kg Wert mit übermittelt. Das macht gar keinen Sinn.
Entweder Fhem ordnet dem Reading selber die Formate zu oder der Hersteller Sontex hat das so definiert.
Außerdem scheinen sich die Einheiten bei jedem Reading zu ändern :o
Ich werde mal in der Wiki nachschauen.... ;D
hier die list von meinem Heizkostenverteiler:D
Internals:
CUL1_MSGCNT 49
CUL1_RAWMSG b3E44EE4D695627231608EF757A0D003025AD40FA9F60663EE656C7A0D067BB22121BF3BA554CD3541D712674015B20720F681DC8306355AE70FAB24DD6F82E8DB926B38B15EAD7CD9380::-26.5
CUL1_RSSI -26.5
CUL1_TIME 2019-10-16 14:17:13
DEF SON 23275669 22 8
DeviceMedium Heat Cost Allocator
DeviceType 8
FUUID 5d6e3251-f33f-05c5-97f5-871c8b5db2565cc7
IODev CUL1
IdentNumber 23275669
LASTInputDev CUL1
MSGCNT 49
Manufacturer SON
MessageEncoding CUL
NAME WMBUS_SON_23275669_22_8
NR 16
STATE no errors
TYPE WMBUS
Version 22
addr SON_23275669_22_8
model SON_8_22
READINGS:
2019-10-16 14:17:13 1_storage_no 0
2019-10-16 14:17:13 1_type VIF_TIME_POINT_DATE_TIME
2019-10-16 14:17:13 1_unit
2019-10-16 14:17:13 1_value 2019-10-16 13:16
2019-10-16 14:17:13 1_value_type Instantaneous value
2019-10-16 14:17:13 2_storage_no 0
2019-10-16 14:17:13 2_type VIF_HCA
2019-10-16 14:17:13 2_unit
2019-10-16 14:17:13 2_value 100663296
2019-10-16 14:17:13 2_value_type Instantaneous value
2019-10-16 14:17:13 3_storage_no 1
2019-10-16 14:17:13 3_type VIF_TIME_POINT_DATE
2019-10-16 14:17:13 3_unit
2019-10-16 14:17:13 3_value invalid: f1e1
2019-10-16 14:17:13 3_value_type Instantaneous value
2019-10-16 14:17:13 4_storage_no 1
2019-10-16 14:17:13 4_type VIF_HCA
2019-10-16 14:17:13 4_unit
2019-10-16 14:17:13 4_value 0
2019-10-16 14:17:13 4_value_type Instantaneous value
2019-10-16 14:17:13 5_storage_no 0
2019-10-16 14:17:13 5_type MANUFACTURER SPECIFIC
2019-10-16 14:17:13 5_unit
2019-10-16 14:17:13 5_value 44
2019-10-16 14:17:13 5_value_type Instantaneous value
2019-10-16 12:29:13 6_errormsg in VIFExtension a0 unknown VIF 4
2019-10-16 12:29:13 6_extension per second, 20
2019-10-16 14:17:13 6_storage_no 0
2019-10-16 14:17:13 6_type VIF_ENERGY_JOULE
2019-10-16 14:17:13 6_unit J
2019-10-16 14:17:13 6_value 10836502000
2019-10-16 14:17:13 6_value_type Maximum value
2019-10-16 13:51:34 7_errormsg in VIFExtension a0 unknown VIF 4
2019-10-16 13:51:34 7_extension per second, 20
2019-10-16 14:17:13 7_storage_no 0
2019-10-16 14:17:13 7_type VIF_STATE_PARAMETER_ACTIVATION
2019-10-16 14:17:13 7_unit
2019-10-16 14:17:13 7_value 1184
2019-10-16 14:17:13 7_value_type Instantaneous value
2019-10-15 09:55:30 8_errormsg in VIFExtension a0 unknown VIF 4
2019-10-15 09:55:30 8_extension per second, 20
2019-10-16 14:12:05 8_storage_no 128
2019-10-16 14:12:05 8_type VIF_ELECTRIC_POWER
2019-10-16 14:12:05 8_unit W
2019-10-16 14:12:05 8_value 0
2019-10-16 14:12:05 8_value_type Minimum value
2019-10-16 14:17:13 LQI 128
2019-10-16 14:17:13 RSSI -26.5
2019-10-16 14:17:13 batteryState ok
2019-10-16 14:17:13 decryption_ok 1
2019-10-16 14:17:13 is_encrypted 1
2019-10-16 14:17:13 meineTemperatur 128
2019-10-16 14:17:13 state no errors
wmbus:
aeskey ------habe ich gestrichen aus sicherheitsgründen
Attributes:
AESkey -- habe ioch gestrichen aus sicherheitsgründen
IODev CUL1
alias SVGHKV1
room WMBUS
svgrechner test
userReadings meineTemperatur {return ReadingsNum("WMBUS_SON_23275669_22_8","LQI",0);}
userattr svgrechner
Im Anhang befinden sich Bildausschnitte von Readings zu unterschiedlichen Zeitpunkten.Auch das Logfile ist im Anhang. Könnte man am besten mit Notepad++ öffnen. Außerdem ein Bild vom Display des HKVs.