Hi everybody,
I just wanted to let you know that I am currently working on a new openHAB2/Eclipse Smart Home binding to receive the messages sent by Techem heat cost allocators vario 4 (Heizkostenverteiler) via Wireless Metering Bus (WMBus).
You can find it here:
There has been some interest and even some effort on this earlier:
Those links all refer to openHAB 1, also the pull request was never incorporated. My effort is a new approach without using the code from the old PR.
What I am using though, is the library jMBus by the openMUC project of the Fraunhofer Institute for Solar Energy Systems (ISE) in Freiburg, it is included in the binding, with a small patch, which I submitted to them recently and hope that it will be included upstream. It in turn uses the RXTX library, which is therefore also included in the binding, together with the native parts for Windows and Linux. It seems, one needs to install librxtx-java via packet manager as well.
I use an Amber Wireless AMB8425-M USB stick as receiver, which is supported by the library. It is available for example at http://www.mysmartshop.de/amber-wireless-m-bus-usb-stick-amb8465-m.html. It should be possible to use a CUL (which I donāt have yet) as well, thatās what the FHEM people use, to whom most of the credits on decoding the messages go to here: Wireless M-Bus fĆ¼r CUL, WMBUS - TECHEM, war: Techem HKV (ok) -> war WasserzƤhler (ok) -> war WƤrmemengenzƤhler (ok), Testversion: 32_TechemWZ, Rauchmelder von Techem, WMBUS ā FHEMWiki, TechemHKV ā FHEMWiki, FHEM reference
There was some earlier and less deep reverse engineering approach, which is still quite impressive and interesting:
There is also a privacy issue here: All devices transmit their data openly very regularly (1-10 minutes), and they have quite some range, so you can easily read the temperature of all your neighbours rooms. You donāt, however know, which device is in which room of which neighbour and it is questionable, how much information you are able to deduce from the readings, but still it would be much better if the AES encryption defined in the standard would be used. This, however would stop us from reading our own meters as wellā¦
The binding is not yet working completely, only the āfirst stepā: You can manually add a new bridge-type thing, representing the receiver stick, fill in the device name (like /dev/ttyUSB0) and henceforth see the messages received in the console. Also, for every message, a new DiscoveryResult will be created in the Inbox, representing the different heat cost allocators. openHAB updates results of the same allocator instead of creating a new one. This way I have around 70 results, 6 of which are ours and the others most probably from the neighbours in the flats around us.
You can also add those results as things and they show up in the control section, but the data from the messages is not filled in yet, I am still working on this.
A received message (in decoded form) looks like this:
Sat Nov 19 15:02:02 CET 2016;-62;68;TCH;92313926;105;RESERVED;160;11;2016-06-30;208;2016-11-19;7;16.46;16.48;000600060100000000000000000000000f00161a271d2f0a01000b
receivingDateTime;RSSI;controlField;vendor;deviceID;version;deviceType;controlInformation;status;lastDate;lastValue;currentDate;currentValue;temperature1;temperature2;almanac
The vendors can be looked up here: http://dlms.com/organization/flagmanufacturesids/index.html. The deviceID is the one also shown in the display and listed on the heating bill. The lastDate is the end date of the last metering period, lastValue is the corresponding meter value (which is also shown on the display), currentDate is ā¦ well the current date and currentValue the current metering value, (also shown on the display). temperature1 and 2 are the room temperature and that of the radiator, the difference is used to calculate the metering value internally. Lastly, the almanac seems to carry bi-wekly information on the last heating period, so that you could deduce, how much heat was used in the separate bi-weeks. There is a patent on the compression for this, meaning that the complete algorithm is open: EP About this file - European Patent Register / EPO - European Publication Server, I didnāt bother to try to understand the mathematics of this and implement it, because as soon as you add the things to openHAB, it will have an even higher resolution. But implementing this might be interesting for academic reasons or to evaluate the last metering period before introduction to openHAB.
The most valuable information is probably the metering value (which is only set daily) and the temperature (which is sent live). This way, you have exact measurements of all of your rooms free of charge, IF you live in a rented flat, have those devices and they are set to transmit. They can be set to be quiet, which is cheaper for the landlord, I guess, in this case they do not show a radio tower in the display.
So, feel free to try it out or have a look into the code, I am open to questions, suggestions and remarks. It is totally in the scope of this binding, to later also read other WMBus devices like the EnergyCam or other Techem devices like water or heat meters or smoke detectors, which are currently rolled out to many german homes because of a legal requirement and use other receivers like the CUL or Amazon.de or Wireless M-Bus USB Stick iM871A | Smart Meter fĆ¼r HomeMatic or USB Meter Reader - Stick - wM-Bus - WebShop Kernbauer Energy Solutions GmbH, but currently I have neither of those devices, so I canāt do it, it would therefore be a second or third step and I would need help from others.
Until the binding is mature enough, I plan to leave it in the custom Java package namespace and as a single binding repo. But as soon as it works reliably, I would like to move the package and do a pull request against the official repo.
So, have fun and let me know, what you think and if you are interested! 
Cheers,
Hanno
