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.
Best,
Łukasz
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/32_TechemHKV.pm 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 
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.
Can someone sum-up the supported hardware, that is used and discussed?
I dont think that there is something generic to use for?
Hi @Oekel ,
I’m currently using a Busware CUL device (eg this one: busware.de) attached to a raspberry pi which is running the openhab instance.
It should receive all sensors that are wmbus compatible and dont use vendor specific implementations.
Hi @Oekel,
I am also using the CUL, with a 3m long USB cable. OpenHab is running via Docker on a RPi, as I have several other packages (TVHeadend, Raspberrymatic, …). Even on Docker the connection to CUL works fine.
Everything was working successful with my setting (RPi, Docker, CUL) and I managed to get a lot of data from many others. But never from my own Techem Sensors. It seems like my devices (Techem FHKV radio 4 / EHKV vario 4) are sending completely differently (but how…?): Techem Radio 4 - Wurde das Protokoll geändert?
So to me it seems that the new generation cannot be used as sensors for FHEM, OpenHab, … any more in general 
Techem uses wm-bus protocol but sends data using vendor specific encoding which is best known by Techem itself. This means that from library point of view we see just a sequencd of bytes without any assigned meaning.
All techem devices implemented in earlier version of binding were based on logic people did while doing their reverse engineering. Later there were some corrections, but its not a reliable way. You need to look at version/model flags found in wmbus logger and then cross check with binding sources if its recognized.
What confused my the most is, that not even the vendor-specific packages arrived. I also tried this: GitHub - weetmuts/wmbusmeters: Read the wireless mbus protocol to acquire utility meter readings.. Also really nice software!
But like you said - there should have at least been some errors or some unidentified messages - but nothing. So my assumption was, that Techem radio 4 / vario 4 not even send on wm-bus with ‘T’ any more. And the CUL can only receive ‘T’ to my knowledge. Maybe with another receiver hardware?
There are two other modes as far I remember S and T which are supported by Amber dongle, so it might be that your techem devices are on T mode.
I now bought a quite cheap DVB-T USB stick - SDR RTL_433. This is now working fine to detect all the Techem messages. With the docker release from GitHub - weetmuts/wmbusmeters: Read the wireless mbus protocol to acquire utility meter readings. I found all my meters . But they are encrypted . I wrote to Techem via their website - let’s see if they will provide the keys…
From wmbusmeters I can send via MQTT / Mosquitto to OH for other meters - works fine. But of course it would be more convenient to have an OH User-Interface / Binding either for DVB-T sticks or wmbusmeters. Any plans to add an additional hardware in addition to CUL?
By the way, it seems these new Techem sensors send on ‘C’.
Hi All,
I managed to successfully install the binding and find the Techem devices. The devices share the radiator and room temperatures every 4 minutes and once a day the current reading.
However systematically after 2-3 hours of sending of the data the device stop updating the temperatures or any other Information. Yet the device is still online, which means it is still communicating with the Wireless M-Bus dongle.
if you pause and reenable the dongle, you keep receiving the temperature for about 2-3 hours sometime 6 hours and then stop again updating data.
Does anyone experienced the same issue?
Any indication on how to solve it?
Note that I use the binding org.openhab.binding.wmbus-3.1.0-SNAPSHOT-20210805.zip. I use radio mode T.
When I look at the OpenHab log there are no errors reported.
I use a AMB8425 (while the binding is designed for AMB8465-M), is there any difference on the binding to use?
Thank you.
Gianluca.
Hi all,
I want to include the Techem heat cost allocators in openhab. I have a Cul (and also I have ordered a nanoCul). Has anyone tried it with these devices (if I use screen to look in thwe communication I can see mbus messages. I assume that these messages come from the Techem devices)
Which binding is recommended? I tried to install the wmbus 3.1.0 binding, but it is not working (I can not see the the binding/a thing I can install). I am using openhab4. Are there any new bindings for openhab4? Or are there any other working sollutions(MQTT, etc) ? Who has some experiences with this setup?
Best regards,
Andi
From what I can see, they should both run via wmbusmeters. Not the native binding-solution you might be looking for, but it does work. See here.
I’ve tried in April/May this year (2023) to get nanoCul from schlauHAUS running with jmbus, but I failed to stabilize it with openhab-serial adapter. Since then I’ve made some progress to get stable operation of jrxtx (mainly through swapping of legacy native part to nrjavaserial) which let binding work without any major disturbance. While experimenting I looked at other solutions and this CUL seems to be supported not only in wmbusmeters but also iobroker.
I didn’t have time to return to this issue since then, but I can confirm that stick itself is operational, sadly at current stage, beyond openHAB.
@Cplant Thanks for tip about wmbusmeters. I get now values with the cul stick. Now I am struggling a little bit with getting the the values into openhab using MQTT.
If my I understand it correctly, then I have to setup a Mosquitto server and to use the MQTT Binding in Openhab. Correct?
I am running Mosquitto in one Docker container and Wmbusmeters in another container. I found the following line I have to add in the Wmbusmeters.conf:
hell=/usr/bin/mosquitto_pub -h mqtt -u <username> -P <password> -i wmbusmeter -t wmbusmeters/readings/$METER_ID -m "$METER_JSON"
But where can I specify the IP/Port of the mosquitto server?
Also I haven’t any experiences with setting up the mosquito server and the MQTT binding. But step by step…
(I found your HowTo Install & maintain openHAB on Raspi in Docker together with Mosquitto, Duplicati, influxDB, Samba etc - Step by step instruction. This helps in setting up the mosquitto server)
@splatch Thanks for yiur reply. The cul stick is working. I got some values from the heat cost allocators by using wmbusmeters and try now to get the values into openhab via MQTT.
That’s how I do it, correct.
And I won’t be of much use to help setting up the mosquitto server. I set this up more than two years ago, and wrote the tutorial more as a documentation for myself in case I have to re-setup this again. 
Thanks for the HowTo. Now it works and I get the values from my heat cost allocators. It was easier than I thought.