[SOLVED] "ERROR: 500 - Internal Server Error" while adding or deleting Homematic "CCU3-App" from Inbox

Hi Community,

I’m receiving the (in the title) mentioned Error-Message while trying to remove the “Homematic CCU3-App”. Hide or Adding throws the same error message. Weird thing though: the CCU3 Bridge is already added and the HomeMatic Configuration works fine. Log is showing no Information (switched to trace level but did not see any hints).
Suddenly it showed up as per below:

My setup is as follows: everything is running on a small ESXi-environement, including HomeMatic (Raspberrymatic)! I have a Pi Zero running as LAN Gateway to ensure radio-communication. The LAN Gateway popped up in Inbox (like the CCU3-VM as “CCU3-App”), but adding it to OH brings no added value, as it appears OFFLINE afterwards, so I removed it (which worked well and it did not show up again in Inbox).

I did not really take care of it as everything is working fine (and only kind of “flaw”). But I started now to set up a new virtual machine for OH3 in order to migrate my things and to get rid of some beginners mistakes I did when I started with OH2. However, the “CCU3-App” as shown above is shown in the fresh installation of OH3 with only the HomeMatic-Binding and I have the same issue: CCU3-Bridge successfully added and HomeMatic is working fine, but the “CCU3-App” is shown and I can’t delete/ hide/ add/ whatever.

Is this a known issue and how can I fix it? (This is now a matter of interest as I will have this issue still with OH3 then).

Many thanks in advance for your support and cheers,
Matze.

Hi all,

need to bring this up again unfortunately…
After playing around with OH3 in test environment for long enough time now, I decided to start to migrate to a production environment of OH3 (so, fresh installation again).
However, even with a fresh setup I get the same issue again, but have now some logging available from OH3.

(running on OH 3.0.2 and HomeMatic 3.55.10.20210213 (I know, newer version available, but the issue occured already before the last update(s); nevertheless, will update CCU asap :wink: ).

HomeMatic CCU3 (still running as an ESXi VM as mentioned above) is already successfully added as Bridge, the screenshot above shows the actual Inbox (obviously :crazy_face: ) with the entry in question. It does not matter whether adding, ignoring or removing the entry (“trying to…”), it states

"Error while removing (/ignoring/ creating) thing: Server Error".

In the openhab-log there’s the following to find:

2021-05-27 21:56:45.929 [ERROR] [internal.JSONResponseExceptionMapper] - Unexpected exception occurred while processing REST request.
java.lang.IllegalArgumentException: UID must have at least 3 segments.
	at org.openhab.core.common.AbstractUID.<init>(AbstractUID.java:71) ~[?:?]
	at org.openhab.core.common.AbstractUID.<init>(AbstractUID.java:49) ~[?:?]
	at org.openhab.core.thing.UID.<init>(UID.java:48) ~[?:?]
	at org.openhab.core.thing.ThingUID.<init>(ThingUID.java:130) ~[?:?]
	at org.openhab.core.io.rest.core.internal.discovery.InboxResource.approve(InboxResource.java:114) ~[?:?]
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
	at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
	at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
	at org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:179) ~[bundleFile:1.0.9]
	at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96) ~[bundleFile:1.0.9]
	at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:201) [bundleFile:1.0.9]
	at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:104) [bundleFile:1.0.9]
	at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59) [bundleFile:1.0.9]
	at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:96) [bundleFile:1.0.9]
	at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) [bundleFile:1.0.9]
	at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) [bundleFile:1.0.9]
	at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:267) [bundleFile:1.0.9]
	at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234) [bundleFile:1.0.9]
	at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208) [bundleFile:1.0.9]
	at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160) [bundleFile:1.0.9]
	at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:216) [bundleFile:1.0.9]
	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:301) [bundleFile:1.0.9]
	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:220) [bundleFile:1.0.9]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [bundleFile:3.1.0]
	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:276) [bundleFile:1.0.9]
	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:?]
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.server.Server.handle(Server.java:494) [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:374) [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:268) [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117) [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336) [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313) [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171) [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129) [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:367) [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:782) [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:918) [bundleFile:9.4.20.v20190813]
	at java.lang.Thread.run(Thread.java:829) [?:?]

…maybe I tried the wrong keywords, but I did not come any further after googleing this stuff for resolution. It would be very much appreciated if someone has a hint where to look/ what to do for a clean Inbox.

Many thanks
Matze.

Hi all,

I’m still struggling with that issue and did not find any solution so far.
Is there any option to alter the UID of the device in order to make it “removable”? As shown in the screenshot, it states the bridge as “homematic:bridge:”, same in the DiscoveryResult.json-File. Even altering the DiscoverResult-File (and restarting the Openhab service) does not help, the UID is still shown with only 2 segments.

…Side note on it: the correct Bridge (same IP-address) is already added and is working properly. So only thing I want to achieve is to “clean up” the Inbox.

Thanks for further suggestions!

Did you enable full API access in the CCU3?

Hi Oliver,

thanks for coming back on this.
The CCU3 is already added as a bridge and working fine. But OH still shows me the “CCU3-App” in the Inbox (or additionally?).

My goal is just to get rid of the entry in the Inbox, it does not affect functionality.

Many thanks.

I would re-open this question in the bindings forum and pull in the developer.
Maybe request also help from raspberrymatic developer because I also have homematic binding and do not have this App thing. However, I have a ccu3 device and no emulation.

The binding scans the network and searches for CCUs. It seems that it detects the LAN Gateway and adds it as “… App”. Maybe it is possible to suppress is completely during the discovery process but this would require some additional information from the discovery process.
Can you set the log mode to DEBUG, run a discovery and attach the openhab.log file with the logs of the discovery?

But I think, there is an easier solution: in the inbox you can set a thing to “ignore”. Then it disappears from Inbox.

Thanks Oliver and Martin for your support on this.
@Oliver2: worth a try to re-open this one in the bindings forum… Thanks for the suggestions!

@MHerbst: thanks as well. I just set basically everything related to Inbox- and Things-Events on debug level but there’s no new information (a manual scan does not bring up anything new, maybe because it was already detected). The issue is, that I’m not able to REMOVE or IGNORE the entry, because it throws the same error (including the log as posted earlier with the “UID must have at least 3 segments.”-entry and yes it is shown as “homematic:bridge:”.

Thanks for any further suggestions and cheers, Matze.

I think the problem with the UID is a problem in OH Core (or even the Main UI) that has been solved with 3.1. It sound very familiar to me.

Hi @MHerbst,

sorry, I just realized that I missed your answer on this which sounded very promising. Unfortunately I’m already running 3.1.0 but the issue still persits. It’s still shown with this wrong UID and I still cannot delete/ ignore/ add…

Many thanks for your support on this!
Cheers,
Matze.

…just in case someone is facing the same issue. Eventually I got it sorted out.

Just a few days ago I changed my Raspberry3-CCU3 (raspberrymatic) and just used the already set up CCU3-Bridge-Thing. However, I encountered some “Item-State-Update-Issues” and just decided to remove the Bridge-Thing and readded it.
With this procedure, this faulty CCU3-App-Thing from the inbox disappeared and reappeared a couple of seconds later on with a correct UID. This one then eventually I was able to add as a Thing (however, until today I don’t know what to do with it, it’s now just there an ONLINE)…

Root cause? Unknown. Will I investigate: not anymore.
With that: case closed and solved.

Thanks to all who helped on this one