WMBUS - TECHEM

[harryzz]

hello
there are sniffed data from Techem FHKV data III: working on WMBUS_T
b3244685043286532698051C3A015701B0000D0126E033E09450900005BBA000000000000000000242F355336666C912E68676D4D0200000000333381
the last period on display is exactly after   :"1B0000D012" - 2 bytes little endian in this case 878 ( 0x6E03 ).
more info late in october when heating will be switched on 
Also there data i think but not sure bcoz srial number in documents do not match the serail number in telegram sniffed from water metters also techem data III
from heat wator meter:
b2F44685046172042746227CEA2062B1D0000D0120000040000000000A18E00000000000000000000000000000000FFFF000000000000FFFF802C
and cold water meter:
b2F4468502318204274722D27A2062B1D0000D0120200040002000000F16300000000000000000000000000000000FFFF000000000000FFFF8031

if someone interested and need more info, sniffed data please contact me.
.
br,
Harry

[kaihs]

Hi,

I'm not sure if you are aware of the 36_WMBUS.pm fhem module which handles W-MBus data packets.
This module implements the W-MBus standard as specified in the standard definition of the oms-group.

Unfortunately TECHEM doesn't comply with this standard.
Each W-MBus starts with a header. The first byte of the of the first application data block (called CI-field) specifies the application protocol used in the rest of the packet.
Your packets contain a CI-field of a2 or a0.
Both are not specified in the standard.

If you are interested in decoding the data from your meters you might contact Techem if they are willing to provide the specification for the protocol they use.
Than I might be able to implement this in my module.

Regards,

Kai

[harryzz]

Hello
I'm sure that TECHEM will NOT BE happy to share protocol for public like all big companies.
Also there user portal of  Techem site ( german only) i think they have own system for home automation.
I will try to reverse protocol and will share results here. i already know some data. Also found i think where is date/time coded for current reading. I you interested i give more logs and post my suggestion.


br
Harry

[kaihs]

Hello
I'm sure that TECHEM will NOT BE happy to share protocol for public like all big companies.
Also there user portal of  Techem site ( german only) i think they have own system for home automation.
I will try to reverse protocol and will share results here. i already know some data. Also found i think where is date/time coded for current reading. I you interested i give more logs and post my suggestion.

I'm certainly interested, please share your progress.

Maybe the (W)M-Bus specification is helpful for you:
M-Bus http://www.m-bus.com/files/MBDOC48.PDF
Wireless M-Bus http://oms-group.org/download4all/

[harryzz]

Hi

attached file with sniffed data from 3 days and some comments.
what about EN 13757-3 there may be can be found some info about custom CI fields?


br
Harry

[kaihs]

Just one more info: make sure that you are using the newest culfw (see http://forum.fhem.de/index.php/topic,24517.msg198228.html#msg198228).
Otherwise the last byte is incorrectly interpreted as RSSI while it is really part of the wmbus packet.

[harryzz]

hello 10x for info.
also i have other problem with CUL -> when switch to WMBUS mode no problem but switching back to SlowRF no more data received until i unplug CUL from USB and plug again.
Now about Techem Wm-bus messages:
there are 2 records  from 15-09 and 16-09

2014.09.15 19:17:06 4: CUL_Parse: CUL_0 b3244685043286532698051C3A015701B0000[F012]6E032009380900005ACE000000000000000000242F355336666C912E68676D4D020000000033338248 -38

2014.09.16 07:56:12 4: CUL_Parse: CUL_0 b3244685043286532698051C3A015701B0000[0013]6E0309091B090000A28500000000000000000000242F355336662F476C68676D4D020000003C418343 -40.5

My suggestions are something like this:

little endian:
0x12F0 -> 000[1001][01111]0000
0x1300 -> 000[1001][10000]0000

month and day.
but somewhere must be coded year i think.

br,
Harry

[kaihs]

also i have other problem with CUL -> when switch to WMBUS mode no problem but switching back to SlowRF no more data received until i unplug CUL from USB and plug again.

I had a short look at that, it's probably a bug in 00_CUL.pm.
WMBus mode isn't disabled when switching back to SlowRF.
I'll investigate further and will prepare a patch for Rudolf to fix the problem.
In the mean time a

Code Auswählen Erweitern


set CUL raw bx
set CUL raw X21

should switch back to SlowRF.

My suggestions are something like this:

little endian:
0x12F0 -> 000[1001][01111]0000
0x1300 -> 000[1001][10000]0000

month and day.
but somewhere must be coded year i think.

This is how a date is encoded in a standard WMbus message

Code Auswählen Erweitern


#value is a 16bit int

#day: UI5 [1 to 5] <1 to 31>
#month: UI4 [9 to 12] <1 to 12>
#year: UI7[6 to 8,13 to 16] <0 to 99>
 
#   YYYY MMMM YYY DDDDD
# 0b0000 1100 111 11111 = 31.12.2007
# 0b0000 0100 111 11110 = 30.04.2007


Doesn't seem to fit your data though.