BasicUI gives Server Error 500 after a few hours

I’m running a Pi with OpenHAB2 which has been stable for a while. Given the troubles I had setting it up, I had tried to avoid updating and had been running 2.3.0 SNAPSHOT for a while (August 2017 ish).

Anyway, BasicUI wasn’t showing the right status of my Hue switches, so I figured what the hell, and updated…

All went well, but now ive started to get Error 500 after a while - ONLY on BasicUI (PaperUI & Habmin work ok);

HTTP ERROR 500
Problem accessing /basicui/app. Reason:

    Server Error
Caused by:
java.lang.NullPointerException
	at org.eclipse.smarthome.ui.basic.internal.render.SetpointRenderer.renderWidget(SetpointRenderer.java:65)
	at org.eclipse.smarthome.ui.basic.internal.render.PageRenderer.renderWidget(PageRenderer.java:194)
	at org.eclipse.smarthome.ui.basic.internal.render.PageRenderer.processChildren(PageRenderer.java:160)
	at org.eclipse.smarthome.ui.basic.internal.render.PageRenderer.processChildren(PageRenderer.java:181)
	at org.eclipse.smarthome.ui.basic.internal.render.PageRenderer.processPage(PageRenderer.java:124)
	at org.eclipse.smarthome.ui.basic.internal.servlet.WebAppServlet.service(WebAppServlet.java:188)
	at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:848)
	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:584)
	at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71)
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
	at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
	at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:284)
	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
	at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:80)
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
	at org.eclipse.jetty.server.Server.handle(Server.java:534)
	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:333)
	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283)
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108)
	at org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
	at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
	at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
	at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
	at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)
	at java.lang.Thread.run(Thread.java:748)

Clearing the UserData Config & UserData TMP dirs bring it back to life, but only for a few hours until whatever is triggering it, happens again.

Any ideas?

Have you tried Clear the Cache yet? When weird things like this start happening it is the first thing to try.

The upgrade should have done this for you but I guess sometimes something goes wrong to corrupt it when it gets rebuilt.

Sometimes it helps.

Yeah, this brings it back to life for a few hours…

@Vini is the cache directory contained in the ones you cleared? There is an actual directory named “cache” the Rich was asking about.

My bad, typo, I of course meant Cache not Config.

I have however, seemed to identify the cause as being an erroneous setpoint in my sitemap. This has worked flawlessly until I switched from 2.3.0 to 2.4.0, so I’m wondering if something has been deprecated in the runtime/binding, or maybe my Java update caused something?

Setpoint item=NestTStatHallway_target_temperature_c label="Target Home Temperature" minValue=1 maxValue=32 step=1 icon="temperature"

Either way, after removing that line from my sitemap, it seems to work again…

The good news (for me) is that im soon to be moving house so plan to redo my Openhab instance anyway. But thats not really the point.

I don’t know that this is new, but I do think the order matters, meaning you should put the icon after the label. Let us know if that fixes it. If not come back and we can start to figure out how to file an issue. Either there is a bug that was introduced and we need to file an issue, or there is a breaking change we need to make sure makes it into the release notes.

Further investigation reveals its actually the [%.1f °C] transform within the label that is breaking it;

Setpoint item=NestTStatHallway_target_temperature_c label="Target Home Temperature [%.1f °C]" minValue=1 maxValue=32 step=1 icon="temperature"

If I remove the [%.1f °C] transform it actually works.

I would say this was definitely introduced in 2.4.0, rightly or wrongly I’ve been using this particularly transform since I started using Openhab & Nest.

I suspect this is something that I’ve missed and/or a bug in the Nest binding (and/or maybe, missing documentation?).

With the introduction of “item dimension” I have dropped the [%.1f °C] transform from the sitemap label and updated the Dimension of the Nest “target temperature” item to Temperature within PaperUI. It now shows correctly as °C in my BasicUI sitemap, with no error.

OK, yes this is probably caused by the introduction of units and Nest 2.x binding just recently started using them. I’ve still not wrapped my head around how they work but I do know they break some things.