[systeminfo] Add CPU frequency channels

[mherwege]

Resolves #15844
Resolves #15608

This PR adds CPU frequency (clock speed) channels to the binding, exposing underlying functionality from the OSHI library. Note that the availability of this information may vary by platform. In my tests on Windows, I could not get reliable information. It did work well on an RPi 4.

It also solves some documentation issues.

[mherwege]

Build failed because of the integration tests that had minimal change. The failure was also not only in the added tests.
Is this a symptom of #13524?

[mherwege]

Tests are failing now. I don't see the immediate reason for it yet.

[mherwege]

Tests were failing because I included update instructions for the 2 added channels.

All of the tests create a thing with only the channel being tested. However, with the update instructions, when the newly created thing is added to the ManagedThingProvider:

openhab-addons/itests/org.openhab.binding.systeminfo.tests/src/main/java/org/openhab/binding/systeminfo/test/SysteminfoOSGiTest.java

Line 282 in 8ed05c5

managedThingProvider.add(thing);

it gets the new channels added to the thing as well (and not just the channels added with the ThingBuilder). The result for all of the tests is that the thing handler initialization fails.

To make this work again, all of the tests would have to be revisited to work with a full set of channels, and not just the channel being tested, unless someone has a better suggestions. I therefore opted to not include update instructions. The user will have to remove and recreate the thing if he wants to benefit from the extra channels.

[J-N-K]

Why is the thing handler initialization failing?

[mherwege]

I am not entirely sure. The next line in the test (assertion on the thing handler) times out whereby the thing handler is null. That would indicate the thing handler initalization is not even running. However, running it through a debugger, the handler factory is called and the handler creation is called from there.
If you want to try, the last commit in this PR removes the update instructions again. But you could roll back that commit to test with update instructions.

[J-N-K]

Just add .withProperties(Map.of("thingTypeVersion", "1")) to the thing builder to prevent updates. The other solution is to get the thing from the registry and before checking it has a handler. The thing changes during the upgrade, so the "original" thing is never initialized and never gets a handler.

[mherwege]

Thanks, I used this:

.withProperties(Map.of("thingTypeVersion", "1"))

I believe I tried this before:

get the thing from the registry and before checking it has a handler

but I then ended up with a thing that also has the new channels. And that would mean I would need to mock the refresh on these channels for all tests as well (easy enough to do in the setup, but not necessary for each test).

[mherwege]

DCO failure is because the revert commit was not signed off. If that is an issue, I can squash that with the original to solve it.

[lolodomo]

Only an ultra minor comment

[lolodomo]

LGTM, thank you

[mherwege]

Build is now failing and I don't understand why. I rebased but it didn't help. The last commit is only a javadoc change, so cannot have an impact.

I have the impression there are other addon PR's suddenly failing the build.

I also have a failed local build.

[lolodomo]

Build was aborted after 240 minutes.
I try again.
I don't know if you have to rebase your branch or not after the Karaf changes of yesterday (my local builds are no more building today without a rebase).

[lolodomo]

Build finally succeeded.

[jlaur]

I don't know if you have to rebase your branch or not after the Karaf changes of yesterday (my local builds are no more building today without a rebase).

This is not necessary. The PR build is performed on the PR branch merged with target branch.