I can tell you that only Echo 4 (the big one, not Echo Dot nor Echo Show) is capable to execute some basics commands when there is not internet.
3 Likes
It may vary regionally, but this is a feature that we do use at our house because our Internet can be pretty flaky, and we can verify that at least the second generation echo show 10 and the old echo plus also support local voice commands for some devices.
What I wanted to say itâs that only certain Echo devices are capable to do that, very sure all the ones with ZigBee radio built in will work and also pretty sure that standard devices like any Echo Dot, Echo show 5 and echo show 8 it will not.
1 Like
1 Like
Two of my favorite home automation bloggers had very different reactions to the aqara M3 hub after they tried it out. Both make detailed and entertaining videos, and I enjoy both their channels.
Paul Hibbert , Who is definitely in the âtinkererâ class, loved it and just couldnât get over all the eventual possibilities of it. (Like me, he was also very impressed with the networking design for the M3.) His main home automation platform now is home assistant, although he tries pretty much everything. He uses a lot of different apps as well as Alexa.
Shane Whatley was disappointed with the state of matter support in the M3 at the time that he tested it since it only supported a few third party devices from specific brands. He has more of a âproblemsolverâ perspective. He looks at new devices in terms of the problems they can solve now. His main platform is HomeKit plus matter, although he also has both a homey and a hubitat hub. He wants everything to work in the Apple home app.
Anyway, it was interesting to see two such very different perspectives.
8 Likes
I agree the initial ârestrictedâ matter support of the M3 was disappointing to hear, and a lot of content creators felt the same way. Kinda defeats the purpose of the Matter standard âjust workingâ. However, Aqara must have heard that feedback because as of May 11th it now supports most of the Matter 1.0 device types. They of course did apply the warning that they havenât tested all devices from all brands, so support is still a âlab featureâ.
5 Likes
Glad theyâve expanded, but again the whole point of matter support is supposed to be that the individual device manufacturers donât have to test âall devices from all brands.â If an end device is matter certified, it should work with a matter controller which is also matter certified, regardless of the brand.
But thatâs only how itâs supposed to work.
Since the independent third-party standards organization for Matter, CSA, has allowed companies to use the matter logo without requiring that they support all of Matterâs features, The logo has become pretty meaningless, and consumers still have to research each individual pairing before purchase to see if it will work. Which leaves us right back where we were before matter. Super annoying. 
They should have withheld matter certification until the manufacturer had matter out of beta, and it did work with any other matter-certified device.
But since CSA allowed logo use for partial implementation, the whole mission statement breaks.
8 Likes
Thatâs how they work. Itâs the same Aqara that advertises its Zigbee light strip and relays as Matter compatible with a very small print that says âAqara hub requiredâ.
Is that âMatter over Zigbee bridgeâ label they have official by the way? A product is not Matter if it does not communicate using Matter. Itâs like saying I speak fluent Chinese when a translator is next to me.
So itâs not surprising they sell compatiblity with third party products and the only third party smart light are the ones from Philips Hue, which also require their own proprietary bridge to speak Matter. Smart lighting must be the category with more native Matter products available and yet Aqara supports none.
They should have just sold it as a Matter bridge for their products, and not as a Matter controller when clearly it isnât. And stop using the Matter brand or logos for products that are not Matter.
5 Likes
Correct on all counts, unless the CSA is changing the logo rules. Bridged devices are not supposed to show a matter logo. Instead, they should say they work with a specific matter bridge, and that bridge device can show the matter logo.
4 Likes
Looking at the aqara site for the US, they are describing the Zigbee devices correctly: if you connect it to an hub, you can then use it with HomeKit, IFTTT, or matter. All true.
I also donât see that âmatter over bridgeâ logo anywhere on their site. It looks like a modification of their âmatter over threadâ logo.
Where I have seen that âmatter over bridgeâ logo is on some ali express product listings from unauthorized third-party sellers. 
That logo is from the recent T1 light strip: LED Strip Lights T1 - Aqara They use it in more product pages. And even media announces it as Matter compatible to confuse people more.
1 Like
Since it includes the Asterisk, Iâm OK with it. Thatâs the same way HomeKit devices that require a bridge have always been marketed. If you have the bridge, then it works with HomeKit. So if you have the bridge, then it works with matter.
- An Aqara 3.0 hub is required, and a Matter-compatible Aqara hub is required for Matter support
But it shouldnât be just the icon logo.
As long as the outside of the box gives me all the information I need, Iâm OK with that. I donât want to have to go look on a website to figure it out.
2 Likes
The problem I see is that everything is on the small print and is misleading for the consumer.
Headlines say Matter compatible, they are making Matter their main selling point and thatâs what people read or see in the media. The ârequires hubâ small print is a nice way of saying âoh, the product is not compatible with Matter actually, thatâs why we make you buy our own bridge for that main feature we announced!â.
Bridges should be a way to integrate old devices in a Matter ecosystem, not an excuse to call new products Matter compatible when they are not.
5 Likes
1 Like
I have to respectively disagree on this one.
Bridges are a long-standing and effective way to bring devices of one protocol into an integration with other systems. Just a few examples:
- The Philips Hue Bridge. The granddaddy in this space, the Hue Bridge, allows the use of a highly effective local mesh protocol, Zigbee, with pretty much any home automation platform out there that uses Wi-Fi, including Alexa, Google Home, Apple Home, and now Matter. Great features, excellent engineering. In a SmartThings context, itâs the only way to bring in Zigbee green power devices like the Friends of Hue switches since SmartThings hubs themselves do not support the ZGP profile.
- SwitchBot Minihub and Hub 2. Local connections are Bluetooth, mostly for cost and battery life reasons, allowing this brand to offer really innovative products like their automatic button pusher and their curtain mover at budget prices while the hub bridges them to platforms like Alexa, Google Home, SmartThings, and now Matter (which adds Apple Home).
- Lutron SmartBridge. Lutron uses its own proprietary frequency, ClearConnect â˘, Which makes it one of the fastest, most reliable lighting systems available. The bridge adds integration options to a wide variety of platforms, including Alexa, Google Home, HomeKit, and SmartThings.
- for that matter, every thread border router is a bridge of this type, allowing the use of thread devices with a multitude of Home Automation platforms, including SmartThings.
ââ-
Whether it is bringing in existing devices or introducing a whole range of new ones, bridging is a well established architecture in Home Automation, with significant benefits to the consumer. It is fundamental to the design of many SmartThings integrations, and that was true long before Matter.
If you donât want to deal with bridges, stick to Wi-Fi-only devices plus, in the case of SmartThings, those devices that can be directly connected to your SmartThings/Aeotec hub. Thatâs a perfectly reasonable approach, and works well for those who just psychologically object to adding additional bridge devices.
But hue, SwitchBot, and Lutron have all demonstrated that many consumers can definitely understand and accept the use of bridge devices to gain additional features and integrations, as long as the requirement is simple and straightforward, and can be printed on the outside of the box for the child devices. These companies are market leaders in their categories and have high customer satisfaction, even with the bridge requirement.
Choice is good. Choose the architecture that makes the most sense to you. But in terms of evaluating a brand or a protocol from an industry standpoint, I wouldnât make having a bridge a blanket negative. You would wipe out a lot of the choices that many people rely on today.
Submitted with respect.
6 Likes
Didnât say otherwise and maybe the point was not clear: the issue here is claiming, and making it the main selling point, that the product itself is Matter compatible, misleading consumers when the product itself is not compatible with Matter.
Aqara has true Matter devices, like the Matter over Thread Aqara P2 contact and motion sensors. They can have the Matter logo, they donât need the Internet for setup, you donât need to give personal data to Aqara or create accounts with Aqara or buy more Aqara products to integrate into Matter.
I donât have any problem with bridges, my motion sensors from Tapo are integrated into Matter thanks to their Tapo H100 hub, they use a sub-GHz frequency and Iâm fine with that. But they donât announce it as a Matter motion sensor, just like I donât put in my resume fluent Chinese and in the small print âtranslator requiredâ.
Philips Hue for instance have Alexa and Google Home logos in the box of the lights, but not the Apple Home logo, thatâs only in the bridge. Thatâs honest because the lights alone can work with Alexa or Google Home using bluetooth, but they wonât work with Apple Home, for that you need the bridge, because thatâs the device compatible with Apple Home, not the lights.
Edit: I believe Aqara does not put that fake âMatter over Zigbee bridge Aqara hub requiredâ logo in the box of their products, but they use it in their official websites. The requirement of the hub is always in the small print, never in the headline, legally fine but dishonest anyway.
2 Likes
I hear what youâre saying, but weâll still just have to agree to disagree on this one. That fine print requirement has been used in all of the examples I gave previously. You can see it in the Lutron image I used, for example. In fact , SmartThings has always used it for their Zigbee devices with fine print saying the hub was required.
Logos are a different story, and I agree, that the logos need to at least be different. Thread has done this with their ârequires thread border routerâ logo, and I think thatâs OK.
But as a potential customer, I want to be able to pick up the box in Best Buy and see on that box which integrations are available. And if itâs a âwhen used with the hubâ or âbridge required for X integrationâ Fine Print statement, Iâm ok with that. As long as itâs clear and available on the box.
What I donât want to have to do is look at three different sensors in the store and have no idea which ones will work in a matter set up or not. I donât want to have to go to a webpage to find out that, OK, the FP1 can be bridged to matter, but the FP2 cannot.
Iâd be happy to see a consistent âmatter bridge requiredâ logo with a fine print statement about what matter bridge it works with. Again, thatâs what thread is doing now, and I think it makes sense. And personally, I would definitely prefer that to no mention of matter at all, which seems to me to create more work for the consumer.
But this may just be a situation where different people have different preferences. It happens. 
4 Likes
Yeah, weâll have to agree to disagree here 
A bridge is a proprietary thing that locks you into a brand of devices while a Thread border router is platform-agnostic and device-agnostic. Once you have a Thread border router you donât need more, just like a WiFi router.
Adding a label like âMatter bridge requiredâ would also mislead the consumer because they would think âoh, I have a Matter bridge, then I can use it!â only to find out it needed a very specific bridge from a vendor that may not be the one they already had.
I would prefer if they use the Matter logo only for Matter products that you can integrate into Matter without extra purchases, account creations, app installs, etc. Otherwise, theyâre killing the brand and the message of a private and secure product that works offline and is compatible with your existing setup.
There has to be a clear way to differentiate a real Matter product from one that is not and needs translators other than a small fine print that says âproprietary hub requiredâ.
2 Likes
Bridges donât have to be proprietary. Some are, some arenât.
A good example is Philips hue bridging to HomeKit. Because Phillips made a developer API available, there are multiple third-party âhomebridgeâ bridges to bring devices into HomeKit using the Hue integration, including HOOBS and Starling.
As we mentioned up thread, thereâs even a third-party matter bridge for one brand of (non Philips) commercial lighting in Europe.
So again, itâs not bridge architecture per se that causes the issues you describe. Itâs how an individual manufacturer decides to deploy it.
1 Like
It is since you would still need to purchase the bridge or install a server, proprietary or not. Itâs not a scan the QR and youâre good to go, which should be the ideal experience when you have a Matter ecosystem and want to add a new Matter device youâve bought because it said âMatter compatibleâ.
Bridges are great to bridge non-Matter devices into a Matter compatible ecosystem. Selling non-Matter devices as Matter compatible ones when they are not, is misleading, that was my point. More or less misleading depending on the size of the fine print.
5 Likes