Adapt to latest OpenHab 3.1.0-SNAPSHOT

[t-8ch]

Only compile-tested, as I don't have the hardware yet.

The eclipse project files should not be needed anymore, but I am not completely sure about that, as I'm not using eclipse.

Is there a reason in-lining the jmbus sources instead of using it from maven central? I have another (compile-only-tested) patch that replaces the bundled source.

[MikeTheTux]

Is there a reason in-lining the jmbus sources instead of using it from maven central?

The in-lined jmbus version includes a small extension for the access to the RAW frame

[t-8ch]

The in-lined jmbus version includes a small extension for the access to the RAW frame

Then it should be possible to only ship that extension with the binding and pull the rest of the binding from maven.
The build system will unpack the jar of jmbus into the jar of the binding, so the end result is the same as before.
This now also part of this PR.

[MikeTheTux]

hey,

I took your PR, compiled it and integrated it in OH3.1.0.
It did not work.
After performing the following changes it is up and running again:

• reverted changes in WMBusDevice.java (added getRawData() again)
• added DataRecord.java again, overriding the file from the maven package and thereby introducing getRawData()
• re-added jrxtx from smartmeter binding (original jrxtx v1.0.1 is not functional)

With these modifications, the WMBus Binding operates again in my OH3.1.0 installation.

Here is the resulting package:
org.openhab.binding.wmbus-3.1.0-SNAPSHOT-20210731.zip

[t-8ch]

How did it not work?

[MikeTheTux]

The binding loaded but the Thing didn't went ONLINE. It was not able to open the serial connection and remained OFFLINE.
I'm also using the Smartmeter binding. Can there be a conflict when using different jrxtx implementations in parallel!?

[t-8ch]

If it compiled, than I think the changes you did to WMBusDevice.java and DataRecord.java should not be needed.
Can you try to also get it to work with only the new jrxtx?
(I don't have a device compatible with this binding at the moment)

[MikeTheTux]

getRawData() is used to override getDataValue().

@Override
public byte[] getDataValue() {
   return getRawData();
}

I guess this is the reason why it also compiles even without getRawData().

[t-8ch]

Did you test it without the changes to WMBusDevice and DataRecord but the fixed version of jrxtx?
I'm still not sure whether these changes should make a difference.

Nothing ever really calls the getRawData methods.
Only getDataValues and that still returns the raw data.

[MikeTheTux]

I was wondering the same ...

I'm using now this PR and only reverted jrxtx to the original version.
My watermeter is online. I will report if it works stable ...

[t-8ch]

I dropped the patch that remove the bundled jmbus and jrxtx libraries.
Now the PR does again what it describes to do in it's title.
@MikeTheTux Could you validate that, too?

[MikeTheTux]

@MikeTheTux Could you validate that, too?

Smoke test positive.
I will report if it works stable ...

[MikeTheTux]

... the latest version seems to operate stable for my use case 🙂

[t-8ch]

Thanks, then let this thing get merged 😃

[pokerazor]

Hey @MikeTheTux @t-8ch thanks for your amazing work!

As you probably have noticed, lately this repo and the Thread on the forum has become quite silent, unfortunately. The reason is, that his binding (which had begun as a private project of myself and then became a part of the company I work for, KUGU Home GmbH) is not currently in the focus a lot anymore, as the business changed a bit.

However, we're still very interested in it and stabilizing it. So it's fortunate that you as contributors turned up. Would you be interested to have a chat in the coming weeks, to talk about ideas for next steps? I could send you a Microsoft Teams invite?

[t-8ch]

@pokerazor Sure, let's have a chat. You can use the email address from my commit on GitHub.

[MikeTheTux]

@pokerazor Sure, let's have a chat. You can use the email address from my commit on GitHub.

same for me

[MikeTheTux]

There is also a wish from openhab to contribute this as an official binding.
See new-binding-wireless-m-bus-techem-heat-cost-allocators#101 .

[t-8ch]

This would also have been my proposal to be honest:

• No need for new developer-provided builds for users.
• No need to keep up to date with internal refactorings of the addon system (like this very PR is doing)
• No need for specific installation instructions.
• Reuse of the modified jrxtx library from the smartmeter binding.
• Fallback maintainers.

I would be willing to help with the contribution.
(FYI the contribution for my other binding went very smoothly)

I'm still trying to get hold of a reasonably priced adapter stick, maybe @pokerazor has a spare one?
Otherwise I'll probably buy a retail one.

[MikeTheTux]

... the latest version seems to operate stable for my use case 🙂

For reference, this is my resulting binding from August'21 that I'm still using:

• org.openhab.binding.wmbus-3.1.0-SNAPSHOT-20210805.zip

[t-8ch]

@pokerazor Any news about the planned talk?
If you give me a go-ahead I could also try submit it upstream on my own (maybe in collaboration with @MikeTheTux )