UniFi Security Gateway


I’ve developed a sensor to monitor a UniFi Security Gateway/CloudKey setup.

The idea is that while the CloudKey is the place to delve deeply into the configuration and status of the network, my sensor provides a top-level overview to confirm that everything is operating correctly. If any sensors flag an issue you can then log into the CloudKey to resolve, so replicating the top level of the CloudKey controller:



Beyond the high level ‘ok’ of the sensor there are a bunch of other stats set as attributes, e.g for the WWW sensor:

drops                           9
gw mac                       fc:ec:da:02:d8:83
latency                        9
rx bytes-r                    3705
speedtest lastrun      1538603628
speedtest ping           9
speedtest status        Success
status                         ok
subsystem                 www
tx bytes-r                   3207  
uptime                       38651
xput down                23.157
xput up                      7.128

A template sensor can be setup to access any other specific fields that a particular user wants.

The component has needed an update to the pyunifi library which needs a pull request before that can be accessed by HA, so I’ll hold off publishing the code until then, but in the meantime wanted to check for any feedback from anyone else with a UniFi setup with regard to any suggestions on any other key info that would be useful.

Update: The PyUnifi library is now updated and the code can be downloaded here:


Very cool, would love to test this out. Just moved from pfSense to a USG and tying it into HA would be nice…


Nice work. Is is possible to pull data on if a firmware upgrade is available?


… if the WAN IP changes… Haven’t installed yet, maybe that’s there already ?


Let me know when you release it, I’d love to try it


The WAN sensor includes the WAN IP as one of the attributes so that is covered.

Firmware upgrades are a good idea, I’ll investigate.

I’ll be putting the code up at the custom_components github repositry https://github.com/custom-components. That way any updates can easily be installed using the custom_updater component.


Looking forward to using this, I tried to load the custom_component on the repo but it’s not pulling much info (looks like you’re still waiting for that version update)

Maybe the WAN sensor has it already, but it’d be great to be able to see if the WAN has failed over to the secondary WAN port on my USG (although I can probably take a good guess at this with the WAN IP if that’s not doable).


Yes the core data for the sensors is in a new function call only in the latest version of the library. The library needs to be updated on PyPi before HA can pull it down as a dependency.

Regarding the secondary WAN post status it may be in the attributes when the port is live, I don’t use the secondary port so can’t check, but sure we can add an extra sensor and decode if required.


The PR has been finalised now and the new version of the library (2.15) is available on PyPi so the component should now work ok. Please let me know any feedback.
Also if you are also using the Unifi device tracker I suspect you will need to setup a different login for this component, still need to do some testing on that area.


Thanks for the update - I’ve now got this working, I had to create a new user separate to my unifi tracker one as you suggested.

Should I be able to see my wan IP address? I can find it in my alerts, but only because it reports it as part of the information from my IPS when someone tries an exploit…



IP address is in the WAN sensor rather than WWW.


Thanks! WAN isn’t listed in the readme :wink:

I’m also getting a heap of errors on startup about once in every three or four times, and the component fails to load. Even with a dedicated login for this component.


Ah, well spotted, have added to the docs now.
If you can send me the error logs I will take a look see.


I have same problem half of the times.


I’ve been having similar errors recently too. Have not been able to identify root cause, but have added extra error checking so rather than exceptions being thrown an Error ‘no healthinfo attribute for controller’ will be generated instead.
Please update to the latest version and see if this is what you get.
Possible other things to check, there is a ‘system stats’ attribute for each user in the CloudKey admin console, try setting this.


If anything the number of times the component fails to load has increased. In addition the UniFi Device tracker will often fail to login too.

I suspect this may have to do with multiple components attempting to login at the same time. (In the last couple of days I have been running the UniFi Device tracker, the Unifi POE switch, the Gateway sensor plus a separate USG ssh sensor.

It would be useful to know from those of you with the errors how many other UniFi related sensors you have running.


I’m getting the errors a lot, about 50/50 now. If it floods me with errors, I reboot Home Assistant, and it’s happy, and stays happy. I have the UniFi device tracker set up (but don’t rely on it very often). For this component, I think I have all of them set up.



This is great! :clap:

Some things I’d like to see from the main dashboard:
internet capacity %
usg 3p utilization %
clients wifi (count)
guests (count)


Edit: I see these in WAN. I’ll try them out with a template…

gw system-stats
{ "cpu": "18", "mem": "40", "uptime": "112207" }

Along with WLAN’s “num user” and “num guest”.


Still seeing a lot of errors saying ‘no healthinfo attribute for controller’` constantly. I have the latest code from github and I am running 0.82.

I have checked that my user has access to system stats in the cloud key. I also have checked that I am using pyUnifi 2.15.

Any suggestions ?


It appears that sometimes on login, only approx half the functions are available via the library. Since we can accurately detect when this occurs (the no healthinfo attritbute error), the plan is to then logout, wait a few seconds and then attempt the login again.
So there will be an update coming soon, once I get some time to implement…