I have an open ticket since Sept 25th regarding our UISP instance performance and reachability. We have had issues all weekend and after several reboots its still running off. I am posting here to see if there is anyone who can respond to my ticket please. #6007081 I believe is the ticket number

There is currently an issue in the CRM where if an account is placed on suspension due to non-payment, the invoice for that entire billing cycle is pushed onto the account instead of the prorated bill up to the time of suspension. This then requires that the account be manually credited from the date of suspension to the end of the billing cycle or the date of reconnection. This is causing unnecessary work due to additional steps becoming required to maintain the accuracy of the balance on the client accounts in the CRM.

There is a critical routing/validation limitation within the UISP CRM API endpoint PATCH /api/v1.0/clients/{id} when attempting to update custom attributes.

If a client record has an existing record/value stored for a specific customAttributeId (even a blank string initialized via the Web UI), the PATCH payload executes perfectly. However, if the custom attribute has never been touched or initialized for that specific client, the backend entity manager fails to find a database row index for that sub-resource, causing the entire API call to reject with a misleading 404 Not Found or a structural mutation failure.

Because POST /api/v1.0/clients/{id}/attributes throws a 405 Method Not Allowed, there is currently no programmatic way via the API to initialize a brand-new custom attribute for an existing client unless the data is manually input or saved via the frontend Web UI framework first.

This completely blocks large-scale data migrations from external data systems into UISP via scripting.

Reproduce

1. Create a Custom Attribute in CRM Settings (e.g., ID: 21).
2. Create or find an existing client that has never had data typed into this custom attribute via the UI (the "attributes": [] array returns empty on a GET request).
3. Attempt to add data to this attribute by sending a PATCH request to /api/v1.0/clients/{id} with the payload:

{ "attributes": [ { "customAttributeId": 21, "value": "TestValue" } ] }

Expected Result: The API should dynamically initialize/insert the missing attribute relation into the client database profile.

Actual Result: The server returns a {"code":404,"message":"Not Found"} response.

is there a way around this? May we request if this can be updated, the validation/ORM logic for the /clients/{id} endpoint. If a PATCH or PUT request contains a valid customAttributeId that exists globally in the system but does not yet exist for that specific client entity, the backend should perform an upsert (Insert if missing, Update if exists) rather than dropping the request with an unhandled 404 entity error.

Access points and stations on firmware 8.7.25

The API endpoint /devices/airmaxes/{id}/config/wireless is returning the incorrect "mode" string for Airmax devices.

On a PrismStation 5AC, that API endpoint returns the "mode" as "ap-ptp", even though it is actually set to PTMP.

On a Litebeam 5AC, that API endpoint returns the mode as "sta-ptp" instead of "sta-ptmp". If you use that endpoint to update the config with "sta-ptp" as the mode, the Litebeam accepts that config and disconnects from its AP because it is now in the wrong mode.

@UI-Team

Attachments:

• Screenshot 2026-09-21 233848.png
• Screenshot 2026-09-21 234632.png
• Screenshot 2026-09-21 234912.png

It's a plugin in CRM that connects to UISP via API. It as admin access to UISP so you can change AP channels from the plugin.

Click the plugin icon and open the map, and it will open this tool. It uses free ESRI world imagery satellite data, but you can connect Google Maps data with a free Google Maps API key in the plugin settings.

You can see on the left panel you can swap between your 60GHz and 5GHz networks. It has every AP in your network placed by its internal GPS coords, and the heading is estimated based on customer location on the AP. Each AP is color coded to a specific channel. Solid color means full channel; diagonal lines mean half channel. The tool takes terrain data into consideration (it pulls terrain data from Amazon - they have free terrain data available to the public for some reason. That being said, this may only work in the US), so you can count on the tool's coverage estimate to be pretty accurate. APs that are highlighted with a dotted yellow line show a channel conflict with another AP in your network.

You can toggle the map between full color map and b&w so it is easier to distinguish channels. You can toggle backhauls on/off. You can enable customer location icons and customer links to better visualize what your network looks like. I have them disabled to protect our customers' privacy but works great to better see where there could be self-interference, or if there is a better AP that the customer could be connected to.

If you click on a sector, will bring up the following information.

Here you can see the tool doing math to find the best possible channel for the AP to operate on. You can select the recommended channel and hit apply, and it will change that APs channel to the recommended channel instantly. The map updates once every 30 seconds, so you'll see the change apply to your map shortly. This is what a clean, conflictless AP looks like.

The tool takes lots of variables into consideration to establish an opinion on the conflict severity. It has a 3-tiered conflict rating: Low conflict, medium conflict, and high conflict. It creates a conflict rating based on AP heading, overlap, channels used (and channel width), whether GPS sync is enabled, AP heading, azimuth and vertical beam, surrounding terrain, customer locations, among a few other variables. Here you can see it taking the 3 degree vert beam of the Wave AP into consideration.

It will also show you relevant information about your network in the bottom left hand panel that UISP may miss.

It works by populating all of your sites into the tool, you can scroll and select each individual site, and you show and hide individual APs so you don't get overwhelmed with the amount of data on your map.

It has changed how we channel plan, and it is AMAZING to be able to visualize the Wave network with a color-coded system.

I am working on getting Wave 5GHz backup radios into the tool, but haven't cracked that egg yet.

For your AirMAX devices, it pulls the data that you have input into the radio - since most of UI's 5GHz APs have SMA connectors. You can update the antenna type width, gain, ect. You can see here that 5GHz operates similarly:

The information card shows information like:

• GPS sync
• Client count
• Beamwidth of AP
• Distance to furthest client
• square km's of coverage area, ect

You can also edit information about the APs, and the information that you manually put in will trump the data that the tool pulled from UISP in case UISP has something wrong.

This is not a replacement for UISP by any means, it isn't magic, and it may get some things wrong - but you can use it as a trustworthy tool to help you channel plan more effectively. PM me if you want the tool and I'll email the zip file to you. If you don't like something about it, you can upload the zip file to Claude and it can make any changes that you'd like.

It's important that we all channel plan as accurately as we possibly can not only so we don't shoot ourselves in the foot, but also so we can be good neighbors. Thanks!

UISP 3.0.159

Console 5.5.0

It seems that the UISP Console that the "Maps" are being blocked by the provider. Just happened to notice it today.

Environment

UISP Application 3.0.159 (self-hosted), ~240 EdgeRouters (ER-4 / ER-12 / ER-Lite / ER-10X) with the web UI moved off 443:

set service gui https-port 9443

Problem

UISP always links to the device as https://<ip>/ – in the devices list (IP Address column), in the device panel (Overview → IP Address), on the dashboard, and in the ⋮ → "Open Device Web UI" action. For every EdgeRouter that uses a non-default GUI port the link lands on whatever is on 443 (nothing, or a different service). There is no place in UISP to tell it the port.

The information is already there: UISP keeps the router's config backup, where the port is a single line (service gui https-port N), and airMAX/airFiber/Wave already get an httpsPort back from POST /v2.1/devices/{id}/iplink/redirect – EdgeRouters are just not covered.

Request

Any of these, in order of preference:

1. Read service gui https-port from the EdgeRouter configuration and build the link with it (zero configuration for the user).
2. A per-device "Web UI port" field in the device settings, with a global default under Settings → Devices.
3. At least a global default for EdgeRouters.

Same applies to service gui http-port if the link protocol is ever made configurable.

What we do in the meantime (for anyone in the same situation)

Two edits in the frontend bundle (public/assets/index-*.js inside the unms container), re-applied after every update:

• the IP link component (href: \${protocol}://${ip}/`) → append :9443when the device type iserouter`
• the "Open Device Web UI" action (window.open(\https://${ip}`)`) → same condition, same port

Other device types are untouched (EdgeSwitch stays on 443, airMAX/Wave keep the SSO redirect).

It works, but it is a hack on a minified bundle – hence the request.

A feature that could be added in some future version of UISP, in CRM part. The idea came from a way Starlink is charging or billing a special plan: enterprise plans, called "Priority" plans: "Local Priority" or Global Priority".

Starlink charges in a "Priority" plan by consumption, by GB. I don't know if globally it is the same, but at least it is here in Mexico: amounts of 50GB (one could choose some fixed 500 GB amounts monthly, cheaper by half per GB, and later add more amounts in 50GB steps).

It is a charge based in consumption.

In Residential plans Starlink still charges by a fixed price, with ToS and Fair Policy obviously, trying to mitigate the use of a Residential plan traffic outside of the house that contracted it. It is a mess of course: here in Mexico Starlink is almost only used by WISPs, putting Starlink residential antennas in their towers and exploiting at its max a residential data plan. Just in these months Starlink started to stop that, and is starting to restrict the Residential line when it reaches 5TB.

But the idea is that kind of charge: by consumption. I have been thinking a lot about that and all the useful implications it delivers if also used in residential service.

Residential internet could be charged the same as electricity is charged; by consumption, and stopped being like it is today: a fixed, calculated price. Which generates some problems when trying to offer high speed to the house for a better experience: high speed like 100Mbps, or more, now that ISP industry tends to deliver gigabit plans: Google for example delivers now up to 8 Gbps in its Edge plan. We offer high speed, but then need to mitigate by different ways the misuse of a residential plan as reselling or distributing by other ISP, which could be a mini ISP or a mini WISP who is entering this business.

If we charge by consumption in residential plans, then we could totally kind of forget about if a person or group of people or business could and would use a line to do its own mini business of delivering internet to neighbors or neighborhood; or becoming the wisp of his/her zone. We could offer of course a special plan for that, delivering tools for that guy or group who will be an isp, even mini (neighborhood): public IP, dedicated customer service, etc., what a dedicated (1:1) isp delivers. But our infrastructures would not be abused or overused by this mini ISP that sometimes is hard to discover and mitigate, mini (or big) exploiters of Residential lines (whose prices are calculated for use of devices inside a house).

Charging by GB, with still competitive GB prices, could mean this:

• You house are sharing your WiFi with your neighbours, no problem, you pay for the use they do, for all that traffic that goes and comes from your modem, from your line; it's not to you asking them for cooperation $ or not, or you have the money for all that use. It's like installing, in a 1-installation time, 3 houses or 4 houses, if a house is sharing with 2 or 3.
• You WISP guy are using this residential line of 500Mbps to deliver to another 10 or 20 houses and you know it's difficult for me to notice it or find it is you: no problem, you pay for all that traffic of all those houses. It's like installing in a 1-installation time, 11 or 21 houses at once.
• Etc.

We could have at last control over all that that becomes sometimes a headache to avoid: TTL, conntrack, constant monitoring of consumption, try to know how many and which are the devices (models, names, stuff) used in the house (just to know if over there could there be a router which could mask hundreds of devices as one), reducing speed if we offer "unlimited data" and try to control misuse by reducing speed if funding a "wisp" house, etc.

We could rest about all that: you want to do it (resell, share with neighbours), then do it. I could still offer you a dedicated line for that (reselling), better than a residential line with kind of "generic" customer service, attention mixed with hundred or thousands, instead of dedicated or more focused. But we can rest, because our infrastructure is gaining the proper revenue from all that traffic distributed in all those "hidden" houses.

Imagine electricity charged by fixed monthly or bimonthly amount... that doesn't happen (at least not here in Mexico) because control of all that energy could be totally a mess: a hosue would stop being carefully with lights and use, with consumption, or would install as hell more load into the house without need and caution. Electricity is charged by consumption, right. Or an electrical company could just calculate the max use of a house and charge a fix monthly amount: Your meter is 100amps or 200amps, then I charge for those 200amps you could use or potentially use: it's up to you to put thick electrical wire and all electricity stuff well installed to consume if you want up to 200amps. But not, not useful an viable it seems. So it is charged by consumption: you used very few energy this month, then you pay very few; you used a lot, then now you have a great pay to do.

Internet consumption, internet traffic into the house could be charged the same way.

Well then, UISP could have an optional feature or function to create plans whose billing is by consumption: Maybe by amounts of 50GB, 100GB, 200GB...; or first amount 400GB and consequent amounts in 50GB steps, or do it in a way we could choose any first X amount and stepped X amounts: we could set a first 400GB, 300GB, 350GB, 1TB... and subsequent steps of 50GB, 100GB, 20GB, 1GB, 500GB...

Do I explain myself.

Charging by amount would help a lot,

For a special first great advantage, to deliver high or highest speed possible with more peace of mind, without the need of some special ToS or Fair Policies that try to mitigate misuse of residential lines.

• UISP Application 3.0.159 (self-hosted, Docker), upgraded from 3.0.151
• EdgeRouter devices (EdgeOS), Device → DHCP → DHCP Leases table
• Reproduced in Firefox and Chromium-based browsers, clean profile, no extensions

Steps to reproduce

1. Open an EdgeRouter in UISP → DHCP tab → DHCP Leases.
2. On a row of type Dynamic, click the ⋮ menu → Make static.

Expected

The "DHCP Lease" dialog opens with DHCP Server, IP address and MAC address prefilled from the selected lease (this is what the action is written to do, and how it used to work).

Actual

The dialog opens empty: DHCP Server shows the first server in the list, IP address and MAC address are blank, Save is disabled. The user has to retype everything from the row.

Root cause (from the shipped bundle public/assets/index-*.js)

The makeStatic action does:

CY1 = n => e => new Promise(t => {
  const r = e(KDn(null));                     // dialog lease = null (add mode)
  setTimeout(() => {
    const i = [
      e(ZDn()),                                // open dialog
      e(k_(zU, "serverName", fd(pTe, n))),     // redux-form autofill
      e(k_(zU, "ipAddress",  fd(nWn, n))),
      e(k_(zU, "macAddress", fd(eWn, n))),
      e(Eoi(zU, "leaseId", "ipAddress", "macAddress"))
    ];
    t([r].concat(i));
  });
});

and the lease form (leaseAddEditForm) does:

componentDidMount() {
  const { lease: e } = this.props;
  this.props.initialize({
    serverName: zr(null, pTe, e), leaseId: zr(null, uTe, e),
    ipAddress:  zr(null, nWn, e), macAddress: zr(null, eWn, e)
  });
}

The app is mounted with React 18 createRoot, so the store update from ZDn() is batched and the dialog (and the form inside it, which is unmounted while the dialog is closed) only renders after the whole setTimeout callback has run. By then the three autofill actions have already written the values into the redux-form state; the form then mounts, componentDidMount calls initialize() with lease = null, and redux-form's INITIALIZE reducer replaces values with the new (empty) initial values. Result: empty dialog. This is deterministic – it does not depend on browser or timing.

The same action/form code is present in the 3.0.151 and 2.4.220 bundles, so this is not a 3.0.159 regression; the ordering assumption (dialog renders synchronously before the autofills) is what stopped holding.

Fix (verified on a live 3.0.159 instance)

Minimal: let the autofilled values survive the initialize:

this.props.initialize({ ... }, false, { keepValues: true });

Cleaner: don't race the mount at all – put the lease data into the dialog state when opening (e.g. KDn({ serverName, address, mac }) with an explicit "create" flag instead of null), so componentDidMount initializes from it and no setTimeout is needed.

Suggestion while you're there

Prefill Lease ID from the lease hostname when it passes the field's own validation (^[\w\-.]+$), e.g. by replacing whitespace/invalid characters with -. Most hostnames are valid IDs and it saves retyping.

Workaround for other users until it's fixed

Type the four fields by hand from the row (select the server explicitly – the preselected one is just the first in the list), or create the static mapping on the router itself (Services → DHCP Server → View Leases → Map Static IP), or via the API: POST /nms/api/v2.1/devices/erouters/{deviceId}/dhcp/leases with {"serverName","leaseId","address","mac"}.

How do I do that? There has to be a way to do it apart from starting all over with a new site/location (including spending hours on fixing the topology when third party equipment is involved and losing all statistics)!

My self-hosted UISP refuses to update M5 CPEs. This applies to both M5 CPEs connected to AC sectors AND M5 sectors. AC CPEs connected to AC sectors work without an issue. In the update tab it simply says "Same version as AP", however it is not same (for example CPE x.6 while AP is x.24). Attaching a screen of an example.

While I don't have a lot of M5 devices, so manual upgrading wouldn't take a huge load of time, I'd obviously still prefer for them to take place automatically during the night.

I'm not sure whether this is an issue or my end or an issue in the UISP application, so I'd love to hear some information about this.

Found a bug in customer service reactivation.

When an expired or ended service is reactivated, the service does not reactivate successfully. The issue is related to the discount start and end dates.

For the reactivation to work, the discount start date and end date must either be set to the current date, a future date, or left unset entirely. If the dates are set to a past date, the reactivation fails.

Even when “No Discount” is selected, the system still picks up and validates the discount dates, which causes the reactivation to fail.

During the reactivation process, no error message is displayed. Instead, the page simply loops back to the reactivation page, giving no indication of what went wrong.

The underlying error and actual cause of the issue can only be viewed through the browser's Developer Mode/Developer Tools. There is no visible error presented in the application itself.

Version: 3.0.159

on my selfhosted UISP (VPS Debian 13).

Warning 'adm...' failed to log in to UISP from 146.70.52.244 Today 1:06
Warning '3as...' failed to log in to UISP from 146.70.52.244 Yesterday 23:42
Warning 'arc...' failed to log in to UISP from 146.70.52.244 Yesterday 22:15
Warning 'ara...' failed to log in to UISP from 146.70.52.244 Yesterday 21:31
Warning 'aop...' failed to log in to UISP from 146.70.52.244 Yesterday 20:02
Warning 'Adm...' failed to log in to UISP from 146.70.52.244 Yesterday 19:18

I'm facing a problem where the system log is absolutely flooded with devices disconnecting and reconnecting to the UISP application (self-hosted version). I can confirm that during those short outages UISP has connectivity with the devices (pinging from the host goes through).

I really wish to utilise the system logs in a meaningful way for our wireless clients, such as getting to them and fixing a problem before they reach out to us about it, but in the current state it is near impossible to do so.

So far I've tried increasing the ping interval from 30 seconds to 120 seconds but that doesn't do much. The network traffic doesn't go past a megabit per second (outside of update time), so I don't think the connection is oversaturated.

Is this a known bug in the self-hosted UISP application or maybe there is something wrong with the devices? Has anyone else had the problem and perhaps found a fix? Thanks a lot

Hi,

Currently, when changing the price of a plan, the change can either be applied immediately or from a predefined date.

This can result in invoice adjustments where the price change takes effect partway through a customer's existing billing period. In Australia, this is generally not the preferred approach. Pricing changes are typically implemented from the customer's next clear invoice period, rather than requiring a mid-cycle adjustment.

It would be extremely useful if a plan price change could include an option to:

Apply the new price from the next invoice billing period for each customer.

For example, if a customer's billing date is the 15th of each month, changing the plan price would automatically apply the new price from their next billing period beginning on the 15th. A customer billing on the 24th would have the change applied from their next billing period beginning on the 24th.

Current workaround

At present, the workaround requires us to:

1. Create a new, identical plan with the new pricing.
2. Manually locate each customer using the existing plan.
3. Change each customer's plan individually.
4. Set the effective date to their next invoice period.

This process becomes extremely time-intensive as we have to make several thousand plans adjustments 1-3 times per year.

Requested functionality

Ideally, when changing a plan price, we would have an option such as:

• Apply immediately
• Apply from a specific date
• Apply from each customer's next billing period

Selecting “Apply from each customer's next billing period” would automatically schedule the price change for each customer based on their individual billing cycle.

This would eliminate the need to create duplicate plans and manually update every customer, while also avoiding unnecessary mid-cycle invoice adjustments.

We would greatly appreciate this functionality being considered. It would make managing large numbers of customers and implementing standard annual pricing, and ad-hoc changes significantly more efficient.

Thanks.

Hi,

I'm noticing that we're starting to have some customers with a large number of closed services in UISP.

We still need this historical information to remain available and accessible. However, we don't necessarily need all of the closed services displayed alongside the active services on the main customer account view.

As the number of closed services increases, the customer account page can become quite cluttered and display a significant amount of information that isn't currently relevant to the customer.

Could we please request a couple of small features to address this?

1. Global default setting for closed services

An option to globally select the default view for closed services:

• Hide closed services by default
• Display closed services by default

When opening a customer account, the selected global default would determine whether closed services are displayed.

2. Display / hide closed services button

Within an individual customer account, it would be useful to have a simple button or toggle allowing the user to:

Display Closed Services

or

Hide Closed Services

For example, if the global default is set to hide closed services, the customer account would initially display only active services.

The user could then select Display Closed Services when they need to review historical services.

Once they leave the customer account, the view would return to the configured global default. Therefore, each time a customer account is opened, the closed services would either be hidden or displayed according to the global setting.

Suggested default behaviour

I would imagine that most users would prefer closed services to be hidden by default, with the ability to quickly select Display Closed Services when historical information is required.

This would keep the main customer account view considerably cleaner while ensuring that no historical service information is removed or made inaccessible.

It seems like a relatively small UI change that could make customer accounts with a large service history much easier to manage.

Thanks.

Is it possible to filter the logs found in the network section in UISP webUI?

For example, I want to filter out logs where the speed of an interface dropped from 1000 to 100, so in the Search section I type in "100" but this results in only showing devices that have "100" in their name. Is the search function any useful outside of the predefined categories (found on the right side) and device names?

Thank you a lot

I've migrated a few hundred devices over from AirControl to UISP (self-hosted) and I'm currently looking for the ability to have more advanced notifications. Examples of those would be: Link Capacity of a station goes below X%, port speed drops from gigabit to fasteth or signal suddenly drops below XdBm.

Right now, the notification section only offers a very small amount of options regarding that. Will there be any update regarding that somewhat soon or perhaps there's another way I could achieve what I want?

Thank you a lot.

Old server>Select device>go to migration and enter to UISP key of new server - on new server adopt the device then go into password and set password (password vault key is uploaded and workiing ok)

The last 5 or so devices I've tried to migrate - on the new server when I click password I get the message:

"there was an error getting the password. is your vault key correct" - which makes me think theirs a vault key issue. If click on the IP of that device to connect to it, it logs me in automatically to the device control interface so the vault obviously has the details stored correctly.

If I try to change the password on the device it won't let me as I don't know the current password.

I've rebooted device and server but no luck.

In UISP currently, when a customer makes a payment, it appears to be applied to the newest invoice allowing a open older invoice to go unpaid. Any way to make it pay the oldest first? A settling somewhere I have not found? We are hosted on the UI server if that matters.

Thanks