Completely fair! 
Some day, I will figure out what language they use and pull enough from other apps to figure out how to do it myself. My biggest worry is my security cameras, None of them actually notify if they go offline, so I'd like something so I know if they do.
Is there maybe a way to return a list of all mac addresses connected? Would be easier to parse a singular list than make calls for each individual device and shouldn't be too complicated of a button to put on
There is a function to poll the clients list... but it returns a massive amount of data (I only poll it once a day for the driver).
In the meantime, I would recommend putting a Presence Check for your security cameras' MAC addresses. Right now the driver allows up to 10 MAC addresses in there (that is arbitrary on my part, I could not think of many reasons for more than 10 when I wrote it AND I thought putting too many might punish the API). 1-5 devices will get checked every minute. If you enter 6-10 it will only check all of them every other minute (again, in case it caused excessive load for the controller). You can always remove them (and the child devices it will create) once I have a "heartbeat" child driver (have to think of a name for it as well).
I considered doing that, but I want our phones to poll every minute while the cameras only need to be every few hours. Maybe while my husband is off next week I can look at a child app that runs on top of your driver
Updated Version(s):
Change(s):
Client 1: {Status=Online, Speed=1000, Signal Strength=-64, Connected To MAC=00:00:00:00:00:01, Connected To Name=AP1234, SSID=YouWish, MAC=00:00:00:00:00:00, Last Seen=Sat Aug 06 17:30:43 EDT 2022, Name=HappyDevice}The fields for the ClientCheck attributes are as follows:
I have tried to create a client check device. I added 2 MACs to the list, but neither of them seem to be getting any data. I confirmed they can be seen from the unifi side. Any ideas?
Has it run the scheduled task to query them yet? It does not run it immediately upon saving preferences, so they will only have the default values (as displayed) populated at first.
If it HAS run the scheduled task (which it should be coming up on, since you posted this ~1 hour ago the forum says)... then there is probably a bug somehow that I need to look into. Let me know if it had the full hour, and if you could a screenshot (or send me a private message) with what the scheduled tasks look like as well.
Yeah, I waited a full day to try to be sure. Guess I should have mentioned that initially! I think this is the scheduled tasks you are asking for?
Well, that is a bummer. That is exactly the information I was looking for, and it APPEARs to be all correct. Ok...
Before I start asking for Trace logs I have one other question... How are the MACs formatted in the preferences?
For example, here is mine (I changed numbers and letters, but they are all still in the style). It should not matter upper/lowercase (as you can see from mine).
23:79:1c:2f:12:5d;34:22:AB:13:74:7C
That's how they are formatted. In the morning I will try (toddler depending) copying the Mac from one of the devices I am already (successfully) getting presence on to verify it's not a typo in the Mac somehow
Thanks! If it is some formatting issue then I will still be curious about what the difference(s) might be to see if it is something I can account for.
If it is not a formatting issue... the next step is to enable Trace logging on the ClientCheck child device to see what data is being posted to it from the parent device.
If THAT does not give any clues I will have to add some additional logging back into the parent driver since I did not leave it all in once I proved it is working on my system. Oh well. 
MACs I had looked fine, I replaced them with a direct copy/paste from my presence MAC, doesn't seem to make a difference so I don't think it's formatting.
This is all I get when I turn on the Trace level logging and run the check specific client. I will DM you the MACs so you can sanity check my MACs 
The MAC addresses looked fine so far as I could tell. Since the copy/pasted versions from your Presence does not work either (but the presence checking DOES...) there is something else going on here.
This error seems to be that the command was not recognized... but it is ALMOST the same as the Presence one (which works), so that is odd. I will have to provide a temporary driver with some extra logging...
Updated Version(s):
Change(s):
Updated Version(s):
Change(s):
Hi @snell, I'm giving this a try and I am getting unauthorized for everything but the 'CurrentStats', that's successful and if I press the login button I get successful. But Presence, RefreshAll, RefreshClients, CheckAlarms all show unauthorized. It's gotta be something silly I'm missing but I don't know where to look, any ideas? thanks
PS: all the groovy code (base, presence child, and AP child) was loaded this morning so I should be up to date.
EDIT: It turns out that my site name is not actually the one needed by the Override Site field. After combing through the response data from the general query, my custom site name was actually the 'desc' and the 'name' was just random numbers and letters. Once I put the 'name' into the Override field everything logged in and worked fine. Maybe this is a known thing and I missed it. But at the end of the day it is working. In case there is a difference in my setup I'm running the Debian controller on an RPi,
I'm migrating Unifi controllers, and the new instance is exposed on port 443 instead of 8443, but it still uses the legacy interface so just flipping the controller type preference doesn't work.
What I wound up doing was adding a preference for port number, then flipping all the occurrences of :443 and :8443 to :${ UnifiPort ?: 443} and :${ UnifiPort ?: 8443} respectively. I would send a PR, but I don't see a Git repo. Happy to send privately, if you'd like; or would you consider a parallel change?
I will add a preference in to support Port if the "Other Unifi Controllers" option is selected. It should be posted this evening.
All of my drivers are hosted on my own website so there is not a Git repo available, I am happy to take recommendations or feedback in the threads or as messages.
Updated Version(s):
Change(s):
I have installed this driver on both my c5 and c7 for testing and it appears to works quite well bringing info in. I haven't tested fully as of yet though. One thing I noticed was with using this driver, my hubs dramatically slow down operations. I am using Hub Mesh for some lighting control where it would normally take approx 1 sec for lights to trigger on, it took almost 10 sec. I'm not sure if there is a polling setting I didn't set properly or what might be going. For now, I have removed the devices from my hub until I have more time to test. Any insights as to what settings I might need to set? I was using this driver mainly for USP-PDU testing.
I have not heard of anyone having a slowdown on their hub from these, that I can think of. There was a case where someone's UDMP was getting overloaded (we never did figure out why) when the Show Network Alarm Data preference was enabled.
The first (and foremost) things you can do to reduce the load are:
Beyond those two there are the Presence Checks and Hourly Client Checks, although neither of those really create that much data.
The big item for data is the Daily Check. But that only happens once a day (based on when you Save Preferences, you can see it in the Scheduled Tasks at the bottom of the device page). It only happens once a day but it queries a couple things that can return a lot of data depending on your Ubiquiti devices.
The USP-PDU should be fully supported (I am jealous, I STILL have been unable to get one) so let me know if you have issues involving it.
As for the slowdown... if you could check the Logs - Device Stats and App Stats... maybe something in particular will stand out there as using a lot of resources.
Download the Hubitat app
