openHAB 3.3 Milestone discussion

In my opinion it is a step forward. Especially those using config files quite often produced invalid configurations and bug reports popped up which turned out to be user-errors. This should be avoided now. The validation was enabled early in the 3.3 development, so smaller issues like you experience can be detected and solved before the release.

3 Likes

Yes, it is. In the latest snapshot there is additionally is a new validation for parameter options. This might be the cause for the mentioned issue.

@apella12 I have to second @J-N-K . It is a step forward. What I see from the past issues users are talking about is the way how they got informed about configuration violations. A log message on DEBUG level might not the best choice. We can change it to be a warning instead.

On the other hand I think the UI must be the place to see more information about wrong configuration parameters. Thus I suggest to add the violation meassages to the details of the ThingStatus which are displayed inside the UIs.

2 Likes

I can prepare a PR for that.

FTR: Show config validation messages in thing status by J-N-K · Pull Request #2829 · openhab/openhab-core · GitHub

3 Likes

@ssalonen

Followed EDIT 1, and that solved the problem.

Also had to change Uint32swap and Uint64swap to Int32/64swap :slight_smile:

Change uint16 to int16 did the trick! :slight_smile: Now I am back on 3.3M2

Great to hear @Nanna_Agesen @Jostein89 that changing the write value type made the difference.

Maintainers, how could we get this breaking modbus change to 3.3 release notes?

We could document the breaking change like this

openHAB 3.3 enforces more strict configuration validation that might invalidate previously valid textual modbus configuration. As a result, manual corrections might be needed for data things defined in things configuration file.

Previously textual config accepted “unsigned” writeValueTypes such “uint16”. These are no longer accepted in openHAB 3.3.

Replace the writeValueType as follows with openHAB 3.3:

  • uint16 with int16
  • uint32 with int32
  • uint32_swap with int32_swap
  • uint64 with int64
  • uint64_swap with int64_swap

Despite the change in parameter value, the behavior is exactly the same as before.

Note that things defined in MainUI require no change. Also note that readValueType parameter requires no change.

2 Likes

Does changing while still on <= 3.2 work? Then we should get people to do it now.

Yes, it works also now. There has been no changes in the binding.

Good idea to change now but I would also like to have it documented in the change log.

I’d further advise to add a more general notice to be alert for “handler errors” since the strict validation also affects the Zwave users (and maybe other bindings I do not know about). See this.

Depending on the timing, complexity and approvals simply raising the log level from Debug to Warn might be a good interim step.

Bob

2 Likes

Raising the log level is not much easier than the solution I presented. In fact the code is much cleaner now.

2 Likes

Ok, just throwing it out there. You are the expert. Cleaner code is good.

Bob

Continuing the discussion from openHAB 3.3 Milestone discussion:

Hey! I’m trying to fix a bug in one of our addons, upgraded to the latest milestone and noticed that my addons are not updating.
OpenHAB throws many errors in the log, which don’t tell me anything since I’m too new into this. Can someone help please?

~$ cat /volume1/\@appstore/openHAB/openHAB.log 
org.apache.karaf.features.internal.util.MultiException: Error:
        Error downloading mvn:org.eclipse.jetty.websocket/websocket-common/9.4.40.v20210413
        Error downloading mvn:org.eclipse.jetty/jetty-client/9.4.40.v20210413
        Error downloading mvn:org.eclipse.jetty.websocket/websocket-api/9.4.40.v20210413
        Error downloading mvn:org.eclipse.jetty/jetty-http/9.4.40.v20210413
        Error downloading mvn:org.eclipse.jetty.websocket/websocket-client/9.4.40.v20210413
        Error downloading mvn:org.eclipse.jetty/jetty-proxy/9.4.40.v20210413
        Error downloading mvn:org.eclipse.jetty/jetty-util/9.4.40.v20210413
        Error downloading mvn:org.eclipse.jetty/jetty-io/9.4.40.v20210413
        at org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader.<init>(MavenDownloadManager.java:91)
        at org.apache.karaf.features.internal.download.impl.MavenDownloadManager.createDownloader(MavenDownloadManager.java:72)
        at org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:457)
        at org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:452)
        at org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:224)
        at org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:399)
        at org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1069)
        at org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:1004)
        at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at java.base/java.lang.Thread.run(Unknown Source)
        Suppressed: java.io.IOException: Error downloading mvn:org.eclipse.jetty.websocket/websocket-common/9.4.40.v20210413
                at org.apache.karaf.features.internal.download.impl.AbstractRetryableDownloadTask.run(AbstractRetryableDownloadTask.java:77)
                at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
                at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
                at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
                ... 3 more
        Caused by: java.io.IOException: Error resolving artifact org.eclipse.jetty.websocket:websocket-common:jar:9.4.40.v20210413: [Could not find artifact org.eclipse.jetty.websocket:websocket-common:jar:9.4.40.v20210413 in openhab (https://openhab.jfrog.io/openhab/libs-milestone/)]
                at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.configureIOException(AetherBasedResolver.java:803)
                at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:774)
                at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:657)
                at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:598)
                at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:565)
                at org.apache.karaf.features.internal.download.impl.MavenDownloadTask.download(MavenDownloadTask.java:52)
                at org.apache.karaf.features.internal.download.impl.AbstractRetryableDownloadTask.run(AbstractRetryableDownloadTask.java:60)
                ... 6 more
                Suppressed: shaded.org.eclipse.aether.transfer.ArtifactNotFoundException: Could not find artifact org.eclipse.jetty.websocket:websocket-common:jar:9.4.40.v20210413 in openhab (https://openhab.jfrog.io/openhab/libs-milestone/)
                        at shaded.org.eclipse.aether.connector.basic.ArtifactTransportListener.transferFailed(ArtifactTransportListener.java:48)
                        at shaded.org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:368)
                        at shaded.org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:75)
                        at shaded.org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute(BasicRepositoryConnector.java:642)
                        at shaded.org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:262)
                        at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:489)
                        at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:390)
                        at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:215)
                        at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:192)
                        at shaded.org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:247)
                        at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:767)
                        ... 11 more
        Caused by: shaded.org.eclipse.aether.resolution.ArtifactResolutionException: Error resolving artifact org.eclipse.jetty.websocket:websocket-common:jar:9.4.40.v20210413
                at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:413)
                at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:215)
                at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:192)
                at shaded.org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:247)
                at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:767)
                ... 11 more
        Suppressed: java.io.IOException: Error downloading mvn:org.eclipse.jetty/jetty-client/9.4.40.v20210413
                at org.apache.karaf.features.internal.download.impl.AbstractRetryableDownloadTask.run(AbstractRetryableDownloadTask.java:77)
                at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
                at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
                at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
                ... 3 more
        Caused by: java.io.IOException: Error resolving artifact org.eclipse.jetty:jetty-client:jar:9.4.40.v20210413: [Could not find artifact org.eclipse.jetty:jetty-client:jar:9.4.40.v20210413 in openhab (https://openhab.jfrog.io/openhab/libs-milestone/)]
                at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.configureIOException(AetherBasedResolver.java:803)
                at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:774)
                at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:657)
                at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:598)
                at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:565)
                at org.apache.karaf.features.internal.download.impl.MavenDownloadTask.download(MavenDownloadTask.java:52)
                at org.apache.karaf.features.internal.download.impl.AbstractRetryableDownloadTask.run(AbstractRetryableDownloadTask.java:60)
                ... 6 more
                Suppressed: shaded.org.eclipse.aether.transfer.ArtifactNotFoundException: Could not find artifact org.eclipse.jetty:jetty-client:jar:9.4.40.v20210413 in openhab (https://openhab.jfrog.io/openhab/libs-milestone/)
                        at shaded.org.eclipse.aether.connector.basic.ArtifactTransportListener.transferFailed(ArtifactTransportListener.java:48)
                        at shaded.org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:368)
                        at shaded.org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:75)
                        at shaded.org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute(BasicRepositoryConnector.java:642)
                        at shaded.org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:262)
                        at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:489)
                        at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:390)
                        at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:215)
                        at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:192)
                        at shaded.org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:247)
                        at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:767)
                        ... 11 more
        Caused by: shaded.org.eclipse.aether.resolution.ArtifactResolutionException: Error resolving artifact org.eclipse.jetty:jetty-client:jar:9.4.40.v20210413
                at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:413)
                at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:215)
                at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:192)
                at shaded.org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:247)
                at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:767)
                ... 11 more

Hello Bob,

I have the same problem, where can I find the Zwave DB?
Thanks in advance
Martin

welcome to Openhab

It is here. Follow the blog on how to register and get update rights.

Bob

In the log during startup I have the following message regarding a NullPointerException. Obviously it is related to MQTT autodiscovery. If anybody is interested I’d be glad to provide more details!

2022-03-29 12:38:48.913 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NullPointerException: null
at org.openhab.binding.mqtt.generic.MqttChannelTypeProvider.derive(MqttChannelTypeProvider.java:132) ~[?:?]
at org.openhab.binding.mqtt.homeassistant.internal.discovery.HomeAssistantDiscovery.publishResults(HomeAssistantDiscovery.java:204) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) ~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:829) [?:?]

Thanks for this great piece of software!

I think this is an issue on what is defined in DEBUG and what should be in ERRORS. IMHO, this should have been an ERROR because DEBUG may not always be available breaking the installation.

This core fix may be in M2 latest release, but this is not in the distro latest release or if it is, then this is not fully resolved for deb distros.

Hi,

I just noticed that after upgrading to 3.3.0.M3 I cannot access the state of an item via the REST-API from a browser. E.g.

http://<IP>:<PORT>/rest/items/<ITEM-NAME>/state)

gives me a HTTP 400 when opened from a browser. Using CURL (also from other systems), this works.

I have no idea where to start troubleshooting and I think this might be something that was introduced in M3. In M2 (and before) this works fine for me. Any idea?

1 Like

As long as we talk about http traffic you may use a network sniffer like wireshark.
Do a capture from your browser and curl. Compare the differnces.

I would personally like to use the new full “minimal” concept as is now active, I like it and have around 200 items. Stripping away parts of the path would make this not work (for me) very well as I have similar duplicated setups with the same upper hierarchy. A good way to support Google Home / Alexa integration would still be needed.

I fully support the opt-in though, as it’s clear that this does not work for everyone.