[PROJECT] Driver for Unifi Network Controllers

First and foremost, your UDM Pro SE was not detected properly by my driver and not given a child driver (see how it is labeled as Generic) because I have not seen one before and have no data to recognize it. If you would be willing, I would love a Trace log for when you run a "Refresh Unifi Devices Basic". That would give me the model information I can then use to start supporting it. Or you can just tell me directly about it... For example, my UDMP has a model value of "UDMPRO". I EXPECT the SE to be something like "UDMPROSE" or "UDMSE" but have no way of knowing. Once I get that I can build it into the parent driver AND create a child driver (based on the UDMP one, but also handling the PoE ports hopefully).

I have a separate topic for Unifi Protect... but I definitely have not put as much effort into it lately as I have for the Unifi Network driver. So when you have requests/recommendations for that one there, let me know.

1 Like

@keithandrewowen You should delete that post and PM it to snell directly.

1 Like

Will do :+1:

I should have given the why part. The logs have a raw dump of all your clients and network info. My recommendation was more to help protect your network info.

1 Like

I probably should have have been more specific. I mentioned the basic because the most people could see is your list of Unifi devices and their MAC addresses.

But all I REALLY need is that model info, you do not even need to send me a whole log.

No problem! Its late here, so I'll do it tomorrow :+1:

Hi @snell , thanks for the PM. As you said, it is UDMPROSE

The other issue I have at the moment is with the G3 Instant cameras. Child devices were created correctly, but the devices don't seem to recognise any motion events, even though the Controller does send me notifications are records correctly. I was hoping to use the G3s as motion detectors

For the Protect-related stuff we can discuss it further in the Protect Driver's topic, just to keep them separate. Long story short, I have a G3 Instant (my only Unifi camera) and it is working for motion detection using the Protect driver and WebSockets, so we can look into it more in that topic.

1 Like

Updated Version(s):

  • UnifiNetworkAPI.groovy = 0.4.21
  • UnifiNetworkChild-UDMPSE.groovy = 0.1.0 (NEW, added to list in initial posting)

Change(s):

  • Support added for Unifi Dream Machine Pro SE. Minor changes to the parent driver to add support for it only. Obviously the child driver is new and should support controlling the PoE ports (1-8) on the UDMPSE in addition to the "normal" UDMP capabilities and data.

I've applied the new version and my UDM Pro SE is now recognised as such in the child devices. However, the parent device is still utilising 0.4.20 version. How do I force it to use 0.4.21?

The Driver Version event (and state) will update if you Save Preferences. It will also be corrected within 24 hours automatically, the next time the parent performs the CheckForUpdate (it is scheduled to run daily).

Since your UDMPSE is now recognized and added as a child properly, then you have the 0.4.21 so you should not need to worry about it (let the automatic one happen).

1 Like

As you said :+1:

Capture

Sorry for all the questions, but I'm keen to get this fully working!

I notice that there is no info on the port usage. All of the ports report like this

In fact, Port 01 is in use with PoE, Port 08 is in use without PoE and Port 09 is WAN. The rest are currently not in use

That is the default values when they get generated. They SHOULD refresh at some point once the API provides information, although (depending on commands) it will often not provide ALL those pieces, so you might see some things remain unknown for a bit.

Here are two examples from a couple of my switches (1st is from my 48 port PoE and 2nd from a Mini):

  • Port 27 Status : {Speed=100, Connected=true, PoE=true, Media=GE, PoE_Status=auto, PortID=27, Enabled=true, PoE_Usage=0.00}
  • Port 28 Status : {Speed=0, Connected=false, PoE=true, Media=GE, PoE_Status=auto, PortID=28, Enabled=true, PoE_Usage=0.00}
  • Port 43 Status : {Speed=1000, Connected=true, PoE=true, Media=GE, PoE_Status=auto, PortID=43, Enabled=true, PoE_Usage=3.10}
  • Port 50 Status : {Speed=10000, Connected=false, PoE=false, Media=SFP+, PoE_Status=NA, PortID=50, Enabled=true, PoE_Usage=NA}
    AND:
  • Port 05 Status : {Speed=1000, Connected=true, PoE=false, Media=GE, PoE_Status=NA, PortID=05, Enabled=true, PoE_Usage=NA}
  • Port 04 Status : {Speed=0, Connected=false, PoE=false, Media=GE, PoE_Status=NA, PortID=04, Enabled=true, PoE_Usage=NA}

And indeed, I am too impatient! I suspect Port 08 will also refresh soon :joy:

  • Port 01 Status : {Speed=1000, Connected=true, PoE=true, Media=GE, PoE_Status=auto, PortID=01, Enabled=true, PoE_Usage=4.40}
  • Port 08 Status : {Speed=null, Connected=false, PoE=false, Media=null, PoE_Status=NA, PortID=08, Enabled=false, PoE_Usage=NA}
  • Port 09 Status : {Speed=1000, Connected=true, PoE=false, Media=2.5GE, PoE_Status=NA, PortID=09, Enabled=true, PoE_Usage=NA}
1 Like

Feature request:
I would love a secondary mac address checker that is less frequent. Basically I want to use it as a way to double check IOT devices remain connected (ie cameras) but I don't need it very frequent (every few hours? ). I also do want my phone presence to be the super fast checking of less than 5 devices still.

Basically, something that checks to ensure devices are connected once every few hours or maybe even a few times a day. Maybe called "heartbeat" devices instead of presence to differentiate.

1 Like

As a workaround, you could use a Rule to run a manual Presence Check. That populates the Manual Presence Result field on the parent, without creating additional child devices. An example of a result displayed is:
[Submitted MAC] is present as of Mon Aug 01 16:07:12 EDT 2022

So you could then parse the string for "is not present" or "is present".

Have to give it some thought about creating additional "heartbeat" child devices...

For whatever reason, I feel like it takes a while for it to actually update that field when I send the request manually. It might take ages to get through all my devices doing them via rules, but I might consider it when I have time

How many devices are you looking to check the heartbeat on?

The thing I worry about is the scale... There are a couple methods I could consider:

  1. Make child devices for each to "nicely" show the information it could bog things down there. But each one could provide it's information and it could EVEN allow individual refresh times (after initial generation of course).
  2. Make one child device that handles all "heartbeats". It would have a limited number of attributes (since attributes are not dynamic) so there would be a limit to the number of devices it could represent in Events (and thus accessible by Rules), although there would be no (real) limit to them as State Variables (if someone is willing to open the child device and check manually). Might be most useful to check the X number of most relevant ones for Rules. Refresh time would be for the entire set (it could be individual for the ones identified by attributes, but that would make for X number of scheduled tasks so I would prefer just one setting/refresh).

One I will not do is just pile these all (like method 2) into the parent driver... Defeats the purpose of trying to separate out most of the data from there as I have been doing with these drivers.

As for the current workaround... it really should not take too long. I usually get the result within a second. Although the parent device (if the page is open) often does not show the Current State as having changed (or it is added at the bottom of the list) until I refresh the webpage itself.

@snell Thank you for your efforts with these drivers! I just setup your drivers in my dev hub to test things out against my UDM Pro SE and other Unifi equipment. Everything matched up and child devices except my USW-Lite-8-PoE. Instead of using the UnifiNetworkChild-USW8LPoE driver, it used the UnifiNetworkChild driver instead. Happy to provide debug logs, etc.