Ubiquiti Unifi Binding Feature Discussion

I’m seeing this:

2018-12-06 19:53:34.868 [ERROR] [org.apache.felix.scr                ] - bundle org.apache.felix.scr:2.1.2 (39)Circular reference detected trying to get service {org.eclipse.smarthome.io.net.http.TlsTrustManagerProvider}={service.id=134, service.bundleid=190, service.scope=bundle, component.name=org.openhab.binding.unifi.internal.ssl.UniFiTrustManagerProvider, component.id=25}
2018-12-06 19:53:34.883 [WARN ] [org.openhab.binding.unifi           ] - FrameworkEvent WARNING - org.openhab.binding.unifi

and I’m definitely using the right jar:

openhab> bundle:list|grep -i unifi
190 x Active   x  80 x 2.4.0.201812061741     x UniFi Binding

PaperUI is showing this for the bridge:

Status: OFFLINE - CONFIGURATION_ERROR java.lang.RuntimeException: No Common Name found

I’m using milestone build M7 - should I be on the nightlies?

Anyone any ideas?

Rory.

Thanks guys for testing this so quickly. This is exactly why I asked everybody to test these changes … the HttpClient + SSL stuff changed a bit.

It’s late where I am but I will dig deeper first thing in the morning.

1 Like

My Bridge and the 2 Things (wirelessClient) are showing Online even with this ERROR being logged and they seem to work

More details from the logs:

2018-12-06 20:54:31.669 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'unifi.things'
2018-12-06 20:54:32.756 [ERROR] [.handler.UniFiControllerThingHandler] - Unknown error while configuring the UniFi Controller
org.openhab.binding.unifi.internal.api.UniFiException: java.lang.RuntimeException: No Common Name found
        at org.openhab.binding.unifi.internal.api.UniFiControllerRequest.getContentResponse(UniFiControllerRequest.java:157) ~[190:org.openhab.binding.unifi:2.4.0.201812061741]
        at org.openhab.binding.unifi.internal.api.UniFiControllerRequest.getContent(UniFiControllerRequest.java:117) ~[190:org.openhab.binding.unifi:2.4.0.201812061741]
        at org.openhab.binding.unifi.internal.api.UniFiControllerRequest.execute(UniFiControllerRequest.java:102) ~[190:org.openhab.binding.unifi:2.4.0.201812061741]
        at org.openhab.binding.unifi.internal.api.UniFiController.executeRequest(UniFiController.java:113) ~[190:org.openhab.binding.unifi:2.4.0.201812061741]
        at org.openhab.binding.unifi.internal.api.UniFiController.login(UniFiController.java:70) ~[190:org.openhab.binding.unifi:2.4.0.201812061741]
        at org.openhab.binding.unifi.internal.api.UniFiController.start(UniFiController.java:56) ~[190:org.openhab.binding.unifi:2.4.0.201812061741]
        at org.openhab.binding.unifi.internal.handler.UniFiControllerThingHandler.initialize(UniFiControllerThingHandler.java:117) [190:org.openhab.binding.unifi:2.4.0.201812061741]
        at org.eclipse.smarthome.core.thing.binding.BaseThingHandler.thingUpdated(BaseThingHandler.java:208) [108:org.eclipse.smarthome.core.thing:0.10.0.oh240M7]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
        at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
        at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [101:org.eclipse.smarthome.core:0.10.0.oh240M7]
        at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [101:org.eclipse.smarthome.core:0.10.0.oh240M7]
        at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
        at java.lang.Thread.run(Thread.java:748) [?:?]
Caused by: java.lang.RuntimeException: No Common Name found
        at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1519) ~[?:?]
        at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:528) ~[?:?]
        at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:802) ~[?:?]
        at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:766) ~[?:?]
        at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624) ~[?:?]
        at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.fill(SslConnection.java:681) ~[?:?]
        at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.process(HttpReceiverOverHTTP.java:128) ~[?:?]
        at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.receive(HttpReceiverOverHTTP.java:73) ~[?:?]
        at org.eclipse.jetty.client.http.HttpChannelOverHTTP.receive(HttpChannelOverHTTP.java:133) ~[?:?]
        at org.eclipse.jetty.client.http.HttpConnectionOverHTTP.onFillable(HttpConnectionOverHTTP.java:155) ~[?:?]
        at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:281) ~[?:?]
        at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) ~[?:?]
        at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:291) ~[?:?]
        at org.eclipse.jetty.io.ssl.SslConnection$3.succeeded(SslConnection.java:151) ~[?:?]
        at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) ~[?:?]
        at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118) ~[?:?]
        at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333) ~[?:?]
        at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310) ~[?:?]
        at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168) ~[?:?]
        at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126) ~[?:?]
        at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366) ~[?:?]
        at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:762) ~[?:?]
        at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:680) ~[?:?]
        ... 1 more
Caused by: java.lang.IllegalStateException: No Common Name found
        at org.eclipse.smarthome.io.net.http.internal.ExtensibleTrustManager.getCommonName(ExtensibleTrustManager.java:157) ~[?:?]

I’m going to touch on both of the issues that have been reported:

[1] Circular reference detected

The error looks like this:

!ENTRY org.apache.felix.scr 4 0 2018-12-07 06:55:13.806
!MESSAGE Circular reference detected trying to get service {org.eclipse.smarthome.io.net.http.TlsTrustManagerProvider}={service.id=62, service.bundleid=4, service.scope=bundle, component.name=org.openhab.binding.unifi.internal.ssl.UniFiTrustManagerProvider, component.id=26}
 stack of references: ServiceReference: {org.eclipse.smarthome.io.net.http.TlsTrustManagerProvider}={service.id=62, service.bundleid=4, service.scope=bundle, component.name=org.openhab.binding.unifi.internal.ssl.UniFiTrustManagerProvider, component.id=26}
ServiceReference: {org.eclipse.smarthome.io.net.http.internal.ExtensibleTrustManager}={service.id=69, service.bundleid=107, service.scope=bundle, component.name=org.eclipse.smarthome.io.net.http.internal.ExtensibleTrustManager, component.id=29}

What I think is happening:

  1. UniFiThingHandlerFactory depends on a reference to HttpClientFactory
  2. HttpClientFactory depends on ExtensibleTrustManager
  3. ExtensibleTrustManager depends on TlsTrustManagerProvider (provided by unifi) <-- circular reference

@martinvw Going to need your input here as you were involved with the TlsTrustManagerProvider interface :wink:

Regardless of this error, it seems that it eventually loads everything and the binding functions as expected.

[2] java.lang.RuntimeException: No Common Name found

@roryd This looks like an issue with your SSL certificate. How are you running the UniFi controller (docker, cloud key, raspberry pi)?

The latest version of the binding expects to see the common name property of the SSL certificate as UniFi and the error seems to be saying there is no CN property in your SSL certificate or it’s blank.

Can you verify this through your browser?

1 Like

I’ll put this on the 2.5.0-SNAPSHOT list

Since the controller is a bridge, I really don’t think it should have any channels. What about if we added a site thing that included a handful of “client count” channels:

  • totalClients
  • wirelessClients
  • wiredClients
  • guestClients

Thoughts?

3 Likes

Why should a bridge have no channels? I think it perfectly fits to have these numbers in the bridge.

Another thing: why do you expect UniFi as CN? What if I imported a valid certificate with a FQDN other than UniFi (e.g. wireless.foo.org)?

It does load but data are not updated… so the Binding is broken with version 2.4.0.201812061741

Sounds cool. I have just checked the few bridges in my system (hue, netatmo and somfytahoma, and none of them have channels of their own, so a “site” thing seems to be the way to go.

1 Like

What if you wanted to track the number of clients for siteA and siteB? If these channels were on the controller (where the site parameter would be defined), you could only track one site.

Because that’s the default generated CN by the controller. If you were to import a valid certificate from a trusted CA (say from Let’s Encrypt), then Java’s built-in trust management would kick in and everything would still work. Just because the binding is expecting CN=UniFi doesn’t mean that’s the only SSL cert it would accept.

@kai requested that I try and make use of the common HttpClient instance provided by the framework. However, since the default SSL cert in the controller is self-signed, it’s a bit tricky to get the framework to accept the SSL cert.

I’m setting up a fresh instance of 2.4.0-SNAPSHOT to try and get to the bottom of this.

1 Like

Good point with different Sites. I overlooked that (only one site here).

Regarding the certs: perfect.

And BTW: Thanks, I really like the binding.

@mgbowman I’m running a cloud key, and now that I’ve checked the cert, that’s where the issue is - no CN:
image

I have another site working fine - cert should look like this:

Not too sure why/how this happened, but I will investigate further.

When you say “another site” do you mean another controller? Is it also running on a cloud key?

@mgbowman Unfortunately not, it’s a Windows version :frowning_face:

I just setup a fresh instance of 2.4.0-SNAPSHOT Build #1451 and it updates fine for me:

openhab> bundle:list | grep -i unifi
233 │ Active   │  80 │ 2.4.0.201812061741     │ UniFi Binding

events.log

2018-12-07 12:14:27.248 [vent.ItemStateChangedEvent] - MatthewsPhone changed from OFF to ON
2018-12-07 12:14:27.249 [vent.ItemStateChangedEvent] - MatthewsPhoneSite changed from UNDEF to [redacted]
2018-12-07 12:14:27.251 [vent.ItemStateChangedEvent] - MatthewsPhoneMAC changed from UNDEF to [redacted]
2018-12-07 12:14:27.252 [vent.ItemStateChangedEvent] - MatthewsPhoneIP changed from UNDEF to [redacted]
2018-12-07 12:14:27.253 [vent.ItemStateChangedEvent] - MatthewsPhoneUptime changed from 0 to 8387
2018-12-07 12:14:27.268 [vent.ItemStateChangedEvent] - MatthewsPhoneLastSeen changed from NULL to 2018-12-07T12:14:20.000+0200
2018-12-07 12:14:27.268 [vent.ItemStateChangedEvent] - MatthewsPhoneAP changed from UNDEF to [redacted]
2018-12-07 12:14:27.269 [vent.ItemStateChangedEvent] - MatthewsPhoneESSID changed from UNDEF to [redacted]
2018-12-07 12:14:27.269 [vent.ItemStateChangedEvent] - MatthewsPhoneRSSI changed from UNDEF to 29

strange. I have been monitoring the state of my Items using the console and doing items list "grep -i unifi and their state hasn’t updated since I used the newest version of the binding

do you get the Circular reference also or not?

Note: I may be wrong but I remember the following: The first time that I started it, it looked ok and I didn’t get any Circular reference logged. I stopped OH2 service, error appeared, started again… error again and since then: no updates

I will enable TRACE to see what is going on and report back

It’s perfectly ok for a bridge to have channels. Having said that, I agree it would be better to have separate Thing(s) for the site(s). As you said, there’s greater flexibility for defining multiple sites.

What’s funny is now that you mention it, going back up in the log, no I did not…

There’s something wonky going on here with the order the service components are getting registered.

I’m going to write a script to trash and redeploy the snapshot over and over to see if I can figure this out!

1 Like

I just restarted OH2 service and got immediately (first 2 entries in openhab.log) the Circular reference error (1st) from org.apache.felix.scr and the ServiceException warning (2nd) from org.openhab.binding.unifi

So far: no updates from the binding to my Items :frowning: (no worries: we are testing stuff out :wink:)

try to restart the OH2 service on your S1451 testbed system to see if they come up