Thread is only a mesh network protocol. It doesn’t have a standardized command language. Same with Wi-Fi. Z-Wave, Zigbee, and Matter all have a standardized command language. Hence the logos in the app.
2 Likes
True. There’s also no Ethernet logo. I got carried away…
They should advertise it a bit more prominently though. There’s a Zigbee, Z-Wave and WiFi logo on the box. See the last image here:
Wouldn’t hurt to put the Thread logo somewhere.
nonsense, the world would be a very lame place if there were no logos… just everything written in words. gimme all the logos please.
2 Likes
I had a GE/Jasco outlet die on me over the weekend so I replaced it with the Eve Energy Dual-Switched outlet (Matter over Thread). Nicely packaged, it comes with a decora style screwless wall plate, mounting screws, and wire nuts. Added easily to the ST mobile app via QR code scan. It adds as two different devices which can be controlled separately. However, energy reporting is located on the primary outlet and there is not separate energy monitoring for each outlet, just cumulative for the entire physical device. Firmware updates are also managed only from the primary outlet. The primary is identified as type MATTER using profile power-energy-powerConsumption and the second outlet is type EDGE_CHILD using profile plug-binary.
Devices were added automatically to Alexa via the ST skill. However, you can also add them directly to an Echo device for multi-admin by doing “Share with other services” in the ST app.
8 Likes
The LEDs are also buttons to manually switch the sockets on/off, right?
1 Like
Yes, they are.
3 Likes
In a number of places I’ve commented about my issues with Matter over Thread devices (mainly Onvis S4). I pointed my finger on the general direction of the GL-S20 I was using as a TBR as GL.iNet actually state that it lacks key functionality for use with Matter commissioning. Not sure exactly what as I have had some success with it, but also lots of failures.
Anyway this weekend I had another go at buying a V3 off eBay. Not quite so good a deal as a previous purchase which unfortunately went missing on the last delivery stage, but more than good enough that making a lower offer would have felt wrong. It arrived today and I’ve replaced my main V2 with it (hub replace is excellent).
My plan was to delete and reinstall my Matter over thread plugs and motion sensor so they were using the V3, leaving just one on a V2 hub and the third-party TBR (I use a plug to power the V3 so I need a different TBR). I also wanted them all on Google as well, largely just because I could (previously with a standalone TBR it gave me control independently of SmartThings).
Did I succeed? I think so, but only because the commissioning onto SmartThings worked first time for every device, and the multi-admin to commission onto Google Home also worked first time for every device bar an Eve Motion (which didn’t commission on Google all). I hadn’t encountered it working so smoothly before. However there doesn’t seem to be any way to know what is actually happening at the Thread level.
I wasn’t asked which Thread network I wanted to use. The first time SmartThings barely paused when it was looking for networks, and every other time it paused then continued. Similarly Google never asked. This I found odd.
I know Thread devices can be on multiple independent networks, and I assumed it would be possible with Matter over Thread too. So not only would I expect to be able to choose the Thread network on initial commissioning, I would also expect to be able to choose the network when commissioning onto other ecosystems (or indeed onto other ST hubs or Locations).
3 Likes
The idea is having a large Thread network for redundancy and reliability with a stronger mesh and multiple TBRs so if one dies nothing happens.
The problem is the “magic” is not there yet. TBR vendors are supposed to use the APIs of Android and iOS to get the credentials of the preferred Thread network and join it when setting up a new TBR. SmartThings does not share the credentials so nobody can (easily) join and won’t read them either to join a existing network. In fact, unless multiple ST hubs belong to a group, they will create individual Thread networks.
2 Likes
So, a dumb question - is this important? I understand that this will not help making a mesh, but as an objective of having a failsafe system this would equally allow, in the case of failure, to take over another TBR, or not? With the gradual improvement on sharing by manufacturers this would be cured …but do we have to wait for that before starting buying Thread devices?
With the Thread 1.4 update, device manufacturers can begin implementing the features and enhancements, which include:
One mesh network, made easier. Regardless of the brand, smart home platform, or mobile OS, when adding an updated device or Thread Border Router, it will join the existing Thread network versus creating a new one. This results in one wider ranging, more reliable mesh, because Thread 1.4 standardizes how devices recognize and trust each other.
…
Let’s wait and see…
1 Like
And it remains to be seen whether they will implement that independent from the Matter SDK so that we don’t have to wait for Matter 1.3 or 1.4 to get the Thread updates.
1 Like
Indeed, and that is the way in which I am moving for everyday use.
However that doesn’t mean that it can’t co-exist with another idea where some of the devices are also on a second Thread network. In my case that is both a convenient stop on my journey, which I think is what @Johnnybegoode was also getting at, and potentially an extra destination.
To put it another way, I should be able to bodge things temporarily with V2 hubs and a GL-S20 a bit better than it appears I can at the moment, and then when I’ve finished bodging they will still be toys to play with.
2 Likes
I mean, there’s a reason why we say Matter over Thread. There are other protocols on top of Thread, notably HomeKit.
The chip manufacturers will update their SDKs and firmware first.
The philosophy is hiding all the technical details so zero configuration is needed, not even a password or knowing the name of the network. Advanced users are going to miss more control for sure, especially in consumer smart home platforms.
Nanoleaf lights for instance allow in their app to change the Thread network with just a tap, assuming the app can get the credentials from the Android/iOS API (or has learned them when they were commissioned, the app is kind enough to display the Operational Dataset needed in platforms like HA to add border routers).
Edit: Didn’t try until now, it’s possible to make the ST Thread network the preferred one in Android using the HA companion app and the Operational Dataset provided by the Nanoleaf app. Theoretically, now the phone knows the credentials and other apps can access them so, if I removed all the Google TBRs (well, I only have one and it’s unplugged anyway), when setting a new one it would join the ST network instead of creating one. I’ll try eventually.
Well, I removed the Nest Hub so it would join the ST network and after setting it up again… it created another NEST-PAN network 
In the Google TV Streamer site it explicitly says that it can join existing networks and there are configuration screens, but I guess the Nest Hub can’t.
Mmmh… this is interesting, it created a new one but moments later it went back to the original NEST-PAN. So, maybe the old NEST credentials were available somewhere and it didn’t realize the ST network was the preferred one. I’m not sure how to make Google forget the previous Thread network.
1 Like
Seems that might be sooner than I expected as this morning I found a still sealed V3 on Vinted for even cheaper. I won’t count my chickens till it is delivered and I have it working.
2 Likes
Just FYI, Matter lights capabilities have recently changed in SmartThings to add the cloud-based circadian lighting option as well as the wake-up / wind-down features.
Same cloud-based features that existed for groups and cloud lights. Doesn’t use any Matter feature and it’s not handled by the driver, it’s just the platform adjusting the values from time to time. Changes are not smooth and you can notice every minute when it updates the brightness or the temperature.
3 Likes
Awesome! Looks like it was also added for Hue bulbs connected via Edge driver. Maybe it was applied for Edge devices in general?
Before:
After:
Probably, all my lights are Matter but the feature is independent of the driver or technology, I guess it applies it as long as it has the switchLevel and/or colorControl capabilities.
Previously there was an easy workaround, adding the lights to a group and using the group instead, but that could be cumbersome if you only had one light because you had to create a virtual one so you had two to be able to create the group.
2 Likes
They have also added the sleep function, only for decrease level when bulb is on, along with the timer.
In the end they have been adding in the cloud the functions that my driver already has in local, hahaha.
Now they just have to add the random lights on off, blink, step changes, color changes.
We see that if they want they can
This is in Android app and zigbee bulb
This is good
3 Likes
Yeah, it’s a pity it’s the cloud and not the hub doing it. Plus they don’t use native features like transitions, although given the current situation with Matter implementations in smart lights I understand it.
SmartThings could expose the transition time to the automation’s user interface (it’s in setLevel command after all so can be used with the Rules API) and add it to the setColor command too, then those dim / brighten / sleep functions would not be needed (and it would be local and smooth instead of step by step every minute).
2 Likes