Ubiquiti Unifi Binding Feature Discussion

I also ran into the issue when I turned on my US-24-250 switch (it was off for a while due to a renovation project). Installing this version fixed it. If you need examples of JSON, I can share some with you (securely).

New binding installed in both locations. Your new filtering mechanism (entering the site in the wireless client config) is working nicely. Thanks!!!

Trying out version 2.1.0.201704101808 - after I link the essid channel to an item, I start getting the following errors (I persist everything to an InfluxDB). Once that happens I have difficulty adding new (PaperUI complains about 500 errors from the web server) until I delete the item and the link.

Apr 10 19:38:00 svr05.ocjtech.us openhab[20935]: [ERROR] [org.influxdb.impl.BatchProcessor] - Batch could not be sent. Data will be lost
Apr 10 19:38:00 svr05.ocjtech.us openhab[20935]: java.lang.RuntimeException: {"error":"partial write:\nunable to parse 'JeffsPixelXL_WirelessNetwork  1491871080002000000': invalid field format"}
Apr 10 19:38:00 svr05.ocjtech.us openhab[20935]: at org.influxdb.impl.InfluxDBErrorHandler.handleError(InfluxDBErrorHandler.java:19)[216:org.openhab.persistence.influxdb:1.10.0.201702140757]
Apr 10 19:38:00 svr05.ocjtech.us openhab[20935]: at retrofit.RestAdapter$RestHandler.invoke(RestAdapter.java:242)[216:org.openhab.persistence.influxdb:1.10.0.201702140757]
Apr 10 19:38:00 svr05.ocjtech.us openhab[20935]: at org.influxdb.impl.$Proxy124.writePoints(Unknown Source)[216:org.openhab.persistence.influxdb:1.10.0.201702140757]
Apr 10 19:38:00 svr05.ocjtech.us openhab[20935]: at org.influxdb.impl.InfluxDBImpl.write(InfluxDBImpl.java:151)[216:org.openhab.persistence.influxdb:1.10.0.201702140757]
Apr 10 19:38:00 svr05.ocjtech.us openhab[20935]: at org.influxdb.impl.BatchProcessor.write(BatchProcessor.java:171)[216:org.openhab.persistence.influxdb:1.10.0.201702140757]
Apr 10 19:38:00 svr05.ocjtech.us openhab[20935]: at org.influxdb.impl.BatchProcessor$1.run(BatchProcessor.java:144)[216:org.openhab.persistence.influxdb:1.10.0.201702140757]
Apr 10 19:38:00 svr05.ocjtech.us openhab[20935]: at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_121]
Apr 10 19:38:00 svr05.ocjtech.us openhab[20935]: at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)[:1.8.0_121]
Apr 10 19:38:00 svr05.ocjtech.us openhab[20935]: at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)[:1.8.0_121]
Apr 10 19:38:00 svr05.ocjtech.us openhab[20935]: at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)[:1.8.0_121]
Apr 10 19:38:00 svr05.ocjtech.us openhab[20935]: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_121]
Apr 10 19:38:00 svr05.ocjtech.us openhab[20935]: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_121]
Apr 10 19:38:00 svr05.ocjtech.us openhab[20935]: at java.lang.Thread.run(Thread.java:745)[:1.8.0_121]

@jcollie it looks like something is coming back NULL. I sent you a message on how you can securely send me your unifi.log for further debugging.

Tried the new version, works like a charm, while having a Unifi switch in the network.

Glad to hear it. Iā€™m waiting on my USW-8 which should give me a better testing environment and help add support for wired clients.

On that note, has anybody thought of some use cases for tracking / integrating wired clients into OH?

Checking if devices are online is useful, although you could do that with the network binding.
But looking at the /STA JSON API, there is also a ā€œlast seenā€ and ā€œuptimeā€ properties, which give history, something the network binding canā€™t do. And you can see on which port of the switch it is connected.

I wonder if there are other APIā€™s because the controller knows a lot more about the APā€™s, clients and switches (I donā€™t have a Unifi router/gateway).

You can always watch the XHR calls in the browser while accessing the UI - itā€™s what I do. If you see anything interesting, Iā€™m always open to suggestions.

As far as wired support goes, I will work on it when I can, but I really canā€™t think of a use case from an ā€œautomationā€ perspective. Sure thereā€™s a case for persistence / monitoring, but there are far better tools out there to solve that problem.

The biggest reason I wanted to develop this binding was for monitoring my phone via wireless associations. This binding gives me a pretty reliable way to tell if my wife or I are at home ā€¦ well at least our phones

One use of the properties you mentioned would be shortening / overriding the time it takes for the controller to report a client as offline. It can be anywhere from 5-10 minutes before the controller removes a client and they appear as OFFLINE. Maybe an additional ā€œtimeoutā€ parameter on the client configuration could be use where if not seen in last X minutes, report as OFFLINE.

Iā€™m having an issue with the periodic scanning stopping. If I reboot the box, or restart OH, I can see from the unifi.log that there is scanning taking place every so may seconds. The problem is that after a few hours, the scanning stops, although if I go into Habmin and manually refresh one of the things, it populates the unifi.log file, but the periodic scans donā€™t start again. I restarted the box yesterday around 11:30am and it worked fine until about 6:30pm when it stopped scanning. I did a manual refresh on a few things at 9:30pm last night and as of 10:30am this morning those manual scans are still the last entries in the unifi.log.

Any ideas?

@roryd no idea - my instance has been chugging along just fine.

I added some more logging and exception handling so please update and try again. Once it stops refreshing, please send me the log via PM (just as you did before).


UniFi Binding v2.1.0.201704121133 : org.openhab.binding.unifi-2.1.0-SNAPSHOT.jar

@mgbowman If thereā€™s an unhandled exception during a scheduled job, the job will be canceled and will not run again until the binding (or OH) is restarted. This all happens silently, so thereā€™s no log file entry that shows what happened. Wrapping the scheduled job run method with a RuntimeException try/catch block is what Iā€™ve seen done in other bindings (including my own bindings).

Thereā€™s some discussion here, a little over half way down the page.

Edit: Nevermind, I see you already wrapped it with try/catch. :wink:

Learned that the hard way :smile:

Yeah, seems like the most sane solution to help with debugging.


In the meantime, Iā€™ve narrowed down @rorydā€™s issue but itā€™s the strangest thing. One of his phones somehow was being reported as a wired client from his controller. Looks like Iā€™m going to have to add an extra check to make sure Iā€™m dealing with wireless clients only (until I can add proper support for wired clients).

Hi Matthew,

I had actually spotted that in the Unifi topology map but never thought too much about it.

I looked at the sw_mac in the two sections you PMā€™d me, and in the first, the iPhone was connected to an AP which was wired directly into a switch in the attic. In the second section, the iPhone was connected to an AP in the kitchen connected to a PoE switch in the kitchen connected to a Devolo Powerline Ethernet adapter in the kitchen, which then connected to another Devolo unit in the attic which connects to the switch in the attic. I wonder if the powerline adapters are confusing the ā€œis_wiredā€ calculation? I updated the Cloud Key and the APs to the latest firmware (3.7.51.6230) last night, so Iā€™ll keep an eye on it and see if that makes any difference.

I want to run a cable directly from the kitchen to the attic, but I need planning permission :wink:

Rory.

Yeah, me too. It was driving me nuts trying to figure out why my scheduled job just silently stopped running. :cry:

BTW, yesterday both my unifi binding instances stopped running their scheduled job. Since they both point to the same Unifi controller, Iā€™m assuming it was the same root cause. I have since installed your latest jar, which has the try/catch block. Iā€™ll post something if I see it happen again.

The only thing out of the ordinary yesterday is that I powered off the Unifi switch, which also took down one AC-LR that was getting PoE from the switch. (Once all the cables are run to the rack, all my APs will get PoE from the switch. :smiley: )

The switch is still off, and I wonā€™t be in that location until next week. When Iā€™m there Iā€™ll power on/off the switch to see if it causes the Unifi controller to report something you might not expect.

Edit: I did see this in one of the logs (for the site thatā€™s remote to the Unifi controller). I seem to recall that I had come back into the house from being away for about an hour.

2017-04-11 09:23:22.593 [WARN ] [ing.unifi.handler.UniFiClientHandler] - Unable to update channel 'site' : device == null
2017-04-11 09:23:22.596 [WARN ] [ing.unifi.handler.UniFiClientHandler] - Unable to update channel 'ap' : device == null

On this version of the binding.

2017-04-11 06:28:44.299 [INFO ] [unifi.handler.UniFiControllerHandler] - UniFi Binding v2.1.0.201704101808

I still need to test and handle the following cases:

  • Controller is unavailable (either at startup or during a refresh)
  • Username or password changes (highly unlikely but could happen)
  • UAP goes offline / missing (not quite sure what happens here)

In the meantime, Iā€™ve reworked the binding data model to better distinguish between wired vs. wireless clients. Thereā€™s still no support for wired clients, however it should solve @rorydā€™s issue.

The only downside is, if the controller misrepresents a wireless client as wired, the easiest thing to do is to treat the wireless client as non-existent. This means itā€™ll appear OFF and all the other channels will be UnDef.

@roryd please update to the latest version and report back.


UniFi Binding v2.1.0.201704131201 : org.openhab.binding.unifi-2.1.0-SNAPSHOT.jar

Thanks Matthew, Iā€™ll update shortly.

I discovered that I can force this to happen. If I click ā€œReconnectā€ on a wireless client in the UniFi console, and that client is connected to the access point in the kitchen (the one using the Devolo Ethernet over Powerline units), it reappears as a wired client connected to the port in the switch where the Devolo unit is connected. After a minute or so, and/or a refresh of the topology, the correct wireless connection shows up.

Iā€™ll try it again after I update the .jar.

Hi, any change this could change the POE state of a port on a UniFi POE switch? I have a few devices (like Raspberry Pi with touch screens etc) that Iā€™d like to power off for example when I leave and come back on again when I come home.

Thanks.

@jmccoy555 Currently the binding does not support this. However, I just took a quick look at the API and theoretically it is possible.

Unfortunately I only have a US-8 with PoE passthrough so Iā€™m not really going to be able to implement support beyond this model. Of course Iā€™m always open to donations for a proper UniFi switch to fully implement PoE support :smile:

What model UniFi switch are you currently using?

So I suspect the answer is no, but I was hoping to use this with my Unifi EdgeMax to determine presence of phones (I use a Eero wireless mesh network, not the Unifi APā€™s)?

Wow, interesting binding. I could use the same for presence detection. However, my Ubiquiti controller is on a separate network where I do not have access to from my openHAB :slight_smile:. So I first have to think about how to incorporate this into my network topology.

If you really want presence detection on your openHAB network (I assume at home), I highly recommend running an instance of the controller there. This way - regardless of Internet connectivity - your presence detection will work as itā€™s all local.