@Kai many thanks for the new release. Can you please advise if PR #10119 [velux] is actually in the release or not? (As it is not mentioned in the release notes).
@massi & @AndrewFG Thanks for noticing, there were indeed a few PRs missing as they weren’t correctly tagged on Github (note: PRs turn up in the release notes if they either have “bug” or “enhancement” tag on them. Issues are never listed in the release notes, so please always make sure to have a speaking title for every PR, because that’s what users will see in the end. Thanks!
Thank you @Kai Installed 3.0.1.M3 and all seems to be ok, but I have these new warnings in the log:
2021-04-02 12:31:57.340 [WARN ] [ty.util.ssl.SslContextFactory.config] - Trusting all certificates configured for Client@3f704dc3[provider=null,keyStore=null,trustStore=null] 2021-04-02 12:31:57.343 [WARN ] [ty.util.ssl.SslContextFactory.config] - No Client EndPointIdentificationAlgorithm configured for Client@3f704dc3[provider=null,keyStore=null,trustStore=null] 2021-04-02 12:31:57.596 [WARN ] [ty.util.ssl.SslContextFactory.config] - Trusting all certificates configured for Client@7fa5f364[provider=null,keyStore=null,trustStore=null] 2021-04-02 12:31:57.598 [WARN ] [ty.util.ssl.SslContextFactory.config] - No Client EndPointIdentificationAlgorithm configured for Client@7fa5f364[provider=null,keyStore=null,trustStore=null]
This issue persists in 3.1M3:
Edit - forgot link:
What “this” ? Make your post a useful one please.
Since 3.1M2 (and now also on M3) this binding is not available, is that correct?
It seems that M3 has introduced a missing dependency problem ‘jcifs.netbios.NbtAddress’ in the ‘HDPowerView’ binding. Does anyone have an idea what I need to change in the binding code to resolve it again?
2021-04-02 13:46:51.356 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception: java.lang.NoClassDefFoundError: jcifs/netbios/NbtAddress at org.openhab.binding.hdpowerview.internal.discovery.HDPowerViewHubDiscoveryService.lambda$0(HDPowerViewHubDiscoveryService.java:83) ~[?:?] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) ~[?:?] at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) ~[?:?] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) ~[?:?] 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:834) [?:?] Caused by: java.lang.ClassNotFoundException: jcifs.netbios.NbtAddress cannot be found by org.openhab.binding.hdpowerview_3.1.0.M3 at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:484) ~[org.eclipse.osgi-3.12.100.jar:?] at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:395) ~[org.eclipse.osgi-3.12.100.jar:?] at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:387) ~[org.eclipse.osgi-3.12.100.jar:?] at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:150) ~[org.eclipse.osgi-3.12.100.jar:?] at java.lang.ClassLoader.loadClass(ClassLoader.java:522) ~[?:?] ... 7 more
I have the same warnings after the upgrade to M3.
Is it something to worry about?
I just tested with a plain fresh M3 install and do not see them. I assume they are related to some specific add-on?
Not correct. Tested it and the binding is there as expected:
Please create an issue and we will figure it out. It was probably me who broke that, sorry for that…
Probably. How can I check which one ?
The tried and true method is to either unload all of them and slowly add them back until the issue reappears or removing each one, one at a time until the issue disappears. Neither method is easy, painless or quick, in fact quite the opposite.
With that said, the warning appears to have something to do with secure socket layer and client certificates. Suspect any binding which is connecting securely to a cloud server
Maybe list all the bindings you use and we’ll take a shot at guessing which one is the culprit
@SpaceGlider I thinkI see the same symptom of system getting slower and slower and it seems that when I disconnect VS Code from the OH machine, everything gets better if not normal.
Note that I use VS Code via SSH, not with Samba… Not sure if this is relevant, but just in case.
I’m pretty sure there is a known issue with VS code slowing performance, dig around a little (although I don’t think it has been resolved yet)
If it is more then one binding, I’d look at your certificates
so… how did you come to this conclusion?
Disabled all, then enabled one by one, and checking the log in between.
Yes, it is mentioned here:
Note that I’m still unsure that in my case it is not openhab itself that is slowing down the Rpi4 entirely like this. I’ll need to spend more time to really understand what is going on. For sure when I stop openhab, then suddenly things get even better…
And if you exit from VSC it also gets better?
I’ve been running on a 3B+, so a quarter of the RAM that you’ve got, and with OH2 I found that using VSC with the remote SSH feature I’d run out of RAM, locking up the Pi. What other services are running on your Pi? How much RAM is free on the Pi before you connect via VSC?