That really makes no difference to the core issue. The point is that even a single attempt at needing an Internet connection, even if it’s just for initial setup, is problematic. Read all of this, in context:
More Ubiquitous Internet Connectivity
With this enhancement, Thread networks will require Thread Border Routers to provide a standardized path to the Internet for the devices connected to it. This assurance of connectivity means product makers can build devices that leverage the cloud for more dynamic features (like a thermostat that responds to weather changes) or give users the ability to remotely control their devices. They can also send software updates to the devices and perform diagnostics to provide better technical support.
With the emphasis on “will”, it seems as if it’s not an optional requirement (it indicates a strong requirement, as opposed to “can”/“may”, which still leaves the door open). Whether it’s standardised in terms of a path really has no bearing on the core issue. Many users of HA, including myself, don’t see any reason that a device would need any form of Internet connectivity, whether it’s for initial setup or continued operation. That paragraph is clearly written from the perspective of the manufacturer and not the end user. The intent with Internet connectivity is made clear in that paragraph. We don’t want devices that have a need to dial home.
Perhaps it’s all badly worded by people not used to writing specifications or standards. Either way, an official clarification would be appropriate.
Perhaps this clarification helps? From article in “The Verge” interviewing Jonathan Hui, VP of technology at Thread:
While this sounds like a backward move for the local, smart home standard Matter, Hui emphasizes it is optional for manufacturers. Plus, if a manufacturer does choose to enable it, consumers can turn it off at the network level. “The spec requires border router vendors to give capability to the users to disable this functionality,” he says.
So:
It’s a requirement for border routers (was optional in previous versions).
It’s optional for device vendors.
Where implemented, it is required to allow users to turn the feature off.
Great, but I’d like to see this nailed into the specifications. Vendors have been known for sneaky tactics too, e.g. saying certain features cannot work without Internet/cloud access (some obviously cannot work without it, but that’s not always the case). Hopefully that kind of thing can be countered with proper certifications.
Ok so, what happens if a device requires internet and the border router does not allow it? I still think this breaks the promise of a local protocol, and introduces compatibility issues. This makes Thread no different than Wi-Fi in these aspects.
I’d honestly like to see what the position from Home Assistant is. HA is treating Z-Wave, ZigBee, Bluetooth and Thread/Matter at the same level… but, with this release, Thread/Matter falls away from the local protocols into the Wi-Fi wild west category, not good for our privacy anymore. Not better than Wi-Fi anyway.
Bluetooth and Zigbee are also like the wild-west. It is only Matter and Z-Wave that has proper certification with specification testing at the device type level.
When I think of Home Assistant of a control for security handling door sensor, camera, burgler protection and more I’m scared about a forced internet connection and everything forcing clouds on third party states and companies.
When I think of Home Assistant as a multimedia entertainment box for games, music, video, Alexas, Echos, Facebook, Instagram, TikTok channels and all this stuff, this may work and nobody “matters”. Maybe that’s why the name is for.
I think there is a big conflict in combining both stakeholder needs in one system, getting weather data and keeping the garage doors locked.
With this statement I’m happy to have chosen Zigbee and sent the matter devices back for a good reason.