Some Items do not work after Release Change

  • Platform information:
  • Hardware: Intel Nuc Processor J3455
  • Windows 10
  • Java Runtime Environment: Java 8 191
  • openHAB version: 2.5.6

I have migrated from 2.3.0 to 2.5.6.
Allmost everything is ok.
One Issue.

In release 2.3.0 I have creates some Items with no channels defined, some in Paper UI and some in .items file.
I have used them only for rules and there based on their state to stear other Items. E.g. An Item called present is used in a rule to switch on and off all power outlets outside the house.

All these Items do not change the state anymore if I switch them off or on.

Is there a change in how to use such Switches which are used in ruels only in the new release?

Please advise what I need to do. Thanks

Please show us your events.log for this happening.

There are a lot of changes from 2.3 to 2.5, but the only relevant one I can think of is that autoupdate will no longer update an Item state in response to a command, if the Item is linked to a broken channel.

ok thanks for the hint. I found a new field in Paper IU of 2.5.6 where I can enforce autoupdate.I have added autoupdate=enforce and now they work as requested. Problem solved. I guess I could also do so in .items file {autoupdate=enforce} without adding a channel

It’s autoupdate="true" in that form.

If you need to do this - your events.log showing your problem is still secret - then you have channels linked to the affected Items. The default for autoupate is enabled, an unlinked Item does not need forcing.
You need to wonder what links you have.

There are a few binding/channel combinations that can invoke this effect also, without there being a “fault”. That happens when a binding assumes a device will respond to commands, but some device configuration prevents it doing so.

More often it is because the channel is simply invalid.

Even when items are defined in xxx.items files, links can made with PaperUI (which won’t be seen in the files). I’ll hazard a guess you may have “ghost links” hanging around from long ago experiments.

2 Likes

Thank you for the explanation. I was migrating from 2.3.0 to 2.5.6. In 2.3.0 I had no issue with any of these items. Since I have enforeced the autoupdate all is fine. It happend with the KNX binding. KNX and ETS was the reason why I installed on Windows. As ETS is only available there.

My questions for you:

  1. I wonder if I have any hidden issues or if I can just leave it as is.
  2. Would You know where in the logs in windows and what exactly would be seen, if I had ghost links?

Thank you for your help
Thomas

In the OpenHAB log I found the following thing, that seems not to be ok.
Any Idea?

Caused by: org.glassfish.hk2.api.MultiException: A MultiException has 1 exceptions. They are:

  1. java.lang.IllegalStateException: ServiceLocatorImpl(__HK2_Generated_694,695,911339700) has been shut down

    at org.jvnet.hk2.internal.FactoryCreator.getFactoryHandle(FactoryCreator.java:106) ~[?:?]
    at org.jvnet.hk2.internal.FactoryCreator.dispose(FactoryCreator.java:173) ~[?:?]
    at org.jvnet.hk2.internal.SystemDescriptor.dispose(SystemDescriptor.java:526) ~[?:?]
    at org.glassfish.jersey.process.internal.RequestScope$Instance.remove(RequestScope.java:532) ~[?:?]
    at org.glassfish.jersey.process.internal.RequestScope$Instance.release(RequestScope.java:549) ~[?:?]
    at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:319) ~[?:?]
    at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:305) ~[?:?]
    at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1154) ~[?:?]
    at org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:473) ~[?:?]
    at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:427) ~[?:?]
    at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:388) ~[?:?]
    at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:341) ~[?:?]
    at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:228) ~[?:?]
    at com.eclipsesource.jaxrs.publisher.internal.ServletContainerBridge.service(ServletContainerBridge.java:76) ~[?:?]
    at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:852) ~[bundleFile:9.4.20.v20190813]
    at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:544) ~[bundleFile:9.4.20.v20190813]
    at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71) ~[bundleFile:?]
    at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) ~[bundleFile:9.4.20.v20190813]
    at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:536) ~[bundleFile:9.4.20.v20190813]
    at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~[bundleFile:9.4.20.v20190813]
    at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235) ~[bundleFile:9.4.20.v20190813]
    at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1581) ~[bundleFile:9.4.20.v20190813]
    at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233) ~[bundleFile:9.4.20.v20190813]
    at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1307) ~[bundleFile:9.4.20.v20190813]
    at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:293) ~[bundleFile:?]
    at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188) ~[bundleFile:9.4.20.v20190813]
    at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:482) ~[bundleFile:9.4.20.v20190813]
    at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1549) ~[bundleFile:9.4.20.v20190813]
    at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186) ~[bundleFile:9.4.20.v20190813]
    at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1204) ~[bundleFile:9.4.20.v20190813]
    at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) ~[bundleFile:9.4.20.v20190813]
    at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:80) ~[bundleFile:?]
    … 15 more

Example here

If you have ghosts here, it does not show up in any logging in particular.
Unconnected to your jetty error log, which might be about a UI

1 Like

Thanks! So I opened Rest API, there “get links” and found some links referencing Items I never had linked. Like here:

Item Kindwest_J is such a “Dummy-Item” as mentioned before to only influence rules.

Net step is to figure out how to get rid of those.

It didn’t happen by itself, probably just some forgotten clicking in PaperUI from long ago.

The linked thread includes a how-to for removal, as well.

Thanks. Concerning the links: Ok, if you say so. At the beginning I have testet some things ans items, which I deleted or changend later. So it is possible that this are remains of it. Strange enough that these items only caused problems after the release update. In the old release (2.3.0) it did not happen.

Anyway, it seems like a bit of work for me, as I have also the Error Code 500 and 503 Problem, that is documented here.

https://community.openhab.org/t/error-500-and-503-after-ver2-4-upgrade/62845

So I will try to uninstall and reinstall all bindings, one after the other and check if I get rid of it. Maybe also the add ons like the myopenHAB cloud.

Yes, they enhanced autoupdate, so that it gave a more appropriate response to a broken channel link than it used to.

Thank you for your advise. I will post as soon as I have made progress or struggle again :crazy_face:. It can take some days, as I have to reserve some time to work through all items and the 500 503 problems.

Hi,

This topic triggered my curiosity since I am doing exactly the same as T-A describes in the first entry: Making extensive use of Switch Items to hold states unrelated to Things in rules.

I do it because I discovered that Items were not modified by xxx.rules updates to a running system, and execution therefore not affected.

Then I saw the discussion in entry 4 on the need for autoupdate=enforce or =”true” related to OH versions, and you lost me.

Simple question: Is it questionable to use link-less Items in rules?

Not at all. It’s routine for most OH users.

By default, autoupdate is enabled for these Items, this provides a link otherwise missing between state and command.

If you’re curious about autoupdate …

Thank you for the primer and the help. All is working now. See my comments in Topic Release change from 2.3.0 to 2.5.5

All fine now!

All is working fine now and works like in release 2.3 , after I have removed my zombie-links or ghost-links using the Rest API, as decribed in this topic.

1 Like