Just some findings for anyone playing with this right now, and the python-matter-server issue queue didn’t seem like the right place to post. I tested with HA 2022.12.3 and python-matter-server 1.0.7. Some particulars might be due to me running Home Assistant and python-matter-server in containers (more details about this setup are in the Standalone Docker image issue).
The HA and python-matter-server containers can’t share a BT adapter (or if they’re supposed to, it’s broken). python-matter-server needs the adapter exclusively.
HA doesn’t see a commissioned device until the integration is reloaded (looks like there’s another issue about this right now)
Once I got the ESP32 paired in HA, it’s sort of stuck because there’s no chip-tool addon.
I factory-reset the ESP32, deleted the HA integration, and deleted all of the python-matter-server data and restarted it.
Then I tried pairing the ESP32 to HomeKit (iOS 16.1.2). BLE got partway through pairing as seen from the console but then timed out even though my iPhone saw the device. But manually pairing using the pairing code worked!
Within Apple Home I was able to toggle the device state, and also change the color of the RGB LED!
Under the accessory details all the way at the bottom there’s a “Turn on Pairing Mode” button. After a second a modal pops up with a new pairing code.
In the Home Assistant Matter integration I pasted that code into “Commission Device”. python-matter-server chugged along for a bit, and then I reloaded the integration and it was added!
Both HA and Apple Home can now control the device at the same time! HA sees device state updates (probably something due to a state subscription mentioned during the workshop it’s now doing?) while Apple Home doesn’t untrue, I am now seeing state changes from HA reflected in Home.
And Apple Home can control the color (sort of, it’s buggy…dimming purple turns to bright green!) while HA can’t yet. They’re both doing this weird thing when turning the light on, it flashes twice. After you set the color you can sort of see what’s happening: the state gets turned to “on” which is white, and then the color/brightness gets set after.
This is all very promising, but it is unbelievably buggy. I almost can’t even believe this is in a non-beta iOS release already, but I guess everyone just needed it to be out there to iron out the kinks. Reading the Philips Hue dev forums it sounds like their Hub firmware is also extremely fragile, so it’s an issue with everyone.
Odd that dbus doesn’t behave, I wonder if the addon has the same problem, might give it a go later.
The led rgb being inverted, is there a way to set the order to grb? I have a different esp32 that needs to be set to grb in esphome. That sort of looks like it might be possible to change in the source file
The HA and python-matter-server containers can’t share a BT adapter (or if they’re supposed to, it’s broken). python-matter-server needs the adapter exclusively.
I’ve noticed too that local Bluetooth commissioning & Home Assistant Core’s Bluetooth integration do not go well together. In theory, it should be possible that multiple Bluetooth clients access the same instance, but it seems that Core interferes with Matter SDK’s Bluetooth scan in a way which makes Matter SDK’s scan to fail. Unfortunately, the Matter SDK Bluez integration is not a very good shape in general, I’ve fixed bugs in there previously already.
In the end, commissioning through the local Bluetooth adapter is kinda uncool anyways, as you can only commission what is within range. The goal is to use the phone app’s Bluetooth capabilities instead. So I am not sure if its worth investing time here. IMHO, commissioning via local Bluetooth is a temporary solution, works for development with the caveat that the Core integration needs to be disabled…
In the Home Assistant Matter integration I pasted that code into “Commission Device”. python-matter-server chugged along for a bit, and then I reloaded the integration and it was added!
Oh wow, that is very cool news, glad that worked This is the flow we intend to support first: Add a Matter device via Google/Apple fabric. This way we do not have to commission a device via Bluetooth
Well I have only tried it with esphome, I haven’t tried the example here yet. Switching the order makes the color wheel line up to the correct colors for esphome where normal order rgb is wrong colors.
Yeah it’s strange… the colors do mostly match up with what the color wheel has, up but there’s a lot of flashing of wrong colors as you drag the color wheel around. It could just as easily be an iOS bug.
@karlshea - Thank you for your post and detailed information. I really appreciate it.
Possibly… or, the early ESP32 firmware example binary may be out of date regarding the Matter Spec. I believe the ESP32 demo firmware was built back in June, and the Matter official specification was released just a month or two ago… so perhaps there is a mismatch? Perhaps Apple’s Matter implementation is up to date with the official Matter specification, while the Nabu Casa demo firmware for the ESP32 is simply using a pre-release demo code base?
I was just able to get a Raspberry PI 4, running HAOS 9.4 and HA 2022.12.6, to pair with my ESP32-C3-DevKitM-1 via Bluetooth commissioning. I am running the Core Bluetooth integration on this development instance of Home Assistant. I did not need to disable it for the Matter BLE Commissioning to work.
Just looking at the color behavior I have a strong suspicion it’s something to do with RGB/HSL conversion. That is based on basically no evidence except for setting it to purple and then changing the brightness slider and watching it go from purples all the way to bright green on the dimmer settings. Could be totally wrong tho!
As far as Bluetooth I wonder if the issue could be something with two containers trying to talk to the Bluetooth socket, whereas with HAOS isn’t the base Home Assistant server NOT running in a container?
Also I noticed for the HA Bluetooth integration one of the requirements is “The host system should be running Linux kernel 5.15.62 or later.” I’m on Ubuntu 22.04 which on my system is currently 5.15.0-56. I’m not sure if there was possibly some fix in .62 that I don’t have, or that wasn’t backported to the Ubuntu kernel.