[PROJECT] Driver for Unifi Network Controllers

🚧 Developers
,
144

That would make it appear that the cookie for authorization timed out for some reason. The driver should Login (the Login in the Scheduled Jobs list at the bottom of the device) every hour to refresh the cookie. It runs the exact same command that happens when you press the Login button.

Is there any apparent consistency in the logs for when it does happen? Like... it happens every time right after midnight, or every 6 hours, or anything? Not sure what might be causing it so just hoping...

145

I'm seeing the same behaviour that @john17 describes. (Welcome to Hubitat John!).

Looking at it today, it seems the "Unauthorized for PresenceCheck please Login again" starts appearing in the log exactly one hour after the last manual login. The driver then attempt three polls every minute, five seconds apart.

A fresh manual login solves the situation for another hour.

1 Like
146

Ditto what @larsplougmann says.
To add, the scheduled hourly login seems to happen as expected, but it is only a manual login that resolves the "Unauthorized for PresenceCheck please Login again" (for an hour).

147

Ugh... Both call the "Login" command and there are not even any parameters to change about it... So of course something appears to be happening that seems like it should not possibly be able to happen.

I re-enabled the detection on mine (because I only have 1 Unifi AP that is NOT the primary AP most devices connect to, it can be flaky for me) just over an hour ago. I will keep my logs running overnight to see what I can catch happening.

Edit:
Something has already happened. I had the automatic hourly login occur but then about 1 minute later I got the error. Looking at the logs, it looks like the Cookie that was received in the most recent Login was not saved properly (the Presence commands are using an old one not the new one that I can SEE a state change saving...). So I have a place to look. Hopefully I can find a quick fix here.

Edit 2:
It is DEFINITELY the cookie. I forced it to use the new cookie that I saw in the logs and it started working again. So I need to figure out why the state did not get retained DESPITE the log showing that the new cookie's value had been sent. Arg. One of those scenarios where it is writing a new value but the variable is in use so the value does not get written...

On a different note, I was messing with the commands to try to block things and such (and a couple other commands I have tried in the past) with no success yet. Keep getting page not found errors despite matching what shows in the Unifi API page for my version controller and on the "Art of Wifi"... So I must be making a simple mistake on it.

148

Is this something can easily be added? There appears to be another Unifi driver in HPM that claims to already do this but I can't even get that one to connect.

149

I am not familiar with the other driver and how they might be accomplishing things, but I am still plugging away at the commands in the hopes of providing something since it seems to be something people would be interested in.

1 Like
150

It appears that the other one may have been abandoned. It says compatibility with devices using Unifi OS are in testing. Unifi OS has been platform wide for a while now.

151

Updated Version(s):

  • UnifiAPI.groovy = 0.2.7

Change(s):

  • Workaround for presence (and possibly refresh) failing just after an automatic login occurs. This is/was due to the new cookie being written to the state as the presence (or possibly refresh) was reading it to use. This prevented the new value of the cookie from being retained even though the log showed it was being set in the state variable (but then the variable would show the old value and unauthorized errors would occur). The workaround is that the presence and refresh (if refresh rate was set for 1 minute) are rescheduled to 1 minute after the login completes.
  • BlockMAC and UnblockMAC commands have been added. In my testing it appears there is a caveat in that they seem to only work if the MAC being blocked is connecting via a Unifi Access Point (AP).
    Testing was fairly limited as I do not have many devices that connect to my sole Unifi AP and most of the ones that do I do not want to mess with. However, there was one poor device that got beat on (a Blink Sync Module if you are curious) and it consistently dropped off and was unhappy when it was blocked (did not show up as present either) but came back on when it was unblocked.
    I attempted to block another WiFi device that was not connected through the Unifi AP (I have 2 other APs that predate my Unifi work and I have not been able to purchase new Unifi APs to replace them). I could not disconnect this device. Even when blocked (and the result showing that it was supposed to be blocked) the device (an ESP8266) was perfectly "happy" and I could connect to the webserver running on it just fine every time.
  • ArchiveAlarms command has been added. This will simply archive any active alarms.
  • Last Presence Check has been updated so that it now ALSO states when the last presence check was performed that did NOT find any devices present (previously it was set only to update as part of a successful result).

Different Topic(s):

  • I THINK I found a way to power cycle (POPO) a port. However it only works with Unifi PoE switches and will only work with a PoE port. It does NOT work on UDMP ports (they are not PoE). I do not have any Unifi switches, let alone any with PoE (I have an old Managed PoE switch that is running just fine and does the job). So I absolutely cannot test this feature out (once I tested and proved it would not work on my UDMP so far as I can tell).
    This feature is considered UNTESTED, UNPROVEN, and USE AT YOUR OWN RISK!
    If anyone is truly curious/brave and wants to try this feature out, you can go into the driver code and remove the comment flags from lines 100 and 105 (around the PowerCyclePort command). This command has two parameters. The MAC address of the switch the port is in AND the port # (code-array format, so port 1 as we see it is port 0 in the code). If you try it and it works, let me know! If you try it and it does not work, let me know! If you try it and fry something, let me know it did not work (and sorry for your loss, but you were warned)!
2 Likes
152

Thank you for taking swift action. Good update notes too. I have installed 0.2.7 and will monitor the log to see if it fixed the Unauthorized-for-presence-check issue.

153

tested power cycle of port, entered 7 and the port 7 in Unifi switch US-16-150W did restart as expected, thanks, this will come in useful

2021-03-08 10:35:37.286 pm tracevUnifiRouter - PowerCyclePort succeeded = [meta:[rc:ok], data:[]]
dev:732021-03-08 10:35:37.283 pm tracevUnifiRouter - Event: Status = Power Cycled Port 7 on switch 80:2a:a8:00:00:00
dev:732021-03-08 10:35:37.176 pm tracevUnifiRouter - PowerCyclePort Params = [uri:https://192.168.1.210:443/proxy/network/api/s/default/cmd/devmgr,
Cookie:TOKEN=e0000000000000;, X-CSRF-Token:0000000c], body:{"cmd":"power-cycle","mac":"80:2a:a8:00:00:00","port_idx":"7"}]

1 Like
154

Have been running 0.27 all morning the "Unauthorized for PresenceCheck please Login again" issue is resolved for me - many thanks for such a speedy response.

155

You brave soul... and THANK YOU!

I will let it stew a bit and see if anyone else tries and then maybe it will become an enabled feature. A lot of it goes back to wishing commands could be dynamic so I could hide it unless people want it.

Speaking of Ubiquiti stocking... I got an email last night that the new Professional AP was back in stock for early access. Cannot blame them this time since they sent the email at 6:35pm and I did not see it until this morning, but I missed AGAIN.

156

@snell I wanted to extent an apology. In an early post I questioned the speed stats as if it was something wrong with your code. I discovered that it was actually something with MY system.

157

Um... No worries at all. I did not take it that way. There are plenty of times I find I have introduced a bug (usually a copy/paste error) or made a mistake in the code so it is always good to make sure. I would much rather have someone say there might be something wrong and go over it to make sure. That is why I asked for the logging so I could check what I see.

So no apology necessary.

1 Like
158

Ok, cool, I wasn't sure. Was in a crap mood over personal stuff yesterday and I have a bad habit of let that come across in my dealings with others.

159

Bummer. Hope it is all going better now then. I try not to read into anything too much (I get enough of that from work). Kindof makes me oblivious at times... oh well.
:slight_smile:

But hey! You and other folks prompting about the blocking/unblocking made me dig into it more and now there is a semi-useful feature added, so it works out for everyone. I may look at more of the possible commands out there tonight. One thing I am thinking about is having a "send command" type of command... where you enter the command (or select it from a dropdown) and whatever the needed value is... and then the driver does the work behind the scenes rather than have bunch of separate buttons.

160

Confirming @john17's observation that the "Unauthorized for PresenceCheck please Login again" issue has been absent for about ten hours since I upgraded to 0.2.7. Good sign.

161

I just added these drivers yesterday -- using the latest 0.2.7, but seeing the same "Unauthorized for PresenceCheck" errors intermittently appear. I've been researching possible solutions, and come up with a couple:

(A) we can easily decode the JWT in the Cookie, and determine the "exp" date/time -- appears to be always be an hour after the last login. With this, we could compare against the current time in GenerateParams and call Login (if needed) before making the intended call? Not sure if this would put us into a race with state -- which is loaded when execution begins and only updated when execution completes...

(B) a more straightforward approach, simply call Login if we get a 401 response -- then the next scheduled presence call should succeed?

(C) related to the statement at the end of A, do we need to use atomicState instead of state, to avoid this race? Storing Data With State — SmartThings Classic Developer Documentation EDIT: atomicState is only for Apps, not Drivers

I intend to play with options A and B on my hub, will report back

162

B is the more likely option to use and potentially the simpler one. I can look into that. It is a bummer the 0.2.7 did not help for yours since it seemed to solve most.

Mind if I ask how many MACs you are checking? Wonder if I need to change the sequencing for when someone checks multiple.

163

Checking 2 MACs - I'll note that it will sometimes recover itself after an hour or two on a scheduled Login - haven't watched it enough to see a specific pattern