#Matter just a trick by Google, Samsung, etc to gain visibility on the devices?

1 messages · Page 1 of 1 (latest)

winter dust
#

I've purchased a couple of WiZ Matter Wifi certified bulbs last week and I've been playing around with them.

What I've noticed fairly quickly, was the massive dependency on Google (Android user here) and the fact that Google seems to keep control of the devices even if added to Home Assistant.

#

On top of that, the ecosystem seems to be very unreliable when it comes to pairing due to this cloud requirement, for example in my case, very often it fails at "Generating Matter credentials"

#

Hence, I'm getting the feeling that Matter was nothing else than a trick by the big tech companies to gain control over smart home devices in a sneaky way.

#

So I wonder, isn't there another option to add Matter devices to Home Assistant without being tied to Google or Android or any big company cloud services?

#

It has been very frustrating as a Zigbee user, which has been working fantastic, 100% local, no tricks or nuances, just works.

#

Now we have Matter which should be the next thing, which seems more robust in some aspects, and its a bit of a s**t show.

crude tree
winter dust
#

My expectation was for the devices to NEVER have to connect to anything in the cloud, not Google, not samsung, etc.

#

But the pairing process seems to use Google servers and than just hand-off admin control of the device.

#

However, I don't want any internet / cloud servers dependencies on my smart home devices

tender orchid
#

Android by default uses all Google cloud services so that is not related to Matter but that is just Google policy

#

It is true that the Android framework uses the Google play services to commission matter devices (which is dependent of their cloud, unforytunately) but you can remove google again

#

so the so called "multi admin" feature of Matter also means that you can kick out google from HA

winter dust
crude tree
#

@winter dust you using google home (then moving it over to HA?), from my experience, removing it from google home tends to remove all the admins

winter dust
crude tree
#

ohhhh rightio

winter dust
#

But still need more time to read it thru

tender orchid
winter dust
#

To the point where if I had a Samsung Smartthings hub or whatever it is called, it would onboard the bulbs without Google

crude tree
#

i mean, nothing wrong with using the phones API to commission the devices? makes sense from the sense every phone has a bluetooth access and can commision that way

#

you got a wifi bulb so its a bit different, but regardless

winter dust
#

So I'm getting the impression that we just need to further expand HA mobile apps to achieve a similar behavior, as from what I read, the spec if fully open

crude tree
#

why cant you just import it into HA, then remove the other admins?

winter dust
# crude tree why cant you just import it into HA, then remove the other admins?

well, since I started this thread, it seems that 1 of the bulbs that worked.
However, the second bulb now won't even manage to be added to HA, as it fails at the "Generating Matter credentials", which is a Google step.
Looking at the Matter-Server logs, there is no indication that a request for enrollment even got there yet.

crude tree
#

you factory reset it?

tender orchid
#

If you want to skip the mobile OS api's we offer an option to use a bluetooth adapter on the HA server

tender orchid
winter dust
crude tree
#

you running HAOS?

#

or the docker container? there is a webgui which is pretty dope

tender orchid
#

Not sure if we already documented it, I just got back from my holidays 🙂

winter dust
# crude tree you running HAOS?

No, all docker, but it works pretty much the same way.
I managed to have the 2 bulbs managed in HA, than removed one of them from WiZ app that made it unavailable to HA too.
I still have control of 1 of the bulbs though

crude tree
#

you got a bluetooth adapter hooked up to the host?

winter dust
winter dust
#

just a SkyConnect

tender orchid
winter dust
#

that is used for Zibgee only

winter dust
tender orchid
#

and then in the Matter Server add-on settings you can assign the adapter id (if you only have one, it will be zero). Make sure that HA doesnt take that adapter for the buoltin bluetooth integration

winter dust
tender orchid
#

Yes, for the matter add-on

#

If you want to use it on container.... that is untested

winter dust
#

ok thanks, I will explore this a bit and get a bluetooth adapter

tender orchid
#

a cheap Asus BT500 adapter already works

winter dust
tender orchid
#

But we see so often folks trying to get it working on a nas OS with a 10 years old kernel or whatever

winter dust
#

For example, right now my IOT devices are on a seperate subnet network, to the HA box, but since I'm relaying mDNS requests between the subnets with VyOS, everything works anyway lol

#

than its just firewall rules

tender orchid
winter dust
tender orchid
#

relaying mdns is already awful on its own, with matter it wont work at all

winter dust
#

and 0 issues controlling

tender orchid
#

its all based on Layer 2 neighbour discovery

winter dust
tender orchid
#

So I really advise you to skip that route - it will cause you troubles.

winter dust
#

initially, it was not working, as soon as I allowed IPv6 in all the interfaces in question + enabled iPv6 on the interface running docker hosting HA and Matter-server, everything started working fine.

#

but I think the main reason it works fine, is due to VyOS mDNS repeater component

tender orchid
#

We'll talk again when you are in issues or want to add Thread based devices.

#

I work all day with Matter and Thread - its not going to work

crude tree
#

next you'll say you have a unifi router 🙈

winter dust
#

I want to keep it simple and either Zigbee or Matter Wifi devices

winter dust
tender orchid
#

Still I will not ever recommend mdns forwarders ever - even though the VyOS one is better than awful Unifi.
These protocols are not designed for enterprise networks, just do yourself a favor and keep it simple.
If you want a IoT network, just add HA to that IoT vlan and dont try to route multicast protocols.

We have seen wireshark traces with malformed data or just packets got replicated like a madman.
No thank you. As soon as I hear that a mdns forwarder is involved, I stop support 😉

winter dust
# tender orchid Still I will not ever recommend mdns forwarders ever - even though the VyOS one ...

Initially, the main reason I kept them separate was to make it easier with Firewall rules.
To lock down the IOT network even from the Internet, etc.
While the HA box (which is hosting other stuff, like pihole, etc) is on what I call a "management" network.
Currently, the more I play with some different solutions from what I started initially (I started with Shelly, went to Zigbee using SkyConnect, than ESPHome and now Matter Wifi) I'm getting to that conclusion that I would make my life easier if I just had HA on the same network as all the IOT devices.

I had the requirement of mDNS first with ESPHome and just worked still for Matter.

#

However, the challenge now is that I don't want to dedicate a full box for HA. It's overkill considering that I'm using a 1L PC.

tender orchid
#

Yes, have HA on the IoT network is going to make your life so much easier

winter dust
#

Hence, I need to explore adding the containers to a specific VLan, but some containers tend to want the easy approach of just getting "host" network

tender orchid
winter dust
#

Although I have very little experience with VMs on Linux, the only times I used them was with either Proxmox or XCP-ng

crude tree
#

i mean, i am running HAOS with just the OTBR add-on and Matter-server and its only using up ~2GiB. not really indicative but like its not using much

#

no reason you cant just test it out

winter dust
#

and the CPU doing absolutely nothing lol

#

but I will need to see creating and managing a VM via ssh and how to pass-thru USB devices

#

which might be more work than just figuring out docker networking 😄

#

@tender orchid it seems that there is enough stuff documented in the python-matter-server GitHub readme for me to setup the Bluetooth adapter.
Just one question, I see the example of requesting the commission with the websocket command "commission_with_code". Does any option show up within HA UI to issue this when the matter-server gains access to a Bluetooth adapter?

tender orchid
#

You dont deal with the websocket commands, you can just use the web UI of the matter server

winter dust
#

I can go find out if you don't, it's fine

tender orchid
#

5580

winter dust
tender orchid
#

One downside of this approach is that you need to have the device you want to commission close to the bluetooth adapter

winter dust
tender orchid
#

A phone is more flexible in that regard but the downside is that google/apple claim a spot in their keychains. I just always kick them out

winter dust
#

I wonder to what extent, wouldn't it be possible for the matter-server to use the phone as a remove Bluetooth extension for the provisioning, by communicating with the HA app lol

tender orchid
#

Our dream is to use the HA bluetooth proxies but that would require a lot of work

winter dust
tender orchid
#

yeah, but then we need to create something to tunnel the matter bluetooth communication

winter dust
#

It seems similar but to another device instead of the phone.

tender orchid
#

Its a lot of work and only little gain. For 99% of folks, the current approach using the Phone SDK is fine.
Its also how it is designed - In case of Google its a a bit frustrating that they made it dependent of their cloud framework but maybe they fix that sometime in the future. At least you can remove the google keychain fabric from the device using HA (HA device page, click manage fabrics)

#

For the record: Apple does the same with the keychain fabric but at least that works without cloud/internet so its somewhat better/acceptable

winter dust
#

Is there any benefit, requirement or future benefit in getting a bluetooth 5.0+ adapter?

tender orchid
#

Nope

winter dust
#

To give an update on this, I've bought the ZEXMTE Z01 (RTL8761BU) adapter, mostly due to having the antenas, which seems to help.

#

I then followed the documentation at:

#

So, installed dbus-broker and BlueZ

#

I'm on Ubuntu 22.04.4

#

For dbus-broker, I just ran sudo apt install dbus-broker, followed by systemctl enable dbus-broker.service and a reboot, which worked fine.

#

On the container side, add the volume bind /run/dbus:/run/dbus:ro

#

And added had to include --bluetooth-adapter 0 to the startup command.

#

Then commissioning the bulb (in this case a WiZ Gu10), worked flawless, much faster and easier than with the phone in my case.

#

Like, after giving it the Wifi credentials, it took like 10s

#

The only thing that wasn't clear to me but it accepted it first try, was the pairing code.

#

since on the labels, etc, it shows up as "1234-123-1234"

#

and I though that probably wasn't it, so tried "12341231234" which worked

#

One thing I'm wondering now, can I still share the bluetooth adapter with HA?

#

Even though I didn't pass it to HA, it's showing me having detected a new Bluetooth device, which is odd

#

A "NOKIA WIRELESS BUSINESS COMMUN Unknown" lol

tender orchid
tender orchid
tender orchid
tender orchid
winter dust
#

So I shouldn't need to disable it

tender orchid
winter dust
#

Just meant that HA shouldn't have access to the Bluetooth adapter, even with the integration enabled, because I'm not mapping dbus to it