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.
The cul can also receive S mode messages as per the commandref from www.culfw.de
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.
1 Like
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.
1 Like