Ubiquiti Unifi Binding Feature Discussion

I will also test this today and report back

Great stuff @mgbowman ! Thanx :slight_smile:

So far, so good…

I installed the binding, added the things from PaperUI and then created a new Unifi.items file.

I defined only 1 item there and I put the binding in DEBUG:

/* Unifi Items */

Switch	Angelos_S6_Pre		"Angelos Presence"	<switch>	(gUnifi)	{channel="unifi:client:Angelos_S6:online"}
2017-04-27 18:45:52.834 [INFO ] [unifi.handler.UniFiControllerHandler] - UniFi Binding v2.1.0.201704270844
2017-04-27 18:58:33.105 [DEBUG] [unifi.handler.UniFiControllerHandler] - Refreshing the UniFi Controller unifi:controller:Unifi_Ctrl
2017-04-27 18:58:33.116 [DEBUG] [nding.unifi.internal.UniFiController] - Found 1 UniFi Site(s):
2017-04-27 18:58:33.116 [DEBUG] [nding.unifi.internal.UniFiController] -   Site{name: 'default', path: 'default'}
2017-04-27 18:58:33.132 [DEBUG] [nding.unifi.internal.UniFiController] - Found 4 UniFi Device(s):
2017-04-27 18:58:33.132 [DEBUG] [nding.unifi.internal.UniFiController] -   UniFiDevice{mac: '44:d9:e7:51:XX:XX', name: 'LAN-SW1', model: 'US24P250', site: Site{name: 'default', path: 'default'}}
2017-04-27 18:58:33.133 [DEBUG] [nding.unifi.internal.UniFiController] -   UniFiDevice{mac: '44:d9:e7:80:XX:XX', name: 'WLAN-AP0', model: 'U7O', site: Site{name: 'default', path: 'default'}}
2017-04-27 18:58:33.133 [DEBUG] [nding.unifi.internal.UniFiController] -   UniFiDevice{mac: '44:d9:e7:fc:XX:XX', name: 'WLAN-AP2', model: 'U7LR', site: Site{name: 'default', path: 'default'}}
2017-04-27 18:58:33.133 [DEBUG] [nding.unifi.internal.UniFiController] -   UniFiDevice{mac: '44:d9:e7:fc:XX:XX', name: 'WLAN-AP1', model: 'U7LR', site: Site{name: 'default', path: 'default'}}
2017-04-27 18:58:33.137 [DEBUG] [nding.unifi.internal.UniFiController] - Found 22 UniFi Client(s):
2017-04-27 18:58:33.137 [DEBUG] [nding.unifi.internal.UniFiController] -   UniFiClient{mac: '44:d9:e7:94:XX:XX', hostname: 'UVC-G3-XXXX', wired: true, device: UniFiDevice{mac: '44:d9:e7:51:XX:XX', name: 'LAN-SW1', model: 'US24P250', site: Site{name: 'default', path: 'default'}}}
[...]

It seems to read all info correctly from the Unifi Controller (version 5.4.14).

I am trying to see now why I can’t get my switch item to update.

I disconnected my mobile phone from the local WLAN but I see that the Unifi controller is still reporting it online (and as a result the binding gets this wrong status from the controller). I am sure that if the controller gets updated faster, it will report back to the 10sec polling interval to the binding the correct situation.

Edit1: After almost 10 minutes from disconnecting my phone, the controller reported it offline to the binding and the switch turned to off. All is ok. Is there a way to force the Unifi Controller to update the clients’ status faster? :slight_smile:

Edit2: Status updates in the scenario where I go online from offline seem to work really fast (within seconds the OH2 switch turns to “On”)

This is one minor drawback as the controller doesn’t immediately reflect the state of a wireless client upon disconnect.

This is where some additional binding logic could be beneficial. There are some timestamps related to when a client was last seen. I’d need to look at these values closer, but the general idea would be along the lines of “assume the client is offline only after N minutes”. If N is less than the controller’s status updates, then you’d have exactly what you’re looking - a pseudo way of “forcing” the binding to mark a client as OFFLINE even though the controller is reporting it as ONLINE.

Additionally, this would have the added benefit of if the controller goes OFFLINE for a short period of time and/or there’s a communication issue with the controller, the client wouldn’t immediately go OFFLINE and it’s channel values wouldn’t be updated to UNDEF.

However (there’s always a catch), this is not something that would be easily implemented in the binding’s current form. I would have to keep a local cached copy of the controller data and do some merge and time-based scavenging on it to realize this feature.

If this is something you guys would really want to see implemented, maybe I can find some free time :wink:

1 Like

I don’t think that there is a need to implement additional logic in your binding. It works perfectly the way it is :slight_smile:
Anyway, more important (for me) is to be able to detect fast the incoming event (when I become present) to use this in my rules (this is happening really fast now).

If there is a delay in the offline event, I don’t mind.

I timed the delta between disconnecting and the ItemStateEvent:

Going Offline: 19:17:43.140
Item Updated to OFF: 19:22:33.135

That’s a delta of less then 5 mins… That’s more than fine :slight_smile:

Additional note: Since every 10 secs the binding checks the Unifi Controller and pulls a report of the connected clients, it then updates the State of the Item (ON…ON…ON). As a result, it is best to use in the rules something like:

when
	Item Angelos_S6_Pre changed from OFF to ON
then
	...

Just for reference, here are my Unifi.things, Unifi.items & Unifi.sitemap contents:

Bridge	unifi:controller:Unifi_HomeR	"Unifi Controller: HomeR" @ "Unifi" [host="172.16.13.100", username="username", password="password", site="default", port=8443, refresh=10]
{
	Thing	client	Angelos_S6	"Angelos_S6" @ "Unifi"	[mac="ec:1f:72:17:XX:XX"]
	Thing	client	Simona_I6	"Simona_I6" @ "Unifi"	[mac="a8:66:7f:e3:XX:XX"]
}
Switch	Angelos_S6_PRES	"Angelos S6 Presence"	<present>	(gUnifi)	{channel="unifi:client:Unifi_HomeR:Angelos_S6:online"}
Number	Angelos_S6_RSSI	"Angelos S6 RSSI [%s]"	<signal>	(gUnifi)	{channel="unifi:client:Unifi_HomeR:Angelos_S6:rssi"}

Switch	Simona_I6_PRES	"Simonas I6 Presence"	<present>	(gUnifi)	{channel="unifi:client:Unifi_HomeR:Simona_I6:online"}
Number	Simona_I6_RSSI	"Simonas I6 RSSI [%s]"	<signal>	(gUnifi)	{channel="unifi:client:Unifi_HomeR:Simona_I6:rssi"}
Frame {
		Group item=gUnifi label="Unifi Clients" icon="network"
	}

I am on OH 2.1 Snapshot Build #896 and all work fine !

Glad to hear everything is working.

Just an FYI, the site configuration parameter on the Bridge item was moved to the Thing item to be more flexible. You can read more about this in the UniFi Binding Readme - Bridge Configuration

1 Like

@mgbowman I just installed the latest OH2 build #904 ( I was on #885).

Running this version of the Unifi binding.

2017-04-30 17:33:48.776 [INFO ] [unifi.handler.UniFiControllerHandler] - UniFi Binding v2.1.0.201704270844

I’m seeing this exception on the port number every refresh interval.

2017-04-30 17:33:49.580 [ERROR] [nding.unifi.internal.UniFiController] - Error trying to authenticate to UniFi Controller
java.net.MalformedURLException: For input string: "8443.0"
	at java.net.URL.<init>(URL.java:627)[:1.8.0_121]
	at java.net.URL.<init>(URL.java:490)[:1.8.0_121]
	at java.net.URL.<init>(URL.java:439)[:1.8.0_121]
	at org.openhab.binding.unifi.internal.UniFiController.openConnection(UniFiController.java:103)[10:org.openhab.binding.unifi:2.1.0.201704270844]
	at org.openhab.binding.unifi.internal.UniFiController.get(UniFiController.java:129)[10:org.openhab.binding.unifi:2.1.0.201704270844]
	at org.openhab.binding.unifi.internal.UniFiController.get(UniFiController.java:155)[10:org.openhab.binding.unifi:2.1.0.201704270844]
	at org.openhab.binding.unifi.internal.UniFiController.login(UniFiController.java:192)[10:org.openhab.binding.unifi:2.1.0.201704270844]
	at org.openhab.binding.unifi.handler.UniFiControllerHandler.refresh(UniFiControllerHandler.java:130)[10:org.openhab.binding.unifi:2.1.0.201704270844]
	at org.openhab.binding.unifi.handler.UniFiControllerHandler.run(UniFiControllerHandler.java:177)[10:org.openhab.binding.unifi:2.1.0.201704270844]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_121]
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)[:1.8.0_121]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)[:1.8.0_121]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)[:1.8.0_121]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_121]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_121]
	at java.lang.Thread.run(Thread.java:745)[:1.8.0_121]
Caused by: java.lang.NumberFormatException: For input string: "8443.0"
	at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)[:1.8.0_121]
	at java.lang.Integer.parseInt(Integer.java:580)[:1.8.0_121]
	at java.lang.Integer.parseInt(Integer.java:615)[:1.8.0_121]
	at java.net.URLStreamHandler.parseURL(URLStreamHandler.java:222)[:1.8.0_121]
	at java.net.URL.<init>(URL.java:622)[:1.8.0_121]
	... 15 more

I’m not sure why this started all of a sudden. I don’t recall seeing any PRs dealing with how ESH deals with integer config items. But, obviously something is different with this latest build.

Looking in the Thing json DB, it looks like the config item is being stored with one decimal place (i.e. 8443.0)

org.eclipse.smarthome.core.thing.Thing.json:          "port": 8443.0,

Anybody else on the latest build seeing this?

Nope…
I upgraded yesterday to build #904 and my unifi binding logs are clean.

On the other hand… I use a unifi.thing flat file.
I didn’t add the things via PaperUI discovery, so I don’t have any unifi entries in my jsonDB to properly compare.
I will try this on my test-bed OH2 system and let you know.

Update: Tested the Unifi Binding v2.1.0.201704270844 on 2 snapshots (#889 & #905)

In both cases, the jsonDB is populated correctly with the following entries:

{
  "unifi:controller:1c8ca854": {
    "class": "org.eclipse.smarthome.core.thing.internal.BridgeImpl",
    "value": {
      "label": "UniFi Controller",
      "channels": [],
      "configuration": {
        "properties": {
          "host": "172.16.13.100",
          "refresh": 10,
          "password": "password",
          "port": 8443,
          "username": "username"
        }
      },
      "properties": {},
      "uid": {
        "segments": [
          "unifi",
          "controller",
          "1c8ca854"
        ]
      },
      "thingTypeUID": {
        "segments": [
          "unifi",
          "controller"
        ]
      }
    }
  }
}

So: I can’t reproduce this error :frowning:

@mhilbush I pushed an update that adds an intValue() conversion to the port number. Now if for some odd reason the port gets stored as a string, everything should work fine.


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

1 Like

Thanks, @mgbowman.

FWIW, I reinstalled the build (#904), as well as deleted and readded the controller and client things, and the problem no longer occurs. No idea why that was occurring, but it’s better now. :+1:

How did I not notice this binding before! Great work @mgbowman All working well on the latest 2.1 snapshot.

Happy to report that I just updated my Unifi Controller from v5.4.14 to v5.4.15 and the Unifi Binding from v2.1.0.201704270844 to v2.1.0.201705010628 and all work fine !

Wanted to report that after a couple weeks of runtime, I’ve not had a single issue with the controller bridge going offline due to a comm issue. And that includes the OH instance that’s on the other end of an IPSEC tunnel from the Unifi controller. That OH instance had been having an issue every few days due to sporadic loss of the tunnel.

Nice work, @mgbowman

Just upgraded the Unifi controller software from 5.4.15 to 5.4.16 and all work fine!
Great binding @mgbowman :thumbsup:

Hello @mgbowman I was wondering wether you were already planning on creating a pull request so we can include the binding in the master in between already in the marketplace

What is your idea about this?

5 Likes

Hi @martinvw

I’ve always planned to get my binding into master but wanted the development / testing to settle down before I created a PR.

My last build was 28 days ago and so far everybody in this thread who helped test has reported everything is in working order. I think it’s stable enough to pull.

However, I’m leaving for vacation and my hands are full these next few days. Once I return, I’ll do a rebase and squash to create a nice clean PR and hopefully get this into the next release.

Cheers!

7 Likes

Great, thanks for the update! And have a nice holiday!

Very nice work with the binding, working fine for me with the latest version of everything (openhab2, binding, unifi).

Have any of you worked out a simple rule to debounce presence detection when certain devices just disconnect from wifi every few minutes due to power saving?

Hi! I just update to version from 1st of May… The mac addresses seems to be case sensitive.

.... (my mobile phone)
2017-06-07 18:47:19.981 [DEBUG] [nding.unifi.internal.UniFiController] -   UniFiClient{mac: '**ec:9b:f3:5e:78:1a**', hostname: 'android-66f7051423a9c68d', wired: false, device: UniFiDevice{mac: '80:2a:a8:83:1a:94', name: 'Dachboden', model: 'U7PG2', site: Site{name: 'mySite', path: 'default'}}}

.... more clients

2017-06-07 18:47:20.024 [DEBUG] [ing.unifi.handler.UniFiClientHandler] - Could not find a matching client: mac = 8c:f5:a3:af:4b:80, site = null
2017-06-07 18:47:20.030 [DEBUG] [ing.unifi.handler.UniFiClientHandler] - Refreshing channel = unifi:client:513ad07b:site
... some other refreshings
2017-06-07 18:47:20.054 [DEBUG] [ing.unifi.handler.UniFiClientHandler] - Could not find a matching client: mac = **EC:9B:F3:5E:78:1A**, site = null

Volker