First 36 devices, then 15 — and nothing had happened

In the morning the network sweep found 36 devices. At midday, with the same command in the same house, 15.

My first thought was that something had collapsed. That was wrong. Nothing had happened — except that I had measured with the wrong tool.

Patience alone changes the answer

Same midday, same devices, just a longer wait when knocking:

Measurement	devices found
morning, 1 attempt, 700 ms	36
midday, 1 attempt, 700 ms	15
midday, 2 attempts, 900 ms	26

Ten devices of difference, purely because the tool waits a little longer. A number that depends so heavily on its own settings is not an inventory.

Three blind spots of the sweep

An IP sweep asks every address in the house whether anyone answers there. That is a question many devices fundamentally do not answer.

Sleeping battery devices. A smoke or water detector wakes briefly once a minute and stays silent the rest of the time.

Devices that never answer. The robot mower did not show up in any sweep even while running — it simply does not reply to that kind of request.

Devices in power-saving mode. This is the case that led me astray: the Shelly devices mostly do not answer and are working perfectly while doing so. Ping them and you measure their sleep, not their health.

The router knows more than any sweep

The mower was found not in the network but in the router’s DHCP client list — under its factory name. The identifier in it is exactly the one the manufacturer assigns to that model, so it was identified beyond doubt.

If you are looking for a device that does not answer, ask the router. It knows every device it has given an address to — including the ones that otherwise stay silent.

The list also supplies names no sweep provides. From that same list, four more devices were identified in one afternoon that had previously been nothing but addresses.

But the router counts dead entries too

The client list held 47 entries, the sweep found around 40 devices. The difference is not hidden devices, it is corpses.

One phone appeared three times, with three different identifiers:

...-von-...   D2-B5-38-...   .189
...-von-...   D2-84-2A-...   .232
...-von-...   4C-39-46-...   .210

Only the third belongs to a manufacturer. The two beginning with D2 are locally administered — rolled, not assigned. You can tell by the second-lowest bit of the first byte.

Android calls the feature “use randomised MAC”, Apple “private Wi-Fi address”. In somebody else’s network that is a gain. In your own house it costs:

• Every reconnection can produce a new identifier. To the router that is a new device, and the old entry stays behind.
• A reservation never takes — it hangs on the identifier.
• Parental controls, prioritisation and block lists run into the void.

And the core of it, which goes beyond the technology:

As long as a device changes its identity, it cannot be diagnosed. First the stable identifier, then the fault-finding — otherwise you are watching three devices that do not exist.

Changing it is a setting in the phone, per network. After that the device keeps its real identifier, gets a stable address and can be observed. Only then is it worth asking whether the connection really does drop.

The false conclusion that cost me most

After a change to the Wi-Fi, three addresses were in the network that belonged to no known device. The router list named two of them immediately. With the third it did not help.

So: a port sweep, ports 1 to 1024 plus about twenty typical device ports. Result: nothing open. My conclusion: this thing offers nothing locally and only phones home.

Wrong — because of a gap in my own port list. A second run over 1025 to 10000 found exactly one open port:

6668   the local Tuya protocol

It was not in the first list.

“No open ports” never means more than “none of the ports I asked about”.

The consequence is a tool instead of a memory: the port list now sits in one place, inside a script that takes an address and returns the manufacturer, open ports with their meaning, protocol replies and the certificate. If it finds nothing, it says so explicitly together with a pointer to this exact fallacy.

How an unknown device gets identified

Five steps, in the order in which they pay off:

1. The identifier reveals the manufacturer. The first three bytes are assigned.
2. The name in the client list often reveals the model. Hardly any reseller overwrites factory names.
3. Open ports reveal the protocol. It is not the number that counts but which ones.
4. Home Assistant’s device registry reveals the rest. Two devices from the same chip maker could not be told apart in the network — the resolution came from Home Assistant, which held the identifier for one of them.
5. A protocol knock decides it. The answer to a Tuya request proves the protocol and even its version, although the content stays locked without the matching key.

And the honest limit: one address is unidentified to this day. No name, only port 443, and the TLS handshake fails even with old settings — the device probably demands a certificate from the other side. Plus a steady pulse of 0.52 kbit/s in both directions. The pattern of a device with a standing, authenticated connection outwards. That is all I know.

What stays invisible, and why that is correct

I spent a day looking for a switch, to see port errors and throughput per socket. Searched on three routes: SNMP, vendor broadcast, web interfaces. Found: nothing.

The reason is one letter in the model name:

Model	manageable?
the S variant ← installed	no — no address, no interface
the E variant	yes — web interface, VLAN, port mirroring

Same shape, same price range, one letter apart.

A device that shows up in no sweep is not necessarily hidden. Sometimes it simply has no address.

I still wrote one trap into the script: manageable switches often sit on a fixed factory address — with some vendors exactly the router’s own. One still on factory settings is found by no sweep, only by the broadcast.

The better question

Instead of “who answers a ping” it is: are the devices working?

Integration	Entities	unavailable
Shelly	93	0
Hue	65	0
Blink	61	0
Robot mower	34	0

What remained were nine unavailable entities in the whole house, all explainable: five entries for an effect speed that only exists while an effect is running; two image ages for freshly paired cameras without a preview; two extra fields of a sleeping washing machine.

For a Wi-Fi device network, the ping response rate is no measure of health. The dependable figure is in the entity registry.

What I’d suggest

1. Take the router as your first source, not the sweep. It knows the silent ones too, and gives you names with them.
2. Expect dead entries. More entries than devices usually means randomised identifiers, not intruders.
3. Turn randomised identifiers off in your own network — per network, in the device. Before that, any fault-finding on that device is pointless.
4. Keep your port list in exactly one place and have the tool say when it found nothing. “Nothing open” is a statement about your list.
5. Measure health by work, not by replies. The number of unavailable entities is dependable; the ping rate is not.
6. If you want port statistics, buy them at purchase time. An unmanaged switch will never become visible, however good your tooling is.

So what?

I raised an alarm one morning and disproved it myself the same day with the better measurement. That is the order in which it stands in the documentation, and that is deliberate.

The sweep was not broken. It answered exactly what I asked it — who replies to a request that many devices are not obliged to reply to. The answer to that fluctuates with the time of day, the power-saving mode and the patience you configured.

A network inventory therefore consists of four sources, and each has a blind spot: the sweep misses the silent ones. The router counts corpses. The port list knows only what it asks about. And the device registry knows only what is already integrated.

Only together do they produce a picture. Separately, each produces a number you would like to rely on.