Wireless M-Bus für CUL

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

Vorheriges Thema - Nächstes Thema

Termlnator

Hallo,

so langsam, denke ich, komme ich voran.
Ich habe folgendes gemacht:
-in
Zitat/etc/udev/rules.d/
eine Datei 50-usb.rules erstellt mit eine Zeile:

ACTION=="add", ATTRS{idVendor}=="1574", ATTRS{idProduct}=="999a", RUN+="/sbin/modprobe ftdi_sio" RUN+="/bin/sh -c 'echo 1574 999a > /sys/bus/usb-serial/drivers/ftdi_sio/new_id'"

-danach mit

sudo udevadm control --reload
neu geladen und Stick rein dann mit

dmesg

bekommen:

Zitat[154436.022220] usb 1-1.3: Product: VSM-100 Funkstick
[154436.022243] usb 1-1.3: Manufacturer: HKW-Elektronik
[154436.022261] usb 1-1.3: SerialNumber: 2D000AA6
[154436.128401] ftdi_sio 1-1.3:1.0: FTDI USB Serial Device converter detected
[154436.129510] usb 1-1.3: Detected FT232RL
[154436.133020] usb 1-1.3: FTDI USB Serial Device converter now attached to ttyUSB1

Als nächstes im FHEM
define Amber AMB /dev/ttyUSB1@38400

und der wurde dann von FHEM initialisiert  :)

aber set Amber raw brs oder brt
wird nicht angenommen. Meine Frage fehlt noch was oder habe irgendwo noch Fehler gemacht ?

Hiermit möchte ich mich bei allen bedanken für die Hilfe und Tipps.
Gruss
Martin

kaihs

Ich habe mir das 00_AMB Modul jetzt nicht angesehen, aber ich glaube du brauchst nichts weiter machen.
Der Stick sollte automatisch im Empfangsmodus sein und sobald etwas empfangen wird sollte ein device angelegt werden.
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

tjk

#497
Hallo Zusammen,

ich versuche gerade meinen EasyMeter Stromzaehler (Q3MB81120 V6.03 mit Modul ESYS-WM10 V2.10) per WMBUS in FHEM einzubinden. Aber entweder hat der Hersteller da in den aktuellen Versionen etwas verändert, oder ich mache irgendetwas grundlegendes falsch.

Das Device wurde korrekt automatisch angelegt, es gibt jedoch ein Problem beim Parsen der Daten:

CUL_0_RAWMSG b244479162875726010024CFA8C0083900F012C25170400002EB310F922594A142E2570F002FD1701004830A7::-74.5
DeviceMedium Electricity
DeviceType 2
IODev CUL_0
IdentNumber 60727528

TYPE WMBUS
Version 16
addr ESY_60727528_16_2

Readings
LQI 161 19.12.2017 00:15
RSSI -73 19.12.2017 00:15
state Unsupported CI Field 8c, remaining payload is 0084900f012c25180400000f2cff840d7bb89a70f002fd170100 19.12.2017 00:15



Irgendjemand ne Idee? CI-Field 0x8c gehoert wohl zu einem Extended Link Layer. Dazu findet man aber nicht all zu viel im Internet.

Nachtrag: Okay, die Neuerung ist der Support fuer AFL (Authentication und Fragmentation Layer) - jetzt noch sicherer. Die gute Nachricht ist, dass das BSI in TR03109 eine Menge Informationen dazu veroeffentlicht hat. Sofern niemand das schon implementiert hat, versuche ich mal ob die frei verfügbaren Dokumente reichen um das zu implementieren.

Viele Grüße
Thorsten

kaihs

Wie du schon erkannt hast, ist ELL und AFL relativ neu und war noch nicht Teil des Standards als ich das WMBUS Modul geschrieben habe.

Mittlerweile ist es in den Dokumenten vom OMS enthalten. WMBUS ist aber auch so schon ein ziemlich wirres Format und wird dadurch nicht übersichtlicher.
Da die zusätzliche Verschlüsselung aber wohl immer mehr Verbreitung finden wird werde ich mal versuchen das einzubauen.
Kann aber keinen Termin versprechen.
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

tjk

Hallo Kai,

danke fuer die Rueckmeldung. Ich hab inzwischen auch selber noch ein bisschen gebastelt und einen Minimal-Decoder geschrieben. Leider sieht es zumindest im Moment so aus, als sei das neue Übertragungsformat nicht mein einziges Problem: Meine Nutzdaten haben ein CI-Field 0x70 (Application Error, shall be used for wired M-Bus only!). Ich hab zwischen den Jahren Urlaub, vielleicht mach ich ja auch noch was beim decodieren falsch.

Thorsten

kaihs

Hast du die Daten nach dem AFL denn entschlü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

kaihs

Ach noch etwas, schau dir mal die Anhänge von diesem Post.

In der zweiten Datei ist das in Abschnitt 2.5 erklärt, das Funkmodul bekommt dann wohl keine Daten vom Zähler.

Falls du die Entschlüsselung hinbekommst kannst du mir ja mal einen Tipp geben wie du den CMAC berechnest.
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

bilbolodz

Zitat von: bilbolodz am 08 November 2017, 08:47:23
Firmware recompiled and loaded. Waiting for messages from meter.
Finally I've managed to catch complete messages. Unfortunately it's NOT decoded by FHEM. Logs bellow:

2017-12-24_08:29:10 WMBUS_APT_00036030_3_3 RSSI: -38
2017-12-24_08:29:10 WMBUS_APT_00036030_3_3 LQI: 128
2017-12-24_08:29:10 WMBUS_APT_00036030_3_3 Unsupported CI Field a0, remaining payload is a1e532000c4000370c0803180c1134dc4e0a0306ff0b394c2a00c7902a009dec2a007
1aa2b00a29c2d00c7722f001d4930001aaf31006e083200ac583200c8a032006c092a00030000000037bd081f000000002000000000000023000000002400000000000027000000280000000000002
c00200301050c2f000000000000
2017-12-24_08:30:58 WMBUS_APT_00036030_3_3 Unsupported CI Field a0, remaining payload is a1e532000c40002a0e0803180c1134dc4e0a0306ff0b394c2a00c7902a009dec2a007
1aa2b00a29c2d00c7722f001d4930001aaf31006e083200ac583200c8a032006c092a00030000000037bd081f000000002000000000000023000000002400000000000027000000280000000000002
c00200301050c2f000000000000
2017-12-24_08:33:46 WMBUS_APT_00036030_3_3 Unsupported CI Field a0, remaining payload is a1e532000c40001f110803180c1134dc4e0a0306ff0b394c2a00c7902a009dec2a007
1aa2b00a29c2d00c7722f001d4930001aaf31006e083200ac583200c8a032006c092a00030000000037bd081f000000002000000000000023000000002400000000000027000000280000000000002
c00200301050c2f000000000000
[..]
2017-12-24_10:37:42 WMBUS_APT_00036030_3_3 Unsupported CI Field a0, remaining payload is ebe532000c40001b150a03180c1134dc4e0a0306ff0b394c2a00c7902a009dec2a007
1aa2b00a29c2d00c7722f001d4930001aaf31006e083200ac583200c8a032006c092a00030000000037bd081f000000002000000000000023000000002400000000000027000000280000000000002
c00200301050c2f000000000000

Ingram

Hi everyone!

Excuse me for writing in English. I can read and understand German, but I have difficulties writing as I have forgotten most of the vocabulary (it takes too long to write).

A few days ago I started looking into how to receive packets from Kamstrup multical 21 water meter that was installed by the utility company a year ago. To my disappointment only S and T-mode was supported, but the meter works in C1 mode as it has been pointed out in this very topic years ago. I was not aware if any of the forks supported it.

After digging through application notes from most major chipmakers, I have now achieved what I was looking for - RX for C1 mode B-type frames. A-type frames can be easily supported as well, but I don't have a device to test with nor had the interest to investigate the structure.

My changes to firmware can be found from https://github.com/Ingramz/culfw

You will need to compile the source, any binaries found are out of date.

To use: type `brc`, which is able to receive both T-mode and C-mode frames, which are prefixed in following manner:
btXXXX... - T mode frame A
bcaXXXX... - C mode frame A (not implemented)
bcbXXXX... - C mode frame B (new)

`brt` will only capture T-mode frames in order to maintain backwards compatibility with existing applications.

I don't have the AES key for my water meter, which I am planning to ask from the utility company soon enough, but since the CRC16 is correct and the unencrypted fields seem to match what is on the nameplate, I am rather confident that the received bytes are also correct.

Any feedback would be appreciated and if anyone is interested in merging this into the main firmware, please let me know.

kaihs

Zitat von: bilbolodz am 24 Dezember 2017, 10:40:38
Finally I've managed to catch complete messages. Unfortunately it's NOT decoded by FHEM. Logs bellow:

Unfortunately CI-field A0 means the data is manufacturer specific and not documented in the official specification.

The manufacturer code is APT, according to dlms.com that is
Apator SA (Gas, water and heat), ó kiewskiego 21/29, Toru , Poland 

Maybe you can get information from them regarding the data format they use.

Another possibility is reverse engineering it yourself as has been done for Techem heatcostmeters.
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

bilbolodz

Zitat von: kaihs am 28 Dezember 2017, 12:17:36
The manufacturer code is APT, according to dlms.com that is
Apator SA (Gas, water and heat), ó kiewskiego 21/29, Toru , Poland 
It's strange. I've expected message from my WATER meter NOT gas meter (I don't have gas meter). I've have meter at-wmbus-08 (http://www.apator.com/en/offer/water-and-heat-metering/remote-reading-systems/wireless-water-meters-reading-system/at-wmbus-08-16). Manufacturer is indeed Apator so maybe messages are from my meter????



kaihs

Zitat von: Ingram am 27 Dezember 2017, 19:14:48
A few days ago I started looking into how to receive packets from Kamstrup multical 21 water meter that was installed by the utility company a year ago. To my disappointment only S and T-mode was supported, but the meter works in C1 mode as it has been pointed out in this very topic years ago. I was not aware if any of the forks supported it.

After digging through application notes from most major chipmakers, I have now achieved what I was looking for - RX for C1 mode B-type frames. A-type frames can be easily supported as well, but I don't have a device to test with nor had the interest to investigate the structure.

My changes to firmware can be found from https://github.com/Ingramz/culfw

Great work!
I can't test if it works as I have no equipment that is sending in C-mode.
Just by looking at the code I can't easily identify the changes you made, thus a patch (see below) would help.

Zitat
You will need to compile the source, any binaries found are out of date.

To use: type `brc`, which is able to receive both T-mode and C-mode frames, which are prefixed in following manner:
btXXXX... - T mode frame A
bcaXXXX... - C mode frame A (not implemented)
bcbXXXX... - C mode frame B (new)

`brt` will only capture T-mode frames in order to maintain backwards compatibility with existing applications.

Are the different prefixes for the different modes necessary? The payload should be the same for all modes, shouldn't it?
I suggest you send the data just as before, i.e. bXXXX, independent of the mode used.
This is already the case for mode T and S and the current WMBUS module isn't be able to handle the new prefixes.

If you want your changes included into the official culfw you probably should create a patch against the current official culfw and post it in this forum in a new thread asking Rudolf König for inclusion.
It would also be nice if you extended 00_CUL.pm with a new option for rfMode WMBUS-C and post a patch alongside the culfw patch.
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: bilbolodz am 28 Dezember 2017, 12:30:17
Manufacturer is indeed Apator so maybe messages are from my meter????

Is the S/N 00036030 printed somewhere on your meter?
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

bilbolodz

Zitat von: kaihs am 28 Dezember 2017, 12:50:59
Is the S/N 00036030 printed somewhere on your meter?
Unfortunatelly not. Picture of my meter in attachment.

bilbolodz

Zitat von: kaihs am 28 Dezember 2017, 12:17:36Maybe you can get information from them regarding the data format they use.
I've wrote an message to the vendor. I'm NOT expecting any replay but maybe......