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.
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:
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).
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.
Question about this before I go through the work of setting everything up. Will this happen to pull link quality information for connected clients?
I'm getting ready to add some additional APs. I have two Pro 6 APs centered in the house. My cameras on the corners of the house don't have the best connection, so I'm adding Lite 6 APs to each corner. I'm hoping I could just use this driver to get a point in time reference for connection quality before turning on the new APs. That way, I can make sure everything is still optimally connected afterwards. My thought is that I could end up with devices connecting to the Lite 6s with their 2x2 radios at a lower data rate because the signal quality is better.
Ok... bunch of stuff today so let me answer each person individually: @ritchierich: Hmm... Can you check the State Variable field labeled Model and let me know what it is? They may have introduced a different model name compared to the one I already had knowledge of. I can add the recognition in, but in the meantime you can just manually set the child device's Type to use the correct child driver. @keithandrewowen: Gotcha. I have an update I will be publishing in a couple minutes that should help. Basically I take whatever the Port X Status is already for the device and only change the fields that have values. If there is null data, I just leave what it had already. @FriedCheese2006: It does not at this time have signal strength. The data IS available (the API provides PILES of data), I just have not piled all of it in. I had already made changes to the Presence child driver to indicate which AP it is connected to (so you could set up a Presence check on the cameras for that). So it CAN do the basics of what you are asking for if you use the Presence Check capability. If you really want the Unifi "Satisfaction" value or "Signal Strength" I could probably add those in without TOO much hassle.
I have Nest cams, so no children for them. I'd be looking for signal strength across the board though. Just want to make sure something like my laptop isn't suffering too bad after installing the new APs. I suppose I could just stand up a new SSID to connect the Nest Cams too.
Either way, not worth the dev time unless you're just itching for something to do.
Changes to the Port X Status handling based on the data returned by the API and compared to what the child device already had (in case the API does not return all fields, it should not reset them to Unknown or null values).
The children would be for the Unifi parent actually. If you enter the camera(s) MAC addresses into the "MAC Address(s) to Presence Check" Preference, it will automatically check to see if they are present on the network on a regular basis. It will generate a new child device for each MAC address in this Preference, so you can readily use them specifically for Rules or checking yourself.
I actually have my smartphone checked (to know if I am home) and my main computer I use (even though it is wired, it makes for a good test subject because obviously it will be on if I am working with the drivers).
Port 08 Status : {Speed=0, Connected=unknown, PoE=unknown, Media=unknown, PoE_Status=unknown, PortID=8, Enabled=unknown, PoE_Usage=unknown}
In fact, now all the Ports give the same response, including the ones that were correct before. It's all just Speed=0, the rest of the attributes=Unknown
Port 01 Status : {Speed=0, Connected=unknown, PoE=unknown, Media=unknown, PoE_Status=unknown, PortID=1, Enabled=unknown, PoE_Usage=unknown}
Port 09 Status : {Speed=0, Connected=unknown, PoE=unknown, Media=unknown, PoE_Status=unknown, PortID=9, Enabled=unknown, PoE_Usage=unknown}
If you select Refresh on the child device's page (not the parent device, that does not get port data), do they remain incorrect? The ports are only polled once a day (since it is not expected they will change often) normally, as part of the RefreshUnifiDevices
Not seeing this behavior on mine after trying 3 different switches and my UDMP.
Just a word of warning (for everyone)... RefreshUnifiDevices (not the RefreshUnifiDevicesBasic) can take a LONG time to be processed and provided by the API because it provides a TON of data for each connected Ubiquiti device, what has connected to that, etc...). My setup (with 15 Unifi devices and ~60 clients) takes around 8 minutes.
UnifiNetworkChild-USW8PoE60.groovy = 0.1.0 (NEW, added to list in initial post)
Change(s):
Added support for Unifi Switch Lite 8 PoE. This will use the USW8LPoE child driver.
USW8LPoE driver modified to specifically control PoE on ports 1-4 (previously there were no constraints). Also changed the driver version checking code.
USW8PoE60 driver is actually a near copy of the USW8LPoE. Some people may have been using it before. If you have the older 8 Port PoE 60 watt switch, you should switch to this new child driver. Like the updated USW8LPoE driver, this now constrains the PoE ports that can be set. However on this device it was ports 5-8 (not 1-4) so a new driver was required to split this out better. The name of this device was not actually a Lite device all along, so I thought I should correct the naming in the driver as well.
Checked again this morning. Two of the Ports in use are now showing correctly
Port 01 Status : {Speed=1000, Connected=true, PoE=true, Media=GE, PoE_Status=auto, PortID=01, Enabled=true, PoE_Usage=4.62}
Port 09 Status : {Speed=1000, Connected=true, PoE=false, Media=2.5GE, PoE_Status=NA, PortID=09, Enabled=true, PoE_Usage=NA}
However, Port 8 now shows Connected=true (correctly) but shows PoE=true (incorrectly)
Port 08 Status : {Speed=1000, Connected=true, PoE=true, Media=GE, PoE_Status=off, PortID=08, Enabled=true, PoE_Usage=0.00}
For the rest of the Ports, they all correctly show Connected=false. I did notice, however, that they show a mix of Speed=10 and Speed=1000. I don't know if this is relevant (as they are all not currently in use) but they are all defined the same in the Controller
Edit: Just to confirm, this is the data from the child device. The parent is running 0.4.23
Not sure why 08 would list as true if it came back from the system as false. If you get a chance can you set the parent to Trace, run Refresh from that child only, and send me the log so I can confirm what the API sent back? You can immediately turn the parent back to your normal logging once you have it (it will say something like data from specific device or such, going by memory here not looking it up... ).
The speed is not so relevant as it is generally whatever the last thing that connected on that port was operating at, a bit odd that it would give a mix of 10/1000 if NOTHING is connected (and no 100 in there)... but that is the connected speed not what the port is set for (I think if you FORCE the speed, it will show that... but since most are just auto-negotiated you get whatever the client could do).
somewhere between 10 and 20 I think? What if it wasn't in the device's page but rather on Hubitat's app page that you could add a child to unifi? Something like the Konnected driver where you could do in batches of 5?10? and add as many children as you want there and that would track x number of devices. It would keep it from cluttering up the device page further but still add some flexibility and organization (One child for cameras, one child for iot devices etc?)
I haven't gotten into the programming for Hubitat yet (It seems there are no good guides on where to start, am I crazy?), so I am not sure how hard that would be to do. I can send screenshots of other apps that do it and what I'm thinking of if that would be helpful.
I do not have any apps developed... and do not really want/intend to.
BUT... 10 to 20 is not really that bad if that is all the particular child device focuses on. I will give it a bit of a test and see if I can provide something over the next few days.
).
