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.
A big thank you to @snell for this great driver. It worked on the first try and I was able to reduce the load by changing my old unifi driver for yours.
With that said, the only annoyance I'm experiencing is with the presence function. I just replaced my phone and I had to change the content of the presence field. When I updated the mac addresses, it replaced all the child presence devices with the mac address. By doing so, all my rules using the presence devices are broken and I have to redo everything.
Is there something I'm not doing correctly? Every time it happens I have to update with rules with the new device.
You could set your phone to not use a random MAC. Most versions nowadays seem to randomize the MAC provided to access points. Meant to help security and privacy... But since the phone manufacturer, OS provider, and any apps have FAR more access... How valuable is it?
In any case, if you set the phone not to use a random MAC anymore it should be fine. There is not really a good workaround because that MAC makes it seem like a different device in the API.
My phone does not randomize mac address at home. This is not the problem.
I had 2 mac addresses in the field and I replaced one because I replaced my phone. The driver did remove both child device and replaced them with the default presence child devices. It broke all my automation that were based on those devices.
Would it be easier to create a child presence device with the mac adress as a parameter? The old unifi driver I was using did not have that problem because it would create a child device with each mac addresses entered. If my phone changed, all I had to do was to change the mac address to check.
I cannot check tonight, but I will try to check tomorrow, because it sounds like a bug actually. I do not think it should delete the child devices even if you change which MAC(s) it should be checking... I generally try NOT to delete any child device automatically except on uninstall. To specifically not break any rules or such.
So if you changed the MACs to check for in the Parent device Preferences and it deleted the child devices when saved, I do not think that should happen.
Sent a message to @bi0hazard to check if they were using a particular setting. I DEFINITELY found a bug in the code (and am working a fix for that right now) but I want to make sure it is what was causing the problem mentioned above.
Fixed a bug where Presence and CheckClient child devices were being deleted when Preferences were saved if you had the Show Unifi Devices as Children? Preference disabled. It was supposed to ignore those children and delete any other child devices if they exist (in case someone had this enabled, then disabled it). So this is now working properly and even if you have this feature disabled those child devices will not be deleted.
@snell I have a strange question (at least it's strange to me for some reason).. What is the delay between a presence device disconnecting from the network, to the time that "device" in your integration updates? I only ask cause i'm trying to offset some "issues" with HE native presence app and your integration to make a more solid virtual presence device that is used to trigger/update rules. I've got a good start on this with your integration, and your integration has improved my presences detection by leaps and bounds combined with the native HE presence which is between "ok" and "so-so". I currently just am trying to get some "timing" worked out and i'm noticing (at least on my setup network/integration/HE) about a 3 minute delay between the time a device drops from the unifi network, to the time your presence device updates, but then once it does my rules run immediately. So I guess I am just trying to figure out, is it my unifi network taking that long to realize a device dropped to let your integration know, or is the integration/check take a few mins to update, or a combination?
Regardless of what it is, I don't think this is an issue in any way as I can adapt for the "delays" wherever they may be, it just makes it easy if i can say exactly where the delay is. BTW I am so enjoying the integration you've created, so thank you.
The presence check is a scheduled check on the Unifi API, based on the number of devices you want to check (so it does not negatively impact the Unifi Controller). If you have 5 or less it checks once a minute. If you have 5-10 (the max) it checks every other minute.
The second factor is when the Unifi Controller itself decides the device is no longer connected. THAT I do not know. I have seen devices report as connected even though I have physically disconnected the wired ethernet (let alone WiFi stuff) but other times I have seen it report almost instantly.
Cool!! so i only have 4 device macs, so 1 mins, that is perfect.. so my guestimation is 3 mins for unifi, cause it takes 4 mins for it to trigger!! That’s perfect, thank you. now i can adjust things accordingly!!
I think that fixed my problem.
Well to be 100% transparent, my wife's cellphone was doing random mac. It might have been the reason why it deleted the child device in the first place or it could be multiple factors including the one you fixed in the last release.
I just updated the driver, and replace my wife's non-random mac with a fixed one, and the old child device stayed, my own phone stayed and the new mac adress was added.
I know for a fact that when this happen, it's always a corrupted database, especially on Cloud Key Gen2 devices, the database is easily corrupted when it gets too big. You need to follow the procedure on unifi website to prune and repair database.
I have never had it happen consistently and it has always resolved itself before it bothered me much. But it IS annoying if it happens when I am testing so I will have to keep the process in mind.
Additional data handling to account for some new variables returned (since Ubiquiti released an update to the Network app/API). Unfortunately neither seemed significant, but at least they will not show up as a debug log entry anymore.
