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 
). 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 org.openmuc.jrxtx.SerialPortBuilder.build(SerialPortBuilder.java:140) ~[?:?]
…
The ‘openHAB Add-ons :: Bundles :: Serial Binding 3.3.0’ is active, also many other Serial related (USB discovery, RXTX, Transport, …)
Update…
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:
. 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.Thanks a lot!
Martin
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:
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.
regards
Robert
@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
33446850834677119480A20F9F2B4C02A010980101C209B209000000000000000000021D0E183C527C494D5E2F230D0A02000000
33446850834677119480A20F9F2B4C02A010980101CA09B809000000000000000000021D0E183C527C494D5E2F230D0A02000000
33446850834677119480A20F9F2B4C02A010980101D409BE09000000000000000000021D0E183C527C494D5E2F230D0A02000000
33446850834677119480A20F9F2B4C02A010980101DE09C309000000000000000000021D0E183C527C494D5E2F230D0A02000000
33446850834677119480A20F9F2B4C02A010980101E509CB09000000000000000000021D0E183C527C494D5E2F230D0A02000000
33446850834677119480A20F9F2B4C02A010980101EC09D009000000000000000000021D0E183C527C494D5E2F230D0A02000000
33446850834677119480A20F9F2B4C02A010980101FB09DD09000000000000000000021D0E183C527C494D5E2F230D0A02000000
33446850834677119480A20F9F2B4C02A0109801010C0AE909000000000000000000021D0E183C527C494D5E2F230D0A02000000
33446850834677119480A20F9F2B4C02A010980101150AF109000000000000000000021D0E183C527C494D5E2F230D0A02000000
33446850834677119480A20F9F2B4C02A0109801011F0AF609000000000000000000021D0E183C527C494D5E2F230D0A02000000
33446850834677119480A20F9F2B4C02A010980101250AFC09000000000000000000021D0E183C527C494D5E2F230D0A02000000
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.
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.