Unifi 4.0.3.0
Gen 1 Cloud key v1.1.13
Controller 6.0.45
Headline: I've successfully connected
Obstacles along the way:
1. Because it wasn't clear whether the plugin wanted the Cloud Key username and password or the Controller username and password, and I had lost my Cloud Key password, I reset the CK and restored from a backup.Without guidance telling me otherwise, if I'm omitting the port from the hostname, I expect to use the Cloud Key's credentials. Wrong, it wants the Controller username and password, not the Cloud Key username and password. Yay, I know my Cloud Key password now, thanks.
2. When I gave it the Controller user/pw at first, I hadn't read the other thread here that talks about turning off Unifi OS and Unifi Protect for G1 CKs. So I was getting a loop of HTTP 412 and HTTP 400 errors.
3. When I tried to disable the OS and Protect incorrect settings, I ran into a variety of UI and config ini data persistence problems. Specifically, if I shut these off then stopped and restarted the plugin, one of them would turn itself back on. This would cause the 412/400 loop as well.
4. After uninstalling and reinstalling the plugin 12 times, including deleting the \config\unifi.ini and its .bak, somehow I managed to magically get the right settings to persist and I won the lottery. The plugin was able to connect and not only pulled all the device, switch, access point and client data, but also retrieved a bunch of old devices from three networks ago. Turns out the Controller remembers clients it has seen forever and includes them in backups.
I'm going to speculate now. I think, and have no way to prove, that the reason why the settings were not persisting across shutdown and restart is due to a complex password. Specifically, one with a \r in it. I think when loading and processing the ini contents, this disrupted field to data alignment and the plugin would set the enable flags incorrectly.
Ridiculous? Well, when I "won the lottery" it was after I changed my Controller password temporarily to all alphabetic characters. Coincidence? Not sure, that's what I pay you $40 to figure out, eh? Now that I have data discovered correctly, I'm hesitant to return to a password as complex as the one I had until this is validated and if found true, fixed. If someone else is in a sporting mood and wants to see if this is real, have at it. It's a sunny day here and I've hit my geekout quota.
Gen 1 Cloud key v1.1.13
Controller 6.0.45
Headline: I've successfully connected
Obstacles along the way:
1. Because it wasn't clear whether the plugin wanted the Cloud Key username and password or the Controller username and password, and I had lost my Cloud Key password, I reset the CK and restored from a backup.Without guidance telling me otherwise, if I'm omitting the port from the hostname, I expect to use the Cloud Key's credentials. Wrong, it wants the Controller username and password, not the Cloud Key username and password. Yay, I know my Cloud Key password now, thanks.
2. When I gave it the Controller user/pw at first, I hadn't read the other thread here that talks about turning off Unifi OS and Unifi Protect for G1 CKs. So I was getting a loop of HTTP 412 and HTTP 400 errors.
3. When I tried to disable the OS and Protect incorrect settings, I ran into a variety of UI and config ini data persistence problems. Specifically, if I shut these off then stopped and restarted the plugin, one of them would turn itself back on. This would cause the 412/400 loop as well.
4. After uninstalling and reinstalling the plugin 12 times, including deleting the \config\unifi.ini and its .bak, somehow I managed to magically get the right settings to persist and I won the lottery. The plugin was able to connect and not only pulled all the device, switch, access point and client data, but also retrieved a bunch of old devices from three networks ago. Turns out the Controller remembers clients it has seen forever and includes them in backups.
I'm going to speculate now. I think, and have no way to prove, that the reason why the settings were not persisting across shutdown and restart is due to a complex password. Specifically, one with a \r in it. I think when loading and processing the ini contents, this disrupted field to data alignment and the plugin would set the enable flags incorrectly.
Ridiculous? Well, when I "won the lottery" it was after I changed my Controller password temporarily to all alphabetic characters. Coincidence? Not sure, that's what I pay you $40 to figure out, eh? Now that I have data discovered correctly, I'm hesitant to return to a password as complex as the one I had until this is validated and if found true, fixed. If someone else is in a sporting mood and wants to see if this is real, have at it. It's a sunny day here and I've hit my geekout quota.
Comment