New Binding: Wireless M-Bus / Techem heat cost allocators

Yes, I did read the posts before :slight_smile:
But I was not sure if a new build is needed only when major version changes (OH 2.x => 3.x) or also if the minor version changes.
And if a newer build in the OH3.2 ecosystem is already available somewhere…

I made a build for OH 3.2 but I couldn’t get it running with my setup based on Amber yet. I don’t use rxtx serial stuff due to permission issues. I see that with a serial port handling delegated to openHAB a lot of data is being discarded for no reason. Do you observe same with your setup @JensH?

Good question, how could I check?

At the mom er n to I still work with the 05.08. snapshot and world great

Version I did ( is based on openHAB serial transport API. It suffers from discarding of (almost) all data. Seems that commands related to setup of amber dongle are not sent or processed properly by radio stick itself. I presume earlier one. In order to narrow this issue fully I really have to dive into what the jrxtx does differently from rxtx and why. All above layers, beside serial port handling are same as they were. Only after narrowing this gap I will be able to make (and publish) a stable build.

Hm, I could test at the weekend. How could I help?

Hi, i just came across this whole OpenHab topic at the end of last year, as i wanted to collect some metering data and make it visible using some nice UI and also supporting rules to trigger certain actions.
As one of my meters data is sent via the wmbus protocol i digged into analyzing the packets using a CUL stick (as this was the cheapest option to receive telegrams of 868mhz frequency and it supports a lot of different protocols - not only wmbus). So i stumbled across this nice little plugin here to receive wmbus data and process it within openhab. Sadly it did not support the CUL out of the box. But as the CUL protocol is quiet simple i played around to integrate support into the existing openhab-wmbus-binding. A pull request is already created (RCL-1 added cul support by rcliebig · Pull Request #10 · KuguHome/openhab-binding-wmbus · GitHub), but i would like to get some more input from different users to see that its working as expected. Please find a prebuild jar for openhab 3.2.0 here: Releases · rcliebig/openhab-binding-wmbus · GitHub . I’m happy for any feedback you can provide and hope that due to the change many more users will get attracted to this nice little binding.


I invested in a stick from würth, because this can listen same time different wmbus-protocols.

Since wmbus binding sadly doesn’t assist all my devices I activated wmbusmeters, saving json per device and easily can be integrated at a thing with all needed channels.

If the protocol is easy, it wont be a big issue to implement the würth stick into openhab-wmbus-binding aswell.

The stick works. But devices not all covered I need

Hello Robert,

I tested with FHEM + CUL on an own RPi and there the Techem discovery works (I found ~50 devices in the building :slight_smile: ). Now I wanted to bring all this to my ‘real’ Home Automation, OpenHab on Docker on RPi. First I wanted to start an FHEM-Container and then transfer the data via MQTT, but then I found your AddOn - great - exactly what I was looking for!

Only I always get the status ‘unknown’ when adding a WMBus Thing (CUL, /dev/ttyACM0).

Screen /dev/ttyACM0 on RPI level (not inside the Docker Container) works. Of course in Docker Compose I entered /dev/ttyACM0, I hope the authorizations are also ok (how to check?).
In the OpenHab log I get the warning:
[WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NoClassDefFoundError: org/openhab/core/io/transport/serial/UnsupportedCommOperationException
at ~[?:?]

The ‘openHAB Add-ons :: Bundles :: Serial Binding 3.3.0’ is active, also many other Serial related (USB discovery, RXTX, Transport, …)

Maybe it was an authorization issue? I tried this on RPi level:
$ sudo adduser pi dialout
$ sudo chmod a+rw /dev/ttyACM0
and I also deleted the ‘Serial Binding’ Thing (I think it was blocking the port) and now the WMBus Stick Thing has a green ‘online’ Tag . Yeah!
Only in 30 min nothing has arrived, while on FHEM every few minutes a package arrived. The CUL is flashed with the latest firmware from here: Home of culfw

Latest Update:

  • Everything is working fine :slight_smile: . Great! Only it seems that with OpenHab much less packages arrive than with FHEM. I will work on finding a good position for the sensor. Now I only have to map the newly found Items to my physical heating. My Techem devices are quite new, so I have no Techem billing document as a help.
    But as a summary - with this AddOn a CUL can be added to OpenHab running in Docker. I would support to add the AddOn to the real / official AddOn channel.

Thanks a lot!

OpenHab and Techem works fine via the CUL USB-Stick. I found many sensors and got over 1000 messages now in the Device Activity Log. In the last 7 days I made two observations:

  • Techem Cold Water and Warm Water is not discovered (FHEM with the same USB-CUL found them)
  • In the Techem HKV 94 the ‘Current Reading’ is for all the sensors always above 256, even if the ‘Last Reading’ is for example 0 - maybe a bug…

With the readings displayed on the sensors (the 4-digit number) I was not able to do the mapping to the results from OpenHab. The numbers are not matching at all… Anyone an idea which transformation I have to do?
Thanks again!

Quick question on this topic: Since 1,5 years I‘m using weetmuts‘ wmbusmeters (see here) on my Docker setup to read out two Techem meters with my Amber stick. A bit tricky to get running, but once running, rock stable.

Out of curiosity: Is this binding more like a „plug-and-play“-solution, especially on openHABian?

Hi @Martin_HD , thanks for your nice feedback! The plugin is actually receiving the only the packets of a certain wmbus mode. (T,S,C). I dont know how FHEM interacts with the stick, maybe it is configuring the stick to receive packets from all wmbus modes in parallel.

maybe you can post some example packets that you are missing to receive in the openhab wmbus binding, and we can check why it is being ignored.


@Cplant it is meant to be plug and play, whereas sometimes you have to play around with the serial libraries a bit.

Hi Robert,
On FHEM I set up the CUL to only use ‘T’, similar to my OpenHab setting. I now compared the results of the parsing for FHEM and OpenHab for the HKV94 devices (“Current Reading”). Here some examples:

Device ID Current Reading FHEM Current Reading OpenHab
416476 1208 260
394599 814 259
11774108 772 259
11774683 408 257

Here is the package dump for one Device (11774683) from OpenHab:
Manufacturer: TCH: 6850834677119480
Type: RESERVED: 80
Version: 148: 94

  • 2022-08-10T10:58:47.778


  • 2022-08-10T11:02:55.781


  • 2022-08-10T11:06:56.561


  • 2022-08-10T11:10:57.583


  • 2022-08-10T11:14:59.083


  • 2022-08-10T11:19:00.017


  • 2022-08-10T11:27:08.803


  • 2022-08-10T11:35:11.321


  • 2022-08-10T11:39:12.258


  • 2022-08-10T11:43:20.256


  • 2022-08-10T11:47:21.030


With regards to the Cold Water / Warm Water I am waiting for FHEM to log something, these sensors send out very seldomly…

Thanks a lot!!! Martin

Techem decoding was implemented a while ago based on FHEM. It was ported over in a very, very basic way. I been refactoring it back in 2018/2019 to make some sense out of multiple Techem device variants seen in a wild but I think Kugu-Home (company which sponsored development of binding) ended up doing its own heuristics on top of already collected frames.

If you see differences in how data is being displayed - feel free to patch binding and align its logic with FHEM.


Hello Łukasz,
…for sure I am not a developer… So the only thing I could do was browsing through the coding. To me this seems quite interesting, as the parsing of ‘94’ and ‘69’ is slightly different in FHEM:
fhem-mirror/ at master · mhop/fhem-mirror · GitHub → line 227

[  # temp sensor 1
  if ($message->{version} eq '94') {
    $message->{temp1} = sprintf "%.2f", (hex(join '', reverse split /(..)/, substr $msg, 40, 4) / 100);
  } elsif ($message->{version} eq '69') {
    $message->{temp1} = sprintf "%.2f", (hex(join '', reverse split /(..)/, substr $msg, 38, 4) / 100);

  # temp sensor 2
  if ($message->{version} eq '94') {
    $message->{temp2} = sprintf "%.2f", (hex(join '', reverse split /(..)/, substr $msg, 44, 4) / 100);
  } elsif ($message->{version} eq '69') {
    $message->{temp2} = sprintf "%.2f", (hex(join '', reverse split /(..)/, substr $msg, 42, 4) / 100);

I could not find the corresponding line here and below: openhab-binding-wmbus/org.openhab.binding.wmbus/src/main/java/org/openhab/binding/wmbus at RCL-2-updating-to-OH3-2-0 · rcliebig/openhab-binding-wmbus · GitHub
But for sure I can have overlooked it…

Update on the Warm Water → now I have received a few messages (receiving frequency depends on how the wind blows…) and they seem to be fine :slight_smile:

You can check this code:

There should be also associated unit test, if not then create a new one and test it with your frame until you get proper output.

As far I remember (its 3 year old knowledge) there were some variants of HKV’s and also other techem devices so there was a need to distinguish them based on part of the payload. It complicated a lot hence matching of frame with its decoder got one more trouble to cover.