Ubiquiti Unifi Binding Feature Discussion

Hmm, it was not the intended design but if it works that would be great! I’m 90% in fixing the NPE, but have an empty laptop battery :blush:

I’m going to do some more local testing and push a build where both services are provided by the same component (UniFiThingHandlerFactory) - I believe this is a more acceptable workaround vs using an internal HttpClient instance.

PR for NPE: https://github.com/eclipse/smarthome/pull/6647

oops…

I never saved the changes for the CUID in my *.items file :stuck_out_tongue: I had vim open but never saved it :frowning:

now it’s ok (modified unifi:client:... to unifi:wirelessClient:...)

from:
Switch          Angelos_S8_PRES "Angelos S8 Presence [MAP(Unifi.map):%s]"       <switch>                (gUnifi)        {channel="unifi:client:Unifi_HomeR:Angelos_S8:online"}

to:
Switch          Angelos_S8_PRES "Angelos S8 Presence [MAP(Unifi.map):%s]"       <switch>                (gUnifi)        {channel="unifi:wirelessClient:Unifi_HomeR:Angelos_S8:online"}

@dim :man_facepalming:

I just pushed the latest with both services being implemented by the same component. Please everybody install the build #86 and report back!

openhab> bundle:list | grep -i unifi
190 │ Active   │  80 │ 2.4.0.201812080844     │ UniFi Binding
1 Like

:+1: (want me to post any additional logs TRACE/DEBUG?)

all clear. working fine (Bridge & Things are Online, Items linked to Channels are getting state updates) here with:
OH 2.4.0.S1454
Unifi Controller: 5.6.40
binding.unifi: 2.4.0.201812080844

It’s hard to test on S1454 because I get lots of errors from binding.zwave and binding.samsungtv which have other (unrelated to binding.unifi issues) :slight_smile: I would downgrade to an earlier snapshot build but I stay to debug those 2 also :stuck_out_tongue:

I think we’re good for now!

If everybody else can give build #86 a test, that’d be great!

I think we’re closer to getting this merged now!

1 Like

With build #87, I am still getting communication errors:

Status: OFFLINE - CONFIGURATION_ERROR java.lang.RuntimeException: No Common Name found
bundle:list | grep -i unifi
193 │ Active    │  80 │ 2.4.0.201812080905     │ UniFi Binding

My configuration is very trivial, via text files, some data anonymized:

Bridge unifi:controller:home "UniFi Controller: Home" @ "Basement"
[
    host="192.168.123.456",
    port=4711,
    username="wont-tell-you",
    password="wont-tell-you-either",
    refresh=60
]
{
    Thing wirelessClient hotticlock "UniFi Client: Hotticlock" @ "Living Room"
    [
        cid="5c:cf:7f:c8:92:86",
        considerHome=180
    ]
}

My controller is a unifi cloud key, which presents me with its self-signed certificate…

If it is of any use, I can send you the fingerprint

I think this is the same issue as @roryd - there’s no Common Name (CN) defined in the generated self-signed certificate. Can you inspect it to double check?

Any chance you’d be willing to send me the cert via a PM?

Yep, looks like my certificate is similiar to the one @roryd has shown us. BTW, you have PM :slight_smile:

Is there any way we can force the Cloud Key to regenerate its key, possibly to a nicer one? I really don’t want to go the letsencrypt way and create my own certificate for that thingy…

Unfortunately I don’t have access to a cloud key so I can’t help you here :frowning:

@martinvw I think I’m going to have to revert back to using an internal HttpClient instance due to these CN issues :neutral_face:

1 Like

I was just able to view the certificate, its imho a pretty crappy certificate, thanks Ubiquiti! There is really nothing identifying there :frowning:

Together with @mgbowman we came up with some other ideas but that will be after release and merge :slight_smile:

FYI: https://github.com/eclipse/smarthome/pull/6651/files

1 Like

Ok guys, build #89 is what you all should be using.

openhab> bundle:list | grep -i unifi
190 │ Active   │  80 │ 2.4.0.201812081314     │ UniFi Binding

It’s what 2.4 would be based off.

Please everybody install it and report back!

1 Like

Operating system: Linux version 3.16.0-7-amd64 (Debian Jessie)
Java: Oracle 64-Bit Server VM version 25.191-b12
openHAB2: 2.4.0 Snapshot Build #1455
Unifi Ctrl: v5.6.40
binding.unifi: 2.4.0.201812081314

greenl

openHAB2 in docker, Build #1455
Unifi Controller: 5.9.29, on a Cloud Key
binding: 2.4.0.201812081314

All fine and dandy for me, GO FOR MERGE :smiling_face_with_three_hearts:

Guys, we should start a donation drive to get Matthew a cloud key, and maybe some more unifi hardware he might wish for christmas.

It’s the least we can do for all the work he has put in into the binding…

:santa: :santa: :santa:

3 Likes

Everything up and running
Openhab Docker stable (openHAB 2.3.0 Release Build)

openhab> bundle:list | grep -i unifi
247 │ Active   │  80 │ 2.4.0.201812081314     │ UniFi Binding
openhab>

Been running all morning in 2 sites without issue.

Controller 5.9.29
Snapshot build 1451

258 │ Active   │  80 │ 2.4.0.201812081314     │ org.openhab.binding.unifi

We did it! :tada::tada::tada:

Thanks everybody for all your help!

4 Likes

I’ve changed the refresh rate from 60 to 120 seconds and the problem was gone. Binding is 2.3.0; OH should be the latest 2.* release.

I will update all the system components (since the “new” version of the binding is available) and then I’ll try testing again.

I am using the cloud-key if that is important for troubleshooting (latest firmware and unifi versions)