I think it is a key issue but I am not currently in a position to test this. Indeed I don’t currently have any hubs configured for Wi-Fi. I’d certainly expect the same scenario as the hub ethernet port being down otherwise it would be rather odd.
I can accept the hub limiting it’s functionality if both ethernet and Wi-Fi are down as arguments can be made for doing so. They can also be made for soldiering on with what is still working.
It may be that they are using the term ‘Router’ very loosely. Because from your description that the Thread device which is connected to the SmartThings Hub’s Thread network is not accessible when you disconnect the Hub’s Ethernet port, then I can only surmise that the Hub is apparently dropping all of its IP network services when there is not a network connection which would include the Thread network which is IP based. If that’s the case, then even though the Thread device is connected to the Hub, the Hub itself doesn’t have any IP services active at all to communicate over its own Thread network to the Thread device that is connected to it, YUK!!!
Second comment in this thread:
I was able to test a Zigbee-only automation and that one keeps working if you unplug the Ethernet. That means the automation engine keeps running and I guess we can discard the possibility of the hub entering a panic mode where it disables features if the Ethernet is down.
So there’s indeed something weird about handling Thread devices directly connected to the hub’s Thread radio that fails when the not needed Ethernet link is down. The automation should work fine and seems like a bug. It may also be related to the Matter controller features and not Thread.
So it sounds like Hissing Sid the automation was innocent?
I hadn’t really thought much about it before, but presumably the hub interfaces with the built-in Thread network using the internal TBR in just the same way it would an external TBR. It wouldn’t make any sense if it didn’t.
I’m seeing a lot of confusion in this topic, so hopefully, we can clear up a little bit by going back to basics.
THREAD BORDER ROUTER IS NOT A NETWORK COORDINATOR
There’s nothing weird about it, it’s how thread works. The hub is a “thread border router,” it is not a function that is equivalent to a “Zigbee coordinator.”Two different protocols, two different ways of setting up the mesh.
The V3 hub is certified as a Zigbee coordinator and as a thread border router, but that doesn’t mean it works identically with both protocols.
No, they are using the term very specifically in the context of the protocol being used.
I honestly think you folks are overcomplicating things. A thread border router is designed to tie two protocols together. If both protocols aren’t working, the border router functions don’t work.
A Zigbee coordinator is designed to establish a Zigbee network. That’s a single protocol setup so it doesn’t care what the Wi-Fi or ethernet connection is doing.
As to whether the hub goes into a “panic mode“ when it can’t reach the cloud, it’s not a “panic mode“ in the way we have usually used it in this forum to discuss Zigbee. But it does know it can’t reach the cloud and some functions do get affected.
Thread doesn’t require a thread border router, but the SmartThings’ thread implementation does.
Just like Zigbee doesn’t require a cloud connection, but the SmartThings Zigbee implementation does anytime you want to add a new device.
DNS SERVICE
A Zigbee network doesn’t require DNS look up because it’s not using IP addresses.
A thread network doesn’t require one if it’s just one fabric, but it does as soon as it goes outside of that patch. And a thread border router is specifically designed to take messages outside of that patch, so it always requires access to a DNS server somewhere.
From the certification requirements:
A Thread Border Router minimally supports the following functions: Bidirectional IP connectivity between Thread and Wi-Fi/Ethernet networks. Bidirectional service discovery via mDNS (on a Wi-Fi/Ethernet link) and SRP (on a Thread network).
https://www.silabs.com/documents/public/user-guides/ug103-11-fundamentals-thread.pdf
It doesn’t have to have its own DNS server, which the SmartThings hub does not. And it doesn’t have to spoof IP addresses, which the SmartThings hub does not. It does have to be able to talk to a DNS server so that it can send messages outside the patch, which is its whole purpose as a thread border router. The border is the line between the two networks. So “border router” means a device that knows how to pass messages from one network to the other.
https://www.threadgroup.org/BUILT-FOR-IOT/
Zigbee is not Wi-Fi, and doesn’t have the same architecture. Thread is not Zigbee, and doesn’t have the same architecture.
The SmartThings hub is a plastic box with multiple devices inside for different networks. There’s no reason to expect that they will all work the same way, and lots of reasons to expect that they won’t. 
MATTER IS LOCAL. SMARTTHINGS IS NOT.
The Apple home app will work fine with matter over thread devices when the Internet is out. It will also work fine with any Wi-Fi devices connected to it as long as the local Wi-Fi is still operating. It uses local communications for its UI.
The SmartThings app won’t work with any devices when the Internet is out. Not even devices on the same local Wi-Fi that your phone is on. It uses cloud communications for its UI.
There’s nothing in the matter spec that requires that an app provide local operation. They left the UI totally up to the individual platforms. Along with the rules engines.
It is what it is.
Everything works as long as the Aeotec hub is connected to a dumb network hub with nothing else connected to it…
And we know that the app needs the cloud - we aren’t beginners here - but this thread isn’t about the app.
Other TBRs don’t need an external network connection and OpenThread considers it as an issue if it does:
@mocelet wanted to point out how it is and how it should be. I’d consider him as somewhat of an expert when it comes to M/T. We can always say: it is what it is - can’t do anything about it.
Maybe the next ST hub won’t need an Ethernet cable connected to a dumb network hub to work locally. Maybe one of the next firmware updates fixes this.
The next time someone asks the question if the ST hub works without Internet connection and we answer with: yes, the only issue is the drifting internal clock because of the missing NTP, we should also tell them to keep the hub connected to a hub.
Again: why is this simple fact ignored that everything works as long as a dumb hub without anything else connected to it is connected to the ST hub?
We weren’t talking about the cloud, the app, DNS or even an IP network.
I’m trying to rephrase the original post to make it clear:
Fun fact: local automations between Zigbee and Thread devices only work when link integrity test (LIT) pulses are sent to the Ethernet port of the ST hub!
They are unipolar positive-only electrical pulses of a nominal duration of 100 ns, with a maximum pulse width of 200 ns, generated at a 16 ms time interval with a timing variation tolerance of 8 ms.
The easiest way to generate these electrical pulses is to connect a $10 hub! That way you can turn on a Thread bulb with a Zigbee button even without an external network!
The point is that what it is isn’t what a number of us thought it was.
Let’s consider a single V3/Aeotec hub connected using the wired ethernet. If the hub is running happily and we unplug its ethernet cable we’d expect a degree of loss of functionality because we’ve lost the SmartThings cloud. We’d also expect to lose control and automation of hub connected LAN devices, Matter over Ethernet/Wi-Fi devices, and Matter over Thread devices accessed via external TBRs. We expect to keep control and automation of hub connected Zigbee and Z-Wave devices. All of that happens.
When it comes to Matter over Thread devices connected via the hub TBR there is an expectation that those will also work. Apparently they don’t.
However let’s assume the hub is plugged into an ethernet switch and instead remove all the other cables leaving the cable to the hub in place. Now the Matter over Thread devices work again though the only difference is that the external ethernet interface on the hub is up rather than down.
So is this inevitable? It doesn’t seem like it should be a fundamental problem as there isn’t anything else on the ethernet. Is it unintended behaviour? Perhaps. Is it intended behaviour? Again perhaps. We don’t really know.
Is it a big deal? Not really because hubs aren’t supposed to be disconnected.
Respectfully, that’s not what that thread says.
It says this:
Rather than publishing the service via avahi, can you publish using SRP instead? See src/cli/README_SRP.mdfor more detail.
.
The reason is that avahi is used for publishing services on an infrastructure interface using mDNS. SRP is used for publishing services on a Thread network.
Which is consistent with what I previously posted.
A thread network can use SRP (not mDNS) to resolve its own addresses when it is not connected to anything else.
But when it is connected to something else via a thread border router, it expects the other network to provide DNS service.
A thread border router might do this for itself, but it doesn’t have to, and the SmartThings hub does not.
SmartThings does not provide any way for setting up a thread network other than Using a SmartThings/aeotec hub as a matter controller. And it assumes the presence of at least one thread border router.
Fair point.
I don’t know for sure what’s going on, but a SmartThings hub is not the only matter controller that fails when it perceives itself as not being connected to its DNS server.
Also, multiple sources have reported that Google home devices have the same issue. If they don’t have at least a local Wi-Fi connection, they lose their thread network if they are the only thread border router.
But my main objection, which I probably didn’t state clearly, was the idea that “if Zigbee does X then thread should do X.” Because they have different network architectures and different addressing methods.
Thanks for all the comments and point of views.
Let’s abstract technologies for a moment and forget about the protocols: I think we can agree that if everything needed for an automation to work is inside the hub, what happens to something not involved in the automation should not prevent it from working.
The Zigbee-only test was not to compare Zigbee and Thread but to address a former question about if drivers do even run when the LAN is down. Well, they do and the automation engine is alive. But, despite the hub having an active link with the Thread device, it won’t send the command.
Not the same since Google Home has no local automations. A SmartThings hub can be connected via Thread to a Thread device and be able to run automations without the rest of the LAN involved, it is useful.
Google Home needs the cloud and hence the LAN, so with no LAN it’s pretty useless, both as Matter controller and as Thread border router. They even disable the clock displayed in the smart displays when there’s no Internet access so it’s expected they turn the whole device into a paperweight.
It would definitely be useful to have local ST automations involving thread devices.
Hopefully, they’ll make that change in the future. 
From a network engineering perspective, I would be curious to know if the same issue impacts V2 hubs, since they don’t have a thread radio. If they’re using a third-party thread border router, I would expect it to need local Wi-Fi to communicate with that, but I wonder what happens if the ST cloud is unavailable? Just curious, really. 
I’m not sure what do you mean by “same issue”. The issue in V2 does not apply because V2 does not belong to the Thread network. It has no Thread radio so it can’t communicate by itself with Thread devices, it will always need connectivity with a external Thread border router. It won’t need the cloud though, just like the V3 doesn’t need it.
I meant the issue of whether a SmartThings local routine would still run if it included thread devices, but the SmartThings cloud was not available.
There would be different possible cases:
The thread border router is still connected to the Internet, but the V2 hub is not able to reach the SmartThings cloud.
The thread border router is still connected to local Wi-Fi, but not to the Internet. The V2 hub is not able to reach the SmartThings cloud.
The thread border router is not connected to Wi-Fi or ethernet. (I personally would expect messages to thread devices that were not bound to fail in that case, because I don’t think the V2 hub could talk to the thread border router. But I don’t know if the V2 hub would be aware of that failure or not.)
Got it, just in case, that’s not the issue of the post. The cloud is not needed, that’s not the problem. Matter and Zigbee automations work perfectly fine without Internet access.
V2 automations will work as long as there is connection to the Thread border router. If that connection is lost, all Thread devices will be offline to SmartThings and the automation will stop working as expected.
The issue that originated the post is that V3 / Aeotec do not need any connection to any external Thread border router, so it makes no sense that unplugging the Ethernet cable would make automations stop working since the hub belongs to the Thread network and does not use the Ethernet link to communicate with them.
I understand, but is the V3 hub capable of using SRP instead of MDNS to resolve device addresses when there is no DNS available? Because not all thread border routers built into hubs with Matter controllers are, although they are probably supposed to be.
Usually when you disconnect the Ethernet cable, the IP address remains assigned to the interface. But there’s a DHCP client (and network manager) running on the hub that detects that the link is down and deletes the IP address.
What if for whatever reason this IP address is used for the Thread network? This is pretty common when there’s a bridge interface (br0) is used instead of classic routing.
Theres a WiFi interface (wlan0), an Ethernet interface (eth0) and we assume that the Thread network has it’s own interface but that’s not certain.
Well, we’ll never know because no one from the engineering team reads this thread…
Interesting observation nonetheless, @mocelet ! At least for me as a HA nerd. Now we know that the ST hub needs to be connected to a switch if we want Thread devices to work.
HA = high availability
The Thread network has its own ULA IPv6 prefix assigned to both the Thread mesh side and the Ethernet and/or Wi-Fi side. You can see the mesh address in the AWA. I posted a request to be able to see the LAN/Wi-Fi side address as well.
Now, there is some probability that the TBR logic might expect there to be an IPv4 address, but if the ethernet interface is plugged into just a hub where no DHCP server exists and Thread still works, that kinda kills that idea.
Who knows what’s going on in this little black box…