Ubiquiti Unifi Binding Feature Discussion

ubiquiti
unifi
Tags: #<Tag:0x00007f51d93dc818> #<Tag:0x00007f51d93dc6d8>

(Martin van Wingerden) #666

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:


(Matthew) #667

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.


(Martin van Wingerden) #668

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


(Angelos) #669

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"}

(Matthew) #670

@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

(Angelos) #671

:+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:


(Matthew) #672

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!


(Hakan Tandogan) #673

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


(Matthew) #674

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?


(Hakan Tandogan) #675

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…


(Matthew) #676

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:


(Martin van Wingerden) #677

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


(Matthew) #678

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!


(Angelos) #679

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


(Hakan Tandogan) #680

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:


(Hakan Tandogan) #681

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:


(Han) #682

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>

(Mark) #683

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

(Matthew) #684

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

Thanks everybody for all your help!


(Alexander) #685

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)