Question: my Current States list for the Unifi API device gets flooded with Presence Check messages that seem to accumulate forever and makes a REALLY long list. Is there any way to change this so that it only shows the most recent, or perhaps the 3 most recent presence checks? Or a clear button?
If you refresh the page all of those extra Presence Check messages will go away. This is a visual issue that I have raised with Hubitat but it is not going to be fixed (it is not directly them either, this is just an oddity of how all the background code IS supposedly). Basically it has to do with Events (attributes) that have spaces in their name (or some other characters). They WORK perfectly fine, and the most recent WILL be the value used for Rules or what have you. But they can build up visually on the webpage of a particular device if that page is left open (like Logs build up if left open).
MANY of my drivers have this issue because I went with easy to read names for many attributes (and did it for YEARS) before this was finally figured out. I am trying to reduce the number on future drivers, but rewriting all the attributes for existing ones (and causing all users to rework their Rules or such) would be a painful process.
1 Like
Ok cool. Thanks for the explanation. 
1 Like
Updated Version(s):
- UnifiNetworkAPI.groovy = 0.4.42
Change(s):
- Handling for additional parameters that could be included in Port Overrides. One of those exception fields I need to specifically identify appears to have been causing trouble for @arlogilbert. This should fix the problem going forward.
boom! thanks man, great driver!
1 Like
Turning a port PoE to off works, both in the interface and via maker API, turning a port to "auto" however does not seem to work. I saw a couple of is null errors around the isNumber on line 1021 of the UnifiNetworkAPI driver. Changed this line if(TempValue.isNumber()) to (TempValue && TempValue.isNumber()) which resolved that error, but still can't turn the port PoE back on.
Same issue for me using 0.4.41, either Null pointer exception on line 1021 or Bad request in logs.
Doing a Refresh and waiting a few seconds for it to update before every port POE change seems work better for me but I have reverted to older version for now.
Updated Version(s):
- UnifiNetworkAPI.groovy = 0.4.43
Change(s):
- Change to checks for SetPortState overrides, per @arlogilbert's mention above. I have no idea why this would do anything... but if it helps I will try to include it. If either of you (@arlogilbert or @Ortovox) or anyone else having this can send me a message with Trace logging of the parameters sent when they attempt to turn the port PoE on/auto, as well as the Port Overrides listed in the device, it would be appreciated. I still have not hit further problems with mine. Off/Auto are working properly. If this solves it and stuff is working again... even better I guess.
- Additional data handling was added overall... Yet some more new points (with little relevance) being returned by the API.
Other Topic(s):
- Further checking with Ubiquiti about the Power Cycle functionality... I have found it IS available... but only on ports actively using power. It will not show up on any other port even if there is a device there (if it does not actually get powered by PoE). I was missing it because it used to be available for all ports (I would swear) and I do my testing on a few specific ports so I do not "break" anything otherwise. I will have to set up a couple PoE test devices on it over the next couple days to recheck things on some different ports.
1 Like
A question only quasi-about this driver set.... I currently have an all-Unifi ecosystem: USG-3, a few switches, a few APs. Using this driver primarily for presence checks, though monitoring is always a plus.
I'm looking at switching to OPNSense for my router. Should I expect to lose any capabilities here with not having a Unifi router (and hence DHCP server), or will the controller still know about all clients from the switches and APs?
I use pfSense for routing. Unifi controller still works perfectly fine, it does not care whether the router is Unifi or not. You still have to use Network Controller to manage your switches, VLANs, WAPs, etc so everything else still works as you would expect. You CAN tell Network Controller that you're using a non-Unifi router and it will do it's best to count the traffic flowing across the switch, but doesn't break down what type of traffic it is (though I use pfsense dashboard instead of Unifi anyway)
You also can just tell Network Controller to use your OPN Sense or whatever as the DNS server and it should get hostnames from there if you still have any need for the Unifi dashboard and stats.
As far as THIS Unifi integration is concerned, it doesn't care about the router either. It still creates child devices for my Unifi switch and WAPs and I can control those devices just fine through Hubitat.
2 Likes
@a.mcdear: Thanks for providing the answer to @mbishop. I only have a Ubiquiti setup at this time so I could not have given a specific answer... but I will say the driver is just coded to access the API and provide some of the information and capabilities to your Hubitat. If the API is still accessible, the driver should not care what the actual environment providing that API is. Recognizing specific devices WITHIN that environment and providing features/data for them can be a different story... but I am willing to add more in as people provide samples so the driver can be improved.
Hi snell, are there any plans to create a driver for the Protect Sensor? It would be great to be able to use it for automation. BTW I have been using your drivers for my other Unifi components and it's been working great. Thanks!
I actually have a separate driver for Ubiquiti's Unifi Protect API. I felt it was better to separate them as they have very different purposes and report vastly different information.
For anyone curious, I also have a driver for the Unifi Connect API.
I did some investigation a long time ago into the Unifi Access API but did not end up making a full project out of it due to a lack of information (I still have no devices for it) and limited interest from others.
Thanks for the quick reply! I got the Unifi Protect drivers installed and will post in that topic going forward.
1 Like
Hi Snell,
I jus bought and installed a Unifi Dream Router (UDR), a relatively newer device very similar to the UDM, but with some differences such as two PoE ports.
I migrated my controller from a USG and Cloud key, and so far looks much better, but I’ve been looking for a driver for that specific device but couldn’t find it, so my presence function, for the moment, is not working.
Do you have any plans for a driver for this device?
Thanks for the great work you do for the community!
The UDR should work with the overall driver. To have the UDR itself as a child of the parent API driver, it would likely just need to be the generic child driver at first. I should be able to make an additional UDR-specific child driver (like I have for the UDMs) readily enough, however I will at the very least need the Model information. IF it gets added as a generic child device, it should be located in the State Variables list as "Model".
If not it does not get generated as a child you would need to send me a message with the trace logging for when you run the "RefreshUnifiDevicesBasic" command. Basically, if the parent device is working, set it for Trace logging, then run the command, and copy the logging (there WILL be multiple entries, you are looking for anything that starts with "Received" and has a pile of data). No problem if you just want to send anything/everything that gets received (feel free to edit any MAC addresses or other information you might not want me to see if you are worried about it). As soon as you get the log, turn the logging level back to Info (or None) so you do not continue to get piles of stuff logged.
Once I have the model info I can create a specific child driver and we can see about more specific functions/commands/data it might need or you might want after the fact.
As for Presence specifically... if the parent device is connecting to the API running on the UDR, it should still be able to use the Presence child devices.
If the parent device is NOT connecting to the API properly... that is a different scenario. You should be able to connect to a UDR's API with the parent's "Controller" preference set for the Unfi Dream Machine setting...
For the Community benefit, I´ll describe what worked for me after support from @snell on pm.
I just deleted the value I had set on Site Override and then everything worked as it should. The UDR appeared as another child device, with all correct values.
That Site Override value, on my previous Cloud Key, was necessary for it to work, but it seems it is not needed with this new router.
Updated Version(s):
- UnifiNetworkAPI.groovy = 0.4.44
- UnifiNetworkChild-UDR.groovy = NEW (added to initial post's list)
Change(s):
- Recognition of the Unifi Dream Router (UDR) has been added as well as a new child driver to handle it's information.
- Descriptions have been added to the Controller Type and Override Site preferences.
1 Like
Edit: I sort of take back everything below. I think 'Auto' is still working, but not as reliably as it used to work. I'm going to tinker some more and report back.
Edit 2: Auto definitely still works. What has changed at some point is how long the Flex takes to "recover" from a PoE Port State change - seems to take about 90 seconds before it's ready to receive another command and thus my "power on" command was falling on deaf ears. All good now, just something to be aware of.
@snell - I'm not sure when this changed, but the PoE State toggle on my USW Flex is now forked up (I'm sure UI's fault). Your driver turns the PoE off with no problem, but the 'Auto' command no longer turns it back on. I'm wondering if it's because they've changed it from 'Auto' to 'PoE+' in the UI (see snip below)? It would be especially annoying if you would need to add commands for PoE and PoE++ too.
USW Flex FW 6.6.34
Network version 7.5.187
This is just to show that UI's interface changes based on the capability of a particular port.
Well... I am glad it is working. Wonder why it might be slow. Is your controller fairly busy and delaying the API?
Obviously nothing has changed on the driver side in some time... so maybe they released new firmware that made a change? I know they did make it so PoE Power Cycle commands will only work on ports that have PoE actually in use (which made my testing of it a LOT more fun... not...) in a firmware a while back, so they do change stuff that can impact the overall functionality.
