If Matter is a supposedly local protocol, why does home assistant contact Google to add devices

Very quick to lay the fault with HA. I don’t have any matter devices but a quick search on the community showed a few threads that might help you. Also, per the documentation, the matter implementation is beta so issues should be expected.

If your memory is correct, I’ll never use Matter. I prefer to buy hardware rather than rent it.

Thats literally my point. I bought these because home assistant pretends Matter is a local open standard like zigbee, but i find out it not only does it require a smart phone, which is already annoying, but craps out if you dont let it talk to daddy Google. So yeah, home assistant really needs to be more upfront about this

2 Likes

This is from the HA documentation on Matter. The Matter std is outside of HA’s control and Google is one of the founders. Installation guides also show that Google Play Store is required.

If Matter really requires connecting to google every time new device is added, then the documentation is wrong. Documentation says:

Matter products run locally and always allow local control, with device control done without the need for any internet connection or cloud services. From a technical perspective, you can use a Matter-compatible device with Home Assistant without connecting to a vendor-specific cloud. However, some vendors may require you to set up an account before you can enable Matter support for some products, (especially for commercial manufacturer’s own branded gateways/bridges/hubs/controllers sold as appliances).

As for the play store requirement, that is only written as requirement to have HA companion app. It’s not required for iOS (obviously). And the companion app is only required to provide the device with wifi credentials through bluetooth. It doesn’t state anywhere that internet connection is required for this.

If this connection to google requirement is confirmed, that’s another reason to stay away from matter. Personally I had no idea it was integrated this much with Google.

I think the OP should report this as a bug in github (either a bug in code or error in documentation).

2 Likes

I would imagine the reason to need internet to provision a new device is simply because HA would not have the details for every device stored internally to know about all it’s features etc. On top of that, more devices are constantly being developed so HA would need to continuously update this internal database. Contacting an online database would be the solution to this.

Or maybe I’m completely wrong…

Emphasis on run or control. No word about provisioning or commissioning :thinking:

That could be right. The DCL (Distributed Compliance Ledger) shouldn’t be vendor specific, actually the distributed should define quite the opposite. :point_down:

And that is allowed in the matter specification! :page_with_curl:

The matter standard does allow vendors/manufactures to cook their own soup and have for example only basic functions available exposed to HA and full functionalities only with vendor app/cloud. :put_litter_in_its_place:

Sad that csa/matter just repeats (or even worsen) the wrongdoings of zigbee :honeybee:

2 Likes

That is disappointing. It’s hard to imagine any manufacturer will avoid the temptation to turn their hardware sales into an ongoing revenue stream or data-capture source. In other words, if they’re allowed to build in a cloud dependency, they will. Gotta keep those private-equity investors happy.

The worse thing is. I was aware of that clause, that certain features may require a login. But in this case i cant even add the device. Heres the breakdown of the testing i have done this weekend.

  1. Tried to add device with my phone. The Home assistant app annoying picked the wifi network for me, but it all worked fine.

  2. Take second bulb, put my phone on the isolated wifi i want to use then repeat the process. But as soon as the process starts,

  3. Grant only my phone internet access, leaving everything else blocked, get past the google error, but get a different connectivity error.

  4. Only after granting internet access to the bulb itself does it work again.

So the conclusion I’m forced to make from this, is to use a Matter device, you have to ask Google for permission to use the hardware you paid for, while also allowing that device send everything it can to china.

1 Like

I deployed a Zemismart Matter LED strip to a fully isolated VLAN several months ago and haven’t had any issues. The HA docs are clear that the mobile device must be on the WiFi network that you want the Matter device to use. I didn’t check during deployment whether my iPhone tried to contact Google over cellular data, but I suspect it did not.

There is a “commissioning hints” post on the forum noting that the current HA companion apps use the native platforms’ Matter commissioning frameworks, which permitted the developers to expedite support for Matter in HA. I would not be at all surprised if the Android commissioning flow requires access to Google (like so many of Android’s frameworks), so I suspect you are seeing an Android limitation, not an iOS or HA or Matter limitation. but I only have my own anecdotal experience to support this.

The forum link above also notes that direct commissioning using the server’s bluetooth, instead of a mobile device, is now an experimental/advanced option. Perhaps if you don’t like the Android framework methods you can try the advanced direct commissioning option, but keep in mind it’s an experimental feature for a beta add-on.

Regarding the DCL, my understanding is that it’s meant to be consulted during commissioning to check if the device is valid and/or has had its certs revoked, e.g. if it was discovered to be hosting malware. The DCL also contains firmware versions for certified devices, leading me to believe the HA add-on (not the mobile device) performs the DCL checks; and that being distributed (basically a blockchain), it is not (exclusively) hosted at Google, so again I would be surprised if it was the source of the Android limitation, but I could be wrong. I also believe Nabu Casa, as a member of the CSA, has the option to host their own DCL instance, which might allay some (though not all) privacy concerns. Hopefully even if the developers are not permitted to skip or ignore the DCL checks, it will be possible to modify the Add-on code yourself and “truly own” the device regardless of its certification (or malware) status.

1 Like

I think (sadly) that is not the case. From what I understand that the real owner (manufacture/vendor) can brick your device and you can’t do anything about beside being happy that you got a new :brick: :raised_hands:

If you (incautiously) decide to buy a ready made matter device you get a totally (:warning:) locked down (:lock:) device that has a authenticity certificate which is backed by some hardware secure boot. This does not allow YOU to do any changes to the firmware at all. :stop_sign:

Take for example the Sonoff M5 Wallswitch, you have a version with matter:

This one you can’t own and you don’t have any rights to repair or modify :put_litter_in_its_place:

The same same device without matter (does also feature a espressif MCU):

This device can be owned (installing own firmware like esphome) and you have the right (possibility) to repair or modifiy YOUR device :trophy:

3 Likes

May or may not help but this thread discusses issues/solutions for adding tapo matter bulbs.

Currently, for ease of commissioning on both App platforms (Android/iOS) we use the commissioning flows provided by the Android (technically Google Play Services) and iOS. These frameworks take care of all initial onboarding, talking to the device via Bluetooth and setting up of the Thread or WiFi network configuration.

I’ve outlined this a bit more in detail in the Matter Pairing/Commissioning hints thread here in the community forum.

So all the above are essentially limitations/implementation details of the Google Matter implementation. They are very much focused on ease of use and expect a flat/single network which most of their users have.

3 Likes

Yeah unfortunately, most commercial products are like that today :frowning_face: ESPHome for the rescue! :sunglasses:

That said, it is not really practicable to build everything yourself etc. And, IMHO, at the end of the day Home Assistant is mainly popular because it can interface with a lot of commercial products and combine to a coheren smart home :robot:

This process is called device attestation, and it resolves mainly around that the device must attest a certificate which allows to cryptographically verify that it is from a certain vendor and it has a certification declaration. The actual validation can happen completely offline, but it needs cryptographic material (public keys of the vendors etc.) which can be obtained from the DCL. There is no requirement in the standard to do this online. Also all validations which mention the DCL are SHOULD’s in the standard. From all I can see, the Matter standard per-se allows local commissioning no problem!

You can also try that with our local commissioning procedure outlined in the Matter Pairing/Commissioning hints thread.

The Matter standard also has this sentence next to the test vendor 0xfff1:

The Test Vendor IDs are reserved for test and development by device manufacturers or hobbyists. Commissioners SHOULD NOT commission devices using one of these VIDs onto an operational Fabric under normal operation unless the user is made fully aware of the security risks of providing an uncertified device with operational and networking credentials.

So self-made devices are explicitly allowed. :tada:

All features which are covered by the Matter standard will work locally. Technically of course a vendor could check for Internet connectivity, and if missing “deny” Matter requests, but that would be very artificial limitation, and probably would not make it through certification (in a quick check though, I don’t think that the standard says anything about that, so I guess technically someone could build such a device :see_no_evil: ). But then, you can do that with any other protocol too :man_shrugging:

Keep in mind that behind Zigbee and Matter is the same organization (CSA). Matter is definitely the more open source/hacker friendly protocol of the two, as the standard is actually free (as in free beer) to download, and the implementation is truly open source (as in freedom). And it is IP based, which to me is the big game changer long term.

4 Likes

I don’t think this is true. The test harness for certification just commissions a device, and then starts to use the clusters on the device. I don’t think that you can require the user to create an account, and certify a Matter device.

I am at least not aware that a single such Matter device exists, and I have tested many! E.g. the Tado thermostat, which is really designed as a cloud based thermostat. However, their latest Matter enabled Thermostat X you can commission first thing with HA, and use as a regular Matter thermostat no problem. You just loose all the features they offer (including software update, since that is not mandatory within the Matter standard - and they opted to do their own/propertary firmware update).

There are some devices which got launched pre-Matter (e.g. WiZ bulbs). Those you obviously need their App to even download the first Matter firmare. But from then onwards, you can delete their account, use whatever reset machism they have, and commission Matter without using any of their stuff.

In the end, currently it really seems that Matter device do hold their promise: What is covered by the standard is local, and vendor (app) agnostic. But I guess we’ll many devices which only unfold their full potential with the app… But in the end, that is the state of IoT anyways :man_shrugging: So at least with Matter we have a standardized baseline. And my hope is that there will be more companies like Eve which just simply make solid “no-frills” Matter device :muscle:

Yeah, but the Matter standard also mandates that all features which are covered by the standard must be exposed through Matter. E.g. you cannot release a smart bulb which can dim only through their app, since that is a feature of Matter.

Update: I thought I’ve read that at one point, but I tried to find that statement in the standard and wasn’t able to. What definitely is the case all mandatory clusters for a particular device type a device is certified for must be implemented (obviously). But it seems that Matter optional features could remain left out, even if the device actually has that feature :frowning_face:

What might happen is that a particular device stays on a old version of the standard which did not yet cover a particular feature… But that is just the nature of things.

I think a lot will depend on the “quality of the Matter implementation” of Matter devices, especially as more and more complex devices get standardized.

2 Likes

Thanks for all the helpful replies! I’m starting to understand Matter a bit better. I’m still taking a “wait and see” approach, but the more I learn the better prepared I’ll be when the time comes.

I sort of get why there would be some validation involved in the commissioning step. I’m not sure I like the idea of Google or Apple doing it. I’d rather see something like we have with SSL, where there are trusted certificate authorities.

Personally, I’d be happy to simply trust the source I got it from, be it a vendor I trust or something I created using a tool like ESPHome. But I can’t imagine any manufacturer being happy with that. So for now, I’m on the sidelines watching and learning :popcorn:

1 Like

I agree. I’d be fine with it home assistant server required internet. it’s the requirement that the bulb be granted internet access as well that bothers me, along with the Google dependency.

1 Like

Their whole smart home platform is very much cloud dependent, so in a way it doesn’t matter all that much for them to do this “online” :man_shrugging: . So I do understand why they go down that road.

I guess another problem is that currently new PAA (Product Attestation Authorities, similar to the certification authorities in browser world) get added weekly. So you’d have to publish a new updated list quite often.

I mean that is kinda the idea: You trust the vendors product attestation certificate.

We just by default trust all certificates on the DCL, so basically follow CSA’s judgment here (which is based on the CSA membership). Technically it would be possible to create a pop-up everytime you commission a device from a certain vendor the first time: “Do you want to trust products from vendor xy…”. Crytpographically speaking Matter’s device attestation is really a step forward compared to Z-Wave/Zigbee.

2 Likes

Wonder what will happen if I would own a matter device that then is commissioned offline - can it still get updates? :thinking:

I think it was falsely advertised that matter would mandate this - maybe it also just was before matter was finalized… Some big corps in the CSA probably didn’t want to loose their walled garden so they watered the matter specs to the fullest before finalized… :sweat_drops::moneybag::moneybag::moneybag:

Clearly I will never own a matter device as the matter specs don’t allow me even a minimum ownership (and obviously no right to repair/change/modify) :put_litter_in_its_place:

Like having a matter smart plug with power metering capabilities that only can be toggled on/off via matter/ha and the power/voltage/… readings only work with the (obviously crap) vendor app? :clap:

This was the standard before a newer matter spec was released that actually included power/voltage/etc., still no obligatory updates for manufactures/vendors means your limited device will stay limited forever :person_facepalming:

Yeah I mean right to repair is pretty bad in general in consumer electronics :sob: Matter is not better or different to any other standard (or pretty much all, if not all, commercially available smart home devices).

Do you feel you are better off with Zigbee or Z-Wave devices in that term? Their software stack are traditionally very proprietary, which hinders hack-ability. The Z-Wave stack just started to open up a bit recently (e.g. see the Z-Wave alliance announcement about open source). Matter was open source from the beginning. Do you think Z-Wave would have open sourced their stack if Matter wasn’t there? :thinking:

Compared to proprietary smart home devices Matter guarantees you at least local. The Matter spec is also owner centric when it comes to authenticating: As a controller you don’t have to be “approved” by the device. However, the device cryptographically authenticates what vendor it has been produced by to the controller. So there is no vendor lock down: You can control it locally, without the vendors approval. You can use the open source SDK and talk to any Matter device. And since the protocol by itself is local only, there is also no propitiatory cloud dependency. This makes Matter devices clearly much better in terms of ownership compared to many of the proprietary solutions.

Well, that was because Matter 1.0/1.1 did not support the power metering feature. Meross and Eve will definitely add the feature to Matter via firmware update, and I expect that most vendors which produce such devices will do that over time.

In the end, this will differentiate good from bad Matter devices: Do they cover the standard well… Over time, I am quite certain that only the good ones will have a chance to survive. The good thing is that since Matter is backed by Apple/Google, there will be many devices. This will give us consumers more choices :muscle:

It seems you are searching for a new villain in smart home? :sweat_smile: IMHO, it really isn’t Matter per-se. All the proprietary, cloud based smart home crap out there is way worse. Within Matter, maybe you can be critical of particular implementation, e.g. Google or Apple’s cloud based one.