#devs_matter-archived

1 messages · Page 1 of 1 (latest)

summer basin
#

Hi, what examples files have i to use if i don't flash from browser tool? Examples from esp-matter or from connectedhomeip github's repositories?

bronze bough
#

The new TI sdk came out on the 22nd with a RCP example

solid mountain
#

Is it working with our OTBR? 🥶

bronze bough
#

I haven't gotten it to build yet

bronze bough
#

okay was able to get to build on Linux. Mac just wouldn't let me open the example

#

seems to work 🎉

solid mountain
#

Nice!

bronze bough
#

was able to form a network!

#

can't post images lol

solid mountain
#

For which chip did you compile now?

bronze bough
#

CC2652P

#

don't really have any thread devices (ready) to work with so not sure what else I can do right now

#

I have nordic stuff that I can prep I guess and try with it.

solid mountain
#

I only have two TI devices here, the Zig-a-zig-ah and the slae.sh one, but I think both are CC2652P. is that firmware compatible?

bronze bough
#

No. let me see if I can build one for the zzh (I have one somewhere)

#

I literally just built the example so.

solid mountain
#

I am guessing you built for your CC2652P2 puck?

#

I guess I could order one 😄 Are you planning to publish firmwares for it?

bronze bough
#

also happy to send you a device for testing

solid mountain
#

The SDK comes with a OpenThread version with the last commit from "Sat Jun 4 01:59:16 2022 +0800", so fairly recent firmware. I think that should be Thread 1.3 capable, and therefor suitable for Matter.

bronze bough
#

okay trying the zzh build now

#

hmmm I just get this repeating when I try to start OTBR addon. [16:19:09] INFO: Setup OTBR firewall... ip6tables: Chain already exists.

#

maybe I didn't chose the right device

#

to build for

#

okay must of been my system and the state of the addon

#

tried on a vm and it worked.

solid mountain
#

If restarting the addon doesn't help, you might need to restart the system

bronze bough
#

ah good to know

#

well you can try with your zzh! now 😉

solid mountain
#

Awesome thanks!

#

What is the difference between the two zip files?

#

Ah nevermind, got it now

solid mountain
#

Just flashed the firmware on my end with zzh! I was able to commission a Thread based nRF52840-DK with a Matter firmware. zzh! was plugged in a Yellow (because, why not 😅 ). So seems this firmware works with the OTBR add-on and for Mattter 🎉

#

Thanks @bronze bough !

bronze bough
#

Nice!

eternal falcon
#

I tried using the thread android app, it recognise the openthread addon on my wifi network, but when I try to comission a thread bulb, say that the QR code is not supported

eternal falcon
#

Im using the Nordic semiconductor

#

I can't use the matter add-ons becouse is not supported on home assistant supervised

solid mountain
solid mountain
#

However, for Matter a different QR code format is used. The commissioning of Thread is part of the Matter commissioning. All you need to do is tell the Matter stack the Thread network credentials. That is done through a service currently. The service has a hint how you can get the credentials from the OTBR addon (involves manually docker exec'ing into the addon currently)

wooden badger
#

As esp32-h2 seems unlikely to become publicly available this year, I'm looking into alternatives for DIY tinkering with matter-over-thread. I've got a bunch of bl70x but their toolchain and stdlib is... not useable for me. What are y'all using for that ?

bronze bough
solid mountain
#

FYI, working on bumping everything Matter to master currently, including the ESP32 example apps. I just saw now a PR that the ESP32 example apps get bumped to their latest IDF release 4.4.2 https://github.com/project-chip/connectedhomeip/pull/21815. So probably another bump upcoming soon 🙂

rare zinc
#

I'm trying to understand something about Matter and specifically Multi-Admin.
Will that be possible for Zigbee devices connected through a zigbee2matter bridge as well?
Or does the device itself need to be matter compatible for this to work?
Anyone know?

solid mountain
#

"Multi-Admin" is a Matter feature, allowing to control a single Matter device from multiple Matter networks (aka fabrics).

rare zinc
#

So, that's a no?

solid mountain
#

If the Zigbee to Matter bridge is a propoer/certified Matter device, it will have to support Multi-Admin. So that should work as well.

rare zinc
#

Cool.
Of course it would be better if the end device was matter compatible directly. but swapping out all zigbee devices to something with Matter support built-in isn't gonna happen. Too many.
So if the bridge is that one handling the matter mutli-admin part that's awesome 😄 Then I can share all the "house alarm" zigbee sensors with a 3rd party matter hub from the Alarm company. And still have access to them in Home assistant for automation stuff.

summer basin
#

Hi

#

Hello

odd blade
# summer basin Hi

General hi is best kept to the #the-water-cooler channel, rather than posting it all over the place. Unless you're slowly working up to a question that's relevant to this channel?

karmic plover
rare zinc
#

Would of course be best with "pure" matter support directly on the device it self.
But if Multi-Admin will be possible with a proper Zigbee to Matter bridge that helps out a lot on zigbee devices that will never get updated.

proud bronze
#

I would assume the bridges will support matter, not the devices themselves? ZigBee networks don't support IP Protokoll as far as I know

#

Like it will be for hue

true crown
#

I'm working on integrating Google's Matter device commissioning flow in the companion app, which then can be called from the frontend, and after commissioning to Google's fabric the app receives an 8-digit "passcode" to handle commissioning. Entering this in the commissioning service in HA generates an error, is this expected and not supported or likely a different problem?

#

Service error: "Failed to call service matter_experimental.commission. Command failed: CHIP Error 0x00000013: Integrity check failed"

tender oxide
#

That seems like a too short code

#

It needs to also know which device

#

We did a share commissioned device during our matter workshop

#

If you check the stream you can see it. Near the end

tender oxide
#

@solid mountain I guess our pairing with code service does not support pairing an onnetwork node

#

CommissionOnNetwork we need to call this method

tender oxide
#

ok I got it

#

I am opening a PR

#

are you having a Matter dev env set up or are you using the add-on @true crown ?

tender oxide
true crown
#

The 'device' I'm using is a virtual device from a dev setup but I'm very much following Google's tutorial and don't know more

true crown
tender oxide
#

Right yeah that code can work once my pr is merged and released

#

I probably won't have time until next week for that

#

Maybe I can sneak in some time tonight but weekends are for kids

#

And I once again broke my local build

true crown
#

Enjoy your weekend, I can wait 🙂

tender oxide
#

here is the bump to the latest Matter

#

seems to work fine on my end from a quick test

#

will ask Stefan to verify it works on Monday and then we can ship an custom component / add-on bump

glacial maple
#

Hi, I am new to Home Assistant but curious if its possible to make a discoverable gateway? I'm familiar with BACnet systems with professional work experience as a field technician for HVAC and Python BACnet stacks....just curious on the In's & Out's if I could contribute some sort of BACnet gateway for Home Assistant.

tender oxide
#

This is the wrong channel for that question.

glacial maple
tender oxide
tender oxide
true crown
#

Sounds good!

#

I received the ESP32 devkit earlier today (thanks!) and am about to flash it, I'll use it once the add-on is updated to test

#

Was updating to 1.0 intentional or just coincidence?

tender oxide
#

coincedence

proud bronze
#

I don't remember exactly where, but it was mentioned that HA will be able to expose all supported device types via matter. Will this change the way how we integrate voice assistants when they support matter as well (as Google and Alexa will)?

tender oxide
#

it's supported by the Matter spec but not something we're currently focused on

tender oxide
#

@true crown have you been able to make the new service work ?

true crown
#

I have a lot more time tonight (EU time), so hopefully I can get it to work. If that also won't work I'll collect logs to create an issue.

tender oxide
#

I don't know what version Google is using, the v1 tag is pretty new

#

make sure you flash the devkit with the version we uploaded like 2 (?) days ago

true crown
tender oxide
#

we need to update it manually

#

but it's the goal yes

true crown
#

Can't get it to work 😔

  1. The devkit doesn't want to be commissioned using the flow on Android, but it does work correctly using HA service. Logs for both the devkit and phone indicate a handshake timeout. https://gist.github.com/jpelgrom/5c6e2ea36313d0a02fc08579ee7c8661
  2. The virtual device from Google's codelab cannot be accepted in Home Assistant, after entering the code there is a lot of activity but no entity appears in HA. https://gist.github.com/jpelgrom/3fa9520dea2e86d4cd031196456e0af7 (looks like the addon logs are truncated, hopefully there's still something useful in there)
    Looking at issues on https://github.com/project-chip/connectedhomeip there are some related ones with similar errors, but I don't know what is relevant and what isn't. Hopefully someone can take a look at these log files and provide steps to try or indicate where/how to file an issue.
tender oxide
#

meh

#

I think it's a version mismatch

true crown
#

That's annoying

#

Google doesn't offer an update button

tender oxide
#

yeah you need to wait till they can roll it out, however I can check

true crown
#

That'd be appreciated

#

Still a bit weird considering that they made it available to developers, you'd expect it to work with a recent version

tender oxide
#

right now it's the wild west, once 1.0 is released there are no more breaking changes

true crown
#

1.0 tagged != 1.0 released?

tender oxide
#

Correct. It's not tagged, just created a branch that will be v1

#

I checked with Google about your issue 1, which should explain the rest too probably

true crown
#

OK, keep me posted

tender oxide
#

always 🙂

tender oxide
#

You need to enroll in the beta program to get latest and greatest Matter

true crown
#

The (public) Play Services beta is full

true crown
#

Received an update to Play Services 22.33.16 (150400-474895102), and commissioning the devkit using Google's flow and then in Home Assistant is working 🎉

#

Without a Bluetooth adapter or WiFi credentials set in Home Assistant

true crown
#

Hopefully this is just a development limitation but maybe you could ask your contacts at Google @tender oxide ?

tender oxide
#

I wonder if pin is tied to VIN?

#

So you need a new commission code

true crown
#

The devkit's VIN doesn't change

#

At this point I'm using the QR code, not the PIN

gusty pebble
#

So I haven’t been able to get matter working on my Hass install yet. But I just now paired my workshops test board to my Apple Home app.

barren flame
tender oxide
undone grail
kind sedge
#

32 bits or 64 bits OS ? You might run into some issues on 32 bits ARM

undone grail
#

Ah that might be a problem, I still havent changed to 64 bit. Maybe this is the motivation I was looking for

vague drum
#

Wil it be a requirement to have a Thread usb dongle like the sky connect to start using the HA Matter integration with Matter/Thread devices or will any border router suffice?

sage sail
#

Good question. Was hoping the latest nest hub will work once upgraded

pallid thunder
#

in theory you can use multi-admin to control a device connected to a existing matter coordinator (like the nest hub), so possibly

I've tried getting Google on my phone to become a admin of my Dev kit, but it might be doing a full compliance check and the Dev kit doesn't pass that

kind sedge
kind sedge
true crown
sage sail
#

Congratulations on the home assistant matter job! Looking forward to good things to come.

undone grail
sage sail
#

Is the only way to play with matter and HA still with that specific dev board from the demo back in June?

tender oxide
#

You can also run Chef

#

It’s an app from the Matter repo

#

That will expose different Matter devices

opal linden
#

Not matter, but a few people are running homekit over Thread in HA 2022.10 with Eve, Nanoleaf and Wemo products to get their home networks in shape for Matter. Good way to shake out whether your ipv6 routes are propagating from your border routers properly etc. Most of the issues I’m getting are because their networks aren’t very ipv6 friendly (bad wifi repeaters, mesh addresses not available between vlans, in my case my HomePod keeps changing wifi networks for shits and giggles)

barren flame
#

There's a meme to be made about having too many competing thread networks :p I count no fewer than 3 (one from nest protect devices, one from a nest hub, and one from Apple). I'm hoping I can merge them in the future when the platform owners provide a method to commission their hubs into an existing network.

halcyon violet
#

I was under the impression that Matter enabled border routers were generally expected to be joined onto the existing thread network when they are added to an existing Matter fabric. In theory the same thread network commissioning APIs are supposed to work on Matter enabled border routers as work on all other thread powered Matter devices. In practice, I'd be rather unsurprised if this did not magically just work, especially if testing of these things are not part of the Matter certification.

kind sedge
#

correct that is the theory, although yet I have to see it in action

gusty pebble
#

With HA having Matter since june in experimental mode, I would have expected a sooner launch of it in the main system. Whats the likelyhood of seeing it in 22.11?

#

I do have to say I like having that little dev board in Apple Home, Smart Things so far.

kind sedge
#

Matter support in HA won't be in 2022.11 but we're aiming at 2022.12 - still some things to do to move it from experimental to a fully working (beta) solution with lots of moving parts

opal linden
#

@kind sedge we’ve been experimenting with thread support in homekit_controller. So controlling nanoleaf, eve and wemo devices over thread but with the HAP protocol. It’s live in 2022.10. I’ve been meaning to touch base as some of the issues we’ve seen will probably impact matter (ipv6 on people’s home networks… oh boy).

#

Was wondering about starting some docs on some of the gotchas we’ve seen and seemed like sharing that with the matter integration some how made sense

kind sedge
#

Good idea, Matter indeed heavily depends on a reliable ipv6 infrastructure

opal linden
#

Not sure where the best place for it is though - for Bluetooth there is a Bluetooth integration that we can hang off, but I don’t think there is a thread integration.

kind sedge
#

Would also be interesting if these Matter capable devices can be controlled by both HAP and Matter or Apple only supports one way

#

I guess that Apple will support both in the border routers

opal linden
#

Yeah will be interesting to see

#

The eve devices I’ve tested with seem to not want to talk ble when they have a working thread convection

#

So I don’t know if that will confuse the normal enrolment process

#

And I guess they’d not want to have users pairing the same device twice on the same homekit instance

#

One problem we’ve seen with ipv6 is sometimes the “route info” part of the RA from the border router is dropped by Linux

#

We’ve found a sysctl that seems to “fix” it but would be good to see if you guys have seen it and why it might be needed

#

I’ll try and summarise some of the stuff we have seen in a gist, and then we can see what we might need to add to the HA docs.

kind sedge
#

nice!
So far we're focused on getting the server part in shape where we host our own Matter controller as add-on.

peak lantern
solid mountain
#

I still have to dig into that for HAOS.

opal linden
#

@solid mountain ah, thanks for that link. it is indeed accept_ra_rt_info_max_plen that i needed. though some people seem to report not needing it.

solid mountain
#

We probably have to tweak the default there so HAOS accepts the RAs of other OTBRs

#

Yeah it seems there are some other factors (e.g. if IP routing is enabled, maybe also the OTBR start script do something, not sure)

#

and I guess most of all: distribution default 😅

opal linden
#

i had one user who wanted this to work cross vlan so set accept_ra to 2 and installed a custom kernel on their main router (a unifi dream machine?) because it doesn't even have accept_ra_rt_info_max_plen by default 😱

solid mountain
#

Yeah Matter/Thread is not well defined for these use cases. Besides the routing you also have to get the multicasting stuff right

kind sedge
#

It really is not designed to travel multi vlan, Its aimed at consumer grade networks

opal linden
#

Unifi has a reflector for mdns by default so they get discovered out of the box, cross vlan, but then you can't connect to them

#

We probably want to filter them out of config flow discovery really

kind sedge
opal linden
#

Yeah, my HA has an interface on the IoT vlan. simple. reliable.

solid mountain
#

From the Matter spec:

Canonical networks supporting a fabric may include a Wi-Fi/Ethernet subnet, or one or more low power and
lossy networks (LLN) subnets.

#

I mean, VLAN is just a technology to create subnets. As long as Matter/Thread operates in that subnet, whatever, its fine. Just crossing Subnets is not really defined/supported, unless its to connect a low power network via an OTBR.

opal linden
#

Yeah, im pushing people towards not trying to make it work cross-vlan atm (of course some do anyway)

#

Someone pointed out that their Apple TV was on a different VLAN to their HomePod. Wasn't really sure what would happen there.

#

If BR's are all active, it would just work. But if theres only one elected BR, it would be sad times

solid mountain
#

I do like the IoT VLAN idea, I operate a IoT VLAN myself but haven't migrated all my IoT devices on it (no other reason than because I am lazy 😅 ). But I think we should not try to make Matter/Thread work accross them. IMHO, what would be nice if we can dual-home the Home Assistant instance, and define the Matter/OpenThread interface.

opal linden
#

Yeah

#

Until my yellow gets here i'm running the container, and its multihomed with macvlan interfaces just like that

halcyon violet
#

Yeah cross vlan support (or just general cross subnet support) is probably tricky. Ipv6 lacking a default gateway concept means that cross vlan support requires that at least one router that connects both vlans accepts the RA into its routing table, and readvertises the prefix on other interfaces specifying itself as the router. I suspect many routers simply don’t offer that.

#

Some might work if the Thread border router is able to get a prefix delegation from the edge router, and the edge router advertises all prefixes it got from the ISP. But then many people with multi-vlan setups will have restrictive ACLs or firewall rules in place. Obviously that is all on top of needing mdns repeater for discoverabliaty across vlans.

#

But I fully agree it is not HA’s job to support that. If people want it to work, and know networking well enough to set up vlans, they need to learn enough to set up mdns repeating and ensure routability.

subtle berry
halcyon violet
#

The trickiest part of Matter in terms of networking is not just Wi-Fi to Ethernet ipv6 connectivity (which the phone app could reasonably check), but the existence of Thread. As long as you are not using fancy things like vlans, the majority of home networking equipment can handle basic ipv6 traffic on the single subnet. But more advanced features used by Thread like handing a second router issuing RAs with route information options (RIO) rather than prefix information options (PIO) is not an especially well tested scenario by home networking manufacturers.

A really good matter test would require a phone with thread hardware so that those sorts of edge cases could be tested. Admittedly a basic ipv6 test is still not a terrible idea, since if that is broken, Matter simply won’t work, but such a test passing would not be especially definitive in saying that Matter will work in the network.

kind sedge
#

Good suggestions. Maybe we can add a few tests in the server as utility functions

#

I do remember I've seen some "is my network ipv6 ready" tests before

true crown
kind sedge
#

yeah, I've opened that qr-code link already like 10 times, but nothing seems to happen in the app so far.

#

I was really curious to try it out 🙂

true crown
#

I can see the Get pairing code screen but it gives an error

#

Guess the bridge update takes some time to process

mortal meadow
kind sedge
#

current scope is consuming devices via Matter and multi admin compatibility.
next phase could be the other way around where HA is a matter bridge on its own but not for now

true crown
#

Definitely wasn't there a few days ago

kind sedge
kind sedge
true crown
#

Not sure how it works exactly, you're more familiar with that 🙂

#

The last used time corresponds to the last time I opened the Hue app

kind sedge
#

Most likely the bridge runs the Matter SDK and they created an application that maps the Hue devices to Matter.

kind sedge
#

I may have found a challenge.... root certificates.... Let's see if we can figure that out next week

umbral bramble
#

Hi.

If i'm reading recent comments correctly (Still getting my head round how Matter is expected to work) the plan is initially that home assistant will be able to subscribe to matter end devices, but that as of yet there's no firm plan in place to allow Home Assistant to publish its existing non-matter entities as matter devices on the network (ie Matter Bridging)

Have i got that right? That would place HA in a similar position to smartthings (where a matter bridge is not being made available) but different to Hue and Aqara who have publically stated that their bridge devices will advertise existing entities as Matter devices.

Thanks

tender oxide
#

Correct

umbral bramble
#

Thanks

fiery stump
true crown
#

No, the option is available for me while I'm still waiting for the firmware update

kind sedge
fiery stump
gusty pebble
#

@kind sedge if you have “smarthome and voice” in your hue app you are registered. Now waiting for the beta channel firmware. 7!day waiting period. Then you should see matter in that smarthome and voice menu where only have homekit now.

kind sedge
gusty pebble
#

Guess we can share pic here’s

#

iOS and android

fiery stump
#

iOS app was updated today / yesterday

summer basin
#

do you get a error when getting pairing code

true crown
#

Did you update your bridge firmware yet?

#

After updating getting the pairing code initially works, once you close the screen it seems like you have to wait some time before you can get it again

summer basin
#

just saw the update now

true crown
#

Amazingly enough, the lights mostly seem to work using the 0.3.0 experimental Matter addon

#

They all get 2 controls, on/off and on/off with brightness, but it's a start

kind sedge
#

Yeah it needs a lot of work and the 0.3.0 addon is probably not the best point to start. Refactor of the server component to work towards the final state is making progress. Today actually had a chance to test it with a few manufacturers which is great.

true crown
#

Yes but 0.3.0 is the latest easily installable version 🙂

#

Still great to see it work with a device that wasn't tested before

kind sedge
#

there's nothing yet to install 🙂

kind sedge
true crown
#

My IKEA lights that are connected to the Hue bridge don't seem to have any brightness controls, just on/off, but I'll wait for a newer version before doing more testing

kind sedge
true crown
#

So much pre V1 everywhere

#

Tried pairing the bridge to the Google Home app and it errored during setup because I guess the Matter libraries on the phone are too old, again

kind sedge
#

Yeah its all very early stage and everbody is completing their final implementation (for V1 at least) but its looking very promising.

true crown
#

"very early stage" yet we've had two Matter launches (1.0 standard and last week) already 😅

warm magnet
#

Sorry for the newbie question - but how does the security model in Matter work for HA? Every device has their attestation certificate etc. so standard commissioners use that to verify if the device can join the network. We probably can't get an accepted certificate for HA in any way, so HA can't join an existing fabric, if the fabric is already managed by Google, Apple, whatever?

In the other direction, HA being the commissioner can obviously accept every Matter device into the fabric - but for that to happen, does HA need to run a CA? Does it need to have a self-signed trust root and sign certificates for each device? Or, even more, does there need to be a CA at Nabu Casa which would be used for these things?

#

BTW, I can buy the Dirigera hub from a local IKEA (saw them in the store) and the new IKEA Smart Home app seems to be working as well.

gusty pebble
#

Last week was the Grand opening Extrava-sava-festa-thon as opposed to the initial soft launch. Ikea's Diribile hub, not yet certified, or updated.

kind sedge
#

@warm magnet HA will be a valid Matter controller (build on top of the official SDK) and will use the attestation certificates. For Multi-admin you can share an existing device on an existing Fabric (like amazon, apple or google) to HA and the other way around.

kind sedge
warm magnet
# kind sedge <@512949563850752002> HA will be a valid Matter controller (build on top of the ...

That's not exactly answering either question. I understand that a single device can join multiple fabrics. So my question number one - can HA join an existing fabric by Google, Apple, etc.? That is, as a device itself, or as a bridge, or just to command devices - I think the answer to this is no, because nobody will grant an attestation certificate to HA, because that requires official Matter certification, and since HA is customizable, no certificate can be trusted to remain secure or to adhere to the specifications.

Second question is that when we act as a commissioner/coordinator/etc. will Home Assistant need a self-signed CA certificate and will it sign certificates? Does it act as the Administrative Domain Manager (ADM)? Will Matter devices send Node Operational Certificate Signing Requests (NOCSR) to HA, and we deliver Node Operational Certificates (NOC) back to the devices? Or will Nabu Casa run a central CA that the commissioner talks to? Or how does this work?

gusty pebble
#

@warm magnet I think what you are trying to ask is if HA will be a Matter Bridge exposing its various Zigbee/zwave or other devices to other matter fabrics like Apple, Google and Amazon as well as being a Matter Controller. What some circles call a 2-way Matter controller?

warm magnet
#

Well, that's one possibility. Simply acting as a single end device is another - and many others. I'm simply asking if it is possible for HA to join a fabric managed by someone else.

gusty pebble
#

I think thats what Multi-Admin is.

#

My Hue Hub now is a Matter Bridge. Its paired to Apple Home. But it can pair to Smart things or HA and its devices would all show up in those controllers too. Smart things, is a Matter Controller, no device goes out to other controllers.

#

matter doesnt cover one controller controlling another. A Scene made in Apple can only be triggered in apple. but you could create the same scene in HA, smartthings, and Apple and then trigger it with your UI of choice.

kind sedge
#

First things first. Home Assistant will start with a controller implementation, which we base around the official Matter SDK and even try to get it certified. This means that HA will have native support for controlling Matter devices using it's own fabric.
Due to the concept of Multi admin you can add Matter devices to multiple fabrics (=controllers) at the same time. So pair a device to Apple, Google and Home Assistant at the same time is no problem. Both platforms will facilitate nice UI options to easily share a device to another platform. So for instance you can select a device in Google/Apple Home and select "share to" where you can share the device to HA.

#

If we have all that working (we're aiming to have a first MVP in december) we can polish it with additional features and at some point there might be interest in creating a separate component to turn HA into a bridge device of it's own. For now that is out of scope and needs a lot more discussion first but the idea is nice.

#

@warm magnet we're implementing a standalone "Open Matter Server" which will act as virtual hub between HA and Matter. This server based on the official SDK will do Attestation checks just like any other implementation based on that same SDK such as Google Home, Apple, Amazon etc. A device undergoes official certification and will be signed using a root certificate authority. The HA Matter server checks the device certificate against root certificate authority for the Atestation test, easy as that. These root certificates are auto retrieved by the HA Matter server using a webservice and auto updated when new devices get certified.

For DIY devices (and now during beta phase) there are DEV certificates available so in theory you can also create your own devices that are Matter compatible.

kind sedge
kind sedge
# gusty pebble matter doesnt cover one controller controlling another. A Scene made in Apple ca...

It all depends on the device but this is all part of a lot of discussion. For example a lock device can store all codes created by all fabrics on the device itself making them effectively available to all fabric controlling it. I can imagine manufacturers implementing the same for scenes on lights. In the end there are some discussions going on for some sort of intermediate or admin fabric as a management fabric to store all common objects.

gusty pebble
#

great explanation. So we can hopefully expect 22.12 to drop the matter implementation? It's too bad about the Bridge component missing at first.

#

@kind sedge My home is already turned upside down right now between migrating from the IKEA Tradfri to Dirigible hubs, and now that Hue's own Matter firmware is available for beta testing. I've been trying to see what I can feed to my hue hub and take off HA's ZHA and Smartthings hubs.

kind sedge
# gusty pebble great explanation. So we can hopefully expect 22.12 to drop the matter implement...

Yes, that is the idea. We actually tested our implemention with several manufacturers last week and first results are great. So we're aiming at releasing a first beta for Matter support in HA in december but you should not expect too much because Matter support is not yet mainstream. There are no devices available, except for a few beta releases like Hue and Ikea. But yeah, it would be great if people activate the beta on their device/hub and start testing the betas. The real game changer will be when there are devices released with actual matter support. So for example you can but a WiFi sensor or actor device with Matter support and you can add it to HA without the need for any chinese cloud or 3rd part hub. That is when things are really going great.

Enabling Matter on you Hue bridge is great but Hue already has a local API which will be more feature rich than Matter is ever going to be. So it will not make any sense to add Hue to HA using the Matter route, you will prefer the already existing native Hue API for that.

kind sedge
# gusty pebble <@461603794090852353> My home is already turned upside down right now between mi...

Do not worry too much about it, their new hub supports both zigbee and thread but the majority of devices is still zigbee. If you are in doubt between the Hue bridge and the Ikea one my personal preference would be the Hue bridge (as that is very stable and feature rich) and using another route for Thread based devices. A Thread border router is/will be built into several devices such as the Google Nest Hub V2, Apple TV 4K, Nest Wifi Pro etc. Or you just pick a Thread stick such as the Home Assistant Sky Connect 😉

elder oak
#

@kind sedge will the December HA Matter release support talking to a external Matter Bridge, e.g. Aqara or Hue, Ubisys? The Hue API is indeed much richer than Matter will be for the foreseeable future.
Reason I ask is I started to implement a own Matter Bridge (from scratch, not using the SDK) and it would be pretty nice to be able to cross test with HA as Matter controller.

warm magnet
tender oxide
#

Yes it will work with other Matter bridges. They are just Matter in the end

#

Marcel is already testing with Matter connection to Hue bridges at home as his bridges are on the beta

warm magnet
tender oxide
#

Although our Hue APIs integration is going to always be more powerful than Matter

warm magnet
#

So, extrapolating from the answers I've got, I think I can guess the answers to my actual questions:

  1. Question: Can HA join an existing fabric as a device/bridge/whatever? Answer: Don't know. Currently this work is fully out of scope so we don't care.
  2. Question: Does HA need to act as a CA and issue certificates for devices joining the network? Answer: Don't know. We just use the official Matter SDK, so the CA and signing processes are probably embedded inside that SDK but we haven't looked. There are no plans to have a central Nabu Casa CA or anything like that, even though the Matter ecosystem would support such an approach as well.
#

Please correct if you think my guesses are wrong.

elder oak
#

Perfect thanks, that sounds good. My work on the Bridge is in very early stage, currently getting the crypto code up and testing against the test data in the alliance repo as well as the mDNS discovery. Hope to get something up on Github in January/February

#

Attestation is my biggest concern for the big players, I'm not sure if Apple and Co. will allow the users to accept uncertified devices. Unfortunately in the specification this is a MAY but not a must.

tender oxide
#

Not sure what language you’re using but there are implementations ongoing in JS and Rust

#

Which are public

tender oxide
elder oak
#

Yeah I looking into these for reference and validation things work correctly, also super nice that this time the alliance repo has a reference implementation. This is super helpful compared to the closed Zigbee stacks of the past

#

With the Yellow and SkyConnect you could embed certificates in the firmware at shipping time not sure if that would be sufficient.

tender oxide
#

True, but we don’t want to lock down Home Assistant

#

And will avoid that as long as possible

kind sedge
elder oak
#

Yeah valid point, I think the best would be for the alliance to mandatory set that straight in the spec, that non CA root signed certificates can be accepted as the user allows it. Like HA having its implementation using a a offcial HA certificate and the user trusts that certificate.

kind sedge
elder oak
#

Time will tell, hopefully it stays this way

kind sedge
kind sedge
elder oak
#

Right but the dev certificates are kind of anonymous, a own certificate would have the details like this is the official <enter name here> certificate, but in the end... user just want to get their devices working 🙂

tender oxide
#

The problem is that it wouldn’t work for another controller.

#

And dev might

kind sedge
#

I expect that custom devices will just be based on the SDK and reference implementations and thus using the dev certificates. Creating your own implementation not using the SDK and not using any of the available certificates will just lock you out everywhere unless you are going to be officially certified.

elder oak
#

Agree, SDK + dev cert will be the most popular choice. Ultimately the Bridge will be certified, that's per device type it supports as I understand the spec. But this is a long shot and heaps of work ahead. Not sure yet how it all will be handled by the alliance, in the past it was required to certify each firmware update, which makes sense but nobody really did it.

tender oxide
#

We’re going to certify our server as a software component. @kind sedge is a certified re-Certifier with the alliance and can recertify it

#

From talking to other controllers relying on software component, takes around a day and a half to recertify

kind sedge
warm magnet
# kind sedge 1) No that is not possible. HA is the controller, not the device. A controller (...

On 2) When a node is commissioned in to the fabric, the node generates "Node Operational Key Pair", which is a fresh key pair. This keypair is then used to create a Node Operational Certificate Signing Request (standard PKCS #10 certificate). The attestation stuff is included in this CSR, but CSR is not generated for the attestation private key, but instead the fresh operational key pair. The CSR is given to the commissioner, which gives it to a Certification Authority to be signed. The Certification Authority returns a certificate to the commissioner that the commissioner then sends to the node to be stored by the node. It is really explicit that the CA here is not the device manufacturer CA, but instead a CA being the root of trust for the speciific fabric. The commissioner is a device with an user interface, like a smartphone, which talks to the Administrative Domain Manager. So for example, I would expect that in the Google ecosystem, my phone is a commissioner, but the Administrative Domain Manager / CA is managed centrally by Google and does not reside on the phone or any other device in my home. This is all described quite clearly in this picture: https://developers.home.google.com/static/matter/primer/images/primer-csr.png

#

Or is that documentation woefully out of date and Matter has changed the security setup to something totally different?

kind sedge
#

Correct, so we check the device against the root CA authority to double check if the device cert has been signed by the root authority.

warm magnet
#

You are not listening on what I'm saying... sorry. This is different from the attestation CA!

#

Device Attestation Certificate is signed by Product Attestation Intermediate Certificate, which is signed by Product Attestation Authority which is a CA. That's not the CA I'm talking about.

kind sedge
#

OK, you made the confusion yourself talking about Attestation. You are talking about security now

warm magnet
#

Yes, I'm talking about security, if that helps the context. Attestation is included in the CSR, but that's a separate process from the security part.

kind sedge
#

This is handled by the fabric. The SDK takes care of that and is in fact a certificate authority

#

So yes, that picture is still correct

warm magnet
#

Okay, wonderful - that's what I was trying to ask. So even though Google is the CA for every fabric managed by Google - we are not planning on making Nabu Casa be the CA for every HA managed fabric - but instead manage the CA internally in the SDK and just store the private key locally in the HA. So the root of trust in the HA and not external.

#

I use "we" very liberally, that's just the way I talk, no deep meaning implied.

kind sedge
#

Yes correct and that is true for every fabric

#

So each fabric has its own certificates and trust with the device

warm magnet
#

Own certificates and root of trust yes - but I don't think the CA is local necessarily. Not for Google, Apple, etc.

kind sedge
#

So when you enable "sharing mode" on the google fabric you just open an comissioning window for another fabric.

solid mountain
#

Yeah I am pretty sure the operational root of trust (as it is called) is assigned with your account for Google/Apple and stored in the cloud

#

Their commissionier will talk to their cloud and to get NOCs

kind sedge
#

We will store the info within the addon data

solid mountain
#

But for HA, it will get created by the Matter Server (as the SDK provides this information).

warm magnet
#

Wonderful, now we are all talking the same language. Understood and agreed, that's the way it looks.

kind sedge
#

So while Google and Apple will store that info in the cloud (end to end encrypted I guess) we will store it on your local HA instance, in the addon to be exactly

#

and that folder can be backupped by you

warm magnet
# kind sedge 1) No that is not possible. HA is the controller, not the device. A controller (...

Now on 1) I'm not sure what "controller" in Matter actually means. How I understand it, Matter has "commissioners" which might be just smart phone or something, and it has a Administrative Domain Manager which is used by the commissioners, and then it's just a bunch of nodes talking to other nodes in the same fabric. Any node can command any other node, within the boundaries of the ACLs. But if you mean that HA is always the Administrative Domain Manager with it's own root of trust, then yeah it's obvious it cannot be a part of another fabric. But, as far as I'm concerned, HA isn't anything yet, as support is being built. And my question was that is there any chance of HA joining an existing fabric as a node - or is the only chance that it runs its own fabric and relies on multi-admin for onboarding each device separately onto the HA fabric as well.

kind sedge
#

HA will NOT join an existing fabric as a node. HA is the controller of multiple nodes, in Matter terms the Cluster admin and Device controller. It is not a node on its own. For MVP we most likely rely on commissioning from the iOS and Android apps to prevent the additional complexity of bluetooth commissioning.

So you will be able to add a matter compatible node/device to the HA Matter controller so you can control that device from HA. At the same time you can also add that same device to the Google, Amazon or Apple fabric but you do not have to.

#

Each device can handle 5 fabrics at the same time (minimum per spec, could be even more)

warm magnet
#

As long as Google etc. allow the user to bypass failed attestation, there's not a technical reason why HA couldn't just join the existing fabric, is there? I'm not saying that it is what HA is going to do, I'm just asking if it is possible technically?

kind sedge
tender oxide
#

yes it's possible, and then expose other devices as a bridge device. But that's not what we're building today

#

and that's not what our server is build around either

#

so the SDK can do many things, but we're just using it as a controller

#

the other direction, it's out of scope

warm magnet
kind sedge
#

Yes it is possible

#

But out of scope

#

A bridge device such as the Hue bridge is an example of that

warm magnet
kind sedge
#

You can control the zigbee based Hue lights over matter

kind sedge
kind sedge
#

We will have to see if they will still allow that bypass in later releases

solid mountain
warm magnet
warm magnet
solid mountain
warm magnet
# kind sedge Why not ?

Device Attestation Certificate needs to be signed by a Product Attestation Intermediate Certificate, which needs to be signed by a Product Attestation Authority. So we need our own "Product Attestation Authority" for Home Assistant - and I don't think anybody else is going to accept that as the implementations are freely modifiable by users so they can't ever promise compliance to any spec?

kind sedge
# warm magnet Device Attestation Certificate needs to be signed by a Product Attestation Inter...

Well, this is all very theoretical and very out of scope but you could imagine a situation where we want a "virtual bridge" between HA and Matter (so the other way around). That would probably be a candidate for an additional addon or custom component without any certification. For now we are aiming at a HA controller for controlling Matter devices in HA and that is what we will try to certify.

The other way around, like the bridge between HA devices/entities to matter is a whole different story.
Maybe we can get that certified too but I guess only if there's a closed source component involved, something we're exactly want to avoid hence its out of scope.

#

I can imagine some people will get creative and build something like that at some point, like Homebridge already exists for homekit

solid mountain
#

Device Attestation Certificate does not mean a device is certified. There is a seprate signature (Certificate Decleration) which does that. So we could have an official PAI/PAA/DAC chain, and ship something without a certification... Theoretically possible. As long as its not certified you just can't call it an official Matter device, essentially

kind sedge
#

Big question remains if Google/Apple etc will still allow that "bypass attestation" in the longer term. I have a feeling they won't somehow

solid mountain
#

I think they will always, it will just be hidden behind developer flags

kind sedge
#

Point is, it's all guessing now. We're not sure. Let's see next year!

warm magnet
solid mountain
#

I think Nabu Casa as participant could do that no problem

kind sedge
#

exactly

solid mountain
#

Just having the PAA in the ledger is not all what the device attestation requires

tender oxide
warm magnet
#

Okay. But ultilmately isn't the point of the attestation that no non-compliant devices are accepted into a fabric (or atleast without specific approval) - and can Nabu Casa assert about the compliance of any HA instance if the implementation can be changed by the user?

kind sedge
#

Correct, so if a user changes a device it can not sign that with the correct certificate. I'm not 100% sure how this works but I can image a private key part is than indeed not open source but held privatly, otherwise there is no way to do that check, I agree

#

But again, for now all out of scope as we do not have any plans (yet) do to the bridge implementation, based on the above discussions you may see why 🙂

#

I'm going to follow the project by @elder oak with great interest though. Sounds really interesting

warm magnet
#

One final question - if we are not going to have an attestation certificate, why do we need certification at all? Devices do not validate which fabric they join, do they? Isn't it possible to run a full Matter fabric without any sort of certification done on the "controller"?

tender oxide
#

we want to certify our server, and certification requires attestation is on by default

warm magnet
#

Why do we want to certify our server? What benefit does it give?

tender oxide
#

Use the badge in marketing

#

Give other companies a reason to use it too and collaborate

warm magnet
#

Right, so no technical benefit. Okay, that answers my question.

#

Thank you for all the answers, it's been very interesting! I'll keep posted on the matter stuff in HA, and possibly do some work myself as well.

fiery stump
upbeat flicker
kind sedge
# upbeat flicker does this mean HA won't work as a matter proxy?

Explain proxy…
Home Assistant will support Matter devices by itself, WiFi based, thread based devices an Matter devices provided by a bridge (e.g Hue and IKEA Hubs) A separate HA project will provide an easy way to run a thread border router on your Home Assistant box.

#

Out of scope is HA being the actual bridge so all devices in HA will become available on Matter. While this idea sounds intriguing and HA is probably the perfect candidate to do this, it requires a lot more thinking/designing. Do first steps first, HA as (certified) Matter controller to actually include Matter (only) devices into HA

#

Another cool idea we have in mind is to actually turn a esphome device into a matter compatible device, allowing for really easy diy sensors and actuators

upbeat flicker
#

what a shame though

upbeat flicker
#

If I make a deep dive into both the Matter API and the HA API, it's not inconceivable that I could write my own proxy, right? Issue would just be with certs though... hmmm 🤔

kind sedge
#

Yes you can and probably it will be done at some point

eternal falcon
#

Open thread is abble to link devices? I tried to link, home assistant recognizes that integration as a apple homekit device, when I click I configure always appears an error

solid mountain
#

The Thread credentials setup is not standardized. HomeKit uses its own commissioning/setup sequence etc. We are currently only focusing on using Thread for Matter.

eternal falcon
#

I suppose that

#

This is what I mean, it is a Thread Matter product

#

It is a nanoleaf bulb

#

I cant send the picture

#

The problem is that, home assistant is considering that matter product as a Apple Hoemkit device

#

And Im not abble to control the device

kind sedge
#

Matter support is most definitely not yet enabled on the nanoleaf, you will have to request a beta firmware for that

#

There are no products available in store with out of the box Matter support, its too early for that.

eternal falcon
#

Why is it to early? I have a google nest with thread, and I successfuly added to google home

#

I unlink it from google and I still not being abble to link it to home assistant

kind sedge
#

yes, the thread border routers are available in the google nest wifi pro, the nest hub v2 and the apple tv 4k

#

but I mean real products as in end devices

#

that support is still beta for most manufacturers

eternal falcon
#

Oooh okey thankypu for the information

kind sedge
#

So the Nanoleaf is probably talking homekit over thread right now

solid mountain
eternal falcon
#

Okey that's true it doesn't have any matter logo, only has Thread and Bluetooth

solid mountain
#

Ok, yeah then it's a HomeKit product which can use Thread as network protocol.

eternal falcon
#

It say It ca be controlled by google, apple and other thread devices

#

The box say it is a homekit product

solid mountain
#
    Nanoleaf Shapes (6.1.1)
    Nanoleaf Elements (6.1.1)
    Nanoleaf Lines
    Essentials Bulbs and Lightstrips (1.6.8)
    Nanoleaf Smarter Series App (6.1.0)
    iOS (14.1+)
#

I am guessing if you don't have any of these, it's probably just controlled through Bluetooth? Not sure.

opal linden
#

@eternal falcon So Nanoleaf bulbs and light strips work with Home Assistant over Thread since 2022.10 via homekit_controller, but thats not matter

eternal falcon
#

Idk

opal linden
#

If your device is getting discovered but you can't pair it, the most common reason is your ipv6 setup not being quite right

eternal falcon
#

It has Homekit and Google Fast Pair

#

My bulb is nanoleaf essentials

opal linden
#

The forum post is for that exact bulb

eternal falcon
#

Okay Im sorry I thank that I could be abble to pair with home assistant via openthread

opal linden
#

openthread and matter are related but seperate things

eternal falcon
#

Ok sorry then and thanks for the info

split granite
#

Hello, I just tried the example (https://docs.google.com/document/d/1MldgA337wHTEx-vPkoxlCqKHrhVm5QIcHV32iLsv_2k/edit#). However, the device is not connected at step 4.
Has anyone also had the problem or / and can someone help me there?

In step 4 the ESP32 with the Matter example light should be connected to the Home Assistant.

Edit:All the steps before 4 have worked. The ESP is also installed correctly with the light example (can be seen in the log when I press the boot button).
Home Assistant is also set up as in the example.

still spade
#

do you use 2,4ghz wifi? not all esp can use 5ghz wifi

split granite
#

I have the ESP32-C3-DevKitM-1 . Unfortunately I can't find any information in the description how much ghz it can do.
But it is BLE capable.

My Wifi can and has both 2.4ghz and 5 ghz.

tender oxide
#

@split granite I think that the latest version of the ESP firmware no longer matches the addon version. There were some breaking changes just before matter 1. The good news is that we aim to have experimental matter merged for the next HA release

exotic lark
#

Hey y'all, I'm not sure if this has been asked yet, but out of curiosity, would Home Assistant be able to act as a matter hub that can forward device info to Google Home, without having to add the application + token?

tender oxide
#

Theoretically possible but not our focus

exotic lark
# tender oxide Theoretically possible but not our focus

Gotcha, this has been the thing that has had me on the fence with Home Assistant, since my partner and I prefer using Google Homes front end, but I'm personally not a fan of how integrations currently integrate to Google Home

tender oxide
#

HA can already be controlled via Google

#

And it’s local too

exotic lark
#

It makes me curious what the lift is for something like this and if it could be accepted as a contrib if it hasn't been roadmapped. I've yet to dive into matter for work since we're planning on integrating it into our ecosystem.

exotic lark
tender oxide
#

It’s a shit ton of work. We’re enabling control first. Also a ton of work

#

Sure no it requires authentication

#

So you want to do a ton of work to avoid logging in 🙃

exotic lark
#

I'll probably take a peeksie into this

tender oxide
#

Subscribe to Nabu Casa if you don’t want to deal with that

exotic lark
#

Ah, it's premium

tender oxide
#

No. You can setup a google cloud project and do it for free

exotic lark
kind sedge
#

Matter support in HA will be supporting Matter enabled devices into HA.
Making HA itself a Matter bridge is out of scope for now but there are already some experiments in the making by community members.

exotic lark
wet stratus
#

I’m an educator in applied computer science (professional bachelor’s degree) at KdG University Antwerp. As an enthusiastic HA user, I was wondering if Home Assistant is interested in the helping hand of our graduating students. Are there any opportunities in the development of the Matter functionality? Maybe there is some kind of sub-project they can work on? They will work in a team of three students and can spend around 400-450 development hours. We will guide them and they are available from the start of February until mid-March.

opal linden
#

Will HA support pairing by QR code? Recently figured out how to do pairing by QR code and NFC for homekit_controller. Both are just urls that containing the pairing secret and a discovery hash as a url. Wondering if any other integrations have anything like this, and if it’s worth exploring adding to HA

kind sedge
true crown
#

I think the Z-Wave integration also supports adding devices with a QR code if the controller supports it

solid mountain
#

While all are using QR code, they are all slightly different and function differently.

At first we plan to use the provided SDKs for the phone apps. In that case the initial commissioning (QR code scanning, make sure the node connects to the WiFI/Thread network by providing credentials) is handled by Google/Apple. In a second step the device is beeing added to Home Assistant via on-network commissioning.

worn agate
#

Does anyone know why there is no custom_components directory after python-matter-server is updated to version 1.0.6, and how to integrate this from HACS?

#

help

#

🥹

solid mountain
#

The Matter repository no longer provides a custom integration. It is part of the current beta version. You have to remove the integration (under Devices & Services), delete the custom integration from HACS and remove the directory in the custom_components, then update to the beta if you want to try it out.

worn agate
#

ok,thank you very much

#

update to the beta for what?python-matter-server?or others?

opal linden
#

Home Assistant

worn agate
#

How to upgrade home assistant Supervisor?we use the Supervisor on development board

opal linden
#

It will be released as stable next Wednesday if you can wait

worn agate
#

ok,thank you very much

true tulip
worn agate
#

Does anyone know how to integrate the matter protocol in the home-assistant system, and then connect the ESP32-C3 device for testing?

worn agate
#

I followed the integration and test case in June this year, but it was outdated on December 1st, does anyone know another way to test it?

worn agate
kind sedge
kind sedge
#

Are you running the beta of HA right now ?

worn agate
kind sedge
#

A Raspberry Pi 3 will probably be a little too slow for running HA and the whole Matter stack but for development/testing maybe its fine. Better to use a Pi 4 or better.

You can either wait for today's update of HA 2022.12 of run the HA 2022.12 beta right now.
That will allow you to install Matter from within Integrations.

worn agate
#

wow,awesome

tender oxide
#

@worn agate since you're not developing on Matter, please use #matter-archived for support. This channel is for development

true tulip
true crown
kind sedge
#

I'm still filling it with stuff and yeah it should be set to public, thanks for the reminder 😉

true crown
#

Bumping the version for the addon is also on your list I presume?

kind sedge
#

Ah... yes.... I bumped the lib version in HA but that small change I made for you is actually important for the addon 🤯

ember summit
#

congratulations on the release all!

tender oxide
dense fable
agile crane
#

Is there a resource that explains how to commission OTBR to the python matter server? I have OTBR running on a pi and it's already on the same network.

#

I see the websocket command "Commission on Network" but I'm not sure if I can use this with a OTBR.

kind sedge
solid mountain
#

@agile crane to get the credentials you need to use the following command in a shell where the otbr-agent is running

ot-ctl dataset active -x
agile crane
#

yes, i've successfully set thread credentials. do i need to start the joiner?

#

in ot-ctl I try "thread stop" then "joiner start 20202021"

solid mountain
#

Nah, Matter doesn't use the Thread joiner stuff

#

Matter has its own commissioning flow. Essentially, a secure connnection is built via BLE, then the full thread dataset is transmitted, and then the Matter commissionier tries to reach the device via IPv6.

agile crane
#

if i try Commission on Network what do i use for the setup_pin_code?

#

and where does that go on my pi OTBR?

solid mountain
#

If you do commission on network, then the device needs to be on the network already..

agile crane
#

yeah. I'm treating my OTBR as a device. do i not need to do any 'commissioning' of the border router onto the python matter server?

solid mountain
#

What kind of device do you have?

#

Ah no, you can't do that. The OTBR itself is not a Matter device

#

Thread and Matter are largely separate things: Thread provides IPv6 "transparency", Matter is the protocol talking to the device and managing commissioning.The OTBR provides merly routing IPv6 (and mDNS) between Thread world and your regular Ethernet/Wi-Fi network

#

So essentially, what happens when commissioning a Matter device onto a Thread network is the following:

  1. Commissioner (your phone) talks to the device via BLE, assigns it crypto keys and and ID
  2. Commissioner sends Thread credentials (aka "Thread operational dataset") to the device (the commissionier knows the Thread credentials from somewhere, that is not defined in the spec. in HA, currently via "Set Thread" button of the Matter integration 😅 , that will change)
  3. Thread device connects to the Thread network and gets an IPv6 address
  4. Thread device tells the OTBR via SRP (service resolution protocol), that its a Matter device and where its reachable (this is essentially mDNS)
  5. Commissioner ask if the previously given ID is somewhere on the network. Here the OTBR will answer via mDNS, and tell the commissionier what IPv6 your device is reachable at.
  6. Commissioner talks IPv6 with the device (routed by OTBR).
agile crane
#

I've been play with a nRF52840dk. I've gotten it commissioned onto my pi OTBR and talking ipv6. I'm a newbie on a lot of stuff but it helps to know not to focus on trying to commission my otbr.

#

I'll mess around some more. Thanks for your help!

solid mountain
#

yeah the nRF52840dk is a good starting point

#

I commissioned that one successfully with HA via OTBR.

agile crane
#

i got the dk commissioned on my pi OTBR but HA isn't picking up the light bulb service that its publishing

#

serial ouput of the dk:

I: Device is commissioned to a Thread network
I: Started Publish service
I: LightBulbPublishService message sent successfully

#

OTBR log output shows activity when the service is being published

#

but nothing in HA. i'll try your lighting app example.

#

could be something simple like not having HA setup for ipv6 correctly

solid mountain
#

Yeah should probably work too

#

What OTBR are you running?

#

Currently the lights don't show up immeaditly, you need to disable/enable the Matter integration for the entities to show

agile crane
#

a build from august when i first tried all this 😬

#

seems like a _matter._tcp. service is being advertised from the dk ipv6 address. Service Browser app on my phone finds it.

#

I'll try enable disable of the matter integration

solid mountain
#

There was a change in crypto something at one point, so you don't want to run too old firmwares

#

but you should see errors during commissioning in the Matter Server logs

agile crane
#

ok. i guess doing some updates is a good next step

opal linden
#

with homekit over thread we’ve found that mdns often works when basic ipv6 connectivity is broken. You should check that your HA box has routes for thread if you haven’t already, a lot of people have to change sysctls to avoid the min prefix length filtering

agile crane
#

i upgraded otbr but same results. it's probably some networking thing that's over my head.

#

nRF52840dk is joined to OTBR and my phone can discover its _matter._tcp service

#

i assume the ha integration should just discover and add the device but maybe i'm missing another step

opal linden
#

(mDNS comes from the border router, so they can work even if your HA can’t reach devices on the thread network)

#

Can you ping6 the thread device?

agile crane
#

::1 dev lo proto kernel metric 256 pref medium
fd11:22::/64 dev wpan0 proto kernel metric 256 pref medium
fd11:1111:1122:2222::/64 dev wlan0 proto kernel metric 256 expires 1753sec pref medium
fdfa:574b:d2a7:7e01::/64 dev wpan0 proto kernel metric 256 pref medium
fe80::/64 dev wlan0 proto kernel metric 256 pref medium
fe80::/64 dev wpan0 proto kernel metric 256 pref medium

opal linden
#

Do any of those routes match what is in the mdns advertisement, and can you ping6 the ip in the advertisement

agile crane
#

the service is found at fd11:22::2a26:2040:b45b:4c7b:5540

#

i'd rather not rathole into this, though. i'm very novice when it comes to this stuff. i don't want to waste anyone's time.

#

if the dev's find value in me poking around more because this might be a common setup problem i'm happy to help.

tender oxide
agile crane
#

does the device need to go into joiner mode again?

tender oxide
#

Yes. For each fabric

runic matrix
#

Hey - just started poking around Matter in HASS. My Eero router supposedly already has a thread network set up (although I don't think anything is on it yet).

Discord won't let me upload a screenshot, but I have:

  • Network key: <some long hexadecimal string>
  • Network name: eero-thread
  • Channel: 25
  • PAN ID: <4-digit hex number>
  • Extended PAN ID: <longer hex number>
  • Commissioning Credential: <NounVerbNumber>

As far as I can tell, the things HASS is looking for are totally different. My guess is that the problem is between the chair and the keyboard, but perhaps I'm missing something?

#

I'm just running it on a stock Raspberry Pi 4. I have a ConBee II plugged in for ZigBee, but I doubt the Matter addon is using it. Still waiting to hear that my Skyconnect has shipped

tender oxide
#

what you just explained is the Thread operational data set

#

HA needs the string that contains all that data encoded in a single string

#

So you're really close

runic matrix
#

Hmm. Doesn't seem to be a way to do that from the Eero app

#

Unless I'm blind

#

I can copy each string individually

#

But not as a set

tender oxide
#

we don't yet have a form to just put in that info and get the operational dataset generated

runic matrix
#

Yeah I figured

#

Is there a format for it? I assume it's not as easy as pasting it all in at once 😉

tender oxide
#

It's a TLV dataset

runic matrix
#

Such has been my experience thus far 😛

#

I can always be patient and wait, I just remembered my Eero already had it

tender oxide
#

So it is possible that Eero would set it's Thread credentials on iOS/Android

#

in that case, when HA commissions via Android/iOS it will use the Eero credentials automatically

runic matrix
#

Yeah, that's sort of what I expected to happen. Although I don't think anything in the house has updated to Matter yet

#

I have a bunch of Google Nest stuff but I haven't seen any updates or news from Google about it

tender oxide
#

Well it depends on if Amazon wants to play nice 🙃

runic matrix
#

The only thing I saw was the Eero and HASS

tender oxide
#

they don't have to share their credentials if they just do all commissioning via Alexa app etc

deft tiger
#

Hello I've migrated three Eve Devices to Matter via the beta app and was able to connect them to a Samsung SmartThings Hub. Now I'm trying do add them to HA. Do I need to take some additional steps after setting up the Matter server via the Integrations on HA OS?

#

Do I have to set wifi credentials?

kind sedge
#

You can share from samsung

deft tiger
#

Adding a shared device has not worked so far

#

I share from Apples Home.app

#

that worked for Samsung

#

(after a few tries, though)

#

tried a few times with HA as well but I am not sure if I have to take additional streps for it to be able to work

kind sedge
#

You can use the "Add shared device" in the UI or service call and indeed share from Apple

#

Do notice that you need to reload matter integration after adding a device

deft tiger
#

ok, then I'll just keep trying 😄

kind sedge
#

that is still flaky but will be fixed within a few days

deft tiger
#

All I got was „Command failed: 99“

#

so far at least

kind sedge
#

I suggest:

  1. share from apple
  2. use "add shared device" from HA
  3. wait 2 minutes
  4. reload Matter integration
kind sedge
deft tiger
#

it should be able to

#

I'll try your 4-step-program and report back in a few minutes 😄

kind sedge
#

OK, I just received an Eve device here so I can test it as well today or tomorrow

deft tiger
#

it is a whole lot of fun

#

had to unplug most of my homepods

#

and reboot my iphone more times in the last 24 hours than my whole life before

kind sedge
#

Living on the edge here right

deft tiger
#

but now i have all three eve device types in home and smartthings

kind sedge
deft tiger
#

yes. in a year or two 🙂

#

when all of this is worked out

kind sedge
#

exactly but the very beginning looks promising

deft tiger
#

Still get an »Command failed: 99« right away

kind sedge
#

Can you take a look at the matter server log ?

deft tiger
#

this should work without a thread connection on my HA, right?

kind sedge
#

that will probably hold the whole error

kind sedge
#

e.g. ATV or homepod mini

true crown
deft tiger
#
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/dist-packages/matter_server/server/client_handler.py", line 183, in _run_handler
    result = await result
  File "/usr/local/lib/python3.9/dist-packages/matter_server/server/device_controller.py", line 164, in commission_on_network
    raise NodeCommissionFailed(f"CommissionWithCode failed for node {node_id}")
matter_server.common.models.error.NodeCommissionFailed: CommissionWithCode failed for node 4
2022-12-14 12:50:19 core-matter-server chip.TOO[124] INFO Discovered Device: fd1c:e4b4:9af8:0:a0cf:744a:175c:a8de:5540
kind sedge
#

so please look at the server log what par failed, for example the attestation

#

@deft tiger can you look a bit more above because that is only the error resulting from the failed commission.

deft tiger
#

sure but the line before is from another try in the morning

kind sedge
#

ah ok, debug logging is probably not enabled then.

#

I will test it myself later today

deft tiger
#

to be totally honest: I'm not a dev 🙂

#

I'll enable it and try again

true crown
kind sedge
#

It should have been added in the addon config a few days ago

true crown
#

Added yesterday it seems

kind sedge
#

set it to debug for the full messages of the chip sdk

cobalt belfryBOT
#

@deft tiger I converted your message into a file since it's above 15 lines :+1:

kind sedge
#

OK that is still not very helpful as the chip log is very generic. I will test it myself and let you know.

deft tiger
#

Thank you!

cobalt belfryBOT
#

@shut garnet I converted your message into a file since it's above 15 lines :+1:

shut garnet
#

This is with an Eve Contact Sensor

kind sedge
#

I still need to test it, waiting for the mail from Eve to arrive after joining the beta program 🙂

shut garnet
#

Those lines show up after similar lines above with NodeCommissionFailed

#

Sounds good! Let me know if I can try anything for you

kind sedge
#

👍

south yoke
#

@kind sedge I have the correct Eve devices, the Eve early access program TestFlight version of their app and debug logs turned on. I can get you logs and do any testing you need. I’m so excited for this to work!

agile crane
#

got my nrf52840dk onto HA via OTBR

#

Can't even say what I did differently to make HA find the device because I tried to many things and after a HA restart the device appeared 😦

kind sedge
#

I can reproduce the issue with trying to share the Eve Matter device from homekit to HA. It does not work at all. Fixed one error but hit the next right after. Not sure if sharing the device is even supposed to work already with this beta firmware.

true crown
#

They mention sharing in the email so I expect it should work?

deft tiger
#

it works

#

i shared from home.app to smartthings

ashen depot
#

Oh hey this is where the good stuff is happening

#

Here's the scenario:

  • nRF52840-DK flashed with Nordic's sample Thread RCP firmware
  • OTBR addon running on HAOS w/ said board
  • Eve outlet flashed with Matter firmware and its commissioning QR code saved
  • Outlet was added to HomeKit as part of the firmware upgrade process but I removed it
  • This didn't remove it from the Apple thread network (as expected)
  • Factory defaulted outlet to wipe old Thread network info
#

Standard Matter addon also on HAOS. Got the ESP32 sample working just fine

#

Did a Set Thread in devices & services / Matter config w/ info obtained from docker exec -it addon_ae6e943c_openthread_border_router ot-ctl dataset active -x

#

Outlet is found via BLE and commissioning is attempted.

#

Fails with this (sorry can't upload file myself to save lines):

2022-12-16 19:55:24 core-matter-server chip.CTL[124] INFO Performing next commissioning step 'AttestationVerification'
2022-12-16 19:55:24 core-matter-server chip.CTL[124] INFO Verifying attestation
2022-12-16 19:55:24 core-matter-server chip.CTL[124] ERROR Failed in verifying 'Attestation Information' command received from the device: err 101. Look at AttestationVerificationResult enum to understand the errors
2022-12-16 19:55:24 core-matter-server chip.CTL[124] INFO Error on commissioning step 'AttestationVerification': '../src/controller/CHIPDeviceController.cpp:1031: CHIP Error 0x000000AC: Internal error'
2022-12-16 19:55:24 core-matter-server chip.CTL[124] ERROR Failed to perform commissioning step 8
2022-12-16 19:55:24 core-matter-server chip.CTL[124] INFO Going from commissioning step 'AttestationVerification' with lastErr = '../src/controller/CHIPDeviceController.cpp:1031: CHIP Error 0x000000AC: Internal error' -> 'Cleanup'
2022-12-16 19:55:24 core-matter-server chip.CTL[124] INFO Performing next commissioning step 'Cleanup' with completion status = '../src/controller/CHIPDeviceController.cpp:1031: CHIP Error 0x000000AC: Internal error'
#

Looks like some kind of cert validation error?

#

</spam>

#

Just kidding I'm still here. Typical CA infrasatructure. The PAA (Product Attestation Authority) is the root, PAI (Product Attestation Intermediate) is the inter, and the DAC (Device Attestation Certificate) is that of the device itself. "The list of trusted PAA certificates are stored in the Distributed Compliance Ledger (DCL)." So I'm guessing the addon is just missing the current DCL root certs

ashen depot
#

Downloaded the latest certs from the CHIP/Matter github repo (https://github.com/project-chip/connectedhomeip/tree/master/credentials) and copied production/paa-root-certs/* into development/paa-root-certs/ (because INFO Using device attestation PAA trust store path ./credentials/development/paa-root-certs) and I have now successfully commissioned an Eve device w/ Matter firmware on my own OTBR in HASS!

#

Only to find that my shiny new "On/Off Plug-in Unit 28" has no Controls to actually turn it on or off! 😄 And with that goodnight. I will continue in the morning

tender oxide
#

We do have the OnOffPlugInUnit mapped 🤔

cobalt belfryBOT
#

@ashen depot I converted your message into a file since it's above 15 lines :+1:

ashen depot
#

That's all I'm seeing for Matter-related logs, and I've got homeassistant.components.matter set for debug

tender oxide
#

Looks like it can’t find an attribute.

kind sedge
#

@ashen depot thanks for testing. I was about to answer you that the error was due to missing root certificate(s) used for the attestation test but you figured that out on your own 🙂
I'm currently investigating another issue (where you share the Eve devices from Homekit to HA) and I will then run into this issue as well. Looks like our mapping schema is not complete for this unit.
I'll let you know once I can reproduce it. For now thanks for the logs and patience.

ashen depot
#

Or I guess more accurately at the initialization of its class inside the .append

#

Too deep for me for now

#

gl;hf

kind sedge
#

Yes, that's why I want to reproduce it instead of guessing. I'm pretty sure I can within the next few days.

#

At this point I'd like to first test the share from homekit to our matter controller before I remove it from homekit and pair directly but great that you already tested that works!

ashen depot
#

Got it. The device lacks a UniqueID. matter_server/common/models/node.py fails in def unique_id

kind sedge
#

hmm that is a problem as that is mandatory. I guess that is the result of another underlying issue. Like I said I will take a look once I can reproduce as this part is not tested in the code

ashen depot
#

I'm still gonna keep poking at it 🙂

#

I'm intrigued now

kind sedge
#

haha good 🙂

ashen depot
#

Yeah very weird though:

root@core-matter-server:/data# grep NodeLabel 7517217511003013707.json
          "attribute_type": "chip.clusters.Objects.Basic.Attributes.NodeLabel",
          "attribute_name": "NodeLabel",
root@core-matter-server:/data# grep UniqueID 7517217511003013707.json
root@core-matter-server:/data#
#

This is getting closer and closer to the CHIP/Matter library itself instead of anything HA-specific so I'm getting kinda worried:

#

Meh, message too long but basically the matter server's data json has chip.clusters.Objects.Basic for usual things like vendor name/ID, location, node label, attributes, featuremap, etc., but no unique ID

#

Hoping Eve didn't mess up and forget it or something

kind sedge
ashen depot
#

Changing the MatterEntity init so it doesn't reference node.unique_id allows it to successfully initialize as a switch:

        self._attr_unique_id = f"{matter_client.server_info.compressed_fabric_id}-HACKYLOL-{device_type_instance.endpoint}-{device_type_instance.device_type.device_type}"```
#

I can now make a Matter outlet on my DIY Thread network click its relay on and off via HA

#

Curiosity sated. Thanks for all your great work marcel + balloob + the rest of the HA team

kind sedge
#

nice! Now let's find out why the unique ID is missing. Curious if its also missing in the Apple route (device paired to homekit primary but shared to our controller).

tender oxide
covert coral
#

heya, ive asked this a while back as well, but im curious if this is still the case;

Will home assistant consider making it possible to expose entities/devices as matter accessories to other hubs? This way, I could for example integrate a legacy z-wave, bluetooth, or homekit accessory, and then "translate" it through home assistant, similar to how i can translate any accessory to homekit right now.

opal linden
#

It’s not ruled out and there’s nothing stopping the community picking it up, but there’s a lot of other work to do first.

covert coral
#

ah, but it is indeed considered? the last time i asked it, it wasnt even considered or on the roadmap and such

#

ahhh that explains it

#

fair enough then 👍

opal linden
#

I don’t think it’s on the roadmap, it’s just not been ruled out

#

(I’m the homekit_controller maintainer tho, I don’t know the matter roadmap)

upbeat flicker
ashen depot
#

@dense fable says he's also having the same issue with Eve's Thread firmware not providing a unique ID

#

@kind sedge it sounded like you have one of those Eve outlets, yeah? Did you also run into that?

muted cipher
#

hey quick question - I'm trying to commission a device I made to test matter out but when I try to commission a device I either get error code 3 or "Matter is currently unavailable.". Any reason for this?

#

I successfully commissioned a device during the workshop, so it did work in the past

kind sedge
dense fable
#

Logger: homeassistant.components.switch
Source: helpers/entity_platform.py:536
Integration: Switch (documentation, issues)
First occurred: 7:44:45 PM (1 occurrences)
Last logged: 7:44:45 PM

Platform matter does not generate unique IDs. ID 3213192207035885959-HACKYLOL-1-266 already exists - ignoring switch.on_off_plug_in_unit_1

ashen depot
#

Yeah without a unique ID I dunno how it’s supposed to differentiate between devices

kind sedge
#

You can’t add eve devices as were still figuring out why they are not spec compliant.

eternal falcon
#

What is the difference between matter and open thread addons?

#

In my OpenThread addon I have 3 devices in topology, a nanoleaf bulb, google nest hub 2 and the openthread border router

#

But home assistant doesnt dettected the devices correctly added

#

I mean what can I do now with that if home assistant doesn't recognize the devices linked via openthread

ashen depot
white sundial
# eternal falcon I mean what can I do now with that if home assistant doesn't recognize the devic...

How did you add the devices to OpenThread? I believe at the moment only Eve devices updated to the beta firmware use Matter. Open Thread is a border router for thread, think of it as a wifi router for thread, it allows devices to connect to it via thread then forwards traffic back and forth to the rest of your network via ipv6. Matter is a protocol used to control devices, similar to HomeKit, http, ftp, ect. The nanoleaf bulb presently uses HAP (HomeKit) as it's protocol, witch can only be paired to one hub (homepod or HA), so to get it to show up in HA you will need to unpair it, but not remove it from thread. Then HA will see it and you can pair it to HA using the HomeKit pairing code (the numbers next to the qr code).

eternal falcon
#

I did this

#

I Link the nanoleaf bulb to google nest hub 2 with google home app. Afrer that in nanoleaf app, It appears in the thread menu, the thread network from my google nest hub 2, and I added the network data to openthread, and thats it

#

In openthread appears in topology 3 devices

#

2 routers

#

And the bulb

white sundial
#

Right, now you need to unpair the nanoleaf from the google home app. That will trigger the nanoleaf to send out an advertisement for pairing that HA will see and it will pop up in HA. In HA if you press pair it will bring up a pairing screen that asks for the pairing code. It kindof sucks, but devices using HomeKit can only pair to one Hub right now and yours is paired to Google Home. Once the Nanoleaf is using Matter this should no longer be an issue.

eternal falcon
#

I did it. Actually HA sent me the advertisement, even the bulb wa connected to google

#

But it is linked to google home and HA

#

Working well

#

More or less

#

I think becouse that bulb is with HA and google in the same network

#

Becouse I joined the google nest hub 2 to the Openthread network

eternal falcon
dense fable
static wyvern
#

Something is off, it should only allow 1 device handler/controller

kind sedge
#

fix for the unique id is on the way. We'll try to squeeze it in a patch release but because it is in fact a breaking change it might be needed to move it to the 2023.2 release

dense fable
#

Hoping we get it as soon as possible! Thanks a lot for working on this ❤️

inner hemlock
#

Made an android app to provision thread dataset to Play Services so matter thread devices could be commisioned from HA android app. Thinking add my code to the HA app, but need some advices where to obtain/set the dataset so that the app can push it to Play Services. Is there a way to get Thread dataset from HA core? Another thought is to patch OpenThread Border router to send external message to HA app with the credentials... Any thoughts? Or is anyone else working on this already?

true crown
#

Hi, I'm one of the Android devs who is planning to work on it

#

At the moment Thread credentials aren't easily exposed for apps to consume, it would need a change in core

#

A full Thread integration (for use with the OTBR/Skyconnect) is also coming soon which might require changes/integration with Matter's Thread settings

#

As you've probably noticed there are multiple situations that might occur for the app, and it needs to handle

  1. no Thread available as far as the device knows, HA knows credentials and/or provides a network
  2. a Thread border router is available as far as the device knows, which should be compared with HA's credential/network
  3. Thread information in HA changed and information on the device needs to be updated
inner hemlock
true crown
#

OTBR is related to the credentials you can set for Matter but not necessarily the same

#

If you want to try integrating it in the app go ahead, though at this point it is not 100% clear where it should go if you want to prevent unexpected prompts

#

Sharing code is always helpful 🙂

inner hemlock
#

I could start to just make a option under app settings to just set the dataset to Play Services, and someone else could take it further and make necessary changes to core?

true crown
#

I think the intent is to start something from the frontend but I'm not sure, let's wait for other devs to chime in

#

Did you limit the code to the full flavor of the Android app or haven't you done that much work on it yet?

kind sedge
#

What is being worked on is getting the thread credentials (dataset) from the OTBR integration/add-on and auto submit it to matter so it can be used for provisioning devices and the user does not have to care about getting those credentials manually.
Another thing discussed is how we could sync up the credentials to google and/or apple. Ideally you want them all to share the same credentials (and even thread network?)

inner hemlock
#

Seeing what @tender oxide is working on seems could be one way of doing it. Pushing the OTBR active dataset to HA, and in parallell just set the active dataset to PlayServices as well. Play Services can store multiple networks. Either by network name or ext pan id or any other id. I've tried using my RCPs EUI64 address successfully. The ID can be a byte array of 16 bytes.

kind sedge
#

Yeah, we kind of figured a sync to both is a nice first step

inner hemlock
#

Or one could upsert the dataset when starting the commissioning from HA.

true crown
#

You can't really upsert it when starting commissioning from the app as asking for credentials will add another intermediate step

#

And there's also commissioning started from outside the app

inner hemlock
#

... thats right, BLE annoncement/NFC/barcode would also start commisioning without HA knowing it started...

solid mountain
#

What essentially got added in Core is a way to read the operational dataset used in our SiLabs Multiprotocol add-on in TLV format (the format Android API is using too). Write will be possible too, but it is a bit tricky in the multi-protocol use case as the channel needs to be the same as Zigbee, otherwise multiprotocol won't work.

#

With that read API we can have Matter use that network, and we can have Android Apps set it too the Play Services.

#

For other use cases more work is required.

inner hemlock
#

Can I add the neccessary code in app config. And make the user copy/paste as they are doing now? And then take it from there?

true crown
#

If you have it ready to go feel free to submit a PR, it can be moved later once other parts are in place

tender oxide
#

Ha you’re jumping ahead 😄

#

So here is what is up on thread

#

We just added an integration that connects to the OpenThread border router

#

And we will hook that into Matter when you send a commission command

#

The WS API is meant for a panel that I will PR tonight

#

So a user can see their active operational dataset

#

Now the next step will be to allow Android to send their active dataset to HA

#

And to query the active dataset that HA is using

#

I think that we’re going to have to come up with a “sync plan”

#

And a way to somehow teach a user about Thread, multiple border routers and why they want to sync it

#

The one thing we don’t want to do it is to automatically resolve things for users if there is a conflict. We can’t know what’s up

#

Easy scenario’s if a user has a single border router, either Android or add-on

#

Android would be able to store it’s thread credentials in HA, so when HA commissions a device, it can use the same credentials

#

Or the add-on stores it’s credentials

#

Now if we have Android credentials and the add-on is installed, and the add-on network is not formed -> yay, we can form the add-on with the Android credentials

#

Same the other way around, when setting up HA, we could check if the user has thread credentials, and if not we could submit the HA ones

#

If both Android and add-on have different credentials, we should open a repair issue and offer user 3 options; Use Android credentials, use add-on credentials, keep different

#

Now we have some challenges, where do we show a sync screen

#

If we do in HA, we need a way to tell the android app we have a credential to push to Android

#

Which is tricky

#

However, I would still prefer HA because there might be iOS too

#

And smartthings, Alexa etc

#

And HA is the location to combine that I think

#

Anyway, we’re still not at a point right now for Android -> Thread sync. The thread integration first needs a few more tweaks, but hopefully later this week it’s ready to add more backend for syncing

#

Including holding onto multiple datasets

true crown
#

Something to keep in mind is that Google will also show UI when the app asks the system for the preferred Thread credentials, so we cannot really avoid doing some things outside of Home Assistant

#

I do agree that it is best to put as much as possible in HA, to keep it simple for the user when explaining how this all works

tender oxide
#

Another challenge we have is that Yellow/SkyConnect multi-pan have to keep their Thread channel in sync with Zigbee

#

So we can’t just adopt every thread credential out there

#

The benefit of thread credential sharing is roaming across border routers

true crown
#

The API will return information about the channel after user interaction but we can't filter for it before asking for credentials

#

So it sounds like there will need to be some additional verification, maybe trial-and-error if there are multiple options

true crown
# tender oxide Ha you’re jumping ahead 😄

Do you still think it'd be useful to have an option to manually enter the Thread dataset in the app like @inner hemlock was proposing while stuff is under development to allow for easy commissioning, or skip it and only integrate with what you're building?

tender oxide
#

Users should never have to manually enter Thread credentials I think

#

Also it’s not stored in the app right

#

We store it in Android Play Services, so I guess he can make a standalone app

#

I think the flow would be that from the Thread panel we trigger the Sync Thread action and Android sends latest thread info to HA

true crown
true crown
#

Also sounds like an option that could be added to the system in the future, no app needed

tender oxide
opal linden
#

Sounds good

#

Will other integrations be able to get the thread network data? homekit_controller will be able to use it to provision supported ble devices onto thread.

#

With my user support hat on, is it worth having the thread integration track meshcop entries for external and unmanaged border routers? Half the bug reports I get are severely lacking in data about network setup, and I have to ask for meshcop service browser data just to confirm they’ve told me about all their HomePods and Apple TVs. At a minimum we could automatically verify that all the border routers are visible from HA (and in 1 hop) in the diagnostic report. I was considering building something like this for hkc as it would streamline my support flow a lot, but it might sit better in the thread integration.

#

But could also generate repair jobs if we eg see a HomePod that thinks it’s part of our mesh but isn’t reachable

tender oxide
#

Yeah that sounds like something the thread panel could show too

#

and yes, this data will be accessible

#

right now we only have 1 external facing method which is get preferred dataset

#

would you need any other ?

#

CC @iron basin

iron basin
#

To be clear, what we have now allows to get the preferred dataset serialized to a non human readable format, we can just display it as a hex string
What we could also show is the state of the router, as well as the operational dataset in a human readable format

opal linden
# tender oxide right now we only have 1 external facing method which is get preferred dataset

That is probably enough if we are nudging people towards consolidating their networks. Our prototype ATM is a HA service call that takes all the values that make up an operational dataset as seperate params, mushes them into a TLV and writes it to the ThreadControlPoint characteristic over HAP BLE. With an API like that, we'd just ask HA for the details and not need any off the user.

tender oxide
#

yeah that would be awesome

solid mountain
#

FWIW, while we should nudge people towards consolidating ultimately, as that is the hole idea of Thread, I am also a bit worried.

My concern is problems/bugs in that area. E.g. multiple OTBR need to be aware of each other, and agree on who is the leader. There are also different BR configurations possible (e.g. Thread Radio Encapsulation Link TREL can be enabled or disabled). And finally, it seems that each BR has its own IPv6 off-mesh prefix. If the leader changes, it seems that the IPv6 prefix for all devices changes as well. I am not 100% sure if that is really the proper way of running multiple BRs.

Maybe, at first, its better to test/make sure that Matter Thread devices work on a single BR. Or at least, if there are problems with Thread devices, people should test with a single BR setup to rule out multi-BR problems.

opal linden
#

Agree, definitely think there are bugs in the thread side of things; lots of annecdotal stuff on Reddit about HAP over Thread with fairly vanilla iOS/Eve/Nanoleaf setups. The setups with more BR's and more routers seem to suffer hours of downtime if something disturbs the mesh enough.

#

(Obviously biased towards the unhappy people posting)

#

But what i've seen with HAP over Thread is people rocking up with 6 HomePod's and 4 Apple TV's. For a sizeable number, multi-BR is here and its not entirely clear how we'd get them to test a single BR. Turn everything off? And we've already talked in here about users unknowingly putting them on different L2's. So we are going to see some really strange topologies very quickly

#

I guess at least with a HA controlled BR, we can get users to ignore the external BR's to prove something works in single BR mode?

tender oxide
#

I'll add a section to the docs with implementation steps and will make sure the "merging" suggestions are in last step, which we can hold off on

solid mountain
#

At least for Matter devices it should be possible to read out Thread information from the Thread cluster. That way we can tell (the user) which network a device is on.

Separating a single Thread border router should be quite straight forward: Decommission it, and commission it with new credentials. In theory all the devices should just use the other routers. And the router in question can be tested in isolation.

Since I work on OTBR add-ons, my concern is mainly "our" routers. With any report, it will be good to know if multiple BRs are invovled, and if the system behaves the same if the BR provided by the add-on runs in isolation.

tender oxide
#

can we see based on discovery info if routers are on same credentials ?

#

would be nice for diagnostics

solid mountain
#

Hm, good question, not 100% sure. I think the network name is not enough to be able to tell.

tender oxide
#

see bottom of thread doc, I attached a screenshot of mdns data of border routers

opal linden
#

i was wondering if you could use the routes aimed at each border router to correlate them

solid mountain
#

From looking at the otbr source code

vn=Vendor name
mn=Product name
nn=Network name
xp=Ext PAN ID
tv=Thread version
xa=stands for Extended MAC Address (64-bit) of the Thread Interface of the Border Agent
sb=state?
pt=partition id
dn=Domain name (only for backbone routers it seems?)
rv=always 1, I guess mDNS TXT format revision)

Some of the fields to others have are definilty not present in OTBR source (like vxp)

tender oxide
#

so xp could be used to see if they are the same ?

solid mountain
#

If I am not mistaken, the OTBR itself listens to IPv6 router advertisements to learn about other Thread routers

solid mountain
kind sedge
#

nice example where you have one network created by apple and one created by google

#

nn is the same for all of the apple BR's

solid mountain
#

Cool, and xp and pt matches for those?

kind sedge
#

no

#

ah yes it does, me being blind

tender oxide
#

can you please add this info to the Thread doc on how we can group border routers

solid mountain
#

OTBR source also has omr as a field, but none of the examples @tender oxide provided has it. OMR stands for Off-Mesh-routable, which is the IPv6 prefix used for the Thread network, and essential to communicate to Thread devices. It seems that this field just got added very very recently (a month ago): https://github.com/openthread/ot-br-posix/pull/1656

opal linden
#

so omr would be the /64 that you see in ip -6 route?

solid mountain
#

Yes, afaik

opal linden
#

Pretty sure my HomePod doesn't have it yet

solid mountain
#

Do you know if these prefix changes from time to time/depending on who is the leader in HomePod world? I saw that when playing with two OTBRs: There is no mechanism which synchronizes this prefix. If the other becomes the leader, the OMR of the network changes.

opal linden
#

i haven't been able to confirm it myself but i did try to help someone with 2 home pods and they saw the same prefix from 2 homepods

#

so they got 2 low priority routes for same /64

kind sedge
#

The Eve app has a nice way to show it

solid mountain
#

Ok. Yeah pretty sure that Google and Apple have vendor specific things they are doing with their BRs... They probably talk through the cloud to sync up their BRs.

opal linden
#

for testing they added a manual high priority route to their chosen homepod

solid mountain
#

Hm I see.

opal linden
#

which worked surprisingly well

kind sedge
#

I was about to show how nice the presentatioon was in Eve app but meh, it fails again

#

looks like my thread network is failing again now

solid mountain
#

More mDNS problems? 😰

kind sedge
kind sedge
ashen depot
#

At least for Matter devices it should be

solid mountain
kind sedge
#

what about google ?

solid mountain
#

It is on 1.3.0 (looking at tv fields of your screenshot in the Thread document)

kind sedge
#

ok interesting, so in theory if apple upgrades to thread 1.3, the apple and google devices may be able to operate the same thread network

tender oxide
#

If we can share the credentials

kind sedge
#

homepod os 16.3 is released next week so maybe that adds thread 1.3 support

dense fable
ashen depot
#

Is it even possible to add Apple devices to an existing Thread network? Rather than them creating their own?

wintry lantern
south yoke
#

I’ve got two Eve Door Contact Sensors upgraded to use Matter in HomeKit and HA. They show closed in HomeKit but their state is opposite in HA (open is closed and closed is open.)

dense fable
#

Same issue here. Told @kind sedge about it.

kind sedge
#

Yeah, I’ll take a look asap. Got caught by some nasty fever so offline for a few days

odd blade
opal linden
solid mountain
#

For Thread link local IPv6 should be sufficient, which should not interfere with aiohttp dual stack services.

#

But if ULA is deployed, I am not sure.. I assume that is the case here.

tender oxide
#

Let’s add an ipv6 section to the docs

solid mountain
#

Yeah, I definitely think we need to educate people more about IPv6. General advice should be don't flip random switches, keep things in a single local network and don't use mDNS reflector 😅 Going beyond that things get quite quickly quite technical.

#

Where would you like to see such docs?

solid mountain
opal linden
#

(Of course homekit_controller is broken here too, we get reports from time to time because we only try the first zeroconf record, and someone’s device is broken and publishing trash - if I practiced what I preach that wouldn’t be a problem for them)

solid mountain
#

but I guess I’ve seen a lot of people advocating for building clients that are robust against this stuff.
If aiohttp is being made robust against these kind of stuff, then the next client will fail 🤷‍♂️

What I'd like to see is some type of network diagnostics where we would check these type of things and inform the user about it.

opal linden
#

Yeah I guess it’s too hard for everyone to write robust code 🤷

#

Agree, top of my list is a BR health check for homekit, hopefully thread generally

solid mountain
#

Also, these type of workarounds go against well established RFCs quite quickly.

opal linden
#

This is why we have RFC6555, RFC8305, etc

#

(Happy eyeballs rfcs)

solid mountain
#

Hm, I see, yeah I guess if well established workarounds for broken networks exist, those should be followed .Kinda sad that this type of RFCs are necessary. 😢

opal linden
#

It is

#

Happy eyeballs also covers the case that ipv6 works but is slow as hell

shut garnet
#

👋 Is it possible to provision a shared device (Eve Contact Sensor) with the current beta matter server addon?

kind sedge
tender oxide
#

Guess what just arrived and was able to set it up with Home Assistant via the Android app 😎

true crown
#

I actually saw an article about that plug earlier today

#

Did TP-Link send them out to people or are you all on top of new Matter devices?

tender oxide
#

1 day delivery on Amazon 😬

harsh jacinth
#

thats a cute little device. Smart of them to start with a simple device - nothing fancy like power metering in there etc.

slim apex
proud bronze
#

It will be interesting if this device will get monitoring when matter adds support for it

fair ice
#

No energy monitoring what?

#

That seems like a pretty dumb design oversight.

#

Support expected for v2.0 in Spring 2024. Awesome ( /s ).

slim apex
fair ice
#

I ran into a Wikipedia article when looking it up, and it was quoted for v2.0 of Matter, which has supposed release date of March-April 2024.

#

I guess that's not right then?

slim apex
#

"Tobin Richardson, president of the CSA, told The Verge they expect to update the Matter spec with new features and additional device types every six months or so. That means we should see the next update around March 2023"

pallid thunder
#

has anyone got the openthread border router to work at the same time as the unifi addon?

upbeat flicker
#

does the matter server have API endpoints so, while HA won't officially support it, we can write our own matter bridges?

#

TYSM

kind sedge
#

yes but they're useless for creating your own bridge

upbeat flicker
#

oh? How come?

kind sedge
#

To create a bridge to matter that will have to be built from scratch

upbeat flicker
#

I know last time I asked, I was deffered to ESPHome, do you know of efforts that has been made in HA since then to make bridging software?

kind sedge
#

nope, but I saw some activity on tasmota

upbeat flicker
#

I unfortunately don't have an ESP device, and don't plan on getting one for this, I guess I have to look into this myself

#

It's just a real shame that I can't make out the GitHub repo 😵‍💫

ashen sedge
#

Will commissioning work right now for my uncertified matter devboard (default test keys/vid/pid)? Not sure if it would reject due to attestation failure or not.

#

oh, that check would be in the mobile app by Google's code (my android). Nevermind...

kind sedge
muted wraith
#

Where do I get the info in Set Thread Credentials?

gaunt phoenix
muted wraith
gaunt phoenix
tender oxide
#

@muted wraith it's not needed

#

It's only for development

#

Just commission using mobile app

noble scarab
#

how is the matter coming along with bridges (anyone testing 2023.3) got a m2 hub I would like to try out 🙂

tender oxide
#

fixing some new bugs, not 100% sure yet if it will make the march release

odd blade
#

This is the channel for development discussion, see the other channels for end user help

spice dune
#

I have HA in docker. So cannot use the add-on for openthread. However, have installed the OTBR docker from https://openthread.io/guides/border-router/docker i am able to get it running with nrf rcp. I am also able to commission another node via the ot-cli. But when integratiing to Home assistant, it requires api endpoint - ot docker has only the web ui endpoint not api. Any suggestion on how do i connect to HA?

dense crow
#

Does anyone know if there is a matter SDK for android?

true crown
#

You can integrate with Google's support for commissioning, or embed the full SDK for local control

foggy panther
#

pretty sure matter cover support is not fully there yet

ancient stream
#

Hm... sad... thaks!

#

I'm sorry. I posted it on the wrong place

modest prawn
#

if a HA dev is fighting a particular aspect of the protocol, maybe I could prioritize that over the other million protocol features I'm missing :p

sly plaza
#

Can I ask what needs to be done to enable HA Thread over HA Matter (without HomeKit)? I assume dev work, but where's that work?

Do I need to compile Matter and start from there? Is there any kind of intro to HA dev (for developers)?

opal linden
#

There are 2 places where there might be problems to solve. The first is that iOS doesn’t currently sync thread credentials to or from HA. So Ha doesn’t learn the secrets of your apple thread network, and apple doesn’t learn the secrets of HAs thread network. That should purely be on the iOS app side. But without a special entitlement from apple that won’t work.

#

Right now that is needed because we are using iOS and Android APIs to commission the devices.

#

Android does have code to do this so you might be able to get some clues there.

#

The other thing is the matter server addon did used to support Bluetooth itself. I think that was turned off. I vaguely remember a conflict or lockup? If that was fixed, then you could commission stuff onto your SkyConnect without involving any mobile device. But there’s a bug limitation to that. You can only commission devices if your Ha has a Bluetooth radio and it is in range of your Ha. Very inconvenient for bulbs or blinds. Because the code is in the addons, it can’t leverage ESP32s as range extenders like homekit over thread can for its commissioning.

sly plaza
#

I have the thread network running from my Skyconnect OTBR using the OpenThread firmware. No Android or iOS hub. (Used Nanoleaf android app to commission to the OTBR). That Thread stuff is working. I have no way to control it from HA. The Matter server isn't recognizing the OTBR thread network.

I believe this is dev work that just isn't done yet?

opal linden
sly plaza
#

I'd post a screenshot if I could.

#

So maybe I could, but they're already commissioned to the OTBR

#

The Matter server just doesn't seem to see the OTBR

opal linden
#

I don’t use android myself but AIUI it does depend on a google api, and google play services. But it does work. There are quite a few users with the setup you describe in #matter-archived. They might be able to help you.

#

Is your OTBR one of the HA addons?

sly plaza
#

Yes. Afaik everyone uses HomeKit integration atm.

opal linden
#

The nanoleaf devices I know that are homekit are homekit only

#

Lots of pre matter people using nanoleaf bulbs and light strips with homekit_controller.

#

You can too if you have a Bluetooth adaptor in HA (it doesn’t use iOS at all)

#

Those products can’t be upgraded to matter last I heard due to limitations of the chips used

#

So if yours are matter they are probably different ones

#

I’m told they are quite different products - lighter and quite a bit different in terms of colours they can produce

sly plaza
#

Huh. I thought once it was on the OTBR that it would handle the matter part, with Matter being able to control any Thread network. I kind of saw it as Thread as the back end, Matter as the front. Maybe that's wrong.

opal linden
#

I only have a nanoleaf light strip (connected to a HA Yellow OTBR via homekit_controller)

#

Thread is basically a way to have ipv6 over a radio mesh

#

You can run any application over that ip network

#

Homekit and matter are 2 protocols that are somewhat optimised for that network

#

But you can run both of them over any ip network

#

You could run BitTorrent on thread if you wanted to, though the bandwidth is terrible so you just wouldn’t do that

#

Some early nanoleaf products with thread won’t ever run the matter stack on top of thread

#

Some eve products ship with homekit over thread and then a firmware upgrade will switch that for matter over thread

sly plaza
#

So they're IPv6 addressable, but not implementing the Matter API?

opal linden
#

Yes

#

Aiui the plan was that they would receive a matter upgrade, but the chip they used wasn’t up to it

sly plaza
#

Seems like a software problem more than a hardware one, that's all. Unless it's fully missing since capabilities expected by Matter, but they're simple enough that that's hard to imagine. On/off, dim, color is about it.

opal linden
#

That’s the excuse they gave

#

I think they said they didn’t have enough flash for a full matter implementation

sly plaza
#

So if we had access to their firmware, we could probably do it. Or it'd need an interpretation layer (like HomeKit, but doesn't have to be HomeKit).

opal linden
#

Anyway, if they are the ones you have they do work with Ha with homekit_controller and OTBR, and you don’t need iOS to make it work

#

I can help when I’m around, though on holiday this week so only around sporadically

sly plaza
#

Hrm, so making an interpretation layer for one outdated product doesn't seem like a good use of time. I was thinking it was a more general problem that would be useful to solve going forward.

#

Really Nanoleaf just wants to sell the same products to us twice.

opal linden
#

Not really no

#

Homekit over thread will likely disappear and we do support it so adaptor layer not needed

modest prawn
#

in terms of protocol layering, Thread is like WiFi, Matter is like HomeKit

wooden badger
#

Got my first esp32-c6 devboards, exited to see what I can do and learn with thread/matter and HA

sour hill
#

silly question here ... is there any plan to reintroduce the OTBR Web UI for the silabs multiprotocol? There's no easy way to access the webui any more; and enabling it (by setting the webui and REST api port numbers) doesn't introduce any in-interface web ui. Also any plans to let the end user configure their own thread network configuration (name etc)?

opal linden
#

i think it was disabled because it was (a) very crashy and glitchy (e.g. when the map view didn't crash it would have nodes coming and going every few seconds when you refreshed it) and (b) because it was super easy for users to poke at things that would easily break, and cause HA to get out of sync with what settings to use for comissioning etc.

#

if you want more control over it you can just run a standalone one outside of HAOS (like a HA Core container user would have to)

sour hill
# opal linden if you want more control over it you can just run a standalone one outside of HA...

See if this is the rationale, then it is at odds with the balance of design ethos inherent in Home Assistant. HA typically gives the user this granularity rather than takes it away. Moreover, the Silabs Multiprotocol is still very much flagged as Experimental, so unexpected behaviour is certainly possible. I can’t understand why removing features or not allowing for their explicit configuration is consistent with everything else home assistant. I guess my sentiment here is +1 for giving users more control rather than less.

opal linden
#

Ha OS had always traded some control for simplicity, ease, etc. Its common for users to “graduate” to the container install for more control.

#

There’s no real point to the web Ui right now. Exactly because it’s experimental. if you “administer” your thread network through it, you’ll just break things by causing it synchronisation issues (OTBR can’t notify HA if you change the channels for example, so HA would end up commissioning with stale network details).

#

And the network view crashes OTBR (frequently when the network is more than a few devices) and doesn’t show the whole network, it glitches every refresh. So you can never see the full topology.

#

So I know it feels like you’ve had something taken away from you but there’s no use case it serves beyond causing sadness.

#

Personally would rather see the functionality integrated into HA anyway

solid mountain
# sour hill silly question here ... is there any plan to reintroduce the OTBR Web UI for the...

The Ingress based WebUI was broken from the beginning: Only port 8080 was routed through ingress, however, the page made asynchronous request to the REST service on port 8081, and that went directly to the HA host 🙈 So the WebUI only worked on the local network.

Furthermore, some functionality like forming the network are really kinda broken for our use case: They don't setup the network the "right" way (using the modern dataset API). The Web Frontend is also seen by upstream developers more as a prototype (see https://github.com/openthread/ot-br-posix/pull/1862#issuecomment-1544194606).

tender oxide
modest prawn
#

OOH

#

I didn't make more progress on my Wireshark dissector 😦

#

Since Matter uses random ports, I was trying to make it recognize the mDNS service discovery responses, so the subsequent packets are recognized as Matter without having to manually select "Decode as Matter", but it's not simple and it exposed bugs elsewhere in Wireshark :/

#

@solid mountain did they add any new device types? I saw a FAQ promising new devices like robotic vacuums in the near future, but I don't see it here, I guess that's for 2.0?

#

No release notes :/

solid mountain
modest prawn
#

I heard that, but I got mine merged first so that's going to bother them :p

solid mountain
solid mountain
modest prawn
#

"Yes" but it does the bare minimum of parsing protocol headers

#

Oh, that's old, I get a few more fields that that

solid mountain
#

Looks good already 😅

#

I guess the crypto makes it challenging to be a full dissector

#

From what I've heard there is a test mode which has some default keys

modest prawn
#

Yeah, but you need both ends to be compiled in test mode

#

So you can't like, test with a virtual device on a computer with the test mode build flag and an iPhone

#

Or HomeAssistant using the test mode keys and a consumer device

#

So I want to do it like the TLS dissector, let it negotiate keys normally but then extract them (for which only one device needs to be patched) and give the keys to Wireshark

#

I underestimated the size of the spec when I started making this

#

Plus I'm multitasking half a dozen projects (when I shouldn't be doing any of them and I should be studying instead) >.>

solid mountain
#

I know the pain 😅

odd crescent
#

so... I'm running my own home assistannt core in containers, and I want(ed?) to use home assistant as my matter controller. I've added the docker.io/homeassistant/aarch64-addon-matter-server container, and tweaked it so that "supervisor" is localhost, but... apparently there's no hassapi_api: true available in my "plain" homeassistant for the addon to talk to.

#

the machine is running other things, so running home assistant OS isn't an option, are there any alternative methods for getting the matter controller running?

kind sedge
#

No

#

at this time only the official add-on is supported

#

there are people that are trying with the docker image but lots of issues, I cant recommend it atm

#

btw: this is a dev channel, not a support channel 😉

odd crescent
#

well, developing matter, I guess, not really developing matter within home assistant sure. ok. I can leave 🙂

kind sedge
#

we have a regular matter channel, some folks there that are also running their own docker

#

so maybe some tips and tricks what they did to get it working

modest prawn
#

it seems the best way to report issues with the Matter spec is to get hired by a company with a paying membership

quick spade
#

i've been testing Matter with Tasmota but I cannot commission a CT or RGB light as such. Matter implementation in Tasmota works according to spec with Apple and Alexa. I'm using the Python Matter server in a docker container if that has any impact on the issue