I can check into that although I do not know if it will help if it is waiting on an external response. Some of the responses from the API can take a LONG time (minutes). That is what is causing the interference with the other jobs. The API itself is busy and then blocks requests until it completes.
1 Like
I am experiencing the hourly presence error at the moment. I added the singleThreaded parameter to the driver and it didn’t help. Clicking save preferences on the device always fixes this scenario. Know timings of the scheduled jobs is recalculated.
I did experience similar challenges on a community app, GCal Search, I maintain and the culprit was having multiple scheduled jobs happening at the same time. I ended up combining things and leveraged a state variable to provide instructions for the scheduled job to perform at each execution. Just wanted to throw out suggestions in case it helps.
I was trying to be "good" by having ones that had very different timings performed on the schedule. Especially as I leave the refresh interval configurable, DailyCheck is once a day, etc...
One thing I have been trying out on my own system is "scattering" the timings more than I have them now.
1 Like
You've done some really great work on this project and I'm glad I came across it. I have been using my phones with it for presence detection. I see that you've stated Uptime is a string, but you mentioned somewhere above that it could be possible to parse it into a value. Is that something you could add at some point? I have a need to be able to do a compare in a rule to see if the Uptime of a connected phone is greater than a certain amount of time (less than would also work.) I'd be happy to help with any testing. Thank you.
I think something broke in the BlockMAC functionality. I noticed the blocking doesn't occur, and was trying to debug it. I pass it a string of MAC addresses (the same ones I've always passed) directly in the device (no variables, no rules) and the Status changes to No valid MAC address entered to block.
@snell can you take a look?
Every now and then those "request time out checking if X is present" errors appear for me. I find if I pull up my UnifiNetworkAPI device and click Save Preferences the error goes away.
Know that @snell is investigating spreading out the timing of the scheduled jobs so this doesn't happen.
I just updated to UniFi Network Application 8.1.113. We'll see if the helps.
@Busthead: Try doing the manual Login command from the parent device to see if that helps get things reauthorized again.
You also have a pretty large buildup of Alarm data. You might want to ArchiveAlarms those if you have dealt with them.
As for the version, it can take 24 hours to update the DriverStatus because that only gets checked/updated as part of the DailyCheck. I did not want it checking all the time both to not be annoying for people since it is EVERY one of my driver/devices checking every day AND because all those are checking my own webserver.
@jbaruch: Nothing has changed lately with that and I just tried BlockMAC and UnblockMAC without issues on mine. Can you shoot me a message with showing what MAC you were actually trying to block? Plus, what version of the Unifi Network API are you using (maybe it is different from mine and the changed something)?
@lelynch: I was thinking that people could just parse it in a Rule. But I just tried to build a Rule to demonstrate how that would be done and cannot figure out an easy way to do it. So I need to figure out a good way to break this out... What were you thinking on values? The uptime is presented from the API in seconds, so I convert it to the readable string. I could easily add an attribute/event that has it in seconds, minutes, or hours (or all three to give flexibility). Does anyone else have a preference on there? Making it selectable would be more work than it is likely needed, but Presence does not have a lot of attributes so adding a few there should not matter.
I don't know how to do archive alarms.
Updating to UniFi Network Application 8.1.113 appears to have eliminated the errors I was seeing.
Weird... 8.1.113 is the current Official so who knows if there was a bug or such.
As for archiving alarms, there should be an "Archive Alarms" button on the parent device.
Also, this isn't going away after 24 hours:
The 403 error is "Forbidden" basically unauthorized... The controller recognized the command but the login did not have authority to run it. Are you still getting login errors or any errors if you run a refresh command?
There should be a new version coming soon... Not sure why that has not gone away on yours but we will see if it changes in the next couple days (maybe tonight ~12hrs or so).
I just updated to the Early Access firmware update version 4.0.3 on my UDM Pro. That update also installed Network version 8.1.127. I don't know if this is the cause of my problem, but I suspect it is.
The problem is below and just started up today after the update:
Is there some way to log in again that I am missing? Or did Unifi make a change to the API?
LJ
**EDIT: ** I should add that when I press the Login button on the main Device, the status field updates to "Login successful." However, it immediately starts showing the Unauthorized messages again. The logs show no login attempt or success. Also, the User ID for this is local only so I believe that 2FA does not enter into this.
I'm using a View Only UniFi account.
No, I clicked the Refresh button on the parent device page and nothing appeared in the Live logs.
Are you still getting the Unauthorized errors that you posted earlier and that I posted immediately above? Mine just started this morning. What did you do to clear them and Login properly?
LJ
No
1 Like
Strange, updating to 8.1.127 started this for me. That version came bundled with Console firmware version 4.0.3.
What Console firmware version are you on?
LJ
UniFi OS v3.2.12
1 Like
Ok, a View-Only account cannot Archive Alarms. They can only poll general data. It should not be able to do any port actions or anything like that either.
