#devs_matter-archived
1 messages · Page 1 of 1 (latest)
The new TI sdk came out on the 22nd with a RCP example
Is it working with our OTBR? 🥶
I haven't gotten it to build yet
okay was able to get to build on Linux. Mac just wouldn't let me open the example
seems to work 🎉
Nice!
For which chip did you compile now?
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.
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?
No. let me see if I can build one for the zzh (I have one somewhere)
I literally just built the example so.
I am guessing you built for your CC2652P2 puck?
I guess I could order one 😄 Are you planning to publish firmwares for it?
let me see if this build for CC2652R works on the zzh
also happy to send you a device for testing
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.
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
nah I think I built the right one. https://github.com/Koenkk/Z-Stack-firmware/blob/master/coordinator/Z-Stack_3.x.0/COMPILE.md CC26X2R1_LAUNCHXL_tirtos
okay must of been my system and the state of the addon
tried on a vm and it worked.
fw files for the cc2652p (as in my devices) and the cc2652R (zzh) are here https://github.com/tube0013/tube_gateways/tree/main/openthread_boarder_router_fw
I remember I have seen that too. In theory, stopping the addon should cleanup the iptables firewall rules, and recreate on start
If restarting the addon doesn't help, you might need to restart the system
Awesome thanks!
What is the difference between the two zip files?
Ah nevermind, got it now
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 !
Nice!
How did you do a router comission?
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
Im using the Nordic semiconductor
I can't use the matter add-ons becouse is not supported on home assistant supervised
It automatically gets promoted to a router if it's a mains powered device
OpenThread has it's own onboarding QR code format and app. Afaik it's mostly used for development of custom Thread based protocols
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)
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 ?
got the cc2652 with rcp hooked up to an esp32 with the ot-br example https://github.com/espressif/esp-thread-br https://imgur.com/a/Pn7lzK2
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 🙂
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?
"Multi-Admin" is a Matter feature, allowing to control a single Matter device from multiple Matter networks (aka fabrics).
So, that's a no?
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.
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.
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?
As a note on this that might be of interest: Many big zigbee supporters are looking at doing OTA update for matter support for their devices. Including Ikea, Huawei, Xiaomi and other big ones. So many zigbee devices might becomes matter supported.
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.
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
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"
(there's a short video of the flow in #devs_mobile_apps-archived )
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
@solid mountain I guess our pairing with code service does not support pairing an onnetwork node
CommissionOnNetwork we need to call this method
ok I got it
I am opening a PR
I have cooked this up https://github.com/home-assistant-libs/python-matter-server/pull/74 but it's very much untested
are you having a Matter dev env set up or are you using the add-on @true crown ?
The reason we didn't have that method yet is because it was added last month https://github.com/project-chip/connectedhomeip/pull/21567
For Home Assistant, I use the addon
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
The app will also receive IP/port info, and general information like device type that could be forwarded to Home Assistant https://developers.home.google.com/reference/com/google/android/gms/home/matter/commissioning/CommissioningRequestMetadata
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
Enjoy your weekend, I can wait 🙂
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
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.
This is the wrong channel for that question.
what channel is best to poke around on this?
@true crown figured it out together with Stefan. New Matter server lib released, custom integration updated, now updating add-on https://github.com/home-assistant/addons-development/pull/76
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?
coincedence
we've updated https://nabucasa.github.io/matter-example-apps/ with 1.0 firmeware too
Add-on updated 👍
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)?
it's supported by the Matter spec but not something we're currently focused on
@true crown have you been able to make the new service work ?
Not quite. The devkit didn't want to be commissioned using Google's flow (logs show handshake timeouts?), so I didn't get a passcode to test the new service. I also wanted to test the virtual device but didn't have the time.
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.
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
I don't know either, will try to find it out but don't expect much
Presumably https://nabucasa.github.io/matter-example-apps/ will always use the latest version?
Can't get it to work 😔
- 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
- 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.
yeah you need to wait till they can roll it out, however I can check
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
right now it's the wild west, once 1.0 is released there are no more breaking changes
1.0 tagged != 1.0 released?
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
OK, keep me posted
always 🙂
You need to enroll in the beta program to get latest and greatest Matter
The (public) Play Services beta is full
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
(Brightness control isn't working but it doesn't work either when commissioning in HA using QR+ Bluetooth -> https://github.com/home-assistant-libs/python-matter-server/issues/79)
After changing the VID of the sample Matter device I had added in the Google Home developer console (https://console.home.google.com/) from 0xFFF1 to 0xFFF4 commissioning no longer works though and it fails with a "Connectivity problem / We're having trouble communicating with Google.". Phone logs indicate "Failed to load device info." https://gist.github.com/jpelgrom/dd4d682acae5bab83f275b151b0cdbe2
Hopefully this is just a development limitation but maybe you could ask your contacts at Google @tender oxide ?
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.
Matter 1.0
Has anybody been able to run the activate script on a debian system? I am on raspberry pi os and have the same problems described in https://github.com/project-chip/connectedhomeip/issues/23069 (some dependencies dont get set up correctly or do not exist pre compiled)
32 bits or 64 bits OS ? You might run into some issues on 32 bits ARM
Ah that might be a problem, I still havent changed to 64 bit. Maybe this is the motivation I was looking for
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?
Good question. Was hoping the latest nest hub will work once upgraded
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
any border router will suffice (in theory) because all a border router does (basically) is proxy the thread network to the local LAN
Yes but that is not yet released, it's all in beta stage
If you're trying to commission it to the sample app Google released, make sure you register the device in Google's developer console as this currently appears to be a requirement https://developers.home.google.com/samples/matter-app#prerequisites
Hoping for that - it will be my first thread border router when released
Congratulations on the home assistant matter job! Looking forward to good things to come.
Thank you for the idea! I finaly had time to check it with a freshly installed 64 bit raspberry OS and there it works
Is the only way to play with matter and HA still with that specific dev board from the demo back in June?
You can also run Chef
It’s an app from the Matter repo
That will expose different Matter devices
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)
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.
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.
correct that is the theory, although yet I have to see it in action
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.
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
@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
Good idea, Matter indeed heavily depends on a reliable ipv6 infrastructure
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.
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
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.
nice!
So far we're focused on getting the server part in shape where we host our own Matter controller as add-on.
Would you mind sharing the details for this? Linux dropping the RA and the sysctl setting
@opal linden afaik that is the default behavior in Linux: Router advertisements getting ignored. The Code Lab on openthread.io has some infos about that:
https://openthread.io/codelabs/openthread-border-router#6
I still have to dig into that for HAOS.
@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.
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 😅
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 😱
Yeah Matter/Thread is not well defined for these use cases. Besides the routing you also have to get the multicasting stuff right
It really is not designed to travel multi vlan, Its aimed at consumer grade networks
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
yeah and that only works partly. In the end I gave up and just have it all on the same vlan which is mouch more stable
Yeah, my HA has an interface on the IoT vlan. simple. reliable.
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.
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
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.
Yeah
Until my yellow gets here i'm running the container, and its multihomed with macvlan interfaces just like that
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.
I wonder if their is some way we can have a matter tester in the HA app; so it connects been the APP and HA server and checks the ipv6
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.
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
like ipv6-test.com for your internet access
Looks like Signify is starting a beta for Matter with the Philips Hue hub, which is helpful for testing: https://www.philips-hue.com/en-us/explore-hue/works-with/matter / https://developers.meethue.com/matter/
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 🙂
I can see the Get pairing code screen but it gives an error
Guess the bridge update takes some time to process
Are there any plans for something like this or is the current scope solely for consuming devices via Matter? Anywhere that we can follow along if so?
https://reddit.com/r/homeassistant/comments/yl3hlh/will_home_assistsnt_allow_me_to_expose_connected/
Seems like HA -> Matter bridging could be similar to HA -> HomeKit/Google/Alexa integrations
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
After logging in to the account details I can see a new app "Matter" connected to the bridge https://account.meethue.com/homes, which seems like a confirmation that it did something
Definitely wasn't there a few days ago
Ah, in that case you're even further than me as I did not get anything at all. Maybe the iOS app is lagging behind
hmmm, like if there is a local app running on the bridge ?
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
Most likely the bridge runs the Matter SDK and they created an application that maps the Hue devices to Matter.
I may have found a challenge.... root certificates.... Let's see if we can figure that out next week
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
Correct
Thanks
you need a hue bridge firmware update.. that can take 7 days to be pushed
No, the option is available for me while I'm still waiting for the firmware update
Yeah, but the app is not even confirming I've submitted for the beta. At least I expected some sort of confirmation that the submission was succesfull and the hub would be updated soon
Yahhh they say it in their docs… I think they are trying to be one of the first ones as there’s people like me who completely stopped buying and upgrading their home until the stuff supports matter
@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.
Nope, not there. Are you on Android or iOS ?
do you get a error when getting pairing code
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
just saw the update now
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
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.
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
there's nothing yet to install 🙂
Yeah exactly, great indeed. Been testing today actually with a Hue bridge to test the new code and besides a few smaller things it actually worked.
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
Yeah, I'll give you a small ping if there's an early version ready of the new refactored code based on the V1 final Matter specs. The current experimental integration and addon is all still pre V1
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
Yeah its all very early stage and everbody is completing their final implementation (for V1 at least) but its looking very promising.
"very early stage" yet we've had two Matter launches (1.0 standard and last week) already 😅
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.
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.
No that was just the specification so now actual products will come out using this 1.0 spec
@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.
All these products are prepared for Matter but not officially available or in some beta version.
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?
https://developers.home.google.com/matter/primer/fabric and https://developers.home.google.com/matter/primer/attestation (obviously we can verify the attestation, but we can't get an acceptable PAA to do PAI and DAC instances for each and every home assistant installation...)
@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?
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.
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.
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.
No a fabric can not join another fabric. A device can join multi fabrics though. that is what the whole Multi Admin is all about (which is great!). To make life easier there's also the concept of sharing a device where a fabric controlling a device can enable a special pairing mode so that another fabric can commission the device.
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.
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.
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.
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 😉
@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.
If your work on the bridge is public (as in, visible in github or something), please toss me a link - it'd be interesting to see how that progresses.
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
I understand how attestation works – and I understand that there are no problems with us performing attestation – that was not my question.
Although our Hue APIs integration is going to always be more powerful than Matter
So, extrapolating from the answers I've got, I think I can guess the answers to my actual questions:
- 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.
- 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.
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.
Not sure what language you’re using but there are implementations ongoing in JS and Rust
Which are public
For HomeKit they allow it. If they ever shut it down, it would shut out HA too. There is no way we can ship a certificate people can’t just copy around
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.
True, but we don’t want to lock down Home Assistant
And will avoid that as long as possible
- No that is not possible. HA is the controller, not the device. A controller (with its own fabric) can not join another fabric.
- I really do not get what you are after here. The device manufacturer is the CA, not HA/NC.
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.
What I've seen so far is that they accept it, at least Google does. You just get a warning when attestation failed that the device can not be verified and you can choose ti bypass the verification. But maybe that is only during beta phase and they remove that option later on.
Time will tell, hopefully it stays this way
You can use the dev certificates for that. Or worst case scenario we create our own root cert authority with dev certificates but I think the dev certificates will stay and we will include them in our controller as valid certs.
Sounds cool what you're doing! I'll follow it with great interest!
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 🙂
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.
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.
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
yes, dev cert for custom/DIY devices. Official devices will have their own certs and will be certified. And yes, recertification with each update is mandatory to guarantee interoperability. The good think however with Matter is the introduction of self recertification for updates to an already certified product.
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?
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.
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.
OK, you made the confusion yourself talking about Attestation. You are talking about security now
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.
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
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.
Yes correct and that is true for every fabric
So each fabric has its own certificates and trust with the device
Own certificates and root of trust yes - but I don't think the CA is local necessarily. Not for Google, Apple, etc.
So when you enable "sharing mode" on the google fabric you just open an comissioning window for another fabric.
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
We will store the info within the addon data
But for HA, it will get created by the Matter Server (as the SDK provides this information).
Wonderful, now we are all talking the same language. Understood and agreed, that's the way it looks.
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
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.
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)
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?
But... why ? You are confusing nodes with fabrics I guess ?
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
To have something that is controllable by Google UI, just like any other matter device - for example. I'm not concerned about why, I'm asking if it is possible.
Yes it is possible
But out of scope
A bridge device such as the Hue bridge is an example of that
Wonderful, thank you - that is exactly what I was asking. So out of scope for now - but possible if the other ecosystem allows bypassing attestation checks.
You can control the zigbee based Hue lights over matter
And we've already answered that question 3 times so far 😉
What has bypassing the attestation checks have to do with that ? For a DIY solution that is true but an official bridge (like Hue and IKEA) will have the good certificates.
We will have to see if they will still allow that bypass in later releases
Just to be clear, when you join another fabric as a node, you do not have the same control as a controller. You cannot just talk to other devices...
If HA wants to join a fabric managed by Google (as a bridge, or as a device), it will have to pass the normal attestation for a device. And I don't think HA can have an acceptable Attestation Device Certificate, can it?
Why not ?
Isn't that just a question of ACL?
Maybe, not sure. But even if its possible from Matters perspective definily not something which works today I'd guess as Google/Apple unlikely will allow you to setup a open enough ACL.
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?
Okay, yeah, makes sense.
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
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
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
I think they will always, it will just be hidden behind developer flags
Yeah, could be.. tucked away in some advanced toggle
Point is, it's all guessing now. We're not sure. Let's see next year!
Right, but we can't get our PAA into the Distributed Compliance Ledger can we? So basically no other ecosystem will accept devices signed by our PAA, since we are not in the ledger?
I think Nabu Casa as participant could do that no problem
exactly
Just having the PAA in the ledger is not all what the device attestation requires
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?
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
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"?
we want to certify our server, and certification requires attestation is on by default
Why do we want to certify our server? What benefit does it give?
Use the badge in marketing
Give other companies a reason to use it too and collaborate
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.
Apple always will, just will show a big scary warning
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
this was exactly what I thought
what a shame though
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 🤔
Yes you can and probably it will be done at some point
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
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.
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
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.
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
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
Oooh okey thankypu for the information
So the Nanoleaf is probably talking homekit over thread right now
So you got a pre-release product? Does it has the Matter logo on the box?
Okey that's true it doesn't have any matter logo, only has Thread and Bluetooth
Ok, yeah then it's a HomeKit product which can use Thread as network protocol.
It say It ca be controlled by google, apple and other thread devices
The box say it is a homekit product
Hm, I guess for Google they use their own protocol. It seems they support certain devices as Thread border routers: https://nanoleaf.me/en-US/integration-hub/thread/
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.
@eternal falcon So Nanoleaf bulbs and light strips work with Home Assistant over Thread since 2022.10 via homekit_controller, but thats not matter
Idk
If your device is getting discovered but you can't pair it, the most common reason is your ipv6 setup not being quite right
this channel is for discussing Matter, not HomeKit, so i can't really help you here, but there is a forum thread where you might be able to get help - https://community.home-assistant.io/t/homekit-accessory-protocol-hap-over-coap-udp-was-nanoleaf-essentials-bulb-via-thread-coap/335167
The forum post is for that exact bulb
Okay Im sorry I thank that I could be abble to pair with home assistant via openthread
openthread and matter are related but seperate things
Ok sorry then and thanks for the info
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.
do you use 2,4ghz wifi? not all esp can use 5ghz wifi
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.
@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
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?
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
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.
Without API tokens? I was under the impression it required the integration
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 🙃
Ah, I remember seeing articles that required an API project for this to work in the past
I'll probably take a peeksie into this
Subscribe to Nabu Casa if you don’t want to deal with that
Ah, it's premium
No. You can setup a google cloud project and do it for free
Yeah, that's what I want to avoid. It's not necessarily that I'm against it, but I've been waiting for matter before diving in neck deep 😉
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.
Gotcha! I'll see what I can find in regards to that or maybe write my own impl for turning it into a bridge
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.
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
The QR itself not yet (but may be built in to the apps at some point) but only the payload
I think the Z-Wave integration also supports adding devices with a QR code if the controller supports it
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.
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
🥹
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.
Home Assistant
How to upgrade home assistant Supervisor?we use the Supervisor on development board
It will be released as stable next Wednesday if you can wait
ok,thank you very much
Seems the beta doesn't want to commission my hue hub (was somewhat working on the 0.3.0 version before)
https://gist.github.com/clienthax/c2fcac5d1902e853f358f51d546c619f
Does anyone know how to integrate the matter protocol in the home-assistant system, and then connect the ESP32-C3 device for testing?
I'm writing some docs now
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?
me too
I'll test that today. My Hue hub was acting up and I couldn't repair it anymore so was unable to test it. I've now factory reset it so I can hopefully test it again today. That said, connecting to the Hue bridge over Matter is not top priority because utilizing the Hue api itself in HA will always provide a much better experience
Yes, today's release of HA core will include Matter support and we are writing new documentation for that.
Are you running the beta of HA right now ?
Yes, we have installed and run HAOS version 9.4 on the Raspberry Pi 3 modelB+ development board
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.
wow,awesome
@worn agate since you're not developing on Matter, please use #matter-archived for support. This channel is for development
Understandable, it's just the only matter device I have to hand currently and thought I'd give it a test
Not sure if it is intentional or not, but the project board mentioned in the readme on https://github.com/home-assistant-libs/python-matter-server/ isn't public (yet)
I'm still filling it with stuff and yeah it should be set to public, thanks for the reminder 😉
Bumping the version for the addon is also on your list I presume?
Ah... yes.... I bumped the lib version in HA but that small change I made for you is actually important for the addon 🤯
congratulations on the release all!
we're going to temporarily disable multi-pan for both Yellow and SkyConnect. We found a bug that can impact the reliability of the zigbee network. Some more details here https://developers.home-assistant.io/blog/2022/12/08/multi-pan-rollback
Hopefully we can find the fix. I was talking with @long nimbus about this since I was experiencing it and could not figure out what was going on.
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.
you will need to send the thread credentials and after that you can send a commision_with_code command. If the device is already reachable on the network you can use commision on network
@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
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"
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.
if i try Commission on Network what do i use for the setup_pin_code?
and where does that go on my pi OTBR?
If you do commission on network, then the device needs to be on the network already..
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?
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:
- Commissioner (your phone) talks to the device via BLE, assigns it crypto keys and and ID
- 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)
- Thread device connects to the Thread network and gets an IPv6 address
- Thread device tells the OTBR via SRP (service resolution protocol), that its a Matter device and where its reachable (this is essentially mDNS)
- 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.
- Commissioner talks IPv6 with the device (routed by OTBR).
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!
yeah the nRF52840dk is a good starting point
I recommend flashing the lightning app from project CHIP: https://github.com/project-chip/connectedhomeip/tree/master/examples/lighting-app/nrfconnect
I commissioned that one successfully with HA via OTBR.
oh ok. i've been using a nordic matter sample: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/samples/matter/light_bulb/README.html
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
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
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
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
ok. i guess doing some updates is a good next step
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
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
Did you check the routes on your ha box? (ip -6 route)
(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?
::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
Do any of those routes match what is in the mdns advertisement, and can you ping6 the ip in the advertisement
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.
Nope. It needs to be commissioned. If you pair it via Google to thread, you will need to open a commission window from Google and send pin to HA for on network pairing
does the device need to go into joiner mode again?
Yes. For each fabric
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
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
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
we don't yet have a form to just put in that info and get the operational dataset generated
Yeah I figured
Is there a format for it? I assume it's not as easy as pasting it all in at once 😉
It's a TLV dataset
the Thread reference is not very helpful https://openthread.io/reference/group/api-operational-dataset
Such has been my experience thus far 😛
I can always be patient and wait, I just remembered my Eero already had it
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
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
Well it depends on if Amazon wants to play nice 🙃
The only thing I saw was the Eero and HASS
they don't have to share their credentials if they just do all commissioning via Alexa app etc
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?
You can share from samsung
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
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
ok, then I'll just keep trying 😄
that is still flaky but will be fixed within a few days
I suggest:
- share from apple
- use "add shared device" from HA
- wait 2 minutes
- reload Matter integration
OK, if that persists, make sure that HA can reach the device on the same network. No VLAN's, firewalls etc in between
OK, I just received an Eve device here so I can test it as well today or tomorrow
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
well, currently I'm chasing an annoying bug with comissioning deep down in the C++ SDK code so currently I don't agree haha
Living on the edge here right
but now i have all three eve device types in home and smartthings
yeah, that is pretty cool right and the big benefit of matter that will change things
exactly but the very beginning looks promising
Still get an »Command failed: 99« right away
Can you take a look at the matter server log ?
this should work without a thread connection on my HA, right?
that will probably hold the whole error
correct, as long as you have a thread border router in your network
e.g. ATV or homepod mini
The command failed 99 error is probably followed by commissioning similar to this issue, if I understand the call that is used correctly: https://github.com/home-assistant-libs/python-matter-server/issues/126
it is all 99 atm 🙂
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
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.
sure but the line before is from another try in the morning
How can one enable debug logging for the addon?
Added yesterday it seems
set it to debug for the full messages of the chip sdk
@deft tiger I converted your message into a file since it's above 15 lines :+1:
OK that is still not very helpful as the chip log is very generic. I will test it myself and let you know.
Thank you!
@shut garnet I converted your message into a file since it's above 15 lines :+1:
This is with an Eve Contact Sensor
I still need to test it, waiting for the mail from Eve to arrive after joining the beta program 🙂
Those lines show up after similar lines above with NodeCommissionFailed
Sounds good! Let me know if I can try anything for you
👍
@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!
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 😦
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.
They mention sharing in the email so I expect it should work?
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?
Very few results on the gargle, and all reference certs: https://github.com/project-chip/connectedhomeip/issues/17981
</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
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
We do have the OnOffPlugInUnit mapped 🤔
@ashen depot I converted your message into a file since it's above 15 lines :+1:
That's all I'm seeing for Matter-related logs, and I've got homeassistant.components.matter set for debug
Looks like it can’t find an attribute.
@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.
It's dying at the entities_append in _setup_node_device (matter/adapter.py)
Or I guess more accurately at the initialization of its class inside the .append
Too deep for me for now
gl;hf
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!
Got it. The device lacks a UniqueID. matter_server/common/models/node.py fails in def unique_id
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
haha good 🙂
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
That is possible. Remember this is all very, very early stage and not ready for prime time yet
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
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).
There are some SkyConnect on sale at Pi Hut and they have them locally in stock. Will ship fast. Otherwise will take a couple of weeks for next batch to go for sale https://thepihut.com/collections/latest-raspberry-pi-products/products/home-assistant-skyconnect
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.
It’s not a priority presently. As you put it in terms of homekit, right now you could say the focus is on the matter version of homekit_controller.
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.
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 👍
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)
last I asked, the answer was no, but that was like a few weeks ago; however they did encourage me to make my own proxy
@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?
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
I'll try that today.
notice you need the latest firmware versions, the version used at the workshop will no longer work with current matter integration state
Any updates to the status of this? @ashen depot and I tested it out and discovered that we could only pair 1 eve device to matter. If I tried to add a second device it would state the unique ID was already in use and not load the new device onto matter.
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
Yeah without a unique ID I dunno how it’s supposed to differentiate between devices
You can’t add eve devices as were still figuring out why they are not spec compliant.
Any updates?
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
Addressed in #matter-archived
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).
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
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.
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
Oh I didn't said I solved the issue
So you have it both connected to homemassistant and Google home and it works via interaction with both apps?
Something is off, it should only allow 1 device handler/controller
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
Hoping we get it as soon as possible! Thanks a lot for working on this ❤️
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?
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
- no Thread available as far as the device knows, HA knows credentials and/or provides a network
- a Thread border router is available as far as the device knows, which should be compared with HA's credential/network
- Thread information in HA changed and information on the device needs to be updated
I see that @tender oxide just commited otbr-websocket https://github.com/home-assistant/core/commit/2359e7aad116f48ea848263ace97edbbd4d63ecc. I could probably use that to provision Play Services throught HA mobile app. Or do you want my code?
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 🙂
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?
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?
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?)
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.
Yeah, we kind of figured a sync to both is a nice first step
Or one could upsert the dataset when starting the commissioning from HA.
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
... thats right, BLE annoncement/NFC/barcode would also start commisioning without HA knowing it started...
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.
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?
If you have it ready to go feel free to submit a PR, it can be moved later once other parts are in place
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
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
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
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
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?
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
Correct, but the app that adds credentials will be considered the owner
Standalone app is a good option if we want the HA app to not have a "dev" panel like core currently has
Also sounds like an option that could be added to the system in the future, no app needed
Here is my proposal for how Thread should work in HA https://docs.google.com/document/d/17myyo7gANt_fZJJbqRBujNzsX8cg36_p5heTPQ7AatM/edit?usp=sharing
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
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
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
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.
yeah that would be awesome
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.
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?
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
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.
can we see based on discovery info if routers are on same credentials ?
would be nice for diagnostics
Hm, good question, not 100% sure. I think the network name is not enough to be able to tell.
see bottom of thread doc, I attached a screenshot of mdns data of border routers
i was wondering if you could use the routes aimed at each border router to correlate them
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)
so xp could be used to see if they are the same ?
Yes, BR push routes through IPv6 Router Advertisements. From the service discovery you get host information, and I guess one of the provided addresses should match the routes pushed by the OTBR.
If I am not mistaken, the OTBR itself listens to IPv6 router advertisements to learn about other Thread routers
Yes, and probably pt should be the same. If pt is not the same, the network partitioned itself.
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
Cool, and xp and pt matches for those?
can you please add this info to the Thread doc on how we can group border routers
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
so omr would be the /64 that you see in ip -6 route?
Yes, afaik
Pretty sure my HomePod doesn't have it yet
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.
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
The Eve app has a nice way to show it
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.
for testing they added a manual high priority route to their chosen homepod
Hm I see.
which worked surprisingly well
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
More mDNS problems? 😰
no, it was the user that was the issue.... had a wrong wifi ssid configured on this temp phone (my phone got stolen last weekend)
At least for Matter devices it should be
Just noticed that your Apple devices seem to be still on 1.2.0. I guess those cannot be connected to 1.3.0 (yet).
all updated are installed so I guess they are rolling out 1.3 later ?
what about google ?
It is on 1.3.0 (looking at tv fields of your screenshot in the Thread document)
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
If we can share the credentials
homepod os 16.3 is released next week so maybe that adds thread 1.3 support
I’m in the beta release candidate and it’s still 1.2
Is it even possible to add Apple devices to an existing Thread network? Rather than them creating their own?
16.4 likely be released next week after release. Maybe include in that version lol
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.)
Same issue here. Told @kind sedge about it.
Yeah, I’ll take a look asap. Got caught by some nasty fever so offline for a few days
If you're not developing you wanted the #matter-archived channel
Interesting one - https://github.com/home-assistant/analytics.home-assistant.io/issues/684. Turn on ipv6, apparently can’t use dual stack services with aiohttp, turn off ipv6 can’t use thread.
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.
Let’s add an ipv6 section to the docs
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?
Just to be clear: IMHO, this case is a broken IPv6 configuration, which ofc breaks dual-stack (just like a broken IPv4 configuration breaks IPv4 connectivity 😅 ).
I don’t disagree that in this case this user had a broken network, but I guess I’ve seen a lot of people advocating for building clients that are robust against this stuff. I think if aiohttp hadn’t been doing its own resolving then we’d have gotten happy eyeballs “for free” from core asyncio and not even noticed there was a problem.
(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)
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.
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
Not sure if this is a case of not robust code. If lower layers lie to you about their capability to reach the internet, then what can you do? You can add heuristics, randomly retry etc, but is that robust code? In case of real connectivity prblems, this might then lead to erratic behavior as well....
Also, these type of workarounds go against well established RFCs quite quickly.
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. 😢
It is
Happy eyeballs also covers the case that ipv6 works but is slow as hell
And it’s already default asyncio python behaviours, unless you do your own DNS resolving - https://bugs.python.org/issue39128
👋 Is it possible to provision a shared device (Eve Contact Sensor) with the current beta matter server addon?
please use the regular matter channel for support, thanks!
Guess what just arrived and was able to set it up with Home Assistant via the Android app 😎
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?
1 day delivery on Amazon 😬
thats a cute little device. Smart of them to start with a simple device - nothing fancy like power metering in there etc.
Matter doesn't support energy monitoring right now anyway....
It will be interesting if this device will get monitoring when matter adds support for it
No energy monitoring what?
That seems like a pretty dumb design oversight.
Support expected for v2.0 in Spring 2024. Awesome ( /s ).
why do you say Spring 2024? It's supposed to spring 2023 - in the first Matter update?
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?
"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"
has anyone got the openthread border router to work at the same time as the unifi addon?
Please ask in #matter-archived for support related questions
does the matter server have API endpoints so, while HA won't officially support it, we can write our own matter bridges?
TYSM
yes but they're useless for creating your own bridge
oh? How come?
because the matter server works the other way around
To create a bridge to matter that will have to be built from scratch
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?
nope, but I saw some activity on tasmota
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 😵💫
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...
Yeah, you need to add it to your google developer console
Where do I get the info in Set Thread Credentials?
Click configure on the thread integration. Use the dataset value.
I guess what I meant was what or where is the data that goes on the line that gets set.
You copy it from the dataset in the thread integration.
@muted wraith it's not needed
It's only for development
Just commission using mobile app
how is the matter coming along with bridges (anyone testing 2023.3) got a m2 hub I would like to try out 🙂
fixing some new bugs, not 100% sure yet if it will make the march release
This is the channel for development discussion, see the other channels for end user help
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?
Does anyone know if there is a matter SDK for android?
You can integrate with Google's support for commissioning, or embed the full SDK for local control
Google has a sample which shows both: https://github.com/google-home/sample-app-for-matter-android/
pretty sure matter cover support is not fully there yet
hello, I'm working on a Wireshark dissector for Matter https://gitlab.com/wireshark/wireshark/-/merge_requests/9865, it's still in veeery early stages
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
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)?
Do you mean you want to use Matter over Thread, where a SkyConnect (using the HAOS multiprotocol addon) is border router? When you say without homekit, do you mean without your HomePods? Or do you mean entirely without needing an iOS device?
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.
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?
So you should be able to commission with the home assistant android app for the scenario you describe
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
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?
Yes. Afaik everyone uses HomeKit integration atm.
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
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.
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
So they're IPv6 addressable, but not implementing the Matter API?
Yes
Aiui the plan was that they would receive a matter upgrade, but the chip they used wasn’t up to it
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.
That’s the excuse they gave
I think they said they didn’t have enough flash for a full matter implementation
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).
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
#thread-archived is probably the best place to get help with that
I can help when I’m around, though on holiday this week so only around sporadically
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.
Not really no
Homekit over thread will likely disappear and we do support it so adaptor layer not needed
in terms of protocol layering, Thread is like WiFi, Matter is like HomeKit
Got my first esp32-c6 devboards, exited to see what I can do and learn with thread/matter and HA
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)?
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)
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.
It wasn’t my decision, so it might not be the sole reason. However given the number of users i was helping recover their OTBR into a working state on a daily basis before that change, I’m personally glad they did 🤪
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
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).
Matter 1.1 specs
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 :/
Cool! I think some Google folks have been working on a Wireshark dissector too
I heard that, but I got mine merged first so that's going to bother them :p
I haven't looked closly, but from what I've read it is only bugfixes? Didn't came accross new devices so far 😅
So yours is already merged then?
"Yes" but it does the bare minimum of parsing protocol headers
Oh, that's old, I get a few more fields that that
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
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) >.>
I know the pain 😅
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?
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 😉
well, developing matter, I guess, not really developing matter within home assistant sure. ok. I can leave 🙂
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
it seems the best way to report issues with the Matter spec is to get hired by a company with a paying membership
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
Nabu Casa is a paying member