Yes
Is that login setup as an admin login ?
Yes, it's set as a superadmin
Edit: I've confirmed I can access the gateway using the local login credentials
Meaning that you can successfully login via the web interface using those credentials ?
Like @kanewolf asked, can you get to the web interface of the controller from a computer on the same network that the Hubitat is on? That is actually what the parent driver is doing, replicating an account accessing the web interface.
The ping shows the controller is "live" (on an accessible network) but ping is a different protocol from the https that the parent driver uses.
All ports are open for the hubitat to communicate with gateway. When putting my laptop on the same VLAN as the hubitat (IoT VLAN), I can't even ping the gateway so the gateway rule seems correct. Attaching screenshot of firewall rule.
So the hubitat can "communicate", but it could to begin with since it got the "Unauthorized". The main problem would likely be with the account trying to do the communication. Since this is a newer setup it likely uses the "Dream Machine" style controller setting.
Does the account you are using have the "Restrict to local access" selection made? Here is a picture of one I made to demonstrate what the local account looks like from the web interface:
Yes, the local account is set up correctly and I've triple checked the password and just tried again with a fresh copy and paste
For the next thing to try, I would recommend setting the Unifi Controller Type to "Unifi Dream Machine (inc Pro). Many of the newer Ubiquiti firmware use that style of controller, even if the hardware is not a UDM.
Seems that did the trick! API now shows logged in! Time to start playing. Is there anywhere I should go to get you specific device info to add the UCG Ultra?
Also, under devices, I have both the virtual device I created and the API device showing after following your setup instructions. Is this normal?
No, that is not normal. The only device you should need to create is the parent virtual one. After that it will create child devices (if enabled in Preferences, or if you use Presence or ClientCheck capabilities) that are under the parent only. It should never create another one at the top level nor is the naming convention such that anything would have Unifi in it as part of the DNI. You can delete whichever one is not the one you are going to use. If you are going to use the Protect API drivers (I saw your note on that thread also), that is a separate set of drivers and will need a separate Parent/Child setup using those.
As for the UCG Ultra, if you enable child devices in the parent's Preferences, it will automatically create a child device for each Ubiquiti device it detects from the API. Once created you can check the child's information and find the Model within the State Variables. That is what I use as the identifier for device identification.
1 Like
@snell I was wondering if you've heard or seen anyone having issues with the lates code from Unifi and your controller code regarding the network presnse? after applying the latest update of your drivers? I am getting a lot of event triggers which is causing hubitat to trigger a issue with the device. It's odd cause the presnese of the network device doesn't change but for some reason it's coming across as it has.. it's really strange. I had to remove it from some rules I had as it was causing rules to fire off every minute when the device presense claimed it changed. I don't want to bombard you with event logs for the device unless you really need them, but I thought i'd just let you know something went weird after the last update. And yes, this time i actually validated the driver and updated it lol..
Unifi Drivers
- UnifiNetworkAPI v0.4.78 (driver)
- UnifiNetworkChild v0.2.10 (driver)
- UnifiNetworkChild-ACIW v0.1.1 (driver)
- UnifiNetworkChild-AP v0.1.8 (driver)
- UnifiNetworkChild-ClientCheck v0.1.8 (driver)
- UnifiNetworkChild-Presence v0.1.11 (driver)
- UnifiNetworkChild-UCGMax v0.1.1 (driver)
- UnifiNetworkChild-UDMP v0.1.11 (driver)
- UnifiNetworkChild-UDR v0.1.3 (driver)
- UnifiNetworkChild-UGW3 v0.1.1 (driver)
- UnifiNetworkChild-UHDIW v0.1.9 (driver)
- UnifiNetworkChild-US8 v0.1.4 (driver)
- UnifiNetworkChild-USAGG v0.1.0 (driver)
- UnifiNetworkChild-USAGGPRO v0.1.3 (driver)
- UnifiNetworkChild-USG v0.1.4 (driver)
- UnifiNetworkChild-USPM16 v0.1.2 (driver)
- UnifiNetworkChild-USPM16P v0.1.2 (driver)
- UnifiNetworkChild-USPM24 v0.1.4 (driver)
- UnifiNetworkChild-USPM24P v0.1.4 (driver)
- UnifiNetworkChild-USPM48 v0.1.4 (driver)
- UnifiNetworkChild-USPM48P v0.1.5 (driver)
- UnifiNetworkChild-USW24PoE v0.1.9 (driver)
- UnifiNetworkChild-UX v0.1.3 (driver)
- UnifiNetworkChild-UXG v0.1.4 (driver)
As always, thanks for everything you do!!
1 Like
I do not think that is an issue of the Unifi firmware. I made a bunch of revisions to my Event and State processing code due to some "strangeness" I found with newer versions of Hubitat firmware. Rather than relying on the device's state variable to determine if a value has changed or not like I used to, I am just sending the events straight through. In some cases (Presence is one) it always forces it to state that it is changed, although that has not changed from my prior code.
So... this is likely due to the changes in the driver code. I simplified it overall and rely more on the built-in checking for Hubitat. I would recommend making some changes to the Rules if possible. You should still be able to use "is Changed" but have a true/false variable (or similar) that remembers the previous state as a condition to determine if it really should trigger the rest of the Rule or not.
Right now things are "most of the way there". If it seems like the Hubitat is processing the events and state variables better then I may remove the forced "isChanged" notice on events, and that should solve this also (it would become fully reliant on the Hubitat to determine if it changed or not).
When my son comes home, his presence shows as here, but then quickly goes back to gone, then here, then gone for about 5 swaps on the latest updated. Hadn't had that happen before. It's happened yesterday and today, but only upon presence being here, not when he leaves in the morning.
Well, that is a new one to me... Not sure what change would cause that behavior if it "settles down" as opposed to what @steelz1 mentioned. Unless you mean it sounds pretty similar to that.
Couple questions:
- Have you updated your Ubiquiti firmware lately (or know if it has updated)? (Mine is a UDM Pro with version 4.2.4 and Network 9.1.112, from the Early Access channel)
- Do you have multiple access points that it might be switching connection between? (I have many, but I have not seen anything special with my phone switching)
I have seen this before, but it's more of when the device (your son's in this case) bounces on/off the wifi, and/or when roaming from one AP to another, but takes a little too long to roam to the next AP. Just my thought. I was able to validate this by looking at my unifi logs and matching them to the HE logs to see if there is more clarity from the unifi logs as to why the device may be "bouncing".
Another one i've seen is with my kid, there was a time when he was a little "younger" he would drop off the wifi and use his cell data to look at "other content" if you catch my drift, which also, caused the same issue.. This one drove me insane, so to get around this issue I made a virtual presence device for him and combined the HE presence and unifi presence from @snell's wonderful app/drivers to make sure "both" devices are present or not present before triggering anything. This helped quite a bit in his case.
Hope this helps.
@snell yea i figured it was something outside your driver code.. I just had to double check.. Yea i think i'm gonna have to undo the "Changed" trigger to specific present not present, which sucks cause the "changed" status was great on triggering only "IF" the status acutally changes. Sadly I don't know enough about the code side of things, but I'm betting I am just gonna have to change the rules and move on hehe.. Thanks again for the response.
1 - it is up-to-date, I'm on the latest early release
2- I absolutely do, but I'm also using presence plus to put a delay on it, so this threw me a bit
Seems once the device (phone) connected to WiFi and I started getting the quick here/away/here/etc notifications, if I went to the device in Hubitat and selected refresh, it stopped changing status and stayed as "here or present".
1 Like
Sorry for the delay getting the UCG Ultra identifier. Was having some issues getting all the devices to show and realized I didn't have the child driver installed for my wall AP. Got that installed and everything looks good.
The identifier for the UCG Ultra is "UDRULT". Any other info you need?
That should be enough. I will try to get an update with that recognized out tonight (~12hrs or so).
1 Like
