Let’s say you have only one SmartThings hub, which is also the only Thread border router and Zigbee coordinator. You create an automation so a Zigbee button turns on a Thread light.
All is connected directly to the hub and the automation is as local as it gets, so it should always work. However… if you disconnect the Ethernet cable of the hub, the automation stops working.
Is that expected? I could understand it in case it was a external Thread border router or WiFi devices were involved and whatnot, but in this case there’s no need to reach outside the hub to run the automation.
Well it initially surprised me when I read your post, but having thought about it a bit more I am thinking that perhaps it shouldn’t have. There is a difference between not having a route to the internet and not having a network at all and I could imagine the latter would be a good enough reason for the hub to stop doing anything.
Yeah, that works, in fact, I have the hub connected to a switch and disconnected the switch from the rest of the network, and the automation still works as expected.
Looks like the hub get nervous if it’s not connected to something.
The Thread network is there and so is Zigbee, it would not be necessary to have access to the Ethernet port.
Oh sure the hub could continue to run automations, but should it? I would consider no to be a perfectly reasonable option if it doesn’t have a connection to a LAN.
Do the drivers keep working without the LAN connection?
The Thread network counts as a LAN, just like the WiFi network.
Imagine a Linux system with multiple network Interfaces that becomes unreachable from the LAN, because the interface with the default route lost its link. It’s a sign that there’s a problem with the network management.
Anyway: good to know that the Ethernet link needs to be up all the time.
Edit: just did a test: disconnected the Ethernet cable, tried to switch on a Thread bulb with a Thread button - doesn’t work. Not good.
What happens when the hub is connected via WiFi and the connection goes down…?
Getting super technical here, but this is the behavior I would expect. Otherwise, we wouldn’t need local binding, but that’s available with thread, even though not yet supported by SmartThings or matter.
The point is that a thread border router by definition is going to use Wi-Fi or the Internet to connect two thread fabrics together. That’s just how it works. It’s not a single protocol architecture.
If you had a thread sensor bound to a thread light switch, then I would expect that to continue to work without an Ethernet connection, the same way z wave direct association works. Or Zigbee binding. But then you don’t get any routines at all or any filters. It’s just this device actuates that device every time.
So…
The hub is a thread board router. That presumes two working protocols, even if both are local.
Binding improves reliability and latency skipping the hub since the hub does not need to run an automation and would be a single point of failure.
My scenario however is an automation that runs in the hub where the devices involved have connectivity with the hub via Thread and / or Zigbee. Why would it matter if it cannot access my wired network when the hub handles everything and doesn’t need to connect anywhere else?
The automation should be able to run, there’s no technical reason not to.
If I unplug my WiFi border[1] router, the devices can still ping each other.
If I unplug my Thread border router, I can’t turn on my M/T bulb with a M/T switch which are of course on the same fabric (and use the same Edge Driver).
I have some wireless matter devices, but they do not connect directly to the SmartThings Hub since my SmartThings Hub(s) ‘do not’ provide the wireless Access Point (AP) network connection for them. My matter devices are connected directly to the home wireless AP network, and my SmartThings Hub(s) connect to the same LAN network via Ethernet. So that network must be UP and available for the wireless matter devices to connect to the SmartThings Hub(s) over the same LAN network.
Since my SmartThings Hub(s) ‘do not’ provide my matter devices their wireless network connection at all, it can only connect to my matter wireless devices as long as my hosting AP wireless for the matter wireless devices and LAN Ethernet network that the SmartThings Hub(s) are connected to is UP which then allows my SmartThings automations for the matter devices to run locally on my LAN network even without an internet connection.
I think the confusion here might be that in the case of Zigbee and Zwave devices. The SmartThings Hub(s) ‘do’ provide the wireless network for these types of devices, so they are connected directly to the SmartThings Hub unlike the matter wireless devices. So that’s why Automations for them can run local (isolated) on the SmartThings Hub(s) even without the Hub having a network connection.
As long as you can provide the correct electrical pulses to the Ethernet port, everything else should work locally… A 1-port Ethernet switch should do the trick.
These link integrity test (LIT) pulses are sent by Ethernet devices when they are not sending or receiving any frames. 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. A device detects the failure of a link if neither a frame nor two of the LIT pulses is received for 50-150 ms
That would indeed be another scenario and require access to a external WiFi AP or external Thread border router to keep connectivity with the devices.
When all devices are connected to the hub though, why would the automations stop working when a cable that is not needed for the automations is disconnected?
I also found interesting a previous question, what happens if the hub is connected via WiFi and the WiFi link is down? Do automations stop working even if that link is not involved in the automation?
What thread device is it and how did you get this thread device setup when you first powered it on?
To backup @JDRoberts post, the definition I see for the term ‘thread’ in home automation devices is.
Thread is a low-power wireless mesh networking protocol based on the universally supported Internet Protocol (IP).
Doesn’t IP mean router? So, since the SmartThings Hub is not an IP router, wouldn’t that mean that the SmartThings Hub requires an IP network connection in order to communicate with other IP devices? Like thread devices which are by definition IP based?
Did you read everything written above? It doesn’t need an actual external IP network, because as long as the ST hub is connected to an Ethernet switch (physical layer, no IP whatsoever) it works.
Doesn’t IP mean router?
No.
You don’t need a router to create a network of IP devices. What you need is a simple network hub (difficult to find nowadays). They can communicate with each other just fine. If you want to connect them to a different network (Internet, for example), you’ll need a router.
Not in this case since my SmartThings hub is the one creating the Thread network and is part of that IPv6 mesh so has direct communication with the devices via Thread. Just like it has direct communication with Zigbee devices too.
That’s why I emphasized that in the very first line of the post. A different scenario would be old SmartThings hubs that had no Thread radio or if the devices were shared via Matter but belonged to another network (like other ecosystem with its own Thread network). In those cases, yes, the hub would need an IP path through the local network to a external Thread border router but, again, that’s not this scenario
A 1-port Ethernet switch should do the trick.
