These drivers are great - thank you very much.
One question, the CPU temperature on the UDMPRO child device seems to only update once every 24 hours for me - am I missing something?
The only thing I can think of there is that the temperature for it is very stable. My UDMP's temperature rarely changes.
But the slowest automatic refresh you can set it for is 3 hours, so no matter what (unless you set it for manual) the driver will be polling the UDMP for the temperature (and everything else) every 3 hours.
Thanks. If I look in the events for the UDMPRO child, the 'last seen' time and all the other stats have a timestamp of 04:26 each morning only. The controller stats refresh rate is set to 5 mins?
The CPU temp is changing each day, so that is working - want to monitor it as it is in the loft and may get a bit too toasty in the summer!
Ok, I figured out what was happening. I forgot this is how it works. The temperature is part of the Unifi Devices data NOT part of the normal CurrentStats. So it is not included in the refresh rate, but rather is part of the Daily Check. Since the Unifi Devices data is a BUNCH of stuff I did not want it to be done all the time.
So... I need to figure out a better way to do that. Running the main Unifi Devices check I do not think is a great idea (it really IS a bunch of data) as part of the refresh. So my current thoughts are:
- Make it so individual child devices can be configured to have themselves checked more frequently. The problem here is that I do not know if it is possible (I THINK it is) to have it only check for results from a single device...
- Make an override option so people CAN have it get the Unifi Devices data as part of the refresh, that way it is up to each person if it is causing issues or not.
It is too bad it is not included in the Unifi Devices Basic data... but it is not.
So thanks for calling this to my attention! I definitely need to come up with some workaround to provide it more frequently. One of the problems of having so many drivers I work on... I forget what can do what, especially as I slowly go through and replace old methods with newer (better) methods as I learn them.
Ok thanks. Glad I could add an extra challenge to your day!
1 Like
It actually is not turning out to be too bad. I have it working already as a method of querying a specific device from the parent AND/OR by setting a refresh rate on the child device itself...
I decided to make things more complicated for myself by revising the html tile Template included. Since Hubitat made it so you cannot include HTML directly in preferences anymore (as a code safety mechanism) I am removing those from the examples and renaming it so people do not think it should anymore. Of course I broke it in the process and am having to figure out what I did wrong. 
Updated Version(s):
- UnifiNetworkAPI.groovy = 0.4.12
- UnifiNetworkChild-UDMP = 0.1.4
Change(s):
- Parent device now has a command to make requests for data from specific Unifi devices using the device's MAC address. The controller can return a SUBSTANTIAL amount of data so this usually takes a bit before it can all be processed and displayed (which is why it only happens automatically as part of the DailyCheck).
- UDMP child devices can now be configured with a Refresh Rate preference which will result in them refreshing their device data (performing the Unifi device data request) at that rate. They also have a refresh command to perform it manually. Additional child devices will receive this capability as I update their device drivers.
- UDMP child devices have had their HTML Template method replaced. Hubitat removed the ability to directly put HTML commands in preferences (as a code-safety measure) so this method needed some revision. More work will likely be done on it going forward but this device now has a slightly altered (but working) method that excludes the HTML. I plan on making more changes to it going forward.
Wow that was quick! Many thanks. Will try it out now.
Working perfectly for what I wanted - many thanks!
What exactly did you do? Having the same issue.
Thanks
Updated Version(s):
- ALL DRIVERS HAVE BEEN UPDATED - This includes the parent driver and every single child driver. Too many to list and their versions, but they all were changed.
Change(s):
- All child devices now have the Refresh capability. When selected it will tell the parent to perform a refresh of just that specific device's information. In the case of Presence devices it will perform a presence check.
- All child devices have had their HTML Template method modified to be a more general Tile Template method due to changes to Hubitat's software that prevents HTML codes from being in preferences like what was required before. The attribute name has been changed and it now accepts commands structured much like the community where you put [] around commands rather than the HTML <>.
- Minor changes to the parent driver to support the refresh from the child devices.
So I installed the API driver and child drivers that I needed today via the Hubitat Package Manager. Got the API setup and it added child devices but I'm getting nothing but timeouts in my logs. Any ideas?
The child devices are generated usually as a response to RefreshUnifiDevices... so it is odd that there were failures for that one in there. It looks like this is just after the initial configuration and update... So (and no offense if these seem too basic and you already checked):
- Do you have the correct Unifi controller IP, username, and password entered in preferences?
- Do you have a site that is different from the default value of "default"? If so, did you enter that in preferences?
- Do you have 2FA configured for your controller or are you using local-only?
- No connection problems when you go to the controller's IP address in a browser, correct?
- Yes, IP and creds are correct.
- No, it's "default" site.
- No
- No, using both local and web portal I can access my setup and all devices.
If it helps it was "Refresh Unifi Devices Basic" that added the children and it is always successful while everything else times out. I'm also seemingly getting all other data.
UPDATE: I think I've figured out what's going on... Any query from the Hubitat drivers spikes the CPU on my UDM pro. The controller itself stops responding, thus the time out. Is this even meant to work with controller 7.0.23?
Well... That helps a bit. Interesting that the basic works, but obviously that does not help your overall scenario. If you go to the individual devices do their Refresh commands work?
Another possibility that comes to mind... do you mind sharing a list of devices you have on the controller (you can send it via PM if you want)? I know my stuff can take a bit (especially after I added my switch) due to the amount of information the Unifi controller returns. I wonder if in your case it is taking so long that the Hubitat's connection is timing out. Although some users do have a fair number of devices...
Check out my update to my last post. The problem is that whatever the API driver, or child driver, is doing is basically popping the UniFi Controller.
I have 14 network devices.
After hitting "Refresh" on just 1 child device:
HEAVILY EDITED after noticing the version you mention...
I just tried it on my UDMP with multiple different devices (ending with my 48 port switch which generates a PILE of data) and it did not seem to affect the CPU Load at all (it was varying between 18-21% the entire time even before/after I ran the tests). I have 11 devices plus a presence check, and my UDMP shows the CPU has stayed ~18% the last 24 hours, and that is with a 30 minute refresh cycle.
Since I use the exact same commands that a browser uses when accessing the Unifi controller I am not sure how this could be causing such issues (ex: when you click on the Unifi Devices icon, it calls the exact same API URL I call to perform the RefreshUnifiDevices).
All that being said, I am NOT running Release Candidate software. Ubiquiti has a bit of a history with funky firmware so I have always maintained at the Official release channels. That is version 6.5.55 for the Network.
But like I mentioned before, I am using the exact same commands their web interface uses and you do not mention any problems there. So... maybe they changed the command in that version?! Not sure how/why though... Then again this may be entirely fixed 7.0.xx becomes Official.
I am running 7.0.23 and do not experience these issues. No errors in my logs, no excessive cpu load. Clicking on refresh unifi devices only increased cpu load by 1-2. I have 18 unifi devices (9 of those are protects)
1 Like
@jkp:
Thanks for checking! This just adds to my lack of understanding for this one... I wonder what could be happening here for @cstory777's...
I read over the change logs for 7.0.23 (they do not have the "API" page posted for it yet, not that it covers much of use anymore) and nothing popped out to me that would cause an issue...
So... maybe something else is going on here? I wish I could compare what the two of you have enabled/running to see because there has to be SOME difference there. That release candidate has not been out for very long and I assume you both backed up your UDMPs and restarted them to make sure they came up "fresh".
Additional info:
Unifi OS 1.11.3
Switch firmware 6.2.6
