Ubiquiti Unifi Binding Feature Discussion

ubiquiti
unifi
Tags: #<Tag:0x00007f0152eb81b0> #<Tag:0x00007f0152eb3e08>

(Angelos) #546

This is a WLAN connected Samsung TV:

    {
      "_id": "5aee8e91e4b0ba053476594e",
      "duration": 5827653,
      "first_seen": 1525583505,
      "is_guest": false,
      "is_wired": false,
      "last_seen": 1541892597,
      "mac": "50:85:69:8e:83:70",
      "name": "",
      "noted": false,
      "oui": "SamsungE",
      "rx_bytes": 24487358609,
      "rx_packets": 135462296,
      "site_id": "5aee8764e4b0ba05347658bd",
      "tx_bytes": 102751470500,
      "tx_packets": 176587811,
      "usergroup_id": ""
    },

it does not broadcast a hostname, so in Unifi Controller it appears as:

image


(Angelos) #547

If I set an Alias in the properties of the client, I get a name reported in the json:

    {
      "_id": "5aee8e91e4b0ba053476594e",
      "duration": 5827653,
      "first_seen": 1525583505,
      "is_guest": false,
      "is_wired": false,
      "last_seen": 1541892597,
      "mac": "50:85:69:8e:83:70",
      "name": "Samsung TV",
      "noted": true,
      "oui": "SamsungE",
      "rx_bytes": 24487358609,
      "rx_packets": 135462296,
      "site_id": "5aee8764e4b0ba05347658bd",
      "tx_bytes": 102751470500,
      "tx_packets": 176587811,
      "usergroup_id": ""
    },

the hostname is not reported (even with an alias)


(Matthew) #548

Yep we have another edge case :stuck_out_tongue_winking_eye:

So in these cases I think just using the MAC address in the name field would be an acceptable solution to me as the controller has named the client by MAC.

For me, the cleanest solution is to just have an ID parameter that accepts MAC, hostnames or aliases. This covers all edge cases and keeps the config straight forward: you have one required parameter that accepts 1 of 3 possible values.


(Angelos) #549

unfortunately, in this case where the hostname is “not existing”, the Unifi Controller doesn’t populate the "name" json field with the MAC Address :frowning: (it leaves it blank). It does show the MAC as the “Name” on the web interface but does not report it either as a hostname or a name (in the json).

You would need to manually set an Alias (using the MAC or any other name) to get the "name" field to get populated.

:+1:


(Matthew) #550

If we do it as just one parameter, it won’t matter how the controller reports it. I index it by all 3 parameters returned by the controller (assuming non-null): mac, hostname and name.

So regardless of which value you define on the client’s ID, the binding should find it.


(Matthew) #551

So just to follow up before I implement these changes, my thought is to combine both the mac and name into a required id parameter.

This id will accept hostnames, aliases and MAC addresses.

While I agree with the dedicated meaning of a parameter, by this logic, I should really have 3 parameters: mac, hostname and alias which I’m afraid will just confuse users.

An id parameter’s meaning is the identifier of the client. For me, just because you can use one of 3 values doesn’t change the meaning of the parameter - it’s still the client’s unique identifier.

If the consensus is to have separate parameters, then that’s what I’ll do.


(Angelos) #552

how about cuid (or uid or cid) :slight_smile:

(cause Unifi reports a parameter called _id)

I think that a unique ID (as a single reference parameter) composed of a mix of the 3 (mac, hostname + alias) is going to work fine and will cover most use cases!


(Jared) #553

Hi guys I just wanted to say thanks for making this and plans to improve. I just set this whole binding up in 30 minutes last night after having sat on it for months (while learning my way around OH). Binding works well, I’ll check my version and update if needed.

Another cool use for my OH server, now to run some Ethernet to locations to disable Alexa by POE when needed. When that feature makes an appearance.

Thanks
Jared


(Scott Karns) #554

The Unifi binding will not start for me after upgrading to openHAB 2.4.0~20181115123158-1 (Build #1425). Up until now I had been using successfully the April 22 build of the Unifi binding with the OH 2.4.0-SNAPSHOTs. I also stopped OH, cleared the cache and copied the latest jenkins build to /usr/share/openhab2/addons/, but startup still fails with same error:

2018-11-15 10:28:53.362 [ERROR] [core.karaf.internal.FeatureInstaller] - Failed installing 'openhab-binding-unifi': Error restarting bundles:
        Exception in org.eclipse.smarthome.io.rest.sse.internal.SseActivator.start() of bundle org.eclipse.smarthome.io.rest.sse.

Any ideas for further troubleshooting or, better yet, a fix?

[Update]
I discovered and corrected a configuration problem that I had introduced. Now my system is operating correctly with the latest build from jenkins.

It’s odd though, in the karaf console there is no sign of either of the two addons I have manually installed by placing their .jar files into /usr/share/openhab2/addons/. I tried:

openhab> feature:list | grep UniFi                                                                                                                                                                                                                                                                                                                                                        
openhab>

No sign of the UniFi binding, but after more than five minutes, I am finally seeing this:

openhab> bundle:list | grep -i unifi
283 │ Active   │  80 │ 2.3.0.201811100627     │ UniFi Binding

Now all of my UniFi-related things are ONLINE.


(Angelos) #555

versus

it only shows up in bundles
a feature includes (a set of) bundles

I think that when the binding will be merged in the distribution, you will see also a feature listed :slight_smile:


(Håvard Berland) #556

The binding on my installation is still not working under 2.4.0, it errors with the message

22:29:29.609 [ERROR] [i.handler.UniFiControllerThingHandler] - Unknown error while configuring the UniFi Controller
org.openhab.binding.unifi.internal.api.UniFiException: javax.net.ssl.SSLException: Received fatal alert: handshake_failure
	at org.openhab.binding.unifi.internal.api.UniFiControllerRequest.getContentResponse(UniFiControllerRequest.java:159) ~[190:org.openhab.binding.unifi:2.3.0.201811100627]
	at org.openhab.binding.unifi.internal.api.UniFiControllerRequest.getContent(UniFiControllerRequest.java:119) ~[190:org.openhab.binding.unifi:2.3.0.201811100627]
	at org.openhab.binding.unifi.internal.api.UniFiControllerRequest.execute(UniFiControllerRequest.java:104) ~[190:org.openhab.binding.unifi:2.3.0.201811100627]
	at org.openhab.binding.unifi.internal.api.UniFiController.executeRequest(UniFiController.java:129) ~[190:org.openhab.binding.unifi:2.3.0.201811100627]
	at org.openhab.binding.unifi.internal.api.UniFiController.login(UniFiController.java:86) ~[190:org.openhab.binding.unifi:2.3.0.201811100627]
	at org.openhab.binding.unifi.internal.api.UniFiController.start(UniFiController.java:64) ~[190:org.openhab.binding.unifi:2.3.0.201811100627]
	at org.openhab.binding.unifi.handler.UniFiControllerThingHandler.initialize(UniFiControllerThingHandler.java:99) [190:org.openhab.binding.unifi:2.3.0.201811100627]
	at sun.reflect.GeneratedMethodAccessor62.invoke(Unknown Source) ~[?:?]

I have upgraded the Unifi software to the latest version. OpenHAB 2.4 build1421 and UniFi version 2.3.0.201811100627

Another discussion on the Jira software with the same error message talks about mismatch between supported ciphers and ciphers needed. In my case, I would be happy to have security warnings, since there is no signed SSL certificate on UniFi controller software side.

This worked before. Not sure how to debug further.


(Matthew) #557

What version of the controller are you running?


(Håvard Berland) #558

I am on 5.9.29.


(Matthew) #559

I will try to replicate this issue and debug. When you access the controller through the browser, are you not accessing it via something similar to https://unifi:8443


(Håvard Berland) #560

I am using https://myserver:8443 yes, and that works fine in the browser.
(except for the usual complaints from Chrome on the untrusted certificate)


(Mark) #561

I’m running 5.9.29 without issue with openHAB build 1423 and binding 2.3.0.201804221805.

Is the Controller on the same box as openHAB? If on different boxes, how do the Java versions compare between the two systems?


(Håvard Berland) #562

Same computer (Ubuntu 16.04 LTS) is running both Unifi controller and OpenHAB:

$ java -version
java version "1.8.0_191"
Java(TM) SE Runtime Environment (build 1.8.0_191-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode)

(Sid Amos) #563

I was wondering if this can be used to disable alarm when I get home (near the house).

So I installed it and tried with 11 seconds as “Consider Home Interval” (because refresh on the controller is 10 seconds).

But with my Android phone, the Online property then always changed between ON and OFF.

What are reasonably/working values for “Consider Home Interval”? If this is too big then it won’t work to disable alarm when coming home.

Or can I get Unifi to update the Last Seen property more often?

Otherwise the binding works really well. Thanks for developing!


(Angelos) #564

Wait… To disable your Alarm when you get home, you don’t need the considerHome parameter.

You can write a rule that triggers based on the Item bound to the online channel changed from OFF to ON

The considerHome parameter is used for the opposite effect: To mark you as Away (changed from ON to OFF)

It works like this:
OFF = lastSeen + considerHome < now

in your case: OFF = 10 + 11 = 21 seconds… that’s too low. If your mobile loses WiFi signal, OH2 will turn OFF your presence within 21 seconds (or less… depending when lastSeen happened). It could happen as fast as 11 seconds!

default is: 10 + 180 = 190 secs


(Sid Amos) #565

Ah, thanks, I understood that wrong. So, I will check how fast it recognizes that I am Online.

Has someone configured the controller refresh lower than 10s? Any disadvantages?