I have an issue logging in UISP via the app.

I have an account I can log into without any problem when i'm using my laptop. However , when i'm trying to use it on a smartphone ( Android ) , I systematically have credentials errors. I have tried to use both e-mail and usernames , change the password , but nothing changes.

Is there any other solution to try out ?

Regards ,

Are there plans to support read-only accounts in the UISP application on the Android system in the near or medium future, or only administrator accounts?

On IOS when I log in to AP and select active stations, I can see all of devices names and signal, but my colleagues with Android when they try the same thing, they see site and signal instead of device name and signal. I tried to find some hidden option in UISP for android, but no luck.

Any idea what are we doing wrong?

this is asite I no longer have access to as it has been handed off to the cusomer.

Uisp mobile version 2.39.2

iOS version 26.1

Surely this is a customizable field now but I can't seem to figure this out. Any super guru's here have same issue and figured this out?

TIA.

A want to now if there is a way that the notification on the UISP local server can let me now if network go down on the mobile app?

I can't seem to get rid of the Inactive Users error in CRM therefore I'm not getting user data usage. This is driving me nuts, I've deleted and started from scratch and still can't get it to work properly. I'm paying for this service so it's very frustrating. It won't allow me to change user location which is the problem I think. Any suggestions?

Thanks

The UISP Mobile app (v3.3.18 on Android) is making changes to the radio system.cfg that doesn't make sense to us. To remove ourselves from the equation, the below testing was done on a default Powerbeam 5AC Gen 2 radio running v8.7.17 (explicitly the non cs version).

Powerbeam 5AC Gen2 radios come out of the box with PTP mode enabled by default. This is shown in the config as radio.1.ptpmode=1. If you use the webGUI to disable PTP mode, the ptpmode config changes to radio.1.ptpmode=0- as you'd anticipate given it's default value.

But, if you use the UISP Mobile app to make the same exact change, disable PTP mode on a default radio, the ptpmode config changes to radio.1.ptpmode=disabled. Same for when you enable PTP mode via the Mobile App, the config value changes to radio.1.ptpmode=enabled. This isn't inherently an issue on it's own, but what ends up happening is if you now make a change to any other setting in the radio via the webGUI, the radio's configuration parser seems to view the radio.1.ptpmode=<string> configuration line as incorrect and will revert it to an integer. This subsequently causes an outage to the connection since the fast radio script build fails and it performs a Softrestart instead of a Fastrestart, even though the boolean itself isn't technically changing values (false to false):

-radio.1.ptpmode=disabled
+radio.1.ptpmode=0
Unsuported change in radio.1.ptpmode for fast update
Fast radio script build failed
ubntconf -p returned 252
ubntconf returned 0

In addition to the above example, the UISP Mobile app appears to cause a number of configuration lines to be removed from the system.cfg that the radio had added itself, even when the change you made was unrelated to those config lines. If you then make a change to the radio using the webGUI, it adds these lines again. It seems like the configuration parser built into the radio is fighting back and forth with what the UISP Mobile app applies. An example of this:

Radius config lines were removed when I made a change to the radio's SSID via the UISP Mobile app (I've only included related config lines from the entire diff):

WA# cat /var/log/ubntconf.log
--- /tmp/.running.cfg.11342
+++ /tmp/.system.cfg.11342
@@ -1,8 +1,3 @@
-aaa.1.radius.acct.1.port=1813
-aaa.1.radius.acct.1.status=disabled
-aaa.1.radius.auth.1.port=1812
-aaa.1.status=disabled
-aaa.1.wpa.psk=0000:0000
 aaa.status=disabled
-wireless.1.ssid=uisp
+wireless.1.ssid=uisp2
-wpasupplicant.profile.1.network.1.ssid=uisp
+wpasupplicant.profile.1.network.1.ssid=uisp2

These config lines then get re-added when I make the same exact change to the SSID via the webGUI:

WA# cat /var/log/ubntconf.log
--- /tmp/.running.cfg.27910
+++ /tmp/.system.cfg.27910
@@ -1,3 +1,8 @@
+aaa.1.radius.acct.1.port=1813
+aaa.1.radius.acct.1.status=disabled
+aaa.1.radius.auth.1.port=1812
+aaa.1.status=disabled
+aaa.1.wpa.psk=0000:0000
 aaa.status=disabled
-wireless.1.ssid=uisp2
+wireless.1.ssid=uisp
-wpasupplicant.profile.1.network.1.ssid=uisp2
+wpasupplicant.profile.1.network.1.ssid=uisp

RE: how this impacts us, we give our install technicians pre-configured radios, which essentially use the base Ubiquiti config file with some config values modified for our network. If the install tech uses the UISP Mobile app to associate a radio to an AP, it changes what was a perfectly accepted configuration by the radio. Later, if our support team goes and makes changes to a radio via the webGUI, they will unintentionally cause a service outage for a setting change that shouldn't cause a service outage. @UI-Team- this seems like a bug rather than a feature. Happy to supply any additional information needed, but this appears easy to replicate.

I click the + sign next to the word "Standalone Mode" at the top and add my domain name and credentials but it doesn't work.

Iv been at this for a while now and have given up therefore I am asking the community.

My UISP server is self hosted and of course reachable outside my network.

Thanks,

Shane

Gallery feature is 1,000x better, it actually works like it's supposed to.

Unfortunately there is a fatal bug in the app. Tower sites are only showing our UI switches. No radios at all, and no 3rd party devices.