Updated Version(s):
- UnifiAPI.groovy = 0.1.7
Change(s):
- Correction on line 262. I accidentally left the state.CSRF getting an it.value instead of the correct temporary CSRF that was being populated. This would possibly have impacted all non-UDMP use.
1 Like
I had a fun time debugging this with @snell and @Bago today.
If anyone is still having issues, try entering your site name as all lower case. The URLs of the requests built from them appear to be case sensitive.
1 Like
UDM Base, I updated to 0.1.7. I'm using "other Unifi Controllers". New error see below
dev:16992020-12-13 22:32:30.282 errorUDM - Exception when performing Login: org.apache.http.conn.HttpHostConnectException: Connect to 10.168.30.1:8443 [/10.168.30.1] failed: Connection refused (Connection refused)
dev:16992020-12-13 22:32:29.355 errorUDM - Exception when performing Login: org.apache.http.conn.HttpHostConnectException: Connect to 10.168.30.1:8443 [/10.168.30.1] failed: Connection refused (Connection refused)
Try the UDM Pro setting, @landon_webster
Changed it UDM Pro setting. Original error is back
UDM - Exception when performing Login: groovyx.net.http.HttpResponseException: unknown
What is the browser URL when you're using the Unifi web portal? Do you have SSH enabled on the controller, and are you using the username and password from the SSH settings (which might differ from your normal Ubiquiti website login)?
https://10.168.30.1/ I entered only the IP (http was not entered) Yes SSH is enable, I can SSH into UDM using the following (ssh root@10.168.30.1) I'm using the SSH root/password in the device preference.
It looks like I misspoke -- try the Ubiquiti SSO credentials (username and password for logging in to the web interface, not SSH). I was confused because my username is the same, but the password differs and my SSH password was rejected.
I can confirm the behavior @landon_webster is seeing on a UDM (non-pro). I am experiencing the same. I haven't been able to login since I updated to version 0.1.2 4 days ago. Prior to that version, I could login and see health stats, but could not use the presence functions.
Updated Version(s):
- UnifiAPI.groovy = 0.1.8
Change(s):
- Disabled the inclusion of CSRF in the headers and for the pre-poll checks as it just seems to be causing more trouble than it solved by including it. Hopefully this will rectify the issues people are seeing. Please let me know (of course it works on my UDMP but that is no proof for all the rest).
Lot of verbage for this one. If you do not want the background, just read the Short story, update your driver, and Save Preferences again or run CurrentStats.
Updated Version(s):
- UnifiAPI.groovy = 0.2.0
Change(s):
- MAJOR rework of how the Site is handled for the controller. The Site preference has been removed and an "Override Default Site" field has been added that is optional.
Short story: I remade it so that after you Save Preferences it will attempt to Login, then run CurrentStats which will pull in the site information for the first-listed site (typically the Default). You MUST run Save Preferences OR CurrentStats after updating the driver to 0.2.0. With this update it now has a Site variable that needs to be populated for features to work. So you need to run the Save Preferences or CurrentStats (you can refresh the browser page for the device to double check it if you want).
Long Story: It was discovered that what many people think they know for the site is not actually correct (I definitely did not know). Thankfully most of us were using the "default" site, which will work unless you made changes. The thing is... we see the site in our controllers as "Default". That is the DESCRIPTION (think of it as the device label in Hubitat terms). That is not really the site name. In most cases it will REALLY be "default". It does not look different but trust me it is when you are trying to poll the API. If someone changed their site name on their controller, what they did was change what shows in the description. The real site name behind the scenes is an alphanumeric string (there may be some logic to it but it looks random). Even without changing the site name this could cause issues for people if they had entered "Default" into the driver's previous site field and their controller was being picky about uppercase/lowercase.
So to help deal with this mess that the controller/api thinks is perfectly normal, I decided to do something. The driver will automatically attempt to get the basic site information when you Save Preferences. If you leave the Override Site field empty, it will just try to use default site information (ie: whichever site comes up first when CurrentStats responds). This allows people that have other sites to set it to check those instead by using the Override Site field so they could use multiple instances of this driver with different devices. For the average user, NONE of that matters. They have the default settings and want it to just work and now it should be easier. But it does cause a bit of an issue for people that already have the driver installed and in use on a device because they do not have the correct State Variable "Site" yet. That gets generated when you run CurrentStats (it gets it from the controller) OR Save Preferences after entering something in the Override Site preference. Once it is generated everything should be good and back to normal again. But if you just update your driver to 0.2.0 and do NOT get the Site variable created... all your commands will fail because it tests for the Site variable that you do not have yet.
2 Likes
Hey, this is great, I've got it installed and running against my USG/CloudKey Gen2+ and it's returning the number of devices etc.
I'm a little bit confused by the "child device" part though for the presence sensing - should I be creating these with the MAC address of the device, or the name I want to see displayed?
The child devices will be automatically created once their data comes back in a poll. So if you put the MAC(s) you want polled in the "MAC Address(s) to Presence Check" field and Save Preferences, it will try to check them from then on. Once it gets a response from the controller it will automatically add the child device and then keep the children up to date with their presence (so far as the controller says at least). It will even put in the name of the device (as shown by the API) as the label for the child. If you change it on your controller the label should change the next time it gets a response from the controller.
the ${ Site } was showing as null in the https string in logs
change to default in code manually and worked, changed to ${ state.Site } and still seems to work
still not getting child devices though
@jschlote: THANK YOU! You helped out a lot because it made me see I had forgotten to put the state in front of all the Site listings. It still worked on my test one because of the old Site variable floating around in the ether... This also made me discover that I had broken presence detection. I created a new device and found them to be working there. One thing to note, the Presence children will not get their labels unless there is a successful (present) response from the controller. Not-present responses do not include any device info.
Updated Version(s):
- UnifiAPI.groovy = 0.2.1
Change(s):
- Fixed Site listing througout driver to be the correct state.Site it should have been. Sorry folks, basic mistake.
- Fixed PresenceChecking. I consolidated it a bit before to reduce the duplicate code but did not realize I had broken it in the process by removing a needed variable.
I'm seeing an issue with Authentication against my USG?
If I click "login" and then click one of the buttons, the commands work.
If I leave it to run, it doesn't seem to log in properly?
Unifi Network - Unauthorized for PresenceCheck please Login again
Any ideas how I can help you troubleshoot this?
Are you logging into the USG or the network controller? It should be the controller (the IP where you access the web interface).
one other issue I noticed line 294
if( MACPresence.indexOf( Json.data[ 0 ].mac ) >= 0 )
the Json.data[ 0 ].mac was lowercase, I entered the macs as upper case on the device preferences, so was never matching, that is why no child devices were created for me, once I entered my macs in lowercase worked
@proffalken:
There is the bit from tomw... but the fact the button works but NOT the regular polling seems like there has to be a bug on my end a bit. I need to take a look and get back to you to see if I can think of anything.
@jschlote:
Good to know. I think I will remake it to be case insensitive (force it lowercase in the request itself and when checking the response) in the next version.
@snell, thanks for creating this
everything seems to be working for me, tested with cell turning off and on, worked as expected, I am using a UCK-G2
I set up a local user as read only to use on the unifi
1 Like
