Ubiquiti Unifi Binding Feature Discussion

yes, I have an UDM Pro SE

Ok I have UCG with UnifiOS and maybe there are some differences there. I have created a dedicated local account for OH and it only works fine first couple of hours when OH is restarted. So look like session expired and the binding doesn’t try to renew

Edit: the binding still receive update and appears online, however any action (block, unblock, reconnect) fails with authorisation error

Same here, unfortunately. UDM Pro.

Ok thanks for confirming the issue.
Does anybody know a workaround?
I’d like to trigger reconnect when device is offline.

Hi, any possibility or trick to get a list of connected clients?

Hi, @DrRSatzteil.

I saw there will be an addition to the binding ([unifi] Add support for new thing type access point by DrRSatzteil · Pull Request #17499 · openhab/openhab-addons · GitHub), and I’m wondering if it’s possible to allow managing the access point’s LED light.

As a user, I want to turn the AP’s LED light off when the home is in away status, or when we go to sleep, for example.

Yes that would be possible. I already prepared a second pull request to provide some more info channels about the APs but I actually forgot to add a channel toenable/disable the led. We already realized that most newer models no longer allow a change of the led color(which is why I would not implement support for this), but switching the led on or off should be supported by all models.

1 Like

I have a local branch for adding LED functionality. I’ll see if I can push this tonight. :slight_smile:

2 Likes

That is awesome! Thanks @DrRSatzteil and @laursen.
Changing the color is not important, especially if some APs support it and others not.

I’m getting a bit confused here with this thread and the beta thread


I guess this one is the thread that should be used so I repeat here:

It seems that the currently shipped jetty version does not yet support partitioned cookies. I cannot tell whether this is the root cause of the authorization problems. However after reading through quite a few error reports in various different projects it seems that partitioned cookies caused quite a few problems everywhere


Can someone maybe validate this!? I don’t really know how to go on from here, if it was that simple I would probably just try to run the binding with the latest jetty version


I decided to implement this anyway, since it might be supported by some access points.

Also, modelling the API to openHAB is tricky when at the same time wanting to preserve the option to default the LED setting to the site-wide device LED setting. This is because the API value has three possible values: default, on and off. So this can not simply be mapped to an on/off switch channel, because they would either lead to not being able to revert to default, or it would mean that one of the states would be undefined in terms of being either on or off, depending on site setting.

So in the current draft version, I have mapped the override option directly in the meaning “override” (channel ledOverride - note: click “show advanced” to see this), and have added a second channel (ledColor) for controlling the color/brightness when overridden. This can be linked to items of type Switch, Dimmer or Color, so a Switch item will be sufficient if color is not supported by the AP.

The current test version does not yet include the changes of [unifi] Add some standard channels to access points by DrRSatzteil · Pull Request #17530 · openhab/openhab-addons · GitHub - this will be merged later. Also, the Thing needs to be recreated since there is no migration provided yet for adding the new channels.

Links:

I tried this today but all I can achieve is to toggle led on and off.

Other things I noted:

  1. After setting the brightness to 0 the led goes off. Setting the brightness to anything but 100 does not seem to turn it back on. Dimming is not working anyway but I think it would be more logical to have it on at 100% instead of leaving it off. However this could probably only be achieved by setting the brightness to 100% first and then to the actual value if the channel receives a command.
  2. It’s a bit strange that color values change after you set them. Apparently the controller does not accept certain colors and seems to be correcting the commands to the next possible color which results in little “jumps” of the sliders after you changed color.

Apart from that I could not really find out more since the access points don’t do more than switching the led on and off. So I would stick with a Switch Item anyway which seems to work fine.

That should work, at least after the changes I made yesterday evening. Did you try with the Wednesday JAR, or did you compile it yourself?

The color logic when having separate RGB, brightness and on/off in an API is somewhat complex because they can be mutually exclusive. For example, color black or brightness 0 is the same as off, so the implementation depends very much on how the concrete devices behave. The implementation is based on a previous implementation I made in 2022 for a Hunter Douglas PowerView repeater, but I also learned a few things while working on this new implementation.

I’m wondering if this happened after yesterday’s changes? I made a fix/change so that green + brightness 50 will be changed from #008000 / brightness 50 to #00ff00 brightness 50, since it seemed awkward having it both ways. This is mentioned in one of the testcases I documented in the PR yesterday (this is only how far I got, more are planned).

With all this being said:

I agree, if it turns out that the controller fully dropped support for brightness and color, so that’s it’s impossible to set it even for access points with LED’s supporting it, we should not provide a color channel that would only cause confusion/false hope. In this case we could always introduce it later if it becomes relevant. So I would like to give a new JAR a test run with a few more access points, and if all results are negative, I’ll abandon the current PR (but keep the branch for later).

In any case, I’ll prepare an alternative version with only an ON/OFF channel. The caveat here is that only on/off would be supported - i.e. not default, which is supposed to use the site-wide LED setting. So the user will not be able to delete the override and go back to that. As a small hack we could support NULL or UNDEF so that at least a command could be fired, even if UI switches will not be able to do that.

It would be interesting to know if this site-wide setting actually works. It seems to me that when using the UniFi app, I can only switch the LED on or off, so after doing that I cannot go back to default either through the app. I have only one access point. I just now found this site LED setting in the app, I’ll give it a try.

It seems to work:

  • When access point LED override is set to default, changing the site setting to on or off will affect the LED on my access point.
  • When access point LED override is set to off, changing the site setting to on or off will no longer have any effect, since it’s now overridden. On top of that, the Android app will throw an error (“Whoops, the application has encountered an unknown error”), so this seems to be buggy.

So having just a single on/off switch will break this concept, but it won’t break it more than the app already does. I’m not sure if this is a good argument for doing it, especially if it would force us into breaking changes later when fixing this after they fix the app to comply fully with their concept.

Thinking loud, we could introduce a configuration parameter to accomodate and then still just one switch channel. The weakness of this would be that openHAB would become master of this setting, and it wouldn’t respect the override being changed by any other integration (like the app or controller web UI). Therefore I don’t think that’s a good idea. So this leaves us again with two channels: Switching between override on/off and switching between LED on/off (only effective when overridden).

WDYT?

I used the compiled jar so I did not have all your latest changes apparently.

Yeah I had a quick look at the code yesterday
 A lot of cases that need to be covered there.

You could also use a String channel with corresponding command options but creating a simple toggle in main UI would be a pain then


I don’t think that two channels would be super bad. I don’t think that you usually would change the override setting on a regular basis anyway. Especially when you use OH you would just create a group of all led channels and leave every ap on override all the time anyway. The only actual downside I see that you would force all these users I imagined to link the override channel to an item even though they probably never want to change this item back to its previous state. So you could also maybe have a config option in the thing that says: if on I will always set override to true for you if you use the switch, if it is off you are required to control the override channel manually?!

The Shelly binding does something similar with the auto brightness setting in the thing configuration.

1 Like

After some waiting time, I finally got some feedback from a colleague having multiple different access points. None of them supports setting brightness or color. So I have abandoned the previous PR and created this one instead:

I also gave up on the idea of being able to revert to site-wide LED settings for two reasons:

  • Consistency (with the Android app which can’t do that either).
  • Simplicity.
2 Likes

Did anybody already upgrade to the new v9 Network Application? I would really like to try out the new zone based firewall but was not sure whether this version introduced some binding breaking changes. After all the API that is used so far is AFAIK not the official API provided by Ubiquiti but I might be wrong here.

Just upgraded to 9.0.108 and it seems to work, not seeing any errors so far.