There are some additional attributes that will be coming in the near future as @vmsman and I discussed it a bit.
Any chance to add a restart function to the APs? The Home Assistant Unifi integration has it, so I know it is possible. Thanks!
I would not worry so much what Home Assistant can do but rely on what can be done using the web interface to the Unifi Controller.
Yes, I can add a restart because I know it is a feature there, there has just been no request for it before and I saw little value personally... I will look at it this evening and see if I can publish it along with the variable edits.
1 Like
I got a bunch of requests coded... so just going to let it "settle" until tomorrow to see if I catch any errors or such.
1 Like
Updated Version(s):
- ALL DRIVERS UPDATED
Change(s):
- "Driver Status" should now be removed the next time Preferences are saved on applicable child devices (finally)
- Almost every device now has a "RestartDevice" command which will restart that device specifically (per the API's method)
- Controllers have had some additional attributes "promoted" such as IP and Last_WAN_IP
- Rack mounted devices that have LCM (the little LCD built in) should now have Preferences to override the brightness, start, and end times
- Basic control of Etherlighting should now be working on the Pro Max 24, 24P, 48, and 48P
- Some additional data returned by the API is now handled
- UDMP controllers no longer have a child device Refresh Rate. After saving Preferences it will remove the scheduled task (I am not sure why this even had one, it might have been a "legacy" thing when I was testing device-specific refresh of data and I never bothered to remove it)
Note(s):
- I think I listed all the significant changes or features. As always, if something that was working no longer works let me know (sending me a message directly is fine as well).
3 Likes
Did the update and all looks well on my end. My UXG-Lite was added already as a generic child device and the new driver picked it up again (I had the generic child and the new one) so I removed the generic child one out the list. Super easy and I did not notice when when came so I imagine when the driver was added as I had changed the driver on the old one the other day with the update.
I noticed on my 'AC-IW' access point it shows up as a generic child device. I thought before it was showing up as a normal AP before.
I looked through the driver list at the top of the page here and sure enough it shows up as the AP that I had selected. I deleted it and refreshed the devices to load it again and it still comes up as a generic device. Not sure why that happened and if it is a change or not.
Here is a screenshot of what it shows today as I did not pay attention to it in the past to say if this is a changed behavior or has always been there.
No rush on getting the driver added / adjusted. It can be done whenever you have time and are ready to make it available. I appreciate your work on this project. Also here is the 'Tech Specs' on the AP in question: AC-In Wall
I am pretty sure I do not have any recognition built in for the U7IW yet, so thanks for the info. You might have better control if you switch it to the existing in-wall driver for the UHDIW (I have one of those myself). I will check the specs to see if it looks like it needs a different child driver made or it can stick with that one (like many of the APs share a driver).
EDIT:
Ok, so the AC-IW is the original in-wall AP prior to the one I have (which the labeled as the U6IW but has a model of UHDIW). The U7IW made me think it must be some new model that just launched supporting WiFi 7. From what I can see of the specs it is very similar to the UHDIW BUT only has 2 output RJ45 ports (but the same only-one with PoE). I hope to post a new child driver for it and update the API to recognize it shortly...
Updated Version(s):
- UnifiNetworkAPI.groovy = 0.4.60
- UnifiNetworkChild-ACIW.groovy = NEW, added to list in initial post
Change(s):
- Added recognition for Unifi AC In-Wall AP and a matching child device (due to the different number of ports it has than other models).
1 Like
I noticed just now that my old USG is detected as a generic device even though there is a specific driver for the USG. If I let it detect and install the generic driver, I can change it to USG and it gives me a few more options (like locate device options). Could the main driver be updated to properly detect and install the correct USG child app instead of the generic child device?
I thought I had that already... can you confirm what Model it shows in the State Variables? I am out for the evening but it SHOULD be a quick change in the morning when I get on my computer.
That explains it. The model shows UGW3 but the recognition is for UGW4 which is the only one I had seen before.
Updated Version(s):
- UnifiNetworkAPI.groovy = 0.4.61
- UnifiNetworkChild-UGW3.groovy = NEW, added to list in first post
Change(s):
- Added recognition for UGW3 to main driver and created a child driver for it since it is different from the UGW4
2 Likes
Greetings....
Updated for the AC-IW driver. When I first did the update I did not accept the driver (I did not come here to read the name of everything new) prior to update. I then seen the name and added it BUT it failed to take and 'rolled back' but I did not realize it. Threw a bunch of errors. I then added the driver back and it worked as expected.
I am now error free and all my devices are correct.
Regarding the U7IW it made me wonder for a brief second but I recalled on the UI forums someone looking for some info regarding regulatory naming stuff and mentioned that those monikers do not reference the generation of the gear as the hardware they was looking for was wifi 6e hardware yet it had the U7 flag the same as the other devices. I was shocked at that regulatory naming stuff being different than the device name / generation.
That is why I included the link to the UI tech specs page for the specific device because the u7 can very easily look like one of the wifi 7 stuff (even though there is only a single product out for it).
Thanks again for all that you do!
My in-wall is the one right after yours and is listed as a U6 In Wall (and has nothing to do with WiFi 6) but has a model name of UHDIW. Go figure. Sometimes the API model names are pretty close to the model names they put on their website and sometimes they are nothing like it.
If you load a "new to your system" driver it will not automatically change a child device to match it (it already has a driver even if it might be the wrong one or a placeholder). It can also just be switched in the Device Type on the child device's page. If you delete the child device it can be recreated so that would also get the new driver (or if you add a new driver before connecting a new device to your controller).
Yes. I have the Wifi 5 AC-IW that you updated as well as the U6-IW that was previously working as well.
Both loaded fine. BUT I discovered that everything did not load fine as presented before.
Turns out that 0.4.61 driver for network now constantly tells me that it is available yet hitting 'save preference' and 'save device' does not get it to update. I think that happened because when I loaded this update it gave a error and rolled back and I did not notice that happened until I looked at the logs to see that the AC-IW was not loaded because of a error and rollback.
The AC-IW is fine and the drivers for all of the child devices are fine. It is just the main network api that is not updating.
I tried a modify, repair, add/remove child devices, and nothing seems to get the driver to load. When I look at HPM it shows the driver is loaded under installed drivers but the device itself shows 0.4.60.
Any steps I can try to get it to load up?
Thanks in advance!
- ps these screenshots are from the NetworkAPI device for the first 2 and the last 1 is from HPM apps and drivers installed section *
Thanks for pointing it out... It was a mistake on my part. I forgot to update the version number in the actual code itself on line 246 of the parent driver. It was still reading 0.4.60 and causing that issue despite the code actually having been updated.
I have reposted it with the correct version in the driver. You should be able to import the driver again or you can change line 246 to read:
return "0.4.61"Sorry about that... of course I missed the most important version to set amongst all the changes. You could also ignore it for now until I come out with another new version in the future. The message will not cause any problems for things unless you have a Rule checking for it and bothering you further. It is only informational.
Ahhh okay. I noticed it was not 'impacting' anything but did not want to have a problem that is not a problem and later on cause another problem.
Glad that it was a simple thing to notice and address.
Have you tinkered around with adding a link to the forum and such to your drivers? I noticed when I clicked on 'View apps and drivers' section of HPM that other apps and drivers I have installed have links to their ' documentation | community thread | donate ' info. Not sure how often they are used by anyone if at all but may be worth having there if easy to add.
Thanks again for all that you do @snell
I do not use HPM myself so I am not familiar with all the options it has nowadays. The only reason I go through the annoyances of dealing with it is that many people DO use it and I was asked to start supporting it as a convenience for the users.
Ahhh okay. That makes sense. I am a recent Hubitat user and friend suggested I get 'the best hubitat app' installed. So far it has been fine. I have no complaints as I am not a power user and have any real insight into what is and is not good for a user experience.
Coding is hard work so I try not to be overly critical and nit-picky about things.
I am happy that your code works with it and I hope it was not too difficult to get it to work with it. I do hope that it actually makes some things easier for the developers by using it rather than more work.
Making that change on line 246 worked like a charm. I did not think about looking at it when you referenced it above but as I thought about it I said maybe you mentioned it as I could change it and sure enough it was easy to find and change.
Thank you again!
Until next time, continue to enjoy life and strive to not get too bogged down with things outside of your control!
No worries. HPM is not too bad to deal with, but it is some extra steps I need to do beyond just publishing the drivers on my website and posting about here. That always makes an extra point I can forget to do something or an extra version number spot I can forget to change. 
I put the line in case anyone wanted to change that one number versus just telling the driver to Import again from the driver's page (or HPM). Pretty simple any which way.
Plus, I always appreciate being told if something is broken, seems off, or whatnot. I will do my best to try to accommodate or solve it. Some (like the request timeout stuff some people have had) is not something I can readily solve in code but I think we got it figured out all working together. Adding devices in is another example. I have a fair size setup of Ubiquiti stuff but nowhere near what they offer (and keep introducing) so I always appreciate people bringing new devices in and letting me know/working with me to get it going.
