It's not a workaround; this is how it should work 
It is a workaround for an account that has had Ubiquiti 2FA enabled as part of their push to making 2FA mandatory.
I think his point is that it's not a workaround, as the local account doesn't have 2FA and is the account that we should use for the app. Just because many of us probably didn't use a local account initially (count myself among them), and instead punished ourselves with 2FA (and broke things) -- doesn't change the fact that we were doing it wrong!
To be fair to those of us that struggled with this -- @snell, in your first post, perhaps in the "REQUIRED" section you could add a comment to note this requirement -- perhaps something like: "For users who have enabled 2FA on their Ubiquiti account, a Local Admin account needs to be created on the local Unifi controller to enable this application to access the controller." -- probably needs much better wording...lol
S.
2 Likes
Edit made. Does not hurt to post it...
2 Likes
I opened a ticket with Ubiquiti over a year ago and informed them of the security risk of not letting us force 2fa on external users. of course they ignored me. i really don't like the fact that they force us to use a cloud database of users. I personally have always used local accounts and disable all cloud functionality. I don't understand why so many people entrust external systems with their credentials. I don't even use the cloud features of hubitat. If you are not using MFA/2FA for all your cloud based accounts its not if, its when you get compromised.
I see UniFi - Request Timeout checking if XX:XX:XX is present in the logs every hour in the last four days. Does anyone have any clue what might be the reason?
Are you performing a client check? Those are the only thing that (by default) runs hourly.
Not sure why it would be timing out but at least this will help narrow down where I need to start checking on my side.
Other questions:
Nothing else has changed? No new version of Unifi or the Network app on it?
Nope, Enable Hourly Client Checks is turned off.
Unifi OS was updated tonight, while I started to get the timeout errors a couple of days ago. The Network app was updated almost a month ago, so it's definitely not it.
So the other item is Presence checking.
So next questions:
- Do you have any MAC address(es) you are checking that match that one? It would be checking more frequently than once an hour. BUT, it could be coincidentally matching up with something else going on at that hour.
- How many devices are you checking for Presence?
- What is your Refresh interval set to?
It is possible that a Presence check might time out if it happens at the same time as a refresh (the refresh can take a bit depending on the level of data the API provides). I have no personally hit that but I do not generally have many devices on Presence detection (except when testing something specific). I have definitely seen OTHER cases of the refresh responses taking a long time though.
The error messages stopped 
I'll pick it up from here if they return.
Running UniFiNetworkAPI driver version 0.4.52. UniFi Network 8.0.28
Strange that State Variables lists two different Driver Versions listed and Driver Status is reporting a patch available:
Current States:
Ok, there is a bunch going on here so I will try to do it in parts. Easiest first:
- The naming for driver-specific variables (Driver Name, Driver Status, and Driver Version) were changed in version 0.4.51 to remove the space in the names. So the "correct" ones are the ones without the spaces. This is a change I am slowly making across all my drivers as I try to remove spaces in names (because of how they can show duplicate entries as Events on the device page).
- Only looking at the more recent errors in your log because many of those are before the more recent version was published (0.4.52 was published on January 21st) and the "worst" problems look like the unterminated data. The problem there is that it is the data coming back from the API that appears to have an error as the json cannot be parsed properly. It is also for the most generic "ReceiveData" function that most everything uses to handle returned data. So... does the timing of the error seem to coincide with a refresh or some other scheduled activity? It does not seem to be on a regular cadence for the time and it is not even happening every day.
I checked my own logs and got something similar but not exactly same and I only have one instance of it. The line number would be the same as yours for 1461 but I have a newer version that has added a couple lines and is not published yet. The 3:10am does not correspond with any specific scheduled activity except MAYBE a presence check (since those are so frequent). Certainly not a refresh or daily check. Here is the error I saw:
[dev:2]2024-02-21 03:10:39.145 AM[error]groovy.json.JsonException: Lexing failed on line: 1, column: 1, while reading '<', no possible valid JSON value or punctuation could be recognized. on line 1463 (method ReceiveData)If you can see if it corresponds to a particular activity or starts happening regularly maybe Trace logging can be enabled and the response checked (since the log would have the response listed as "Received" with the data after it). Then we can see if the API is provided some incorrectly formatted json.
None of the items in the release notes for Unifi Network 8.0.28 (I have the same version) seem to indicate any changes with the API, although that is no guarantee.
We were out of town all weekend. These errors appear to occur when the driver is checking for presence of our son's phone - which was not present because it was with us on our trip.
The same thing happened to me when we were away. @snell that explains why I don't see the errors now when I am back.
Huh... so that implies that one of the newer versions of the Network API changed the response method. It used to just return a 400 error "Bad Request" if a device was offline, which I handle. Maybe in some cases they are now returning a 408 "Request Timeout"...
Seeing what I can do on my end. Still not sure why there would be any JsonExceptions though. I am hesitant to just immediately make 408's for Presence Checks become offline without testing. What is troubling (for me) is that I have a device I keep "offline" (powered down) for a lot of the testing and it comes back with the normal response.
EDIT:
Out of curiosity sake... are these phones set to have fixed MAC addresses? Not sure how that might impact the response.
From what I understand, even for "randomized MACs" the MACs are fixed per network. So, if a phone connects to the same Wi-Fi, it will fake the same MAC consistently.
I do not know if that is a factor here... but according to the android docs as of Android 12 it is a "non-persistent" randomized MAC by default.
EDIT:
I checked about iPhones (I do not have one myself) and they apparently implemented "persistent" randomization in iOS 14, like what Android used to do prior to 12.
EDIT2:
I did my "usual" test with a real but powered down device and it reported as not present using the http 400 "error" like usual.
I tried using a completely bogus MAC "aa:bb:cc:dd:ee:11" and it reported it exactly the same way...
So it looks like something going on with how the Unifi Network API is handling not present/offline devices but what specifically and how to replicate it so I can make sure this would be a proper handling and test it going forward...
Maybe they want you to implement exponential backoff in the retries?
@snell FWIW the error that @Busthead and @jbaruch is the exact same error I reported to you above on Jan 26 when I was on business travel.
I was out of town this past weekend and i didn’t experience any errors so strange situation.
I do use an iPhone and have the Private WiFi address setting turned off for my home network which keeps the MAC address the same.
@ritchierich: I had wondered about that but I had asked about whether there were any conflicting schedules that might have induced it at that time. It also is a problem diagnosing it when yours did not have the errors again most recently.
So right now, there are 3 samples: @ritchierich, @jbaruch, and @Busthead
I COULD just bypass this all and make it show the device as not present for this error (like 400) but I do not know if that is accurate yet or not. Are all three of you pretty sure that the errors correspond to when a device was not present on your network?
