openHAB 2.5.7 release discussion

So where does that mention your issue ? It does not. It is just a very generic warning that there may be more problems than usual.

Serious ? You want to tell us that after years of usage, you still don’t know the difference between openHAB and openHABian ? Your issue is on openHABian hence it does not belong here.

No, but is deprecated. Remove it and restart OH to see if that makes a difference.

Hi @Kim_Andersen , would you please so kind and move your discussion with @mstormi to a private one? It’s annoying here to read your entitlement of a bug-free openHAB, which is maintained with blood, sweat and tears from everyone in their free time.


I already removed ... but the warnings remain. I don’t know if it’s relevant, I’m still using Java 8.



After installing 2.5.7 (over 2.5.6) a few days back, I had to downgrade to 2.5.6.
On 2.5.7, the CPU load for the java process maxed out for 15-20s every minute or so, blocking everything until the CPU was released again.
I tried enabling DEBUG logging for karaf,core and all my bindings, but nothing showed up in the logs as the CPU was hogged.

My system runs Ubuntu Server 18.04 LTS

openhab> list -s | grep -i binding
136 │ Active   │  80 │ 2.5.0                   │ org.openhab.core.binding.xml
203 │ Active   │  80 │      │ org.openhab.binding.nanoleaf
239 │ Active   │  80 │ 2.5.6                   │ org.openhab.binding.astro
240 │ Active   │  80 │ 2.5.6                   │ org.openhab.binding.daikin
241 │ Active   │  80 │ 2.5.6                   │ org.openhab.binding.deconz
242 │ Active   │  80 │ 1.14.0                  │ org.openhab.binding.expire
243 │ Active   │  80 │ 2.5.6                   │ org.openhab.binding.harmonyhub
244 │ Active   │  80 │ 1.14.0                  │ org.openhab.binding.http
245 │ Active   │  80 │ 2.5.6                   │ org.openhab.binding.hue
246 │ Active   │  80 │ 2.5.6                   │ org.openhab.binding.kodi
247 │ Active   │  80 │ 2.5.6                   │ org.openhab.binding.mail
248 │ Active   │  80 │ 2.5.6                   │
249 │ Active   │  80 │ 2.5.6                   │ org.openhab.binding.onkyo
250 │ Active   │  80 │ 2.5.6                   │ org.openhab.binding.samsungtv
251 │ Active   │  80 │ 2.5.6                   │ org.openhab.binding.shelly
252 │ Active   │  80 │ 2.5.6                   │ org.openhab.binding.squeezebox
253 │ Active   │  80 │ 2.5.6                   │ org.openhab.binding.systeminfo
254 │ Active   │  80 │ 2.5.6                   │ org.openhab.binding.tradfri
255 │ Active   │  80 │ 2.5.6                   │ org.openhab.binding.zwave
openhab> logout
Connection to localhost closed.
omr@shs2:~$ java -version
java version "1.8.0_201"
Java(TM) SE Runtime Environment (build 1.8.0_201-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode)
omr@shs2:~$ uname -a
Linux shs2 4.15.0-66-generic #75-Ubuntu SMP Tue Oct 1 05:24:09 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Downgrading to 2.5.6, the CPU load for the java process is a stable 8-12%

Can someone guide me in my issues after the upgrade? Details below. I am running OH2 on RPI3 with Buster. I kinda got stuck on 2.5.4-1 as anything above I upgrade to (today tried 2.5.7-1) I’m getting loads of errors with items which I guess are coming from binding issues. Rollback to 2.5.4-1 (and cleaning cache) helps to stabilize, get the log file clear and proper Basic UI look.

Error I’m getting:

2020-08-11 09:34:10.226 [WARN ] [basic.internal.render.SwitchRenderer] - Cannot determine item type of 'kamera_dol' 2020-08-11 09:34:10.259 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'kamera_dol' for widget org.eclipse.smarthome.model.sitemap.sitemap.Switch 2020-08-11 09:34:10.261 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item for widget org.eclipse.smarthome.model.sitemap.sitemap.Switch 2020-08-11 09:34:10.264 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'kamera_dol' for widget org.eclipse.smarthome.model.sitemap.sitemap.Switch 2020-08-11 09:34:10.267 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'kamera_dol' for widget org.eclipse.smarthome.model.sitemap.sitemap.Switch 2020-08-11 09:34:10.269 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'kamera_dol' for widget org.eclipse.smarthome.model.sitemap.sitemap.Switch

item is defined as:
Switch kamera_dol <camera> { http=">[ON:GET:{Authorization=Basic xxxxxxxxxxx=}]" }

same error for item introduced by PanasonicTV binding:
Switch BedroomTVPower "Power" { panasonictv="tv_sypialnia:POWER" }

and then with no errors in the log (no debug), there are lots of issues with items which are filled in via mqtt (for weather station, alarm etc) - values are not present but also icons problems. I tried to restart the instance couple of time, clean the cache, I didn’t try to restart the whole server yet so maybe I’m asking for help too early. On the other hand this must be something straightforward.

Leave the cache alone after an upgrade. Let it populate and do its job, do an “extra” restart without touching it, see what issues are left.

@rossko57 I obviously tried that in the first place (let it do its job and 2 restarts), then when it didn’t work, I tried to remove cache an so on. I tried this with 2.5.5, 2.5.6, and today 2.5.7. This isn’t a conincidence

There’s no “obviously” about it, we only know what you tell us.

The “missing Items” reports you show us invariably arise when the cache has been cleared, and stop happening when the cache has been allowed to settle and openHAB restarted. Some report two attempts needed at that, maybe it is configuration dependent.

It’s not quite impossible for some part of validation to have changed, so that an xxx.items file that worked under earlier versions now no longer loads. You would get a message about that in your openhab.log but you say there are no errors.

None of the problems you have shown us are directly to do with bindings. Let’s clear these Item related problems, and move on to the next.

After an upgrade did you try to resave your items file to have it read in again?

@Thedannymullen no I didn’t try it. It is a good idea to give it a try. Thanks

1 Like

Today I tried to upgrade again, then before I started OH2 again, I rebooted the server and when it came up it was already clean and no issues with items. Defintiely RPI reboot helped and I regret I didn’t try it before raising this issue but on the other hand it was never required before. Thanks to all who spent time and looked at my case and answered with ideas! This is very much appreciated. I will keep observing 2.7.1 now and see if any issues


I haven’t seen the same error message in the logs but I found my z-wave controller stopped working so all my devices aren’t initialized. Did you get it working again?

My Z-wave controller and my enocean Controller worked well. I have no problems, only the warning messages in the log.
And I have no idea where they came from.

1 Like


I am running openhab natively in Ubuntu 18.04 and since upgrading to 2.5.7 i am seeing out of memory errors pop up after a random amount of time running.

How do you change the memory setting?

Start java with increased -Xmx parameters (-Xms, too, eventually)

If it´s some binding or ervices which doesnt free the memory as it should, then it wont change anything increasing the Xmx and Xms parameters. Thats my experience though.

@Kim_Andersen what debugging steps should i look into to see what binding is causing the problem.

I will add that while things were stable with 2.5.6 for me i did have an issue with the MQTT bundle where i had to reset it every so often. If i remember correctly i think there was an underlying issue with a library. But that would only shut down the MQTT bundle and its devices would stop working. I could reset the bundle and openhab would become responsive again.

Now when it happens openhab locks up completely and you can’t even access the openhba-cli console.

I have looked at my logs but they don’t appear to be helpful, i don’t see a binding mentioned in the error message

2020-08-18 19:55:38.415 [ERROR] [ersey.server.ServerRuntime$Responder] - An I/O error has occurred while writing a response message entity to the container output stream.
java.lang.OutOfMemoryError: null
	at sun.reflect.GeneratedConstructorAccessor765.newInstance(Unknown Source) ~[?:?]
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance( ~[?:1.8.0_262]
	at java.lang.reflect.Constructor.newInstance( ~[?:1.8.0_262]
	at java.util.concurrent.ForkJoinTask.getThrowableException( ~[?:1.8.0_262]
	at java.util.concurrent.ForkJoinTask.reportException( ~[?:1.8.0_262]
	at java.util.concurrent.ForkJoinTask.invoke( ~[?:1.8.0_262]
	at$ReduceOp.evaluateParallel( ~[?:1.8.0_262]
	at ~[?:1.8.0_262]
	at ~[?:1.8.0_262]
	at ~[?:?]
	at org.eclipse.smarthome.core.thing.internal.ChannelStateDescriptionProvider.getStateDescription( ~[?:?]
	at org.eclipse.smarthome.core.thing.internal.ChannelStateDescriptionProvider.getStateDescriptionFragment( ~[?:?]
	at org.eclipse.smarthome.core.internal.service.StateDescriptionServiceImpl.mergeStateDescriptionFragments( ~[?:?]
	at org.eclipse.smarthome.core.internal.service.StateDescriptionServiceImpl.getStateDescription( ~[?:?]
	at org.eclipse.smarthome.core.items.GenericItem.getStateDescription( ~[?:?]
	at ~[?:?]
	at ~[?:?]
	at ~[?:?]
	at$0( ~[?:?]
	at$3$1.accept( ~[?:1.8.0_262]
	at java.util.HashMap$KeySpliterator.tryAdvance( ~[?:1.8.0_262]
	at$WrappingSpliterator.lambda$initPartialTraversalState$0( ~[?:1.8.0_262]
	at$AbstractWrappingSpliterator.fillBuffer( ~[?:1.8.0_262]
	at$AbstractWrappingSpliterator.doAdvance( ~[?:1.8.0_262]
	at$WrappingSpliterator.tryAdvance( ~[?:1.8.0_262]
	at java.util.Spliterators$1Adapter.hasNext( ~[?:1.8.0_262]
	at ~[?:?]
	at ~[?:?]
	at ~[?:1.8.0_262]
	at ~[?:1.8.0_262]
	at org.glassfish.jersey.message.internal.ReaderWriter.writeTo( ~[bundleFile:?]
	at org.glassfish.jersey.message.internal.AbstractMessageReaderWriterProvider.writeTo( ~[bundleFile:?]
	at org.glassfish.jersey.message.internal.InputStreamProvider.writeTo( ~[bundleFile:?]
	at org.glassfish.jersey.message.internal.InputStreamProvider.writeTo( ~[bundleFile:?]
	at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.invokeWriteTo( ~[bundleFile:?]
	at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.aroundWriteTo( ~[bundleFile:?]
	at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed( ~[bundleFile:?]
	at org.glassfish.jersey.server.internal.JsonWithPaddingInterceptor.aroundWriteTo( ~[?:?]
	at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed( ~[bundleFile:?]
	at org.glassfish.jersey.server.internal.MappableExceptionWrapperInterceptor.aroundWriteTo( ~[?:?]
	at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed( ~[bundleFile:?]
	at org.glassfish.jersey.message.internal.MessageBodyFactory.writeTo( ~[bundleFile:?]
	at org.glassfish.jersey.server.ServerRuntime$Responder.writeResponse( [bundleFile:?]
	at org.glassfish.jersey.server.ServerRuntime$Responder.processResponse( [bundleFile:?]
	at org.glassfish.jersey.server.ServerRuntime$Responder.process( [bundleFile:?]
	at org.glassfish.jersey.server.ServerRuntime$ [bundleFile:?]
	at org.glassfish.jersey.internal.Errors$ [bundleFile:?]
	at org.glassfish.jersey.internal.Errors$ [bundleFile:?]
	at org.glassfish.jersey.internal.Errors.process( [bundleFile:?]
	at org.glassfish.jersey.internal.Errors.process( [bundleFile:?]
	at org.glassfish.jersey.internal.Errors.process( [bundleFile:?]
	at org.glassfish.jersey.process.internal.RequestScope.runInScope( [bundleFile:?]
	at org.glassfish.jersey.server.ServerRuntime.process( [bundleFile:?]
	at org.glassfish.jersey.server.ApplicationHandler.handle( [bundleFile:?]
	at org.glassfish.jersey.servlet.WebComponent.serviceImpl( [bundleFile:?]
	at org.glassfish.jersey.servlet.WebComponent.service( [bundleFile:?]
	at org.glassfish.jersey.servlet.ServletContainer.service( [bundleFile:?]
	at org.glassfish.jersey.servlet.ServletContainer.service( [bundleFile:?]
	at org.glassfish.jersey.servlet.ServletContainer.service( [bundleFile:?]
	at com.eclipsesource.jaxrs.publisher.internal.ServletContainerBridge.service( [bundleFile:?]
	at org.eclipse.jetty.servlet.ServletHolder.handle( [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.servlet.ServletHandler.doHandle( [bundleFile:9.4.20.v20190813]
	at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle( [bundleFile:?]
	at org.eclipse.jetty.server.handler.ScopedHandler.handle( [bundleFile:9.4.20.v20190813]
	at [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle( [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle( [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.server.session.SessionHandler.doHandle( [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle( [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle( [bundleFile:9.4.20.v20190813]
	at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle( [bundleFile:?]
	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope( [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.servlet.ServletHandler.doScope( [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.server.session.SessionHandler.doScope( [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope( [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.server.handler.ContextHandler.doScope( [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.server.handler.ScopedHandler.handle( [bundleFile:9.4.20.v20190813]
	at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle( [bundleFile:?]
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle( [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.server.Server.handle( [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.server.HttpChannel.handle( [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.server.HttpConnection.onFillable( [bundleFile:9.4.20.v20190813]
	at$ReadCallback.succeeded( [bundleFile:9.4.20.v20190813]
	at [bundleFile:9.4.20.v20190813]
	at$ [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask( [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce( [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce( [bundleFile:9.4.20.v20190813]
	at [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob( [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.util.thread.QueuedThreadPool$ [bundleFile:9.4.20.v20190813]
	at [?:1.8.0_262]
Caused by: java.lang.OutOfMemoryError: unable to create new native thread
	at java.lang.Thread.start0(Native Method) ~[?:1.8.0_262]
	at java.lang.Thread.start( ~[?:1.8.0_262]
	at java.util.concurrent.ForkJoinPool.createWorker( ~[?:1.8.0_262]
	at java.util.concurrent.ForkJoinPool.tryAddWorker( ~[?:1.8.0_262]
	at java.util.concurrent.ForkJoinPool.signalWork( ~[?:1.8.0_262]
	at java.util.concurrent.ForkJoinPool$WorkQueue.push( ~[?:1.8.0_262]
	at java.util.concurrent.ForkJoinTask.fork( ~[?:1.8.0_262]
	at ~[?:1.8.0_262]
	at java.util.concurrent.CountedCompleter.exec( ~[?:1.8.0_262]
	at java.util.concurrent.ForkJoinTask.doExec( ~[?:1.8.0_262]
	at java.util.concurrent.ForkJoinPool$WorkQueue.runTask( ~[?:1.8.0_262]
	at java.util.concurrent.ForkJoinPool.runWorker( ~[?:1.8.0_262]
	at ~[?:1.8.0_262]