Ubiquiti Unifi Binding Feature Discussion

I’m really not sure if that’s the issue.

Besides, @mgbowman knows the binding a lot better than me. I know he’s been busy with his reno project, but hopefully he’ll have a few minutes to look into this.

Hmm, I installed a demo controller on my local machine and added it as a new controller in OH. It seems it is successfully connected (altough my test controller is empty, but still).

Any other clue that I can use to reproduce this error?

I made a PR earlier today with an added feature regarding the ability to “block” a client. We are sometimes finding ourself in need of blocking the devices of the little people in the household :slight_smile: I’ve been using the UniFi app to do so, but thought it would be much easier in OH and the possibility to add all items to a group, and block/unblock that group instead.

I don’t know it will get approved or if @mgbowman thinks this is a good thing for the binding. However, the PR can be found at https://github.com/openhab/openhab2-addons/pull/4845 .

Hi Patrik,

Are you talking about having 2 bridges configured on OH for the Unifi binding or the something else?

Best, Jay

Well, I installed a 5.10.12-controller in order to test it in parallell with my 4.9-controller. However, it seems to work fine. After the test I also upgraded my own UniFi Controller which my production OH runs towards. It also worked OK.

My issue is tied to this configuration below; the binding only uses the first bridge listed. I have another unifi controller in another location which I’d like to monitor also with OH.

Bridge unifi:controller:home "UniFi Home Controller" [ host="192.168.0.20", port=8443, username="ubnt", password="password", refresh=10 ] {
	Thing wirelessClient TriciaiPhoneUnifi 				"Tricias iPhone XR"			[ cid="e4:b2:fb:d6:XX:XX", site="default", considerHome=60 ]
	Thing wirelessClient JayAndriodUnifi 				"Jays Note9"				[ cid="44:91:60:c1:XX:XX", site="default", considerHome=60 ]
	Thing wirelessClient ParkeriPhoneUnifi 				"Parkers iPhone XR"			[ cid="f8:2d:7c:22:XX:XX", site="default", considerHome=60 ]
	Thing wirelessClient RyaniPhoneUnifi 				"Ryans iPhone XR"			[ cid="fc:18:3c:6c:XX:XX", site="default", considerHome=60 ]
	Thing wirelessClient MainFloorControlUnifi 			"Main Floor Tablet"			[ cid="68:5a:cf:4c:XX:XX", site="default", considerHome=60 ]
	Thing wirelessClient UpStairsControlUnifi 			"Up Stairs Tablet"			[ cid="68:5a:cf:22:XX:XX", site="default", considerHome=60 ]
	Thing wirelessClient BasementControlUnifi 			"Basement Tablet"			[ cid="68:5a:cf:22:XX:XX", site="default", considerHome=60 ]
}

Bridge unifi:controller:work "UniFi Work Controller" [ host="x.x.x.x", port=8443, username="ubnt", password="password", refresh=10 ] {
	Thing wirelessClient PamiPhoneUnifiRIS 				"Pams iPhone"				[ cid="48:d7:05:6e:XX:XX", site="default", considerHome=60 ]
	Thing wirelessClient JayAndriodUnifiRIS 			"Jays Note9"				[ cid="44:91:60:c1:XX:XX", site="default", considerHome=60 ]
	Thing wirelessClient JayEchoDotUnifiRIS 			"Jays Echo Dot"				[ cid="fc:65:de:16:XX:XX", site="default", considerHome=60 ]
}

Best, Jay

My issue is tied to this configuration below; the binding only uses the first bridge listed. I have another unifi controller in another location which I’d like to monitor also with OH.

Ah, ok - That I have difficulties to test out since I only have devices registered to one controller :confused:

Is there any way thru OpenHAB to control the blue halo led light on the UniFi AP’s? Can say they are a good nightlight at night, but I would prefer to be able to kill the lights on the units in my house at 9:00PM every night and turn them back on at say 7:00AM.

Thanks.

JR

Not as of today. The API supports turning on/off LED, but it is done via a “Device” object rather than a “Client” object. The UniFi binding today supports Controller and Client (Wireless). It has to be publishing Devices into OH if the LED state should be configurable.

Thanks Patrik. If I’m understanding right, you are saying until the AP’s themselves can be exposed as things this can’t be done? I know my AP’s are set to accept the setting of the master config or whatever. Which I would think is the Controller. So if there was a way to change this setting for the controller, the AP’s would absorb them.

Thanks.

JR

Thanks Patrik. If I’m understanding right, you are saying until the AP’s themselves can be exposed as things this can’t be done? I know my AP’s are set to accept the setting of the master config or whatever. Which I would think is the Controller. So if there was a way to change this setting for the controller, the AP’s would absorb them.

No - Actually I mean that until the Binding for openHAB is extended to also discover “Devices” (AP’s, Switches, USG’s) it is not possible to set LED state from OH. Today the binding discovers Clients (connected devices in the UniFi deployment), which is the thing to use when for example tracking “Online status” of a user.

Where do things stand on the 5.10.12 controller update? I’d like to update my controller but I don’t want it to break my openhab…

Hey guys,

Regarding the 5.10.x updates - sorry I haven’t been active but I’ve been super busy at my house wiring the electrical panels. Unfortunately, I’m leaving town this morning so I won’t be able to look at this until I get back towards the end of the week. Just from reading the previous messages, if it’s something as simple as some JSON quoting, maybe there’s a flag in the GSON library that will make this an easy fix.

Cheers

Matthew

Well - I upgraded my UniFi Controller to 5.10.12 yesterday and OH works just like before (from what I can see). I run 2.4 release build of OH but nightly snapshot build of the UniFi binding. Altough, only integrated with one controller.

I make no guarantees that it will work on your setups though :slight_smile:

I purged and installed back UniFi Controller 5.10.12 and binding working without errors on OH 2.5.0~M1-1
Looks like binding restart helped…

1 Like

I’ll probably run the update tonight or tomorrow. I’ll let y’all know how it goes.

So far so good here too. …

I’m running UniFi in docker. I saved the latest backup from the controller, stopped it, removed it, removed the volume maps from my compose file (so I could revert back and to get a clean install). Started the 5.10.12 version, restored the back-up and all is well so far. I’ve toggled the WiFi on my phone and OH sees the disconnect and reconnect.

Running OH 2.4 Docker.

2 Likes

Another successful update here-

I’m running openhabian on a pi 3b+, UniFi cloud key 2. Updated the controller, saw 2 json errors in OH logs, then everything successful after that.

Sorry, I’m not sure if this is the right place for a feature request. Please let me know if there is a better way.

The unifi binding works really great, I’ve just one problem. My Unifi controller runs on a server in the public internet and every time it’s not reachable for a little time all devices are considered as offline suddenly.

It would be great if I could configure what should happen with the device status if the controller is offline (all offline/all online/don’t change) or if I could use the controller status (on/off) in a openhab rule.

Best regards
Daniel

Hey guys, I’ve been collaborating with @scurb on adding blocking / unblocking support to the binding but we identified some major refactoring which made implementing this feature easier (and it also makes future enhancements easier).

I would like for you guys to test before we try and merge his PR. Please install my latest build and let me know if you have any issues:

org.openhab.binding.unifi-2.5.0-SNAPSHOT.jar

You can check the updated README for info on the new blocked channel as well as the Full Example.

The most important thing to note is the user credentials you define in OH have to have admin rights in the controller of blocking / unblocking clients simply will not work.

Cheers!

Matthew

PS: As soon as we get this PR merged, I’m going to address the multiple bridges issue as well as the other features proposed in this thread!

2 Likes