Errors received for switches after upgrade to OpenHAB 2.5

  • Platform information:
    • Hardware: RPi 3
    • OS: Raspbian Stretch
    • Java Runtime Environment: Oracle Java 1.8.0_65
    • openHAB version: 2.5
  • Issue of the topic: After upgrading to OpenHAB 2.5 (via apt) and checked the logs I have found errors related to turning on and off switches. I’m not completely sure if this problem started after the upgrade, but most likely. I’m not looking in the logs every day since the system has been working well for quite some time, but when I have done it before, I have not noticed this. I have both Tellstick Duo switches as well as Z-wave switches (aeotec z-stick gen5), and the problemappears for both types of switches when I push the switch in the sitemap gui. Please see the log below!
    I think what happens is that the value for some reason is “-”, instead of “ON” or “OFF”. Furthermore, it can’t find the file /etc/openhab2/transform/, but I guess that is caused by the actual error. Despite these log messages the system works.
    • Items configuration related to the issue
  • If logs where generated please post these here using code fences:

[ERROR] [ui.internal.items.ItemUIRegistryImpl] - transformation throws exception [, value=-]
org.eclipse.smarthome.core.transform.TransformationException: An error occurred while opening file.
at ~[?:?]
at ~[?:?]
at org.eclipse.smarthome.core.transform.AbstractFileTransformationService.transform( ~[bundleFile:?]
at org.eclipse.smarthome.ui.internal.items.ItemUIRegistryImpl.transform( [bundleFile:?]
at org.eclipse.smarthome.ui.internal.items.ItemUIRegistryImpl.getLabel( [bundleFile:?]
at [bundleFile:?]
at [bundleFile:?]
at [bundleFile:?]
at [bundleFile:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_65]
at sun.reflect.NativeMethodAccessorImpl.invoke( ~[?:1.8.0_65]
at sun.reflect.DelegatingMethodAccessorImpl.invoke( ~[?:1.8.0_65]
at java.lang.reflect.Method.invoke( ~[?:1.8.0_65]
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke( [bundleFile:?]
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$ [bundleFile:?]
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke( [bundleFile:?]
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch( [bundleFile:?]
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch( [bundleFile:?]
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke( [bundleFile:?]
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply( [bundleFile:?]
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply( [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_65]
Caused by: /etc/openhab2/transform/ (No such file or directory)
at Method) ~[?:1.8.0_65]
at ~[?:1.8.0_65]
at ~[?:1.8.0_65]
at ~[?:1.8.0_65]
at ~[?:1.8.0_65]
at ~[?:?]
… 68 more


It is looking for a file that is cannot locate.

EDIT: Also please use code fences.

Yes, but why, and why not in 2.4? I think it’s looking for it because it can’t find a suitable transformation because the value is strange (?).


Sorry for that, I tried, but used the wrong type of ticks…

I do not use transforms. sorry.

The transformations should not be necessary here, I think. It could be that there is another error triggering a transformation. But it’s strange since it seems to have worked in 2.4.

Have you tried stopping OH, cleaning the cache, and rebooting?

It won’t be looking for at random. You do have something configured to instruct openHAB.
From the mention of “-” I would guess in a label [format] block. Either an Item definition or a site map entry.
The “-” is what OH looks up in a label map for a NULL or UNDEF Item state.

I found the cause in a sitemap, as you say. It was in a map for a door sensor in my sitemap. I was confused because the error was triggered by the switches, but now I understand that it probably was triggered by the switch that updated the gui. I temporarily commented these lines out.

Still I think is strange that the map-problem started when I upgraded to 2.5.

Is the and standard maps (files)? Or is it something I must have defined myself, probably more than a year ago… :slight_smile:

They are something that you included.and configured.
You might want to consider that this issue has probably always been there, but doesn’t show up - unless you have unusual states like UNDEF for your Items that you didn’t account for in your MAPs.

That’s to say, this is a red herring and you actually have some problem with your Items updating. A look in events.log might help.

The maps are not in the transformation folder and I have for sure not removed them manually. But perhaps when I created them I followed some instruction on the internet, put them somewhere else and they were removed during the upgrade (?). Note that the sitemap still worked before I commented the lines and the doors showed the text “open” and “closed”. So I get the impression that it finds the map, but still produces an error.

Did you stop OH, clean the cache and reboot as mentioned above? You may have something lingering around in cache or tmp file that’s giving the issue. Cleaning the cache using sudo openhab-cli clean-cache will clean tmp file as well.

Thanks for the advice. I have tried that, I learned that because I had some issues with the mail and Z-wave after the upgrade. But I could solve those problems, and then this appeared when the log-files got readable again, too late in the evening before the Christmas holiday when I really need it to work to control the lights… :slight_smile:

I have now got some more time to investigate the issue. The MAP-transformation has been missing for some time, so there has been errors related to this before (but not as extensive writing to the log file). I’m not sure why the MAP-transformation has been removed, but the reason why these messages appeared now is because I saw the missing MAP-transformation and reinstalled it because I thought it was missing as a consequence of the upgrade (like the issues mention above). But I was wrong and too tired to make a proper debugging. Now the MAP-transformation has been removed in the sitemap and it seems to work as it should without it.

Thanks for you help!

1 Like