Ubiquiti Unifi Binding Feature Discussion

Tags: #<Tag:0x00007f51ddb80d18> #<Tag:0x00007f51ddb80ae8>

(Mark) #766

No regressions in my environment (note that I haven’t tested the blocking functionality).

(Patrik) #767

I’ve roughly tested the blocking feature and it seems to work!

(Matthew) #768

I just tested with 2 instances and it appears to work just fine.

What version of OH and what version of the UniFi binding are you running?

I’m pretty sure @mhilbush is running 2 controllers successfully. Maybe he can post his config and we can get to the bottom of this.

(Matthew) #769

Ok guys, one last build to test - I did some minor refactoring but everything should work just as before:


Most important change with this build is proper handling of non-administrator credentials.

Please update and report back - we should be good to merge afterwards.

(Patrik) #770

Just recently uppdated. No issues so far :slight_smile:

(Mark) #771

My config has only one Unifi controller instance with multiple sites and an OH instance in each site. All the OH Unifi controller things point to the one controller instance across IPSEC tunnels.

This latest version looks good from my perspective.

(Mr. Wiseman) #772

Hi Mathew,

I’m running OH 2.3.001 on a Synology. I’m running 1 step back from the latest binding that you guys just posted above to handle the new controller.

One bridge is pointing locally and the other bridge instance is pointed across the internet which has a trust for my IP (which by the way; I’m seeing NO traffic on the firewall across the internet on the 2nd bridge instance.

Could you post your thing definition of the 2 instances for me? Maybe there is a syntax error on my side that I’m not seeing.

Best, Jay

(Matthew) #773

My config is the same as yours - I have access to my office controller instance via a VPN.

Bridge unifi:controller:home "UniFi Controller Home" [ host="unifi", port=8443, username="...", password="...", refresh=10 ] {
    Thing wirelessClient matthewsPhone "Matthew's iPhone" [ cid="...", considerHome=180 ]

Bridge unifi:controller:office "UniFi Controller Office" [ host="unifi.example.com", port=8443, username="...", password="...", refresh=10 ] {
    Thing wirelessClient matthewsPhoneOffice "Matthew's iPhone" [ cid="...", considerHome=180 ]

Debug output from my home instance:

Found 1 UniFi Site(s)
Found 1 UniFi Device(s)
Found 7 UniFi Client(s)
Found 11 UniFi Insights(s)

Debug output from my office instance:

Found 1 UniFi Site(s)
Found 8 UniFi Device(s)
Found 3 UniFi Client(s)
Found 67 UniFi Insights(s)

It’s obviously communicating with both controller instances.

I’m not 100% sure, but maybe your old OH version contains a bug dealing with multiple bridges :thinking:

(Matthew) #774

Spoke too soon :laughing:

I swear this is the last one:

Build #6 : org.openhab.binding.unifi-2.5.0-SNAPSHOT.jar

Please update and report back!

PS: All of this refactoring has made it super simple to add support for more things! There’s already a site thing in the works! :wink:

(Mr. Wiseman) #775

I have 2 bridges working with the Amazon Echo binding so I’m not sure that’s it. The only difference I’m seeing is you have a VPN connection between your locations and mine is just a trusted IP from home to work via the work firewall. We’ll at least we know 2 bridges work with the binding for sure; I’ll have to turn on debug mode and see what its saying.

I’ll keep you posted.

Thanks again for investigating it!

Best, Jay

(Patrik) #776

Just a simple thing to check - are you able to reach for example https://external-unifi-controller-dns:8443/api/stat/sta


I know you’ll get an error, but anyway good to know that you reach it correct.


(Mr. Wiseman) #777

Yup, here’s the output after the SSL cert errors I have to hit ignore on in the browser window.

{ “data” : [ ] , “meta” : { “msg” : “api.err.LoginRequired” , “rc” : “error”}}

Best, Jay

(Mr. Wiseman) #778

Could it be that it’s a CERT issue?

I’m calling the controller via an IP and I get this in the browser that I hit ignore on. I do have a wildcard SSL cert I could install on the controller. I never installed a cert on a controller on my on site premise one.


Best, Jay

(Patrik) #779

Could it be that it’s a CERT issue?

Hmm, well - I have ssl cert warning as well… Doesn’t lead to any problems when used in the binding.

(Mr. Wiseman) #780


I found why the 2nd bridge entry would not work!

It was the password . . .


Looks like the binding will need to handle most likely the hash sign, is my guess.

Best, Jay

(Matthew) #781

I will try and reproduce this when I get back to see if the problem is with the binding or the GSON library. If I can fix it in the binding, I will. Thanks for the feedback!

(Elias Gabrielsson) #782

I have the issue that a added wirelessClient gets the status: UNINITIALIZED - HANDLER_CONFIGURATION_PENDING. What does it mean in this context?
The bridge is online using a user with read permissions.

The configurations are as follows:

Bridge unifi:controller:home "UniFi Controller" [ host="unifi.my.domain.com", port=8443, username="openhab", password="password", refresh=10 ] {
	Thing wirelessClient SonyPhone "Sony Xperia XZ2 Compact" [ sid="xx:xx:xx:xx:xx:xx", considerHome=180 ]

Using build: openHAB 2.5.0 Build #1522

(Matthew) #783

There’s a typo in your config… should be cid=“$mac” (you’re using sid)

Bridge unifi:controller:home "UniFi Controller" [ host="unifi.my.domain.com", port=8443, username="openhab", password="password", refresh=10 ] {
	Thing wirelessClient SonyPhone "Sony Xperia XZ2 Compact" [ cid="xx:xx:xx:xx:xx:xx", considerHome=180 ]

(Matthew) #784

Hey guys,

So thinking about how I will move forward with the binding, I realized I don’t have access to a lot of UniFi hardware that would help make implementing new things (like device) easy :frowning:

One thing that came to mind was the idea of asking you guys to submit the results of your JSON calls to me such that I could use them to help develop initial support for all UniFi devices by having access to a wide range of data.

I’ve already taken the steps to setup a local MockServer infrastructure that will allow me to easily “mock” the calls to your individual controllers to ensure the binding handles everything correctly.

If this is something you guys are willing to help me with, I can push a small modification to the binding which will update the trace level JSON logging to properly output the format MockServer expects.

Let me know how many of you are willing to do this!


(Mark) #785

Sounds like a good idea. My info would cover the following devices:

  • US24-POE-250
  • US24
  • AP-AC-LR
  • AP-LR
  • AP-AC-Mesh