I have a local Super Administrator account on each of my Unifi Network Controllers (I have a controller in each of 2 sites). The local account is a simple userid (i.e. not my Unifi account email address) and a password. That’s what I put in the Unifi binding config.
Let’s bundle to conversation if you do not mind within the existing specific treat.
I experienced another issue:
When trying to reconnect a device via openhab, I get the following info log:
2024-05-02 17:11:29.943 [INFO ] [ternal.handler.UniFiBaseThingHandler] - Could not handle command ON for channel = unifi:wirelessClient:home:Shelly_Kueche_Arbeitsplatte_links:reconnect because no entity/controller data available.
items file:
Switch Shelly_Kueche_Arbeitsplatte_links_reconnect "Reconnect Shelly Kueche Arbeitsplatte Links" <switch> (gUnifi_ReconnectHauptschalter) {channel="unifi:wirelessClient:home:Shelly_Kueche_Arbeitsplatte_links:reconnect", listWidget="oh-toggle-item", stateDescription=""[options="ON=Ja, OFF=Nein"]}
Thing file
Bridge unifi:controller:home "UniFi Controller" [ host="192.168.186.xxx", port=443, unifios=true, username="yyyy", password="zzzz", refresh=60 ] {
Thing wirelessClient Shelly_Kueche_Arbeitsplatte_links "Shelly Kueche Arbeitsplatte Links Unifi" [ cid="192.168.186.abc", site="default", considerHome=180 ]
}
Any idea?
Any idea on this? Do I need to put a bug report somewhere?
Hello everyone,
I’m currently migrating my OH instance and I’m trying to do some cleanup while I’m on it.
I still use the Art-Of-Wifi API to disable/enable AP devices (GitHub - Art-of-WiFi/UniFi-API-client: A PHP API client class to interact with Ubiquiti's UniFi Controller API) via the Exec binding. It works great but It would be much nicer to be able to do this via the binding itself.
I thought about contributing a PR to this binding to add this feature. Since I would need to create a new Thing Type for that (AP device) this might be quite a bit of work so I wanted to make sure that there is some interest from the community before I start working on it. Would anyone else be interested in this feature or would the binding maintainers consider including a PR? I don’t want to maintain a separate fork of this binding so I would only consider contributing if there is a chance that it might get added to the official binding.
I asked about this feature about two years ago and there was no real interest back then. If this is still the case thats of course fine for me but I will probably simply continue using my external API intergration then.
Thank you for any feedback!
If you are willing to invest time in this, I am interested. I can have a look at the code, but I am not a maintainer, so cannot approve it.
If the only use of the extra thing would be to have the ability to enable/disable an AP, you may be able to do that using dynamic channels on the Wifi network thing. But that would of course introduce a new way of doing things in the binding. There might be more relevant channels though.
Thank you! Unfortunately there are not many other useful things you could do: turn the led on and off, locate the AP (blink led). The more complicated stuff like assigning WiFi groups or change radio settings does not seem to make a lot of sense in my opinion.
As I only want to disable some APs during the night I don’t want to mess around with the WiFi networks but rather keep switching individual APs on and off.
Hi, I have Unifi UCG running UnifiOS, I created a local user and the binding seems to connect and get correct info about the devices, however whenever I try to make a change (like reconnect or block) I receive the following error:
2024-08-30 07:32:19.943 [WARN ] [g.unifi.internal.api.UniFiController] - Not Au
thorized! Please make sure your controller credentials have administrator right
s
I have checked the local user and it does have full permission. Any hints?
Same issue here. It however seems that sometimes after restart it works for a while, but than it reverts back to “not authorized”. Even tried to setup different accounts for Unifi and NVR and other instance. I’m hoping that the newly introduced Unifi API (UniFi API Version 0.1 | UniFi API) will (when it develops management functionalities on top of the current monitoring set) allow someone smarter than me to re/implement the binding.
1 Like
Thanks for confirming the issue - I also did some test initially when I setup the local account, I could reconnect, block/unblock without problem back then. So it looks like initial login has a period of time validity and for some reason the binding doesn’t re-authroise.
But on the strange side, despite the issue, I can still get updates from Unifi, and the Thing is also always online.
This is exactly the boat I’m in. It worked for some time, I’m using a local user that has admin privileges, things display online, but anytime I try to “reconnect” a client I get the not authorized error. What’s interesting is that in the UniFi interface, it says my openHAB user last logged in a few minutes ago.
Ok, I did some more experiment, and when it stops working it looks like I need to disable enable the Unifi Controller thing, then it works again.
So in my rules now I have added the ugly workaround: whenever before I perform any action, I disable and then enable the controller thing.
I will report back in a couple of days experiment if it indeed solve the issue, if so I guess the binding could just reinitialise every time when an action needs to be performed.
Stay tuned 
So far it works - so indeed disable/enable the bridge helps. I suspect it triggers a re-login so subsequent actions are permitted.
Hi, I was actually trying to achieve the same thing some time ago, but was not successful. Maybe I was doing the disable wrong using
executeCommandLine(Duration.ofSeconds(6), "curl", "-X", "PUT", "/", "http://localhost:8080/rest/things/unifi:controller:home/enable", "-H", "accept: */*", "-H", "Content-Type: text/plain", "-H", "Authorization: Bearer oh.scirpting.xxxREDACTEDxxx", "-d", "false")
Still getting the “Not Authorized! Please make sure your controller credentials have administrator rights”
Are you using the same or different way to “toggle” the binding?
Thanks in advance.
Hi I still see those error messages, but the binding is working after disable/enable, I never had issue since. I use dsl rule and send http request to enable/disable the thing by OH rest api. I put a 10 seconds delay inbetween
1 Like
Thanks, I do the same thing, see the error messages but did not think that the reconnect happened despite that. As I also do other workaround (turn off IoT wifi for 15 minutes in night in Unifi Scheluder) everything works. I will try to turn off the other workaround and see…
Hi Mark,
I finally found some time today to add the accessPoint thing to the UniFi binding. Luckily it was not as complicated as I expected but of course I haven’t had a code review yet 
Functionally it seems to work well for me. The new accessPoint things are discovered and you can use the single channel “disabled” to disable and reenable the access points. It does not seem really intuitive to disable the access point by switching a switch item ON but this is the way the unifi controller handles it so I decided to do the same in the binding. However I could of course reverse this logic for the sake of being more intuitive for the user.
If you want to give it a go you may get the precompiled jar file here:
https://www.dropbox.com/scl/fi/h8vnxo3q3kc45oa023klz/org.openhab.binding.unifi-4.3.0-SNAPSHOT.jar?rlkey=rj98mxbvvklpb1053vx20v4jr&st=7mvp1ov4&dl=1
You can find the code here:
There are more commits than the required ones on this branch due to my bad git skills… They all affect a different bundle though, the last two commits are the relevant ones. I will try to clean this up later…
1 Like
In the latest build I inverted the logic so that the thing had an enabled channel instead of a disabled channel. Makes much more sense that way.
1 Like
Speaking of that, do you know if some AP’s support other colors than blue, so that a payload like this would work:
{
"led_override": "on",
"led_override_color": "#00ff00",
"led_override_color_brightness": 50
}
For me color and color_brightness doesn’t seem to have any effect, I can only switch it on or off, but it’s always blue at the same brightness. My AP is a UniFi UAP-nanoHD.
The reason I ask is because it actually could be slightly useful. If I could have whiter light, it could be used as night light triggered by a motion sensor. led_override can be either on, off or default (site setting), so at first glance seems hard to map to a switch channel for light on/off. But it could be mapped to a switch channel meaning override on/off, and off = default and on would let another channel control the HSB color.
Actually I’ve never tried that but I thought about it already. I think the led is white when you install a new AP and it is not yet adopted so it should support different colours.
I can give this a try in the next few days, I have some AC-Lite, a U6+, a U6-Pro and a Flex-HD so I can test a few different models.