Why multiple bridges? How about this?
(uap, usg and usw are the official short names, see here).
Would be excellent for monitoring general activity on the network.
Lets say that I have multiple AP’s and I want to monitor if a device / person is in one or another place. For that purpose the AP as bridge could become handy.
If a person has more devices, it could be relevant to map the person to a user (could map to a real person) in Unifi, The user should then be a bridge. When attaching multiple clients to the user bridge, it would be possible to verify if one or more clients is online.
Off course all of this can be done in scripts if the client thing is exposing enough properties:
And maybe some more.
You could argue that it should just expose things as they are in unifi controller. But on the contrary people wnats to use the unfi binding for presence detection, so way not add some value to it?
I’m not sure your usage of Bridges, Things, Channels and Items is the best match.
What you want in the end are Items for sitemaps and rules. Items are functionally linked to Channels of Things. Things are defined with a set of properties (Channels), defined by the ThingType. Multiple things can be logically grouped under one Bridge.
In your Unifi system you have devices and clients with certain properties. However from the openHAB perspective I don’t see a strict hierarchy. Devices and Clients are loosly linked. Hence my suggestion to define all of them as Things. Properties, including relations, are then represented as channels.
Edit: After reading again, I understood your real-person-bridge idea. Higher level logic (which exceeds the techonology/binding) should happen inside rules. Bindings are merely the communication interface to one technology.
I am also in doubt my self. At least I am unsure if I am trying to implement something that doesn’t belong in a Binding.
At least if you argue that a binding is nothing more than a adapter to a foreign system and thus just a mapping of data between the foreign ssytem and openHAB, then my suggestion is no go, since it adds new functionality that the system doesn’t have directly.
What I really miss in openHAB 2 is the jsr223 scripting, since I could implement my own scripts, that will add this kind of functionality. I have had my struggles with plain scripting in openHAB, and my personal conclusion is that it is great for small things, like turning a light on when a door is opened. WHen you need to check multiple states, and also want to know which switch triggered the rule, those rules becomes more or less useless.
Alternatievly I miss some option to develop addons that can be used to add functionality to openHAB. For instance a presence detection module, or an security / alarm module, but that is antoher story 
So long story short, it might be a good idea just to keep things simple…
This will sadly still take a while… but have a look here:
I know 
Quick question on how multiple sites would be handled.
I have OH2 instances running in 2 sites – call them Site1 and Site2. The two sites are connected via a nailed-up IPSec tunnel. Site1 is 192.168.1.0/24 and Site2 is 192.168.2.0/24.
The Unifi controller is running in Site1 at 192.168.1.59. Site1 has 4 Unifi APs. Site2 has 3 Unifi APs.
A quick look at thing-tyoes.xml suggests this config will work. Note I haven’t looked at the Java code yet…
install Unifi binding in Site1, and configure bridge with
install Unifi binding in Site2, and configure bridge with
Does anyone see any reason why this won’t work?
Hey guys, sorry I haven’t chimed in - life has been busy to say the least.
First let me say, thank you to everybody that has tested my binding and reported that it’s working - I’m glad to see my efforts have helped others automate all their things! 
When I first started this binding, the most difficult thing was figuring out the best way to map the UniFi model to the new OH2 model. If you read the Bridges section of of the Eclipse SmartHome documentation, I think you’ll find that the Controller to Bridge mapping is the correct implementation moving forward. The only Bridge in this equation should be the UniFi Controller - any additional “pseudo-Bridge” logic should be outside the binding.
As far as the Thing mappings, there are definitely use cases to extend the existing Thing definition with additional properties, as well as add other UniFi devices like UAPs, USGs, and USWs. However, as I was mainly interested in detecting presence of me and my wife - not to mention it simplified the exercise of writing an OH2 binding from scratch - I focused purely on detecting “wireless clients” with simple “home” vs “away” logic.
I’d be happy to try and extend this to include other client properties and add an additional Thing definition for a UAP, but beyond that, I do not have any USGs or USWs to develop with (though I’d be more than happy to accept donations) 
I’m going to read through all the comments again and poke at the controller API and make a list of interesting properties that should be easy enough to implement given their existence in the UniFi API.
I’ll report back once I find some free time.
Disclaimer: I’m still rocking OH 1.8.1 at home (if it ain’t broke - don’t fix it … amarite?) and wrote this binding as an exercise to get familiar with OH2 concepts. I have every intention of migrating to OH2, but as we all know, real life takes priority and finding free time is like playing hide 'n seek with a ghost.
I don’t see any reason why this wouldn’t work. I never tested multiple controllers but give it a go and report back!
The controller can manage multiple sites, I believe the Bridge should represent a Site.
That’s okay of course! You should keep in mind that your binding should support other ThingTypes at a later point. If this is considered, extension by e.g. USWs would be easy.
Careful. With devices like the USG or USW, the Unifi Controller will also support wired clients. In the screenshot you can see that they are represented pretty similar. Your design should either address “clients” or support “wireless clients” and “wired clients”. Both concepts can be found in the Unifi Controller itself:
Excited to see first results! Thanks for your efforts!
Just tested with 5.4.11, I was able to add the Thing (how can I do that in a .things?) and it says online, I then entered a mac address for a wireless client and it also said online. So I disconected the wireless device and it still said online, undaunted I changed the mac address to something fake and it also said online.
@sipvoip are you talking about the Thing being “online” (little green bubble which just means the Thing is configured properly) or the bound Contact Channel showing the wireless client as online / present on the wireless network?
I just realized that the whole README is missing. @mgbowman It was probably too early to spend the effort. Make sure to add one before you create a PR. Adding one quickly will help users test the binding. Example
Agreed - as all the API calls are per-site, this is more logical.
Agreed, when I first started, I was on a one-track mind of “wireless” and it never occurred to me the binding could support USGs or USWs. For consistency, I think using “clients” would be the most logical as this is how the UniFi controller represents them.
Yeah, it was a quick 'n dirty implementation. I’ll make sure to have one prior to creating any PR.
Ouch, sorry about that, new to openHAB2 (still waiting on zwave config files). Can you provide an example on how to manually create the .things?
Can you add this use case to the client properties?
I currently use python scripts to block/unblock devices from the wireless network with scheduling. Makes devices like the iPad/iPod unable to connect to the internet.
I need to look at the API and see what’s exposed to see how this can be handled. Off the cuff, this may be best suited as an action (as it would more than likely be called from a rule / script) but needs more investigation.
I’ll get my dev environment back up to speed and start poking around later today.
Taken from my (working) setup:
Bridge unifi:controller:<BridgeInstanceName> "Unifi Controller: Home" @ "<SomeNameToDisplay>" [ host=<UnifiControllerServerIP>, username="<UnifiControllerUserName>", password="<UnifiControllerPassword>", site="default", port=8443, refreshInterval=10] {
Thing client sample-device "Unifi: Sample device" @ "Sample Device" [ mac="<MAC Adress>" ]
}
You should replace every text in <> (eg. < BridgeInstanceName> should be replaced by some text)
Martin, is the “Sample Device” another Unifi device, e.g. AP, or an endpoint such as a mobile phone?
It is an endpoint / mobile phone.
Thanks Martin,
I still can’t get presence working. I’ve got the following settings:
unifi.things:
Bridge unifi:controller:MyHome "Unifi Controller: Home" @ "MyHome" [ host="192.168.1.100", username="username", password="password", site="default", port=8443, refreshInterval=10]
{
Thing client ipad "Unifi: iPad" @ "MyHome" [ mac="ab:cd:ef:12:34:56" ]
}
unifi.items
String ipad "iPad [%s]" <present> { channel="unifi:client:MyHome:ipad:online" }
unifi.sitemap
...
Text item=ipad
...
Can anyone see what I’m doing wrong?