Continuing our discussion of thread networks from the Ikea thread.
This morning my Home app showed all 80 some odd devices offline. That included Matter, Thread, and HE devices. Everything was still working from other means, such as HE app. Had to unplug both the Pod and the Apple TV 4K to get them back. After all that it also seemed to fix the issue with the Pod showing communication error. So I’m basically more confused then ever.
Something was said in the other thread that got me thinking. It was the remark about having a router with a built in Thread radio to eliminate one step in the progress. About 5-6 years ago I used a Google Nest router. Don’t remember why I changed it out. Anyway, dug in the retired electronics boxes, found it and got the model number. As old as it is apparently it has a thread radio. Surprised me. Not sure I want to change routers at this point as that always seems to cause issues.
But for now everything seems to be working so gonna keep my hands off it.
Make sure it is a Google Nest WiFi Pro. The older version (non-Pro) has an unactivated Thread radio. Only the Pro version was activated.
As for setting up a Thread network, I’ve got boarder routers from Apple (two 4K TVs with ethernet), Google (Nest WiFi Pros and Google Nest Hub Maxes), and Samsung (Home Hub 2 and a TV with a Thread Radio Built-in) all working wonderfully on the same Thread network with several routers (ThirdReality 3-1 Night Lights Matter via Thread) in support.
The issue I run into is Hubitat doesn’t speak native Thread so it relies on the Thread to IP/LAN conversion. If and/or when Hubitat adds that capability, that is one less hop and should fix most issues.
It’s all IP (IPv6), so this isn’t as much a conversion as a physical layer bridge (not unlike wireless vs wired ethernet), which should work seamlessly if the TBRs are doing their job correctly.
Yes. I’m trying to find the article about it, but the Google Home app on iOS can read Apple’s Thread Credentials. So, if someone started from scratch with only an iPhone, it is possible to have all one Thread Network. Thread 1.4 provides an easier mechanism for sharing credentials, but it is not required if one has the right equipment. In my case, I had an iPhone and setup my Google stuff first (WiFi Pros and Home Hub Maxes). So, Google setup the original thread network, but because it was done on an iPhone, Apple stored the Thread information. When I later setup some Apple TVs, they automatically joined the Google Network.
For Samsung, they updated their firmware on the Home Hub 2 that allows a user to switch their network. So, I switched the Smartthings Hub to the Google Thread Network. Then I created a Samsung Group between the Hub and the TV. This brought the TV onto the Google Thread Network too.
I’d argue slightly that it is closer to Zigbee to LAN than all IPv6. It’s really no different than having a Zigbee device connected to Hubitat and use Homekit Bridge to bring that device into Apple Home. There is still a translation that occurs since Hubitat does not have its own Thread Radio.
In some ways, this is all semantics with Thread and Hubitat. There will always be little quirks that would be mostly fixed if Hubitat participated in a Thread mesh.
It literally isn’t. Zigbee and Thread share the same PHY, the difference between them is Thread carries IPv6 frames, while Zigbee has its own proprietary upper layers. Matter devices, whether Thread or LAN, all communicate over IPv6.
I’m not sure what it would fix beyond perhaps owning the credentials.
Fair enough. It was a poor example and you are correct regarding IPv6 and Boarder Routers doing their job correctly.
Because Hubitat would no longer be dependent on other system’s Boarder Routers. Devices would not need to hop between another system. Rather than Hubitat -> LAN -> TBR -> Thread Device; an internal radio makes it: Hubitat -> Thread Device. This matters (no pun intended) for a device designed for local control. That is why I expect them to eventually offer either a new device with Thread built-in or an option on the C8/C8-Pro to convert the Zigbee radio to Thread. It might be awhile, but Hubitat will do so eventually.
There was a time in my life where I actually understood networking. But after retiring almost 15 years ago I quit keeping up. So this conversation is way way over my head. And I realized I really don’t care that much anymore. As long as things are working I’ll let it.
Speaking of working, my thread stuff, including the IKEA’s, have suddenly been solid. Don’t know that anything changed. Hasn’t been any firmware updates in awhile. Course as soon as I say this they will probably quit..
That is true, and the independence it would bring would have some value. Such as, for example, not requiring a double-commissioning of each Matter-over-Thread device (once to the TBR, then to the hub).
I simply doubt it would fix the issues some of us have been experiencing, which I suspect have more to do with the implementations of the Matter layer itself not yet being mature, not with Thread or Ethernet underneath it. I don’t claim any expertise there, so could be wrong.
Related, but since it was specific to eero, I created a new thread about trying to use eero as my Thread backbone (spoiler alert: mixed results, but no joy for IKEA devices).
I knew I was tempting fate by saying all my thread devices were staying connected. My Eve sensor dropped off HE. Was still fine in Home. I tried initialize, configure, and refresh. Nothing worked. Then about 20 minutes after the event it caught up. Which basically makes it unusable.
To be clear no issues in Apple Home. So there is something different somewhere between Apple and HE.
Edit: I realize that statement about something different between Apple and HE isn’t really fair. The device is obviously sending the data to the TBR which means being Apple it immediately has the data. But for some reason it never gets sent on to HE. Or it gets sent on and HE bobbles it. Don’t know where the glitch might be.
Just wondering if it’s a Matter sleepy end device management issue more than a Thread-specific issue. Any plans to add GRILLPLATS or ALPSTUGA on your mesh?
Not exactly sure what you mean, but here’s my take.
First off they are not all Ikea devices. I also have an EVE device. And even the EVE is acting up.
The GRILLPLATS, etc. would just act as repeaters for the thread devices if I understand correctly. To my understanding the Battery Thread devices communicate to the TBR. That could be direct or thru a repeater. In my case I have an Apple TV 4K and an Apple pod mini. Which one is currently acting as TBR and which is repeating I have no way to detrmine.
Anyway, the data from the devices are getting to the TBR. I say that as Apple Home shows them responding 100% of the time. So to my way of thinking the basic thread network is good.
From what I understand the TBR is responsible for passing the data on to wherever else it’s supposed to go over the main WIFI network. And that either isn’t happening or the final destination isn’t responding. Again I have no way to know what is happening.
They would act as repeaters, but more importantly (to my hypothesis) they are mains-powered and not sleepy-end devices.
My hypothesis is that the issue is not with IPv6 routing between Thread and Ethernet but with Matter subscription/session management of sleepy end devices. The hypothesis could be verified if you had mains-powered Matter-over-Thread devices on your Thread network and they did not “fall off” of Hubitat.
This is where I love Matter via Thread and hate it at the same time. The tools for diagnostics are just not there yet compared to WiFi, Zigbee, or Zwave. They will eventually get there, but it is still very much a black box. My Thread issues have, for the most part, settled down with Hubitat since they implemented a few tweaks in their lower level code to be more agressive with running re-initializations. However, I’m only run mains powered Thread devices.
Personally, I think this theory is 100% correct. There are definitely some subscription/session management kinks to work out with Hubitat and they will get there.
