Thanks, looking forward to the results. I can add that the led_override_color and led_override_color_brightness are persisted correctly, so it seems that the payload is correct. But still blue.
I see that the Art-of-WiFi implementation also does not support colour changes (GitHub - Art-of-WiFi/UniFi-API-client: A PHP API client class to interact with Ubiquiti's UniFi Controller API) but is pretty comprehensive otherwise. So I guess it might not be possible. But I can still give it a go 
Do you happen to have some code ready to go for me to try this out?
Third is an interesting read regarding the colour changing capabilities: https://community.ui.com/questions/UniFi-menu-for-color-change-on-APs-gone/23af4382-1cae-4e12-9a19-65b44d943e8b
1 Like
I only tried sending the payload mentioned above to the same endpoint you introduced in the binding for disabling the AP. Since I cannot get it to work, I did not write any code yet. I suspect now, since my AP is more than 5 years old and reading the forum posts you mentioned, that my AP does not support colors.
I see the same now for a couple of days. Pausing and starting the UniFi controller thing fixes the problem temporarily but it is kind of annoying. Has anybody found a more permanent solution?
My workaround is to disable then enable the controller thing for each operation.
For example I need to block indoor cameras when somebodyâs at home, so in my rule I do:
- disable the thing
- wait for 10 sec
- enable the thing
- wait for 10 sec
- block/unblock cameras
It works stable for me in the past couple of weeks
1 Like
Hmmm, that might work for automated tasks but not with user interaction in Main UI. Anyway itâs far from being an actual solution for the problem. I already turned on debug logging but I donât see anything interesting in there.
I also tried to replace the FQDN with the IP of the UDM SE in the bridge config without success. I now set the refresh interval to 15 instead of 10 seconds to see if that charts anything.
Couldnât agree more, itâs a temporary workaround and I really hope the issue can be solved by the binding. I think enable/disable the Thing triggers a re-authentication, which allows actions like block/unblock/reconnect to work. There is some sort of timeout that I donât fully understand, the binding works fine for a while after OH is restarted, and it will continuously get updates from Unifi, however after a while I can no longer send command (block/unblock/reconnect), which gave me the inspiration of this silly workaround.
My refresh interval change didnât change anything (I wasnât really expecting this anyway).
Yes it seems that it should be possible to fix this from within the binding if it would be possible to somehow detect the disconnected state. As far as I can see however this is what the binding already tries to do. It tries to login again if something goes wrong upon performing an action. Maybe I will put in some more log statements to find out in more detail what is really going on.
I also would like to use this binding. Is the one of the add-on store the right one?
I havenât had time to check the code, but I think it is something with the way how Unifi works. The binding works fine if I just want to read updates from Unifi, but only work for a while when I need to write (send command) to Unifi.
I found my workaround as I can always reproduce:
- I send command to block/unblock
- The command fails - with authentication error in log
- Things are still updated from Unifi even though now I cannot send command
- I manually disable the Thing wait for 10 seconds
- I manually enable the Thing wait for 10 seconds
- I try the command again, it now works (note I will still see the authentication error in OH log however the command works)
So my guesses are:
- When the binding is re-initialized it does something more than just login.
- When the binding is disabled, it triggers a refresh of the session or similar
My script to fix the issue in case anybody is interested:
val refreshUnifiBinding = [String username, String password|
//Disable then enable Unifi Controller thing
sendHttpPutRequest("http://"+username+":"+password+"@10.x.x.x:8081/rest/things/unifi:controller:home/enable", "text/plain", "false")
Thread::sleep(5*1000)
sendHttpPutRequest("http://"+username+":"+password+"@10.x.x.x:8081/rest/things/unifi:controller:home/enable", "text/plain", "true")
Thread::sleep(10*1000)
]
I have UCG-Ultra with MFA enabled and login as local admin user. I notice the error in the log regardless if the command works or not (after the initial working period after OH is restarted):
2024-10-06 10:37:06.459 [WARN ] [g.unifi.internal.api.UniFiController] - Not Authorized! Please make sure your control
ler credentials have administrator rights
2024-10-06 10:37:11.509 [WARN ] [g.unifi.internal.api.UniFiController] - Not Authorized! Please make sure your control
ler credentials have administrator rights
So this error doesnât mean if the binding failed in sending command to Unifi
1 Like
Yes, itâs the one from the add on store 
There is an easier thing to check: From either the UniFi Controller web interface or the app: When going to the access point and settings, do you only see âLEDâ with options âOnâ or âOffâ (like me)? Or perhaps some options to change color?
No I donât see any other options there. I already checked that.
1 Like
In case you are willing to compile the addon for yourself this is my current workaround. I changed the executeRequest method in the UniFiController.java. See the added logout() line.
Iâm aware that this is by no means an actual âfixâ, it just logs you out after every request. But since I couldnât find the actual problem this is still better than not being able to control my devices through OH (or even more so my wife, I cannot tell her to disable and reenable the âcontroller thingâ 
)
private <T> @Nullable T executeRequest(final UniFiControllerRequest<T> request, final boolean fromLogin)
throws UniFiException {
T result;
try {
result = (T) request.execute();
csrfToken = request.getCsrfToken();
} catch (final UniFiExpiredSessionException e) {
if (fromLogin) {
// if this exception is thrown from a login attempt something is wrong, because the login should init
// the session.
throw new UniFiCommunicationException(e);
} else {
login();
result = (T) executeRequest(request);
logout();
}
} catch (final UniFiNotAuthorizedException e) {
logger.warn("Not Authorized! Please make sure your controller credentials have administrator rights");
result = (T) null;
}
return result;
}
After you logout donât you stop receiving updates from Unifi?
No, the binding will log you back in for the next request. Its just a lot of overhead constantly logging in and out though in practice you wont notice even when clicking a button in the UI. I would still be very interested in an actual fix and tried to compare this project with the Art-of-Wifi Unifi Client implementation but I could not figure it out where the problem could be 
Isnât it the same issue?
Yes I guess this could be related. I was also trying to figure out if there might be some cookie in place that causes the login to fail after the session has ended but I could not find anythingâŠ
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 problem but it after reading quite a few error reports in various different projects it seems that caused quite a few problems⊠So this might be the root cause here as well.
It seems that we minimum need Jetty 10; latest version is Jetty 12.
An update of the current Jetty 9 is already in discussion since some time:
https://github.com/openhab/openhab-core/issues/3315