Add support for listing all configured/known clients on the site

[nielsbasjes]

I needed a call where I can get all clients and with that their mac and if they are blocked or not. I was unable to find a call in your library that provides this.

I found that list_clients($client_mac = null) does not return the offline blocked clients (which I do need). The stat_client($client_mac) does return what I need but that is really slow as you need to do a call for every mac. Side note: The documentation on stat_client says the client_mac is optional but I found that not to work.

On https://ubntwiki.com/products/software/unifi-controller/api I found this:

rest/user | GET/POST/PUT | List of all configured/known clients on the site

As a quick test I added this to my copy of your Client.php and this delivers exactly the information I needed.

public function get_all_clients()
{
    $this->curl_method = 'GET';
    return $this->fetch_results('/api/s/' . $this->site . '/rest/user/' );
}

My request to you is to add this option to your library.

[malle-pietje]

Have you checked the output from the stat_allusers() method?

[malle-pietje]

If needed you can always use the custom_api_request() method to issue your own custom request.

[malle-pietje]

BTW, the $client_mac parameter for the stat_client() method is required, I will update the docblock with the next release to fix that. Thanks for spotting that.

[malle-pietje]

After a quick look, this call provides me the same results as the stat_allusers() method but without the ability to filter them:

$unifi_connection->custom_api_request('/api/s/' . $site_id . '/rest/user/');

[malle-pietje]

The challenge is we need to maintain backward compatibility and historically some method names (e.g. stat_allusers) are a bit odd. While I would like to change many of them, it is going to create potential confusion if we do so. Also adding yet another method to fetch client(s) details does not make things easier.

In the back of my head I'm thinking about a complete rework of the API client but that won't be a single file drop-in which many people prefer when working on small projects. And maintaining two clients in parallel is a bit too much for me...

[nielsbasjes]

I have controller version 6.4.54 and in my experiments I found that some clients are returned via the /rest/user/ but are not returned via the stat_allusers().

In my network it is 89 records from stat_allusers() and 114 returned records from /rest/user/.

I did quite some digging and I think (not sure) that the difference is in how long it has been since a client was connected. If it was been too long they are no longer returned by stat_allusers(). Note that for all of those I have configured something for them (a name, a fixed ip, etc.).

[malle-pietje]

I have controller version 6.4.54 and in my experiments I found that some clients are returned via the /rest/user/ but are not returned via the stat_allusers().

In my network it is 89 records from stat_allusers() and 114 returned records from /rest/user/.

I did quite some digging and I think (not sure) that the difference is in how long it has been since a client was connected. If it was been too long they are no longer returned by stat_allusers(). Note that for all of those I have configured something for them (a name, a fixed ip, etc.).

That makes sense, check the $historyhours parameter.

[nielsbasjes]

Yes! With this $unifi_connection->stat_allusers(400000) I now get everything.

Thanks!