Hi friesenkiwi
This is really great work!
My appartment building have approx 300 appartments, all installed with bothTechem heating meters and water meters.
Do you know how precisely the room temperature is measured by the Techem heating meter?
I don’t have programming skills, but I can implement your binding and give you feed back if wanted?
Thank you
Thank you,
glad you like it! 
But remember, the Techem HKV (Heizkostenverteiler/Heat cost allocators) are NO heat meters! The numbers they show are dimensionless and have no unit, they only carry some relative sense in the overall view and in context with the energy bill and only if they are calibrated correctly to the radiator.
Now, the thermometers included are measuring °C and the messages carry a precision of 0.01°C. I cannot say if they can actually measure that exact. The manufacturer documentation doesn’t mention this.
Regarding the water meters, they should be received by the stick and the library, but since it is not really implemented yet, they won’t show up in the UI, but you will probably see some debug output in the system console/log.
Now, a last word on privacy: You mentioned your house and 300 apartments. Please do not consider to receive all messages of all allocators/meters of all apartments in real time.
This data shouldn’t be transmitted in the first place, especially not without the knowledge and consent of the resident and especially not unencrypted! You have additional knowledge, which allocator and meter is installed in whose apartment, so to you it is personal information of your tenants.
It is one thing to have the water and heat consumptions for a long-time accumulation period such as one year, but it is a totally different thing to have not only such information but even the single room temperatures in a resolution around 1 minute.
I certainly don’t want my landlord to have such information about me and I would consider it creepy, intrusive, offensive and downright illegal for her/him to try.
Please don’t refer that to you specifically, I am only expressing a general thought of ethics here.
So, provided the privacy of the tenants is not violated, yes, of course you can use the binding, I would be very happy to hear of your feedback and to help.
Cheers
Hey friesenkiwi,
many thanks for adding this addon to openhab! I also live in a flat with the Techem HKV, therefor I bought the Amber USB Stick to log the details of my heating behaviour.
Unfortunaly, im not able to see any HKVs, but let me start from the beginning with what i have done…
According to your manual at github, i downloaded your release Github Release and placed it in the opehab addon folder (with changed permissions).
The addon is visible in openhab, and i successfully added the Amber USB Stick to my THINGS
But…
I cannot add any Techem HKVs, cause none of them are visible via the inbox of openhab, nor via a manually added thing, where i added manually the ID, see the following screenshot:
I added some channels to see, if values are updated for my manually set thing, but they are not:
no one?
the above mentioned problem is fixed, i cannot say why, but i can see my devices in the inbox page. everthing works.
but no i am faced with another problem. when this binding is active, my symlinks are not working anymore. meaning, that all other usb sticks (which are connected via a symlink to my device) are not recogniced anymore correctly.
after having installed this binding here, my entire communication was broken with the other bindings (e.g. zwave, maxcul, jeelink lacrosse…)
See the following link: https://community.openhab.org/t/symlinks-not-working/53082/4?u=baggerfahrer
Is anyone facing the same issue?
Hey, @anon71383850, it’s great to hear you are using the binding, I’m glad it’s of interest!
Yes, you are right, that version you are currently using is quite old and has some issues, especially with regard to the serial interface. In the background we are working on implementing more devices, fixing bugs and improving code quality to put up a PR to include it into the main openHAB codebase soon.
This is the latest development version, which should be working now out of the box and conflict-free with other serial bindings like Z-wave.
We are using it stable in several systems in parallel to Z-wave.
Can you please check out, if this works for you? Also, to debug, I would advice to put the following into /var/lib/openhab2/etc/org.ops4j.pax.logging.cfg.
# Define WMBus file appender
log4j2.appender.wmbus.type = RollingRandomAccessFile
log4j2.appender.wmbus.name = WMBUS
log4j2.appender.wmbus.fileName = ${openhab.logdir}/wmbus.log
log4j2.appender.wmbus.filePattern = ${openhab.logdir}/wmbus.log.%i
log4j2.appender.wmbus.append = true
log4j2.appender.wmbus.layout.type = PatternLayout
log4j2.appender.wmbus.layout.pattern = %d{yyyy-MM-dd HH:mm:ss.SSS} [%-5.5p] [%-36.36c] - %m%n
log4j2.appender.wmbus.policies.type = Policies
log4j2.appender.wmbus.policies.size.type = SizeBasedTriggeringPolicy
log4j2.appender.wmbus.policies.size.size = 100MB
# Configure WMBus logging
log4j2.logger.de_unidue_stud_sehawagn_openhab_binding_wmbus.level = TRACE
log4j2.logger.de_unidue_stud_sehawagn_openhab_binding_wmbus.name = de.unidue.stud.sehawagn.openhab.binding.wmbus
log4j2.logger.de_unidue_stud_sehawagn_openhab_binding_wmbus.additivity = false
log4j2.logger.de_unidue_stud_sehawagn_openhab_binding_wmbus.appenderRefs = wmbus
log4j2.logger.de_unidue_stud_sehawagn_openhab_binding_wmbus.appenderRef.wmbus.ref = WMBUS
It will create a new log at /var/log/openhab2/wmbus.log which you can then tail -f to see a live trace of what is happening, which messages are received and how they get parsed.
I’m looking forward to your feedback and will be happy to help out or discuss bug reports or feature ideas.
Cheers,
Hanno
many thanks for this great work! I downloaded and tested the new release, and it works like a charm.
my problems with the symlinks and the serial ports are gone; all the other bindings are working again, like zwave, maxcul and jeelink lacrosse, which are implemetend in my system via different serial ports.
at the moment, debugging is not necessary anymore, so i leave the step you mentioned out with the hint to add some lines to the logging.cfg.
except you need it from me, then i will support! but for me everything is fine at the moment.
Good to hear! 
If you are willing to do the logging, maybe for an hour or day, it would be interesting to see if there are any other devices around you sending, that the binding doesn’t already know.
Please let me know all other comments, questions or feature ideas.
Cheers,
Hanno
i implemented the change of the logging just now; you will get the logfile propably within this weekend.
hey friesenwiki,
see attached my logfile. I just stopped logging this binding again, meaning that the logging content is brand new 
but due to the fact, that this file is 70mb in size, i cannot upload it here… i will send you an pm.
if you see unknown logging content, it could be because of the following device, which is also from techem and maybe communicating in wireless mbus.
this is a hot-water counter, meaning that the used hot water consumption is counted.
Thanks for the logging!
Yes, those water meters are quite popular as well and also use a proprietary encoding by Techem. It has already been uncovered by the people at FHEM (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/32_TechemWZ.pm#L202) so should be implementable for openHAB as well. But it may take some time until we find the time to do the implementation.
Does the wmbus binding have support for Kamstrup Multicast 21 water meters as well?
Which hardware is needed, except for the Kamstrup Multical 21. I believe some sort of USB dongle or something… I tried your Github, but there isn´t much document in there.
Sorry for the late reply 
We are currently working hard on cleaning up the code and bringing it upstream into Eclipse Smart Home, also including a couple more devices.
Currently, the only implemented Kamstrup device is the MultiCal 302, but if you have a Multical 21 and can provide us with a log, we should be able to implement it in the coming weeks. Or you could try yourself
The latest version is at https://github.com/KuguHome/openhab-binding-wmbus/tree/develop .
To receive the WMBus messages, you’ll need a receiver. The underlying jMBus library supports Amber Wireless AMB8465-M, Radiocrafts RC1180-MBUS and IMST iM871A-USB. Currently, we are working with the AMB8465-M, which is unfortunately quite expensive. I belive, the quickest, cheapest solution will be this one: https://shop.imst.de/wireless-modules/usb-radio-products/10/im871a-usb-wireless-m-bus-usb-adapter-868-mhz
We are also looking into supporting the CUL hardware later, but that may take some time.
Okay thanks for the reply. I guess I´ll have to buy this im871a adaptor and then give it a shot.
I just received this USB dongle. Currently I have in installed in my windows 10 workstation, but I seem to have a problem finding some software to monitor whatever wmbus devices we have ??
I know, there are wMBus softwares for windows, but they are typically targeted for a professional audience. I don’t have that IMST stick myself, but maybe it’s worth asking them via phone or email.
Otherwise, you could use our latest development version of them wmbus binding at https://github.com/KuguHome/openhab-binding-wmbus/releases/download/v0.3.0-develop/org.openhab.binding.wmbus-2.3.0-SNAPSHOT.jar and watch the logs.
Yep, and that software is highly expencive.
Would that be the tail log or debug log?
I´ll give it a try.
We always set the logging to DEBUG or even TRACE and output it into a separate file
(in /var/lib/openhab2/etc/org.ops4j.pax.logging.cfg):
log4j2.appender.wmbus.type = RollingRandomAccessFile
log4j2.appender.wmbus.name = WMBUS
log4j2.appender.wmbus.fileName = ${openhab.logdir}/wmbus.log
log4j2.appender.wmbus.filePattern = ${openhab.logdir}/wmbus.log.%i
log4j2.appender.wmbus.append = true
log4j2.appender.wmbus.layout.type = PatternLayout
log4j2.appender.wmbus.layout.pattern = %d{yyyy-MM-dd HH:mm:ss.SSS} [%-5.5p] [%-36.36c] - %m%n
log4j2.appender.wmbus.policies.type = Policies
log4j2.appender.wmbus.policies.size.type = SizeBasedTriggeringPolicy
log4j2.appender.wmbus.policies.size.size = 100MB
log4j2.logger.org_openhab_binding_wmbus.level = TRACE
log4j2.logger.org_openhab_binding_wmbus.name = org.openhab.binding.wmbus
log4j2.logger.org_openhab_binding_wmbus.additivity = false
log4j2.logger.org_openhab_binding_wmbus.appenderRefs = wmbus
log4j2.logger.org_openhab_binding_wmbus.appenderRef.wmbus.ref = WMBUS
We also have a nice collector tool for the WMBus frames available, which can be accessed from the browser, we should be able to release it soon.
Have you already have had luck with receiving something via the stick?
@anon71383850 just for your information, we are also currently working on implementing those Techem water meters. Should also be available soon.
@patrik_gfeller did continue playing around with your devices? Our focus is currently still on wireless MBus, not on the wired variant, but for testing I threw one of your messages into the decoder, and this was the result:
2018-11-16 12:09:40.689 [DEBUG] [wmbus.discovery.DebugMessageListener] - Could not decode frame (manufacturer ID: ZDH, device ID: 09720908, device version: 16, device type: RESERVED, as bytes: 8868080972091099)
org.openmuc.jmbus.DecodingException: Unable to decode message with this CI Field: 0x00.
The manufacturer “ZDH” is not listed at https://www.dlms.com/flag-id/flag-id-list so probably there is a problem with decoding, maye a byte-shift
Not yet… Plan on testing this upcoming weekend.