Wireless M-Bus für CUL

Begonnen von tostmann, 12 Juni 2014, 17:34:32

Vorheriges Thema - Nächstes Thema

killah78

Zitat von: pc1246 am 14 März 2019, 09:53:35
So wie ich das sehe bist Du auf eine Version vom 18.11.18 zurueckgesprungen!

Das sieht so aus. Tatsächlich ist das aber die "aktuelle" Version, die kaihs in #715 angehangen hat.

Gruss

kaihs

Zitat von: killah78 am 14 März 2019, 11:08:59
Das sieht so aus. Tatsächlich ist das aber die "aktuelle" Version, die kaihs in #715 angehangen hat.

Gruss

Ja, in meiner Entwicklungsversion ist die svn id nicht aktuell.
Ich kann dein Problem aber immer noch nicht nachvollziehen.
Was passiert denn, wenn du

define let WMBUS b2008B4B098630000010256847A000000000403754D0900022B00000686AB6D0C504483202881928019

eingibst?

Wird das sauber dekodiert?

Wenn du weiter Probleme hast dann verwende erstmal die Version aus dem svn, d.h. die per update ausgelieferte.

Aktuell klappt das Senden bei mir gar nicht mehr, daher kann ich keinen Test inkl. Empfang durch den CUL machen.
Vielleicht komme ich am Wochenende weiter.
Banana Pi, Add-On Board mit 1.8" TFT LCD und IR-Sender, CULFW V1.61, div. Homematic Komponenten, Pollin Funksteckdosen, Selbstbau CUL433 MHz, Jeelink Clone, EC3000
Selbstbau CUL868MHz für Wireless M-Bus, SIGNALduino mit Logilink Temp.-sensoren und Auriol Wetterstation

killah78

Zitat von: kaihs am 14 März 2019, 21:56:15
Wird das sauber dekodiert?

Da bekomme ich auch die Meldung decryption failed.
Fehlt mir da vielleicht ein perl Modul?

rieders

Hallo

Nachdem mein FHEM sich verabschiedet hatte musste ich es neu auf mein Banana Pi installieren.

Nun bekomme ich die Fehlermeldung bei WMBUS

Attempt to reload WMBus.pm aborted. Compilation failed in require at ./FHEM/36_WMBUS.pm line 13. BEGIN failed--compilation aborted at ./FHEM/36_WMBUS.pm line 13.

FHEM Update habe isch schon ausgeführt.


Ich hoffe das mir jemand weiterhelfen kann.

Grüße André

killah78

Zitat von: rieders am 29 März 2019, 10:25:51
Ich hoffe das mir jemand weiterhelfen kann.

Hi rieders,
nur so eine Idee: Schau mal, ob du das Perl-Modul Digest::CRC installiert hast.

Gruss
killah78

chbla

#725
Hallo allerseits,

Ich bin neu in diesem Thema und bin nicht ganz sicher, wo ich anfangen soll,
vielleicht kann mir da jemand weiterhelfen:

Ich bekomme (noch nicht in FHEM), sondern über LoRaWan schon einige
Wireless MBus Telegramme.

Jetzt stellt sich mir die Frage:

Wie ordne ich die Telegramme einem bestimmten Zähler Typ oder Hersteller zu, sodass ich mich schlau machen
kann wie ich das ganze dekodiere? Gibts da eine ID die ich direkt auslesen kann?
Oder muss ich mich um den AES key kümmern und dann einfach schauen, wo er "passt"?
Ich bin nicht ganz sicher wie ich das am besten angehe..

Danke fuer eure Hilfe,
Christoph

kaihs

Zitat von: rieders am 29 März 2019, 10:25:51
Attempt to reload WMBus.pm aborted. Compilation failed in require at ./FHEM/36_WMBUS.pm line 13. BEGIN failed--compilation aborted at ./FHEM/36_WMBUS.pm line 13.

Ist die Datei FHEM/WMBus.pm vorhanden? Stehen mehr Informationen im Log?
Banana Pi, Add-On Board mit 1.8" TFT LCD und IR-Sender, CULFW V1.61, div. Homematic Komponenten, Pollin Funksteckdosen, Selbstbau CUL433 MHz, Jeelink Clone, EC3000
Selbstbau CUL868MHz für Wireless M-Bus, SIGNALduino mit Logilink Temp.-sensoren und Auriol Wetterstation

kaihs

Zitat von: chbla am 01 April 2019, 12:38:44
Ich bekomme (noch nicht in FHEM), sondern über LoRaWan schon einige
Wireless MBus Telegramme.

In welchem Format hast du die?

Wenn die hexadezimal sind (oder du sie darin wandeln kannst) dann kannst du manuell mit diesen Daten ein Device in fhem anlegen, siehe die Beschreibung des define hier.

Beispiel:

define wmbus WMBUS bAABBCCDDEEFF


Ggf. entfernt dein Empfänger schon die CRCs, dann kannst du es mit dem sog. AMB Encoding versuchen

define wmbus WMBUS bAMBAABBCCDDEEFF


Zitat
Wie ordne ich die Telegramme einem bestimmten Zähler Typ oder Hersteller zu, sodass ich mich schlau machen
kann wie ich das ganze dekodiere? Gibts da eine ID die ich direkt auslesen kann?
Oder muss ich mich um den AES key kümmern und dann einfach schauen, wo er "passt"?

Diese Informationen sind in den Daten enthalten und zwar immer unverschlüsselt.
Banana Pi, Add-On Board mit 1.8" TFT LCD und IR-Sender, CULFW V1.61, div. Homematic Komponenten, Pollin Funksteckdosen, Selbstbau CUL433 MHz, Jeelink Clone, EC3000
Selbstbau CUL868MHz für Wireless M-Bus, SIGNALduino mit Logilink Temp.-sensoren und Auriol Wetterstation

chbla

Danke @kaihs

Ich bekomme zB. folgende telegramme (HEX aus der thethingsnetwork console, per LoRaWan uebermittelt):

2F446850091901427472A2069F25C709E027960000001D1E0A151412140A1412190D08111514160C120C141A100A181A
19442423850721250617A24119001351E464AF01185D43580761
2F446850837285347472A2069F25271010281C01000000372034332F223138364141401F1E2B3B3A232940312A333533
2F446850953185347472A2069F259E0B10281901000000121E3534423C3A2120403B373C3A333A1F2C2A2E2620282C29

Jetzt wuerde ich eben gerne verstehen wie man das zerlegt bzw. wie die Zaehler Infos/Typ/ID da unverschluesselt gespeichert sind,
bevor ich mich um die Weiterleitung an FHEM kuemmere.

Gibt es da irgendwelche Tools? Ich bin nichtmal sicher ob ich da einen AES Key brauche oder nicht..

kaihs

Ich habe mal die dritte Zeile ausprobiert, da ist der CRC bereits entfernt.

Ein

define lora WMBUS bAMB2F446850837285347472A2069F25271010281C01000000372034332F223138364141401F1E2B3B3A232940312A333533


ergibt dann:

nternals:
   CFGFN     
   DEF        TCH 34857283 116 114
   DeviceMedium unknown
   DeviceType 114
   Error      Unsupported CI Field a2, remaining payload is 069f25271010281c01000000372034332f223138364141401f1e2b3b3a232940312a333533
   FUUID      5ca3aa9b-f33f-4fb2-2bf3-bab6a4ceecb9a417
   IODev     
   IdentNumber 34857283
   Manufacturer TCH
   MessageEncoding AMB
   NAME       lora
   NR         136
   STATE      ???
   TYPE       WMBUS
   Version    116
   addr       TCH_34857283_116_114
   READINGS:
     2019-04-02 20:31:55   LQI             65
     2019-04-02 20:31:55   RSSI            -41.5
Attributes:


TCH steht für Techem, die kochen ihr eigenes Süppchen. Evtl. kommst du da mit dem TechemHKV Modul weiter.

hermannj hat meine ich auch noch versucht weitere Techem Protokolle zu unterstützen.

Wenn du dich erst mal nur allgemein für das (W)MBus Protokoll interessierst sehe dir mal die Referenzen an.

Wenn du außerhalb von fhem die Daten analysieren willst hilft dir vielleicht das perl Modul WMBus.pm weiter.

Das wird intern vom fhem WMBus Modul benutzt, lässt sich aber auch eigenständig verwenden. Das hat aber bisher keine Dokumentation, ich könnte höchstens ein kleines Beispielprogramm zur Verfügung stellen.
Banana Pi, Add-On Board mit 1.8" TFT LCD und IR-Sender, CULFW V1.61, div. Homematic Komponenten, Pollin Funksteckdosen, Selbstbau CUL433 MHz, Jeelink Clone, EC3000
Selbstbau CUL868MHz für Wireless M-Bus, SIGNALduino mit Logilink Temp.-sensoren und Auriol Wetterstation

chbla

@kaihs,

Das klingt interessant - an einem Beispiel Programm wäre ich interessiert, ich will mal ausprobieren was hier so in der Umgebung empfangen wird.
Die restlichen Zähler, die ich momentan verwenden will sind von Diehl "IZAR RADIO COMPACT INDUCTIVE"

Sieht es da besser aus? Wie ist das mit dem CRC oben?

lvogt

Zitat von: chbla am 01 April 2019, 12:38:44
Ich bekomme (noch nicht in FHEM), sondern über LoRaWan schon einige
Wireless MBus Telegramme.

Hallo,

sorry wenn ich den Beitrag etwas vom Thema abbringe, aber mich würde sehr interessieren wie genau der Hardwareaufbau mit Empfang über LoRa aussieht.

Um noch was produktives zu sagen: wM-Bus Telegramm enthalten nach Spezifikation (recht viele) CRC Prüfsummen zwischen den eigentlichen Daten. Die meisten (kommerziellen) Empfänger (zB von Embit, Amber, IMST) entfernen automatisch in ihrer eigenen Firmware nach Prüfung die CRCs (und fügen teilweise eine eigene Prüfsumme am Ende ein). Der hier häufig verwendete Empfänger auf Basis der culfw tut das nicht, sondern übergibt das "Roh-Telegramm".


kaihs

#732
Zitat von: chbla am 03 April 2019, 08:29:44
Das klingt interessant - an einem Beispiel Programm wäre ich interessiert, ich will mal ausprobieren was hier so in der Umgebung empfangen wird.

Siehe Anhang. Beide Dateien in einem Verzeichnis ablegen. wmbus_beispiel.pl ausführbar machen (chmod +x wmbus_beispiel.pl ).
Zusätzlich muss noch das CRC Modul installiert werden (sudo apt-get install libdigest-crc-perl). Falls entschlüsselt werden soll noch mehr (sudo cpan -i Crypt::Mode::CBC Crypt::Mode::CTR).
Die auszuwertende Nachricht steht aktuell im Quelltext. Bei Bedarf kannst du dir das ja so umschreiben, dass das z. B. aus einer Datei gelesen wird.

Zitat
Die restlichen Zähler, die ich momentan verwenden will sind von Diehl "IZAR RADIO COMPACT INDUCTIVE"

Die zweite Zeile ist wahrscheinlich von so einem Zähler und da gilt leider die selbe Einschränkung wie bei Techem.
Banana Pi, Add-On Board mit 1.8" TFT LCD und IR-Sender, CULFW V1.61, div. Homematic Komponenten, Pollin Funksteckdosen, Selbstbau CUL433 MHz, Jeelink Clone, EC3000
Selbstbau CUL868MHz für Wireless M-Bus, SIGNALduino mit Logilink Temp.-sensoren und Auriol Wetterstation

chbla

Zitat von: kaihs am 03 April 2019, 20:37:17
Siehe Anhang. Beide Dateien in einem Verzeichnis ablegen. wmbus_beispiel.pl ausführbar machen (chmod +x wmbus_beispiel.pl ).
Zusätzlich muss noch das CRC Modul installiert werden (sudo apt-get install libdigest-crc-perl). Falls entschlüsselt werden soll noch mehr (sudo cpan -i Crypt::Mode::CBC Crypt::Mode::CTR).
Die auszuwertende Nachricht steht aktuell im Quelltext. Bei Bedarf kannst du dir das ja so umschreiben, dass das z. B. aus einer Datei gelesen wird.

Die zweite Zeile ist wahrscheinlich von so einem Zähler und da gilt leider die selbe Einschränkung wie bei Techem.

Vielen Dank @kaihs für den Code, ich bin leider noch nicht dazugekommen das zu testen.
Ich melde mich sobald ich dazugekommen bin, wollte aber schonmal Danke sagen!

blaxbox

#734
Hy,

kann es sein, dass es in manchen Bereich Probleme mit dem shiften gibt?
z.B. in decodeDataInformationBlock bei tariff u. devUnit:
im Code:
$tariff    |= (($dif & 0b00110000 >> 4)) << (($difExtNo-1)*2);
$devUnit   |= (($dif & 0b01000000 >> 6)) << ($difExtNo-1);

da wird meiner Meinung nach die Maske geshiftet u. dann das log. UND ausgeführt.
Habs getestet, so passt das bei mit zumindest:
$tariff    |= (($dif & 0b00110000) >> 4) << (($difExtNo-1)*2);
$devUnit   |= ((($dif & 0b01000000) >> 6) << ($difExtNo-1));

Auch bei decodePayload beim INT48 Wert geht was schief, da "+" bei den words gerechnet wird:
im Original:
$value = $words[0] + $words[1] << 16 + $words[2] << 32;

bei mir ausgebessert:
$value = $words[0] | ($words[1] << 16) | ($words[2] << 32);

dann stimmt der INT48 Wert.


lg