two weeks ago, I decided to resurrect my home automation. As many things were broken over time, I’m starting with a clean 4.0.0 setup.
My trouble is I cannot create a bridge anymore, be it via textual config (my preference), be it via UI. It always fails at the very start with a NPE:
Exception occurred while initializing handler of thing 'somfytahoma:bridge:41259be218': Cannot invoke "org.openhab.core.thing.ThingUID.getId()" because the return value of "org.openhab.core.thing.Thing.getBridgeUID()" is null
java.lang.NullPointerException: Cannot invoke "org.openhab.core.thing.ThingUID.getId()" because the return value of "org.openhab.core.thing.Thing.getBridgeUID()" is null
at org.openhab.binding.somfytahoma.internal.handler.SomfyTahomaBridgeHandler.createHttpClient(SomfyTahomaBridgeHandler.java:198) ~[?:?]
at org.openhab.binding.somfytahoma.internal.handler.SomfyTahomaBridgeHandler.initialize(SomfyTahomaBridgeHandler.java:177) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
This error comes at a very early step, while even trying to create a Bridge thing. My openHAB server is clean at this moment as I have a seperate instance in which I load only the somfytahoma binding, clear the userdata directory and start the dockerized version of 4.0.0-RELASE.
Any ideas where I might keep digging? The above even happens when I enable developer mode as something fails while starting the httpclient and the debug message fails:
Network access from inside the docker container works, as I can successfully do a “curl -v https://www.tahomalink.com/” from the shell inside the container…
Hello,
thanks for the investigation, obviously the root cause is some exception during starting of HttpClient. When developer mode enabled, it is necessary to create a different HttpClient, because we need to trust the local server certificate. For an unknown reason it cannot be started and unfortunately we do not see the root cause exception, because of the null value of bridge UID. Are you able to change the debug message - remove the thing.getBridgeUID().getUID() so we can see the exception? Or I can compile the binding for you, just let me know (I do not have the OH 4.x dev environment ready, can take some time)
Thanks
Ondrej
Could you please compile it? The last time I built something for OH was 3.x and at least two years ago, so I would have also to recreate everything from scratch…
If I manage to build something myself, i’ll be sure to notify you here to avoid duplicate work, but expect that you would be faster…
I had to rebuild the addon myself as 4.1.x was staying at “Waiting”… Anyway, here is my debug output, maybe you could amend the error logs or the README with a hint that a higher number of threads might be necessary?
I don’t understand why the bridge would have no bridgeUID() in this case though, but I don’t have to understand everything
Now that I’m looking at my older config files, we had a similar thread with 3.x as well:
2023-08-16 12:01:01.607 [DEBUG] [nal.handler.SomfyTahomaBridgeHandler] - Cannot start http client for: somfytahoma:bridge:bcaeba8966
java.lang.IllegalStateException: Insufficient configured threads: required=12 < max=10 for QueuedThreadPool[OH-httpClient-somfytahom-e9f43da6]@466a057e{STOPPED,5<=0<=10,i=0,r=-1,q=0}[NO_TRY]
at org.eclipse.jetty.util.thread.ThreadPoolBudget.check(ThreadPoolBudget.java:165) ~[?:?]
at org.eclipse.jetty.util.thread.ThreadPoolBudget.leaseTo(ThreadPoolBudget.java:141) ~[?:?]
at org.eclipse.jetty.util.thread.ThreadPoolBudget.leaseFrom(ThreadPoolBudget.java:191) ~[?:?]
at org.eclipse.jetty.io.SelectorManager.doStart(SelectorManager.java:255) ~[?:?]
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73) ~[?:?]
at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169) ~[?:?]
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117) ~[?:?]
at org.eclipse.jetty.client.AbstractConnectorHttpClientTransport.doStart(AbstractConnectorHttpClientTransport.java:64) ~[?:?]
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73) ~[?:?]
at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169) ~[?:?]
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117) ~[?:?]
at org.eclipse.jetty.client.HttpClient.doStart(HttpClient.java:258) ~[?:?]
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73) ~[?:?]
at org.openhab.binding.somfytahoma.internal.handler.SomfyTahomaBridgeHandler.createHttpClient(SomfyTahomaBridgeHandler.java:196) ~[?:?]
at org.openhab.binding.somfytahoma.internal.handler.SomfyTahomaBridgeHandler.initialize(SomfyTahomaBridgeHandler.java:177) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:568) ~[?:?]
at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:147) ~[?:?]
at org.openhab.core.internal.common.Invocation.call(Invocation.java:52) ~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[?:?]
at java.lang.Thread.run(Thread.java:833) ~[?:?]
thanks for updating me, glad you found the solution. Looking at the first occurence of this issue back in 2018 I wonder, that we do no have the threads increased by default…
Actually, now while I am thinking about it… Would it be possible to have an option to completely disable contacting Somfy if my system is running in developer mode? My Production system is still having problems even with the increased threads size, and there is no real purpose to contact the Somfy servers when all the necessary information can be obtained from my local gateway, right?
Unfortunately it still needs connection to cloud, because authentication is done in Somfy cloud. You get a local token and your local gateway synchronizes the valid tokens from the cloud as well, so you can use this token directly with your gateway as authenticated one.
