Hi.

With nothing connected to the inputs and all default settings (after clear config)

I did a "clear config" again and was able to set the time and date correctly.
Last time I put a point between the dates and it broke the recording.

The remaining errors are the same.

Sincerely,
g.

开云体育

Hi.

The situation you have is - honestly - a nightmare.

With so many clients in a mesh network you mess up a lot of theoretically available bandwidth, so I am not really surprised about your problems.

As you already found out, your home theater(?) worked lots better since you changed the smart relay mode and it got worse when many clients in small time window are turned on.? That is the consequence of using WiFi.

It is not only the number of MAC addresses. On every power-on every device initiates a long sequence: It enables WiFi, then it searches for available networks, then it starts to connect to this network, then it starts requesting an IP address (if you are running on DHCP). Imagine the amount of network traffic for that!

After the device is successfully registered and connected, you still have the situation that lots of traffic moves forward and backwards through the mesh and that all APs have to talk permanently to each other (exchanging mAC addresses and signal quality of every MAC to control handover).
If your central "smart controller" is located on the other end, you increase the problem, as every packet has to be forwarded again and again...

So I do not really wonder about your issues, but I am very, very sure this is not caused by something you can solve with a tinySA*. This is mostly the internal function of WiFi, with and without mesh (doesn't really matter with not moving clients).

The only way you can get this nightmare under control is installing lots(!) of LAN cables?and install some more APs (using this LAN cables as backbone to the central switch and smarthome controller. I know, you don't want to hear that, but there is no other way. This LAN cables drastically reduce the WiFi traffic, and a LAN cable is also LOTS faster (GBit or even higher) and has a lots lower overhead and latency, this is a huge improvement. But don't do it wrong and install a chain of LAN network switches, you need a star architecture.

It is also good advise to enforce smaller wifi-meshes, so every mesh has less clients/MAC addresses inside. Configure different WiFi SSIDs, so you gain control over where a client can connect at all. So the mesh traffic will be reduced to inside every mesh, only packets that belong to outside the mesh will leve it, but using the LAN cable.?? -> This is the correct way. If and how you tell this your APs you have to tind out by yourself. They must NOT use radio as backbone to outside their mesh(es), only LAN cables.

You may configure two virtual WiFi networks on your APs, one for the individual "smart stuff" mesh (use different names to enforce small areas to enforce where?a client can connect at all), and another one for "human use" (one huge SSID and mesh across entire site, so you can walk around with your mobile phone, laptop, ...) without disconnects. This virtual meshes must not be interconnected inside any AP with the "human mesh", they have to run completely isolated. And try to keep the number of "smart clients" below 80 (because of MACs). If this doesn't work with your APs, you need two APs one for every mesh.

This I see as absolutely mandatory. What you try right now has no realistic chance to work properly. You will notice a drastic improvement when doing it this way. Without splitting all this into smaller sections and using high effeicient backbones (Copper) I see no real chance that you can solve your issues.

Am Mittwoch, 2. April 2025, 22:17:24 CEST schrieben Sie:

> Thanks. I'm unfortunately well aware of the MAC address limits. The Ubiquiti

> APs I use advertise being able to support 200 to 350 clients each. I tested

> this, but this is not reality. When I disabled all but one AP, 120 clients

> on the 2.4 GHz band is the maximum the lone AP could handle. Subsequent

> connections were rejected, with a smartphone located near the AP getting an

> authentication error when trying to connect. I filed a case with Ubiquiti

> and they claim they do this because airtime is likely to become the

> bottleneck with this many clients. It may be true, but their specs are

> still false advertising. I don't have nearly enough 5 GHz clients to see if

> the same MAC address limit applies to that band. I could easily test

> whether the airtime is the bottleneck by placing 2 APs next to each other

> on the same channel, and seeing if I can get more than 120 clients to

> connect, between the two of them. I haven't taken the time, but I strongly

> suspect I would get >120.

>

> While the clients are numerous, most of them are lightbulbs, which are very

> low bandwidth, and support only 2.4 GHz channels. For example, my porch

> light Wifi bulb, which is connected to Wifi 24/7, averages 135 bps for the

> last 24 hours in the Unifi controller. A good chunk of that traffic is

> likely from smokeping that I have been running to track packet loss and

> latency. I disable/enable smokeping periodically for testing purposes. It

> significantly increases traffic as it will be pinging all devices, but is

> not the root cause of the Wifi problems.

>

> I am not using repeaters, but I'm using a mesh network, because I only have

> Ethernet plugs in 2 indoor locations on the same bottom floor, when there

> are 17 indoor locations to be covered, and many more outdoors (I haven't

> kept a count).

Rainer