Change String to Switch, then it at least is identical to mine.
unifi.items
Switch ipad "iPad [%s]" <present> { channel="unifi:client:MyHome:ipad:online" }
If that doesn’t work, check the log to se if some communication takse place 
Thanks Martin,
That makes more sense alright, but there doesn’t seem to be any updates occurring. All the clients appear offline. If I go into habmin and do a manual refresh, I see this message about the binding being read-only:
16:53:00.832 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'ipad' received command REFRESH
16:53:00.832 [INFO ] [ing.unifi.handler.UniFiClientHandler] - Ignoring command = REFRESH for channel = unifi:client:MyHome:ipad:online - the UniFi binding is read-only!
Am I missing something to trigger status changes?
I get the same entries in my log,so I guess you shouldn’t be to worried about that one.
If I check my events.log I have a line like this:
2017-03-28 22:22:18.793 [ItemStateChangedEvent ] - unifi_MartinMobil_Online changed from ON to OFF
That should occur whenever a state change happends (eg. connect / disconnect tyo Wifi.)
As a start you should check PaperUI. Verify that your configured Unifi bridge and all things is configured correct, and appeasr to be Online. Notice that you can’t change config from UI, when it is entered in a things files. The Bridge and the Thing MUST have state ONLINE.
If I go to the Unifi controller and explicit forces a recoonect for a client, I get these two lines in my events.log:
2017-03-28 22:29:38.753 [ItemStateChangedEvent ] - unifi_MartinMobil_Online changed from ON to OFF
2017-03-28 22:29:58.534 [ItemStateChangedEvent ] - unifi_MartinMobil_Online changed from OFF to ON
You can always remove the things file and configure it manually if you are in doubt what is wrong.
Thanks again Martin,
I think there’s something more fundamental wrong - there aren’t any notifications from the binding in events.log at all.
I suggest that you open PaperUI and checks that the corresponding things is ONLINE. Both the thing itself and the Unifi Bridge should be ONLINE. My best suggestion is that it isn’t the situation.
1 Like
Okay, I’m officially stumped. The bridge and things all appear as online in PaperUI. I can’t get any status updates to show in events.log. If I uninstall the bundle from /usr/share/openhab2/addons/org.openhab.binding.unifi-2.1.0-SNAPSHOT.jar, all the things go to “Uninitialized”, if I copy it back, they all go to “Initializing” and then “Online”, even the ones that aren’t connected to the network. The clients appear to always be online, even when they actually aren’t.
1 Like
@mgbowman As far as specifying the site in the controller (bridge) config, it appears you are looking for the site ID (the thing in the URL) versus the site name (the friendly name you assign to the site).
For example, referencing the URL below, you would put 2dqumqzy in the controller (bridge) config, rather than the friendly name (e.g. MD House) that shows on the Unifi controller UI.
https://myhostname:8443/manage/site/2dqumqzy/devices/1/50
This being the case, it would be helpful to clarify this in the definition of the config parameter in the bridge thing xml.
Also would like to config that my multi-site configuration works.
As a reminder,
- in Site A I have an openHAB instance along with the Unifi controller and several Unifi APs
- in Site B I have an openHAB instance along with several Unifi APs managed by the controller in Site A
Site B’s openHAB instance has a Unifi Bridge thing that points to the Unifi controller in Site A, and some Unifi Wireless Client things used for presence detection.
Working well so far!
Edit: I’ll also add that I’ve been looking for an easy and reliable presence detection method for a while. From what I can see so far, this method looks really good!
That’s not neccessary
The Status in PaperUI has absolutely NOTHING to do with the actual status of the device you are monitoring. Everything you monitor is mapped to a channel in the bridge or thing. The status I have asked you to look at is simple a status telling if the bridge and/or thing is configured correct. If you change your username or password in the bridge, the bridge will go OFFLINE and every thing you are monitoring for that bridge will also go OFFLINE as a consequence of the Bridge going OFFLINE.
So everything is perfectl and working just fine as you describe it. At least the bridge is configured correct.
Next step would be to start PaperUI or even better the Habmin UI, and find the overview page for each thing there you can see the actual state of the channel.
SInce the events.log doesn’t contain any entries from the unifi controller I suspect that something isn’t configured correct, WHen you watch the channel state. Try go to the unifi controller and force a reconnect a client. That should give you two lines in the event log. Else something isn’t correctly connected.
Next steps (if no entries) would be:
- Start openHAB from commandline and in the karaf console list installed bindings. make sure unifi binding is only installed once. And that it is active. If not you have found the problem.
- Try to rename the things file,. Then go to PaperUI and configure the bridge, after it is online configure one thing. Then you should map the thing to an item.
Thanks for your patience Martin 
I checked the karaf console, and there’s only one instance of the Unifi binding listed, and it’s active:
openhab> bundle:list | grep UniFi
69 | Active | 80 | 2.1.0.201701251046 | UniFi Binding
openhab>
I renamed the things files, created a new Unifi controller, and then created a new Unifi client. When I look at that client in Habmin, it says OFF. I’ve reconnected the client fron the controller but there’s no notification in the logs, and the status never goes on. FYI, I’m using a Cloud Key Controller, and not the controller software installed on a PC - would that be the cause?
@mgbowman I just wanted to say thanks for this binding. It’s working really well for me.
You ought to submit the PR so that this gets into the queue for inclusion in OH2. Given the number of new bindings awaiting review, it takes quite a while (months) for the review to occur.
Thanks for catching this! I only ever tested with 1 site configured. I did a little API digging and it was quite easy to add friendly site name support. So using your example, you should be able to use either 2dqumqzy or MD House (it’s case insensitive) in the bridge configuration and it should work just fine. Hopefully this will avoid others running into the same issues in the future.
I’ve managed to work some more on the binding and made the configuration process more robust and added the following channels:
- ap (String) : Access point the wireless client is currently connected to
- essid (String) : Wireless network name the wireless client is currently connected to
I was trying to do something with the signal, noise and rssi values but I’m not exactly sure how they all relate. It’s easy enough to include them, but I’m not sure if they will be useful. For example (testing with my phone), from the API I get the following values:
- signal = -70
- noise = -99
- rssi = 29
And in the controller UI (under Statistics) it shows Signal: 54% (-68dBm). I have no idea how this percentage is calculated, but I’d be happy to include these numbers if someone finds them interesting.
I’m almost ready to push a “release candidate” version for another round of testing before creating a PR to get this into master (with a proper README of course). If there’s any other information from the controller UI that you guys would like to see, just let me know and I’ll look into it.
Cheers!
1 Like
Awesome! Thanks for that.
@mhilbush Hacking away a little more this morning I actually figured out a way where the controller’s site configuration parameter is completely irrelevant since it can be discovered dynamically. This works off the assumption that MAC addresses are unique and will only ever be associated with one site which I believe is a fair assumption.
Naturally, this lead to an additional channel on each device:
- site (String) : Name of the Site where the wireless client is currently connected
Given my comments above, the Bridge would now be the Controller and regardless of the number of sites, you only need 1 Bridge.
I’m going to do some more robustness testing (controller going offline, username/password changing, etc…) and try and package up another testing release this weekend. I will post back once I’ve got another bundle online.
Cheers!
2 Likes
Can you be a little more clear about when you mean by “ever associated with one site”? In my scenario, I have two locations (homes), and the MAC addresses can be in either site.
Edit: I also have one OH instance in each location (home). Each OH instance has the Unifi binding installed. Each OH instance has a Unifi bridge thing that points to the Unifi controller, which is running in just one of the locations. Not sure if your approach will break this?
Not to disclose too much about my network config… Pardon my poor ascii art. 
Location 1 <<---- IPSec Tunnel ---->> Location 2
---------- ----------
Unifi Controller for sites NJ and MD
Unifi site NJ Unifi site MD
Multiple UAP-ACs in site NJ Multiple UAP-ACs in site MD
OH instance1 OH Instance2
Unifi Bridge points to location 1 Controller & site NJ Unifi Bridge points to location 1 Controller & site MD
Unifi Thing for MAC1 Unifi Thing for MAC1
Unifi Thing for MAC2 Unifi Thing for MAC2
Unifi Thing for MACn Unifi Thing for MACn```
Hopefully, this will still work.
When I say “site”, I’m referring to the UniFi Site (like default or “MD House”) that you configure in the UniFi controller, not the physical location site (like Site A vs. Site B in your ASCII art).
Let’s say you have a Home and Office “site” defined in the UniFi controller. Take your phone as an example, your phone’s wifi MAC address could never be connected to a UAP under the “Home” site and a UAP under the “Office” site at the same time.
Configuring the MAC address on the client Thing is still required, but as part of this simplification, you can dynamically tell which UniFi site your phone is connected to without having to define 2 Bridges that point to the same Controller instance but only differ by site (“Home” vs. “Office”).
Now there’s a client site channel that would dynamically change between Home and Office depending on which UAP you were connected to.
I hope this makes sense.
Getting there, but not quite there yet…
I fixed my ascii art above to be more clear on terminology.
So in my example,
- I need the Unifi binding installed in OH instance 1 and OH instance 2,
- the binding in OH instance 1 needs to have a bridge that points to the Controller in location 1,
- the binding in OH instance 2 needs to have a bridge that points to the Controller in location 1,
- OH instances 1 and 2 will have client things defined with the same MAC addresses (as in my drawing above)
Question: When MAC1 is physically in location 1, will the OH instance in location 2 report ON or OFF for MAC1? I was counting on it reporting OFF.
Do you have two sites defined in the controller?
More specifically (from you ASCII art), do the Multiple UAP-ACs in Location 1 belong to a different site in the controller than the Multiple UAP-ACs in Location 2?
Theoretically in your UniFi controller, you should have 2 sites: one for Location 1 and one for Location 2
The Controller in location 1 defines sites MD and NJ. The APs (and switches) in location 1 belong to site NJ. The APs (and switches) in location 2 belong to site MD.