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
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.
oops…
I never saved the changes for the CUID in my *.items
file I had vim open but never saved it
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"}
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
(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) I would downgrade to an earlier snapshot build but I stay to debug those 2 also
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!
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
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
@martinvw I think I’m going to have to revert back to using an internal HttpClient
instance due to these CN issues
I was just able to view the certificate, its imho a pretty crappy certificate, thanks Ubiquiti! There is really nothing identifying there
Together with @mgbowman we came up with some other ideas but that will be after release and merge
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!
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
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
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…
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!
Thanks everybody for all your help!
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)