On unifi controller 6.4.54 on a RPI 4 and the latest nightly OH build on another RPI 4 I do get all channels working except the online channel. It only shows “NULL”. Similarily to what other reported.
Hi, same behavior here. I am using Software version 6.4.54 on a CloudKey 1 (original) together with a recent unifi binding snapshot for 3.2.0. ALL unifi items stay NULL, although bridge and wirelessClient are status green. I could nor manage to get it working at all under OH3. It has been working fine on OH2.5. And yes, I have added the parameter unifios=“false” in my Thing config.
Other prev. working config has been inherited.
regards,
funcarver72
Not sure, but I think that for the cloud key you should use unifios=true, but perhaps that’s just for the CK2 and UDM. Have you tried that?
As far as I know, the Unifi OS is on CK2 and UDM. Nontheless I have turned on the setting, but then it lost connection to the CK1 device.
Just as as follow up. The binding has been working just fine with the nightly builds, for a week or so.
Where do you download the latest builds?
Sorry, the latest openHAB builds.
Please see [unifi] Thing configuration changes are not reloaded · Issue #11407 · openhab/openhab-addons · GitHub - a fix for this configuration reload problem was included in milestone 4. I discovered this problem also while working on a fix for [unifi] Online channel not working after upgrading UniFi Controller to 5.12.35 · Issue #7001 · openhab/openhab-addons · GitHub which is also included in milestone 4.
1 Like
Hi
it able to work with Amplifi HD?
thx
Hi guys,
yesterday I updated Unifi OS (v2.2.12), Network (v6.5.53) and Protect (v1.20.0) on my UCKP. Since auto-updates are disabled within Unifi OS I am pretty sure that there were some former updates not installed - just as information.
Since those updates OH3.1.0 is running into OOM issues all the time. Several restarts of OH and Windows lead to a proper running OH for some minutes until RAM gets highloaded and any click on the PC and / or OH Main UI takes several minutes. There is no hint within the logs what is the rootcause, all errors which occur are related to any time out issues.
Since the updates on my UCKP were the only thing changed, my assumption was that Unifi binding (and / or Unifi Protect binding?) were causing the issue. I disabled all things related to those bindings and now OH is working fine again.
Unifi Protect NVR thing was online (as well as the cams), Unifi Controller was not (404 http error shown in Main UI). That’s why I firstly disabled Controller Thing (+ Phone Things) but only disabling Protect things additionally solved the OOM issue. However, since there definetly is an error at the Controller thing, most likely related to the updates within Unifi - I am posting this message in this thread.
Is there anybody running with above mentioned versions? Any issue with OH OOM? Or is there any idea how to solve at least the error of Controller thing (http error) even it’s not related to the OOM?
If you need any information from the logs (e.g.) please let me know. Thanks!
I run Unifi Network application standalone on the same Nuc as OH (no Protect controller o binding) and I haven’t experienced any issues (upgraded to 6.5.53 almost a week ago). So my guess is it’s the Protect binding that might be causing the issues.
Based on your reply I tried it and you are right, Unifi Controller seems not cause OOM issue. At least OH is running since a while with Controller Thing active (+ Protect still disabled!).
However, Controller thing shows an error in the UI and is offline:
**CONFIGURATION_ERROR**
Unknown HTTP status code 404 returned by the controller
log file shows:
org.openhab.binding.unifi.internal.api.UniFiException: Unknown HTTP status code 404 returned by the controller
at org.openhab.binding.unifi.internal.api.model.UniFiControllerRequest.getContent(UniFiControllerRequest.java:167) ~[bundleFile:?]
at org.openhab.binding.unifi.internal.api.model.UniFiControllerRequest.execute(UniFiControllerRequest.java:131) ~[bundleFile:?]
at org.openhab.binding.unifi.internal.api.model.UniFiController.executeRequest(UniFiController.java:207) ~[bundleFile:?]
at org.openhab.binding.unifi.internal.api.model.UniFiController.login(UniFiController.java:114) ~[bundleFile:?]
at org.openhab.binding.unifi.internal.api.model.UniFiController.start(UniFiController.java:97) ~[bundleFile:?]
at org.openhab.binding.unifi.internal.handler.UniFiControllerThingHandler.initialize(UniFiControllerThingHandler.java:92) [bundleFile:?]
at org.openhab.core.thing.binding.BaseThingHandler.thingUpdated(BaseThingHandler.java:152) [bundleFile:?]
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.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
at org.openhab.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:829) [?:?]
Any idea?
Since it’s a 404 error, it would indicate that the binding is trying to access a resource that doesn’t exist, and from the stack trace this seems to be when it tries to login. Can’t say more than that though…
Edit: a hypothesis could be that the protect binding encounters something similar, but handles it in a bad way, which causes a memory leak.
Can you log in manually to the Network/Protect applications? Do they produce any logs that gives some clues?
Yes, I can log into Unifi OS (network & protect) with the credentials saved in OH Controller & NVR thing - double-checked again.
The latest log entry is a bit more longer, but as far as I can assess, it shows the same information:
2021-11-29 15:41:00.493 [ERROR] [.handler.UniFiControllerThingHandler] - Unknown error while configuring the UniFi Controller
org.openhab.binding.unifi.internal.api.UniFiException: Unknown HTTP status code 404 returned by the controller
at org.openhab.binding.unifi.internal.api.model.UniFiControllerRequest.getContent(UniFiControllerRequest.java:167) ~[?:?]
at org.openhab.binding.unifi.internal.api.model.UniFiControllerRequest.execute(UniFiControllerRequest.java:131) ~[?:?]
at org.openhab.binding.unifi.internal.api.model.UniFiController.executeRequest(UniFiController.java:207) ~[?:?]
at org.openhab.binding.unifi.internal.api.model.UniFiController.login(UniFiController.java:114) ~[?:?]
at org.openhab.binding.unifi.internal.api.model.UniFiController.start(UniFiController.java:97) ~[?:?]
at org.openhab.binding.unifi.internal.handler.UniFiControllerThingHandler.initialize(UniFiControllerThingHandler.java:92) ~[?:?]
at org.openhab.core.thing.binding.BaseThingHandler.handleConfigurationUpdate(BaseThingHandler.java:107) ~[?:?]
at org.openhab.core.thing.internal.ThingRegistryImpl.updateConfiguration(ThingRegistryImpl.java:94) ~[?:?]
at org.openhab.core.io.rest.core.internal.thing.ThingResource.updateConfiguration(ThingResource.java:498) ~[?:?]
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:3.4.3]
at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96) ~[bundleFile:3.4.3]
at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:201) ~[bundleFile:3.4.3]
at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:104) ~[bundleFile:3.4.3]
at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59) ~[bundleFile:3.4.3]
at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:96) ~[bundleFile:3.4.3]
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) ~[bundleFile:3.4.3]
at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) ~[bundleFile:3.4.3]
at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:265) ~[bundleFile:3.4.3]
at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234) ~[bundleFile:3.4.3]
at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208) ~[bundleFile:3.4.3]
at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160) ~[bundleFile:3.4.3]
at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:225) ~[bundleFile:3.4.3]
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:298) ~[bundleFile:3.4.3]
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPut(AbstractHTTPServlet.java:234) ~[bundleFile:3.4.3]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710) ~[bundleFile:3.1.0]
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:273) ~[bundleFile:3.4.3]
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:791) ~[bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:550) ~[bundleFile:9.4.40.v20210413]
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.40.v20210413]
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:602) ~[bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~[bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235) ~[bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624) ~[bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233) ~[bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1435) ~[bundleFile:9.4.40.v20210413]
at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:294) ~[bundleFile:?]
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188) ~[bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:501) ~[bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594) ~[bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186) ~[bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1350) ~[bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) ~[bundleFile:9.4.40.v20210413]
at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:82) ~[bundleFile:?]
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~[bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.server.Server.handle(Server.java:516) ~[bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:388) ~[bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:633) [bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:380) [bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277) [bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) [bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105) [bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104) [bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336) [bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313) [bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171) [bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129) [bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:383) [bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:882) [bundleFile:9.4.40.v20210413]
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1036) [bundleFile:9.4.40.v20210413]
at java.lang.Thread.run(Thread.java:829) [?:?]
I guess you may be right, protect binding is doing basically the same and is most likely causing the OOM issue therfore. But how can I solve the issue? Credentials, IP, port, Unifi OS activated - everything is the same as before when it works properly for month…? 
Can you ssh into the cloud key and check the logs there? Not sure about the location, but on my system they are in the /var/log/unifi folder.
As far as I remember the Controller software has several different log files. Based on Ubiquiti’s How To the log can be directly downloaded via Unifi OS for UCKP. But there is only one log file (server.log)…
The most recent entries (at the time where I changed and saved OH Controller thing’s settings in order to “manually” start login trials maybe):
[2021-11-29T17:20:53,060] <inform_stat-1> WARN event - Unrendered device from unknown type ap_from while trying to render device name
[2021-11-29T17:20:53,061] <inform_stat-1> WARN event - Unrendered device from unknown type ap_to while trying to render device name
The following one comes up several times - and I am wondering why there seems to be an issue with firmware?!
[2021-11-29T17:34:47,735] <webapi-47> ERROR system - Failed to load file[/usr/lib/unifi/data/firmware/firmware_meta.json] as JSON
java.io.FileNotFoundException: /usr/lib/unifi/data/firmware/firmware_meta.json (No such file or directory)
at java.io.FileInputStream.open0(Native Method) ~[?:1.8.0_302]
at java.io.FileInputStream.open(FileInputStream.java:195) ~[?:1.8.0_302]
at java.io.FileInputStream.<init>(FileInputStream.java:138) ~[?:1.8.0_302]
at java.io.FileInputStream.<init>(FileInputStream.java:93) ~[?:1.8.0_302]
at java.io.FileReader.<init>(FileReader.java:58) ~[?:1.8.0_302]
at com.ubnt.data.X.loadJSON(Unknown Source) [ace.jar:?]
at com.ubnt.service.system.FA.o00000(Unknown Source) [ace.jar:?]
at com.ubnt.service.firmware.OO0O.øÖ0000(Unknown Source) [ace.jar:?]
at com.ubnt.service.firmware.OO0O.returnclass(Unknown Source) [ace.jar:?]
at com.ubnt.service.firmware.OO0O.oÒ0000(Unknown Source) [ace.jar:?]
at com.ubnt.service.firmware.OO0O.Ò00000(Unknown Source) [ace.jar:?]
at com.ubnt.service.firmware.OO0O$_o0.doCmd(Unknown Source) [ace.jar:?]
at com.ubnt.ace.api.ApiUtils.execute(Unknown Source) [ace.jar:?]
at com.ubnt.ace.api.ApiUtils.execute(Unknown Source) [ace.jar:?]
at com.ubnt.service.firmware.OO0O.o00000(Unknown Source) [ace.jar:?]
at com.ubnt.ace.api.OooO.o00000(Unknown Source) [ace.jar:?]
at com.ubnt.ace.api.ApiServlet.service(Unknown Source) [ace.jar:?]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:741) [tomcat-embed-core-8.5.56.jar:8.5.56]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231) [tomcat-embed-core-8.5.56.jar:8.5.56]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) [tomcat-embed-core-8.5.56.jar:8.5.56]
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) [tomcat-embed-websocket-8.5.56.jar:8.5.56]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) [tomcat-embed-core-8.5.56.jar:8.5.56]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) [tomcat-embed-core-8.5.56.jar:8.5.56]
at com.ubnt.service.trace.requestmetrics.new.doFilter(Unknown Source) [ace.jar:?]
at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:358) [spring-web-5.3.7.jar:5.3.7]
at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:271) [spring-web-5.3.7.jar:5.3.7]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) [tomcat-embed-core-8.5.56.jar:8.5.56]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) [tomcat-embed-core-8.5.56.jar:8.5.56]
at com.ubnt.ace.view.AuthFilter.doFilter(Unknown Source) [ace.jar:?]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) [tomcat-embed-core-8.5.56.jar:8.5.56]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) [tomcat-embed-core-8.5.56.jar:8.5.56]
at com.ubnt.ace.view.UbiosHttpsFilter.doFilter(Unknown Source) [ace.jar:?]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) [tomcat-embed-core-8.5.56.jar:8.5.56]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) [tomcat-embed-core-8.5.56.jar:8.5.56]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:199) [tomcat-embed-core-8.5.56.jar:8.5.56]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96) [tomcat-embed-core-8.5.56.jar:8.5.56]
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:543) [tomcat-embed-core-8.5.56.jar:8.5.56]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139) [tomcat-embed-core-8.5.56.jar:8.5.56]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81) [tomcat-embed-core-8.5.56.jar:8.5.56]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87) [tomcat-embed-core-8.5.56.jar:8.5.56]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343) [tomcat-embed-core-8.5.56.jar:8.5.56]
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:615) [tomcat-embed-core-8.5.56.jar:8.5.56]
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65) [tomcat-embed-core-8.5.56.jar:8.5.56]
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:818) [tomcat-embed-core-8.5.56.jar:8.5.56]
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1627) [tomcat-embed-core-8.5.56.jar:8.5.56]
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) [tomcat-embed-core-8.5.56.jar:8.5.56]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_302]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_302]
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) [tomcat-embed-core-8.5.56.jar:8.5.56]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_302]
Is this helpfull somehow?
No idea unfortunately . Looked through my server.log and also had repeated errors (but different than yours). Hard to know what to expect to be normal when you don’t look at them regularly.
I just restarted my unifi service and got the same OH-logs as you (without the full stack trace however), but only temporarily, after it had completed restarting the controller thing went online again. I believe there was some bug fixes in the unifi binding that’s included in 3.2.0.M4, so you might want to upgrade. If you want to wait for the stable release you might have to wait a month.
I will try the OH update and let you know if it works.
Edit: after update to OH3.2 everything is working fine again! Thanks for your support! 
Glad to hear. Might still be something to fix the login, you shouldn’t run oom in case it cannot login.
Edit: I was writing this more in the context of the UniFi Protect binding.