I've had no problems and no controller restarts since uninstalling the drivers. I'll keep them uninstalled for now, thanks.
Updated Version(s):
- ALL DRIVERS HAVE BEEN UPDATED - This includes the parent driver and every single child driver. Too many to list and their versions, but they all were changed.
Change(s):
- Most child devices required a correction to their Tile Template preference. While I changed the method in the previous version I forgot to correct the preference. It does not appear anyone NOTICED this bug... but it should now be corrected.
- All switches (or devices that provide additional ports like the UDMP or an in-wall AP) have had their port status reporting substantially altered. At this time they still have the attributes for each port but the data is now only provided as a state, not an event (to help minimize the mass of data). Additionally, each port now has much more information available about it rather than just is it disabled or not, or PoE or not. Hopefully this will prove much more valuable for those that want to look at such details on the device page.
- Applicable devices now have an Uplink attribute. This is very similar to the normal port information (and the data actually is only in the state fields, not events) but also says which port it is uplinked to and that device. Like the other port status this could be useful at-a-glance information.
Note(s):
- If you are having Unifi controller crashes like @cstory777 was, it appears related to when the driver polls the Unifi controller's Alarms. While at this time there is still no indication WHY polling that causes the crashes, there is a workaround already in place. Within the parent device preferences there is an option to "Show Network Alarm Data?" that is enabled by default. If you disable it and Save Preferences, the driver will no longer query for the alarm data. I have been unable to replicate the problem myself, even now that my Network version is updated to 7.0.23 (it is now on the Official channel). If anyone else runs into this, please let me know so maybe the root cause can be determined.
1 Like
I finally got around to upgrading the drivers this past weekend. Everything seems fine as long as I don't choose to get the "alarm data". The moment I turn that on the CPU on my UDM Pro spikes and crashes the unifi controller still.
1 Like
Crazy. Especially since it is now an official release (the did not even change the build number). Mine is having no issues even with the new version. I mentioned when I posted the new one for anyone to let me know if they have an issue with it. I would love to be able to figure out what the difference is that is causing yours issues... but so far it seems "unique"... the worst kind of issue.
Yeah, I wish I knew what it was but the second it tries to get alarm data it chokes. I've got no notices in the controller UI so I'm not even sure what data it may be choking on.
Hi guys, @snell,
For a few weeks/months I´ve been getting an alert from Hubitat System Messages (Upper right corner) alerting me that "Some devices are generating [excessive events]".
When I click on "excessive events", which sows in blue, it takes me to a new page where the Alerts are, and it is Unifi Controller device the only one on the report, with 232 events.
|Device|Events|
|Unifi Controller|232|
I already unchecked the Show Network Alarm Data, but the alert message keeps appearing.
Any ideas?
The excessive events are due to how many events the drivers are generating based on the data changes it receives from the controller. That will depend on how often you poll it and how much data it is putting events for. The Network Alarm Data has nothing to do with it.
There are a couple things you can do:
- Reduce how frequently you refresh by slowing the Refresh Rate. However, most people do not want to get data any slower.
- Change the event threshold. This is located on the device's page in the Device Information section "Too many events alert threshold". You can change it all the way up to 2000. My parent device is set to 300 and I have not seen the alert since doing that.
As a sample, I have 14 Unifi devices and ~50 online clients (>100 known) although I only have 1 device being polled for presence. My refresh rate is set for 30 minutes.
The Excessive Events Alert they added has been a mixed thing in my opinion. I already knew which devices of mine were "spamming" with the worst being a Tuya sensor I CANNOT control (even though I wrote a driver for it, it does not accept changes to it's refresh interval... thanks Tuya for doing custom things over the ZigBee protocol...).
Sorry for my delayed response.
Yes it worked, and was easy.
Thanks
1 Like
No worries about the delay, people get busy and home automation is USUALLY something lower priority. 
Glad to hear it helped!
Hi - two questions regarding this driver. I did read through most of the messages so sorry if I missed the answers:
- What is the primary purpose of this driver? Is it to extend keeping tabs on the network beyond what the unifi controller already does? Or does it go beyond that?
- Will this work with the controller hosted on a windows machine, using an Edge Router and unifi APs and switches? I don't have a UDM or a USG.
Thanks!
-
Originally it was to detect presence of devices on the WiFi (so I could see if a smartphone is home or not). Since then it has evolved in capability as I have gotten more Ubiquiti hardware and learned more about the API. Now it allows your home automation if to control aspects of the Unifi hardware (and functions). An example I have is that I can control the outlets on my Unifi Power Strip, control my Unifi Power Plugs, and can use the APs for status lights (by controlling the color and whether their status LEDs are on). Some people have also used the options to control their PoE ports on their switches or such.
-
It should... I would think. It would not hurt to try as the basic install of it and such only READs data from the Unifi controller (whatever it may be). It does not attempt to control anything unless you start doing that yourself.
2 Likes
Ah - using the LEDs on the APs - now that is cool!
Depends on where they end up (whether it is useful or not) but it was something I was interested in when I found it was possible.
Very useful controller. I'm looking forward to turning off POE to some of my non essential APs at night. Thank you!
One problem that I have is that when I use the switch "Set Port State" command and enter a port number and set the state to either auto or off, all 24 of my custom Port names get wiped out and set back to "Port x" and all 24 of my custom POE settings get wiped out and set back to POE/POE+. Am I doing something wrong or is this a limitation of the functionality?
Device Driver: UnifiNetworkChild-USW24PoE
Device Driver version: 0.1.3
Model: US-24-250W
UnifiNetworkAPI version: 0.4.15
Sounds like a goof on my part. I think the response when a command is sent only is for the port in question... but I might be passing it through a check that is meant to deal with all the ports. Since there is no other information it might be just setting the values to default.
If my guess is correct, this should not actually affect the switch itself and the data should be corrected on the next refresh.
I will have to look over it this weekend. My switches should show the same behavior readily.
Awesome. Thank you for checking. Sending "Set Port State" for Port 4 did actually change the settings on the switch. I have the names set to things like "6: 1st Floor Office" and have PoE turned off for any ports that don't needed it. When sending the single Set Port State command to Port 4, all 24 of them changed back to their original labels (e.g. "Port 6") and PoE state to on in the Unifi Controller. Appreciate you taking a look when you get a chance and for this amazing driver as well.
Edit: additional information: Port Profile is also reset to "All". (For example, if a custom profile or network are set, they are returned to the "All" value after Set Port State = auto is run.)
Well that is DEFINITELY not good nor intentional, thanks for the additional information.
So I did a check of what the Unifi API does on the controller itself... and it is not fun. Basically any change sent to it needs to include EVERY port "override" for any port. If it does not receive that information, it just assumes the other ports should be default values. Every other thing I have dealt with before retains everything but what you are changing. This one is different. Since I did not label my ports and typically was just using a single port for testing I never noticed it.
Figuring out a way to deal with it right now.
1 Like
Very strange behavior by the controller. Sounds like you'd have to load all current values and then send a "change" to each port with the existing settings, sans the actual one wanted changed. Sounds like a heavy lift so if I'm the only one affected after 1 and a half years of smooth sailing with the controller, probably not worth the effort. Thanks again for the contribution!
I think I MOSTLY have it figured out. Basically I am keeping a state variable with the current port overrides (sorry, will not help prior to it receiving them from the API the first time) on the child device. When a port command is now set it checks if that exists, and if it does it works it's way through it adding each port into the overall command to be sent. If it hits the port you are changing (if you changed it before) it will copy most of the information except the port state (which will be changed to the desired state).
It worked once I got it on one child device... but is being a bit more finicky with my 48 port switch... so I am not publishing it until I have been able to test it more.
I also found a bunch of new attributes in the API data (mostly irrelevant) but I am adding those in as well, and trying to do some better command handling. Lots of cleanup as usual.
1 Like
Updated Version(s):
- UnifiNetworkAPI.groovy = 0.4.18 (I did not realize I never published 0.4.16 or 0.4.17 until now)
Change(s):
- Rework of how Port Override data is handled as well as changes to the way Port State commands are processed in order to retain existing port overrides (such as a Port Name). I recommend refreshing a device after applying this update so that the device SHOULD generate a Port Overrides state variable, but this will only occur if you have configured any ports so that there IS an override needed.
- Change made in 0.4.17 to support millisecond-based epoch reporting
- Change made in 0.4.16 to add units to temperature reporting.
Note(s):
- Switch-based child drivers will be updated in the near future to better clarify port related commands.
2 Likes
