Yes, I did read the posts before
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 (https://github.com/ConnectorIO/openhab-binding-wmbus/) 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.
Robert
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:
- Everything is working fine
. 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!
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:
- 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.
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
- 2022-08-10T10:58:47.778
33446850834677119480A20F9F2B4C02A010980101C209B209000000000000000000021D0E183C527C494D5E2F230D0A02000000
- 2022-08-10T11:02:55.781
33446850834677119480A20F9F2B4C02A010980101CA09B809000000000000000000021D0E183C527C494D5E2F230D0A02000000
- 2022-08-10T11:06:56.561
33446850834677119480A20F9F2B4C02A010980101D409BE09000000000000000000021D0E183C527C494D5E2F230D0A02000000
- 2022-08-10T11:10:57.583
33446850834677119480A20F9F2B4C02A010980101DE09C309000000000000000000021D0E183C527C494D5E2F230D0A02000000
- 2022-08-10T11:14:59.083
33446850834677119480A20F9F2B4C02A010980101E509CB09000000000000000000021D0E183C527C494D5E2F230D0A02000000
- 2022-08-10T11:19:00.017
33446850834677119480A20F9F2B4C02A010980101EC09D009000000000000000000021D0E183C527C494D5E2F230D0A02000000
- 2022-08-10T11:27:08.803
33446850834677119480A20F9F2B4C02A010980101FB09DD09000000000000000000021D0E183C527C494D5E2F230D0A02000000
- 2022-08-10T11:35:11.321
33446850834677119480A20F9F2B4C02A0109801010C0AE909000000000000000000021D0E183C527C494D5E2F230D0A02000000
- 2022-08-10T11:39:12.258
33446850834677119480A20F9F2B4C02A010980101150AF109000000000000000000021D0E183C527C494D5E2F230D0A02000000
- 2022-08-10T11:43:20.256
33446850834677119480A20F9F2B4C02A0109801011F0AF609000000000000000000021D0E183C527C494D5E2F230D0A02000000
- 2022-08-10T11:47:21.030
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.