I have the problem that when installing the binding (V.3.2.0) with OPENHAB (V3.3.0 under Windows).
inserted CUL is recognized as a WM bus bridge ONLINE.
During a subsequent thing search, my encrypted Hydrus water meter is recognized and installed as “WMBus device: water meter #xxxxxxxx (68DME1187)”. Without an AES key, the device is initially offline, which is certainly normal.
When I enter the AES key into the bridge and the device, the WMBus device appears as UNKNOWN.
In principle, the CUL and AES key are fine, since I can read the device with a Raspberry Pi and “wmbusmeters”.
However, I do not want to run a Raspberry for a counter. The solution would be more elegant
via OPENHAB WMBus binding.
2023-03-20 13:10:51.906 [INFO ] [openhab.event.InboxAddedEvent ] - Discovery Result with UID ‘wmbus:encrypted_meter:3b00d17519:A511920372757607’ has been added.
2023-03-20 13:43:03.756 [INFO ] [openhab.event.InboxRemovedEvent ] - Discovery Result with UID ‘wmbus:encrypted_meter:3b00d17519:A511920372757607’ has been removed.
2023-03-20 13:43:03.761 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘wmbus:encrypted_meter:3b00d17519:A511920372757607’ changed from UNINITIALIZED to INITIALIZING
2023-03-20 13:43:03.765 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘wmbus:encrypted_meter:3b00d17519:A511920372757607’ changed from INITIALIZING to UNKNOWN
2023-03-20 13:43:03.769 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘wmbus:encrypted_meter:3b00d17519:A511920372757607’ changed from UNKNOWN to OFFLINE (CONFIGURATION_PENDING): Please provide encryption key to read device communication.
2023-03-20 13:43:31.573 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘wmbus:encrypted_meter:3b00d17519:A511920372757607’ changed from OFFLINE (CONFIGURATION_PENDING): Please provide encryption key to read device communication. to UNKNOWN
I just had a look on binding code and I think it could be due to fact that OH 3.4 core prohibits bindings from setting certain states on things. Are you on OH 3.4 or 3.3, and if you are not on 3.3 - can you quickly test it?
Hello,
thank you very much for the message. I use openhab V3.3.0 with Binding V3.2.0
I enter the keys in the following form:
Stick: “75720392:ABCDABCDABCDABCDABCDABCDABCDABCD” and
device: “ABCDABCDABCDABCDABCDABCDABCDABCD” each without quotation marks.
Is that correct? However, I have tried other variants without success.
Hello,
thank you very much for the message. I use openhab V3.3.0
I enter the keys in the following form:
Stick: “75720392:ABCDABCDABCDABCDABCDABCDABCDABCD” and
device: “ABCDABCDABCDABCDABCDABCDABCDABCD” each without quotation marks.
Is that correct? However, I have tried other variants without success.
I’m unfortunately not further. Do you have another idea? Is it possible to link the binding for OH V3.3.0 or V3.4.0 or is there a possibility for detailed logging. It’s obvious that the device gets stuck during initialization. But why, what’s wrong?
I made a sketch of simplified wmbus binding which is free of all complex parts brought back in 2018/2019 to handle specific use cases at Kugu as well as Techem devices.
What occupied me mostly was an attempt to unify underlying serial library. I was able to get everything working with openhab serial port api, sadly its not as stable as I expected. Anyhow, I’ll publish development build (hopefully over this weekend) with support for basic and encrypted devices alone.
WM-Bus can work in several ways - bi-directional might mean that meter expects a wake up signal to emit its readouts. I haven’t looked into that part of specification since its not very common.
Do you have any indication of mode in which your Diehl works? Binding supports S, C and T modes which are one direction (afair “meter to station”).
