Ubiquiti Unifi Binding Feature Discussion

side note (not related to the Unifi binding):
If you are running Debian (Jessie) or Ubuntu, do not apt-get upgrade your system today (20/Jun/2017) cause it will break Unifi Controller, Unifi Video NVR and mFi Controller… most possibly the new kernel (3.16.43-2+deb8u1) is the root-cause…

If you do upgrade, here is a temp fix (downgrade) for it:

Just wanted to add another thanks for the work on this binding. Of all the presence detection systems I have tried this was by far the easiest to get going, and so far (I just installed it earlier today) seems to be far more reliable than others also. No battery impact on the phone is just icing on the cake.

My only “complaint” is that it seems to take about 10 minutes for the device to register as offline. This isn’t a problem with the binding. I was watching my Unifi controller and that’s how long it took for my phone to fall off of the client list.

The folks over at HA seem to have run into the same issue. A proposed solution there is to use the “last_seen” time for each device. I don’t know the mechanics of the binding so I don’t know if this would be simple to do. Something to consider at any rate.

@PointandClick glad to hear everything is working for you!

Unfortunately this is how the UniFi controller works :frowning: On the bright side, there are a handful of interesting time related variables in the controller’s JSON API (per-client):

  • _last_seen_by_uap
  • _uptime_by_uap
  • assoc_time
  • first_seen
  • last_seen
  • latest_assoc_time
  • uptime

Using these, I could add some “enhanced” logic to the binding similar to HA’s approach. Something like a client is still considered online iff it was “seen” within the last X minutes. Will have to do some trial and error while debugging the JSON API to see exactly which variables are of interest.

Are there more people interested in having something like this?

1 Like

Yeah, that sounds useful to me. I primarily use the unifi binding to add logic to my presence detection so if it was more definitive in when it determines a device has not been seen it would be helpful.

I think that this would be useful. We could use it in a rule to update the presence as we see fit.

by the way:
I still get that jackson crap warning:

2017-06-24 21:46:57.035 [WARN ] [org.apache.felix.fileinstall        ] - Error while starting bundle: file:/usr/share/openhab2/addons/org.openhab.binding.unifi-2.1.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.unifi [176]
  Unresolved requirement: Import-Package: com.fasterxml.jackson.annotation

	at org.eclipse.osgi.container.Module.start(Module.java:434)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
	at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:392)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1253)[4:org.apache.felix.fileinstall:3.5.6]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1225)[4:org.apache.felix.fileinstall:3.5.6]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:512)[4:org.apache.felix.fileinstall:3.5.6]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:361)[4:org.apache.felix.fileinstall:3.5.6]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:312)[4:org.apache.felix.fileinstall:3.5.6]

This happens (to me) whenever I clear tmp & cache (usually after apt-get upgrade)
If I restart OH2 with tmp & cache populated… I don’t get this error (at least, I haven’t seen it till now appearing)
Running OH2 S#965 atm

The above WARN message is not unique to this binding. I’ve seen it before with other bindings in the addons folder after a clean install and/or upgrade. It seems that the bindings in the addons folder get activated before all the dependencies are available.

Once the binding is merged into the build, and can be installed using Paper UI or added to conf/services/addons.cfg, I believe the above WARN message should go away.

1 Like

@mgbowman I’m still having the jackson.core dependency issue. I tried wgetting them in the addons folder but it doesn’t help.

I guess everyone has an addon installed which also installs the jackson.core library, but I don’t have it.
It should be easily reproducible using a clean OpenHAB 2.1 install and trying to add the Unifi Binding.

just fyi: I just uped the Unifi controller from 5.4.16 to 5.4.18 and all is good
Running on OH 2.2.0 Snapshot #978 with org.openhab.binding.unifi (shouldn’t this go to 2.2.0.x snapshot versioning also? :slight_smile:)

Another data point: with Unifi 5.5.11 and OH 2.2.0 Build #977, the binding works fine too.

But yes, the binding should be rebased against the master (and then force pushed), then we will get a 2.2.0-compliant version. Not that there are many changes in the core since the 2.1.0-RELEASE…

1 Like

The 5.5 series is now the officially released version


Nice, time to upgrade then… Maybe now I can set up a proper VPN to my home :smile:

IMHO this would also be the perfect opportunity to change the Online channel from a switch item to a contact item.

I managed to fix the dependency thing using the console by going through the following steps:

bundle:install https://jenkins.otr.mx/job/openhab2-unifi-binding/lastSuccessfulBuild/artifact/addons/binding/org.openhab.binding.unifi/target/org.openhab.binding.unifi-2.1.0-SNAPSHOT.jar
bundle:install http://central.maven.org/maven2/com/fasterxml/jackson/core/jackson-core/2.8.8/jackson-core-2.8.8.jar
bundle:install http://central.maven.org/maven2/com/fasterxml/jackson/core/jackson-annotations/2.8.8/jackson-annotations-2.8.8.jar
bundle:install http://central.maven.org/maven2/com/fasterxml/jackson/core/jackson-databind/
bundle:start "UniFi Binding"

But now I added the controller but I get communication errors:
When it calls: https://myunificontroller:8443/api/s/null/stat/device
I see it logs in fine, and discovers that I have a default site, but that the path is null and then calls the above adres which gives this if I call it using my own browser:

{ "data" : [ ] , "meta" : { "msg" : "api.err.NoSiteContext" , "rc" : "error"}}

Looking at what the controller’s web interface does, I see that it calls https://myunificontroller:8443/api/s/default/stat/device which does work.

I used to have a 5.4.11 controller, but also after an update to 5.5.19 I keep getting the same message.

Anybody else had this? It looks like it mixes up the variables that make up the url.

I have to double check but I don’t think that I see this error.

By the way, on OH 2.2.0 Snapshot # 985, the jackson stuff version included/used are:

openhab> list -s |grep -i jac
181 | Active   |  80 | 2.4.5                  | Jackson-annotations                                    | com.fasterxml.jackson.core.jackson-annotations
182 | Active   |  80 | 2.4.5                  | Jackson-core                                           | com.fasterxml.jackson.core.jackson-core
183 | Active   |  80 | 2.4.5                  | jackson-databind                                       | com.fasterxml.jackson.core.jackson-databind
184 | Active   |  80 | 2.4.5                  | Jackson-dataformat-YAML                                | com.fasterxml.jackson.dataformat.jackson-dataformat-yaml

I got the versions from a post in a bug report (the thread is in the related section of this thread)

I’ve being going through the code of the binding. And it looks like the path property of a site is never set. The response to get the sites doesn’t contain a path element in the json either. So the weird thing is, how does this binding work for anybody? This this path property is used to make up the url’s to get devices.

Are you guys using the latest build (from the url in my previous post)? Or the pre-release from github?

I use the same as you (build #29 = lastSuccessfulBuild):

openhab> list -s |grep -i unifi
176 | Active   |  80 |     | UniFi Binding                                          | org.openhab.binding.unifi

I downloaded it from:


My controller is still on 5.4.18 (I will upgrade soon to 5.5.x)

I think that this reminds me of something that I saw in the past… I will put the binding in TRACE, look at the logs and report back.

Any update to this binding? *I’m on the 2.1-SNAPSHOT.jar. I was hoping to use it. I notice it’s still trying to access https://mycontroller:8443/api/s/null/stat/device

Hello @mgbowman thanks for your work! Is there progress on wrapping up and starting the PR process it would be great to include it.

Hi @martinvw, I’ve been away for the last month now I’m finally back home. I will try and find some free time this coming week. There’s 2 things I want to do before I squash and rebase:

  1. Look into the **null** issue @psyciknz is experiencing
  2. Change the online channel to a Contact (instead of a Switch as it’s read-only)

I will make these changes and post a new build (with a 2.2.0-SNAPSHOT version) to see if we can get this in OH 2.2.

Will keep everybody posted.


I’m interested in testing this. How do I proceed?