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.
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.
@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.
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.
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.
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.
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.
FWIW, I've been using the Flexes for several years with my cameras, and power cycling the ports has always been a bit slow through the UI interface.
However, I've always felt that this is more of a UI Interface update issue than anything, and the feature seems to get tweaked fairly frequently.
In my experience, a manual disable, wait, then reenable of a port, wait, rinse, repeat as required has been the only "reliable" way to cycle port power.
Its also interesting to note that if a Flex is providing a high percentage of its max PoE power, then when power cycling a port, you may not get a successful power up.
My best guess is startup current may result in too much demand on the PoE source, and the port becomes current limited, resulting in a bad PoE negotiation with the end device, and a hung port.
Interesting... Hopefully this proves useful to someone. It would be possible to make a rule power off a PoE port, wait, and power it on versus using their power cycle command.
I wonder if having a longer delay in there would help it recover nicer?
Added recognition of the Ubiquiti U6+ AP. It should now be identified the same as the other APs that have a controllable LED (which is most), using the UnifiNetworkChild-AP driver.
U6+ correctly detected. I updated to 0.4.46, then ran a "Refresh Unifi Devices".
However, ther might be a wee bug in the gubbins someplace.
A new U6+ (AP f4:e2:c6:40:8e:aa), showed up in the child list, right under the old U6+ (Generic f4:e2:c6:40:8e:aa). None of the other children are duplicated,
The last update field is carrying a time of around 0715 this morning, while the new one (and all the other devices) are carrying a time around 1935, which is about when I ran the "Refresh Unifi Devices".
Seems like the old device link didnt get cleaned up. I haven't tried to delete it yet.
You can delete the old one freely. The new one generated with the new DNI, so does not replace the old one. I do not automatically delete children (except on uninstall) in case someone has Rules or other stuff that they are used to with the old child. This gives them a chance to switch it over and then delete them when they want.
On the flip side, you can delete a child at any time and it will be recreated automatically the next time there is data for it.
