[PROJECT] Driver for Unifi Network Controllers

Not a bad idea about that user. At this time I do not have any commands or such built in that do anything other than read.

But I am trying to make some. I hope to be able to archive alarms (just so I can get rid of an annoying one I have listed) in tonight's update.

just an fyi

I updated to the "UniFi Cloud Key Firmware 2.0.24"

the 2.x uses the "Unifi Dream Machine (inc Pro)" option as the " Unifi Controller Type"

so if anyone upgrades the Cloud Key, don't forget to change that

2 Likes

Good to know that!

Updated Version(s):

  • UnifiAPI.groovy = 0.2.2

Change(s):

  • Minor change... I now made it so all MAC addresses submitted for Presence (manual or in Preferences for automatic checks) and MAC Exists checks will be submitted to the controller in all lowercase and the response handled as such. This eliminates a potential failure point.

Different Topic(s):

  • Still working on the abilities to archive alarms and initiate a speed test. These commands exist and it should be possible to get a status of how the speed test is running also however I have not figured out quite the right structure yet. Rather than continuing to hold off longer I felt it was better to get this minor update out and keep working on it.
  • For those of you using this... is there anything in particular you might be interested in seeing from your controller or being able to tell it to do from your Hubitat? I have a couple more ideas... but they are pretty low priority to me. Otherwise the majority of features I could need are already here (I do not even need/want the speed test, just thought it might be nice to provide).

I'm happy to report that all features are now working as expected on my UDM (non-pro). Big thanks for all the efforts.

I think the CheckAlarms is bringing my hub to halt. I had polling set to 5 minutes. Then at some point, my hub locks up. After 5 minutes of loading, the devices page comes up, but then the Unifi API driver device wont open. I have to reboot and delete the device right after restart in order to get the hub back. I have turned polling to manual, and things work fine, but wondering if i have a high number of alarms or something causing this. I have just commented out that function and will resume 5minute polling to see if the same thing happens.

Let me know if that was the cause. There is a query for just a count of alarms. I could not see the point but maybe you stumbled on it. If there is some X number I could exclude pulling them in.

I have noticed some functions can take a noticeable amount of time if there is a lot of data coming in. Things like checking all the devices the controller has ever seen, or logs... So I try to avoid those.

Well i guess i always just ignored them. I just went into the unifi app and archived them all. I still set it up to run the latest version without alarms hopefully all good now. Will report back if i notice anything strange. Thanks!

sorry I wasn't clear, these were the lines I meant for the case sensitive potential issue, not the sends to unifi

unifi returns them in lowercase, but if on the device you enter them in all caps, the indexOf fails as it is case sensitive

if( MACPresence.indexOf( Json.data[ 0 ].mac ) >= 0 ){

change to

if( MACPresence.toLowerCase().indexOf( Json.data[ 0 ].mac.toLowerCase() ) >= 0 ){

and

if( MACPresence.indexOf( data.MAC ) >= 0 ){

change to

if( MACPresence.toLowerCase().indexOf( data.MAC.toLowerCase() ) >= 0 ){

also while I was testing this, I noticed that when I went over 5 macs, got error that "runEvery2Minutes" is not valid

this seemed to work, saw on another topic

schedule("0 0/2 * * * ?", PresenceCheck)

1 Like

Thanks to @jschlote for point out I had forgotten to get the toLowerCase in the Responses (I missed the two spots there after focusing on what got sent for it). Plus the note about runEvery2... I thought there was one. Oops.

Updated Version(s):

  • UnifiAPI.groovy = 0.2.3

Change(s):

  • toLowerCase has been corrected in the responses for MAC Exists and Presence detection. Now it should not matter what you enter for manual checks or automatic ones.
  • Changed the runEvery# lines around automatic Presence Checking into schedule items instead. I think I will just go with those in general, easier to deal with. Plus while there I made it so if you enter more than 10 MACs for automatic Presence Checking it not only gives you an error in the log but will pop a Status event so there is a greater chance of people seeing it.

Thanks again to @jschlote for the feedback.

Thanks @snell - I'm not sure what has fixed my authentication error, but it's fixed! :slight_smile:

The clients are registering with their MAC addresses as opposed to their device names, but that's fine, I can fudge that in the config :slight_smile:

I second @scottie.holden UDM [non-pro] is working without issue.

The child devices will always register with their MAC addresses because it is the most likely to be unique on the Hubitat. You can enter a name in the label... but... when it receives a successful response from the controller to an automatic Presence Check it is supposed to put the name provided by the controller in the label for the device. Of course, this assumes that the controller has a name.

Ah, ok, I think all my devices have an alias as the actual names weren't picked up properly. That could explain it!

If you do not mind, could you send me a trace log from when one of them is successfully detected with the presence? You can cut out all the MAC and other stuff you may want, but I want to see why the label is not being populated. I am populating it from the "name" field that is returned, which corresponds to the Alias on my UDMP apparently (one of my test MACs is the Hubitat I am using to develop this, so I know it will be online, another MAC is my cellphone which usually is NOT listed as online because it is not to a Unifi AP).

My Hubitat got it's label right away (because the controller says it is online) but my cellphone has not because the controller is saying it is offline (incorrectly, but I can only work with what the API tells me for this).

Not sure if this is the correct location, but since the lastest update to HE 2.2.5.120 I am having issues with the UNIFI controller login. I did get this every few days but would just go and click login and it would work again. Now this does not seem to work?

This is not 2.2.5 related. I also had this with 2.2.4

I am not having this with mine (on 2.2.4 or 2.2.5) so let me ask a couple questions:

  1. Nothing has changed about your Unifi password? You can login normally to the controller itself?
  2. Have you upgraded to the latest version of the UnifiAPI driver (0.2.3)? Did this happen before the upgrade or after?

I will have to change the logging a bit regardless to try to give more detail when there is an exception like that... but the overall problem should not be happening of course.

1 Like

Hi @snell

Yes I can login to the unifi controller fine. Yes mine is updated and was working okay, every few days I would have to go in and click login and it would work fine again.

Now it wont login at all. I am on the latest Unifi controller version 6.0.45 running on a raspberry pi 4b 4GB

Thanks for having a look.

@snell sorry, I've only just seen this, I'll try and sort something out for you...