openHAB 2.5.10 release discussion

yes, and everytime i delete the chache

Try the following:

  • Stop Openhab
  • Delete the cache
  • restart
  • wait until LOAD is “normal”
  • REstart again without cleaning the cache

I had a same error. I cleared cache and made other variants, but without success. But when I deleted “Amazon Echo Control Binding” from paper ui and reinstall it everything started as needed.

The next patch release is available: openHAB 2.5.10

@Kai many thanks for the update :slight_smile:

I just want to mention though that when I installed it on my Rasberry Pi via the openhabian config application, it restarted the machine in an unstable state, so it was just sitting there and spitting out about 130 megabytes of logger crash dump messages per hour :frowning:

This may be because (by coincidence) the openhabian config application also applied many changes to the raspbian o/s at the same time ??

In any case a clean shutdown and reboot fixed the problem => but may I suggest that openhabian config application should have an option “Clean Shutdown and Reboot” on the menu?

An update does this for you.
Every time you clear the cache again, you cause difficulties for the next boot.
“Stop shooting yourself in the foot” :wink:

1 Like

but may I suggest that openhabian config application should have an option “Clean Shutdown and Reboot” on the menu?

You may but no we won’t build that in. Too many people way prematurely reboot their boxes, killing traces and diagnostics. @rossko57 has put it well. We won’t animate people to shoot at their own feet.

Hmm :frowning:

Since Update 2.5.10 no items in the paperUI anymore. Items return when amazonechocontrol binding uninstalled, but disappear again when reinstalled.

Logfile tells:

2020-10-27 22:14:56.457 [ERROR] [ersey.server.ServerRuntime$Responder] - An I/O error has occurred while writing a response message entity to the container output stream.
org.glassfish.jersey.server.internal.process.MappableException: java.lang.NullPointerException
	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_152]
Caused by: java.lang.NullPointerException
	at org.openhab.binding.amazonechocontrol.internal.smarthome.DynamicStateDescriptionSmartHome.getStateDescription( ~[?:?]
	at org.eclipse.smarthome.core.thing.internal.ChannelStateDescriptionProvider.getDynamicStateDescription( ~[?:?]
	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 org.eclipse.smarthome.core.library.items.NumberItem.getStateDescription( ~[?:?]
	at ~[?:?]
	at ~[?:?]
	at ~[?:?]
	at$0( ~[?:?]
	at$3$1.accept( ~[?:1.8.0_152]
	at java.util.HashMap$KeySpliterator.tryAdvance( ~[?:1.8.0_152]
	at$WrappingSpliterator.lambda$initPartialTraversalState$0( ~[?:1.8.0_152]
	at$AbstractWrappingSpliterator.fillBuffer( ~[?:1.8.0_152]
	at$AbstractWrappingSpliterator.doAdvance( ~[?:1.8.0_152]
	at$WrappingSpliterator.tryAdvance( ~[?:1.8.0_152]
	at java.util.Spliterators$1Adapter.hasNext( ~[?:1.8.0_152]
	at ~[?:?]
	at ~[?:?]
	at ~[?:1.8.0_152]
	at ~[?:1.8.0_152]
	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( ~[?:?]
... 53 more

18 posts were split to a new topic: Start issue after upgrade

same for me, i have also tried to downgrade to 2.5.9, and there i have similar problems now :confused:

Guys you went off-topic. Nothing about start issues is specific to 2.5.10 so please stop here.
Open another thread if you feel the need to discuss this (again).


I have this problem with IKEA tradfri:

I thought that I found a solution but latest ooenHAB update broke it again.

[DEBUG] [internal.handler.TradfriThingHandler] - Sending payload: {“15015”:[{“5536”:0}],“3”:{}}
[DEBUG] [g.tradfri.internal.TradfriCoapClient] - CoAP PUT request uri: coaps://192.168.xx.xx:5684/15001/65548 payload: {“15015”:[{“5536”:0}],“3”:{}}

[DEBUG] [g.tradfri.internal.TradfriCoapClient] - CoAP GET request uri: coaps://192.168.xx.xx:5684/15011/15012

After updating from stable 2.5.9 to 2.5.10 I was not able to control my Philips Hue devices connected to my Hue Bridge anymore.

I noticed in Paper UI that the Hue Binding was not installed anymore after the update, so I installed it again through Paper UI.

Then more issues started, the Hue things were listed as online in PaperUI but I could not control them through OH2. After restarting the OH2 service I could control them in OH2 but only with a 5-10 second delay.
There were no errors in the logs, but in the binding debug log I saw that the http call to the bridge appeared only 4-10 seconds after I pressed the button in the sitemap.

I now deleted all hue things, removed the binding, restarted the bridge, installed binding again, paired it with OH2 and added the things again. It seems to work for now.

With htop I see that OH2 shows a lot of memory usage in VIRT, not sure if this is related to my issue or it was also like this before the update…

Hello when is it planned to release openhab 2.5.11 ?

I do think, there’s no immediate plans für 2.5.11, everyone is focused on openHAB3 I guess! :wink:
perhaps there’s one last release for openHAB2, but the focus is to bringt as much users as possible to OH3, as it is much much easier to maintain all the efforts, questions and stuff in the newest release.

I tentatively mentioned a 2.5.11 for early December, so yes, in this regard it would be time for it.
Running the release build shouldn’t be much effort, so I can try to do it this weekend.

But indeed: 99% of spare time is spent for 3.0 at the moment…

Yes, it’s clear that everybody is focusing on the OH3 release…

I am waiting for the updated yio remote plugin therefore I am asking

Was there any commit in 2.5 branch since 2.5.10 was released?

Yes, I had a rather important one.

A cherry picking before the build run should be good…