That's actually the one thing I had read, that if you setup your iOS thread first, using iOS device, then GH using iOS device, that the GH would join the pre-existing thread network. Supposedly, anyway...
Maybe so. Not how I did it as I almost never use my iPad. I really didn't care if the Apple Home played nice with Alexa/Google anyway, as that was just for vendor integration testing with my custom dives (aka it isn't a permanent member of my home/network).
1 Like
I guess I've been lucky with my Nanoleaf products. I only use them via Hubitat, though they were commissioned (and remain) on Apple Home, and all of my problems -- and originally I had frequent problems -- went away after I reset and upgraded a HomePod that seemed to "freeze up" and cause problems for all my Thread devices when it was acting as my Home hub.
Zero issues since then, at least as long as I ignore the Nanoleaf mobile app. 
2 Likes
Yep. This is what Iām finding as well.
1 Like
Vendors always have a vested interest in making things work (no matter what) with Apple. This doesn't surprise me.
It's annoying though since Thread is supposed to be implemented the same way in every ecosystem. Either way, I'm not using any Apple devices (other than an iPad for Facetime) so I'll just wait until it's more mature.
1 Like
As it stands today, Thread is definitely not implemented the same by vendors. For example, Apple has always led the way with TREL (Thread over infrastructure) support. That was optional in the Thread 1.3 spec, but Apple included it in all their hubs. Google still doesn't have it (last I read). Now the Thread 2024 spec should make that, and other features, mandatory.....so there should be less variance between vendors. But even Wi-Fi has many optional features, and many vendors don't implement options that could benefit users. When a spec has optional features, a lot of vendors cheap out and don't go the full mile. Just look at Thunderbolt 3 in PCs vs. Apple. Apple implemented the whole spec, while most PCs vendors only did the bare minimum.
3 Likes
I must look up this TREL. It sounds like I must have this TREL you speak of... even if I don't. (as long as it's not on Apple hardware - so, in time, I guess).
Edit (I looked at the spec first; that was a mistake):
If a feature was very important, it wouldn't be OPTIONAL in the spec. As an engineer I am hard pressed to fault Google's approach. In my line of work we all know that anything optional in a standard isn't likely to be done, and definitely shouldn't be relied on.
But my industry has longer life cycles, and less frequent "churn". If we got a shot at re-doing the spec every 18 months maybe optional items would get tested/used more and migrate to mandatory.
But I build things for 20 year life cycles, not 20 month.
2 Likes
TREL is very important, which is why the Thread working group will make it mandatory in the upcoming revision. It improves mesh quality, can reduce latency between devices, and can reduce RF traffic on the 2.4GHz spectrum by using ethernet for some communications. Eero and I think another vendor (name escapes me) have implemented it, in addition to Apple. Everyone will have to when they use the updated spec.
Google has half assed their Matter implementation (e.g. no button support), and I don't think they support Matter bridges (don't quote me on that...the landscape frequently shifts).
I'm not saying TREL is not important, it is.
What I'm saying is that it's unreasonable to lambast a company for not implementing OPTIONAL portions of the spec.
The thread working group should have made TREL mandatory in the first place.
I also agree that Google's implementation is the worst out of all the major vendors at this point. I'm not arguing that point. But complaining that they didn't implement optional portions is not one of the reasonable criticisms against them.
2 Likes
Ok, so thanks for clearing that up, absolutely no need for IPV6 to be activated on a user's LAN. Now when these Matter devices setup their own network is there any type of interference calculation performed when selecting a 2.4gHz channel? I see many go through the exercise of keeping their WiFi out of the band of their Zigbee frequency. Surely this was thought of? Anyone know?
Not from what I could tell. I went through the border routers that would allow me to change channels and did so myself. Thread itself should be frequency agile though so it wouldn't matter if all of them were on a different channel (someone correct me if I'm wrong).
That also only applies to Thread. If it is a Matter over Wifi device then it is using your existing Wifi SSID and Channel, but they create their own IPv6 network (on the LAN) using link-local addresses.
This topic was automatically closed 360 days after the last reply. New replies are no longer allowed.
