#devs_matter-archived
1 messages · Page 3 of 1
Yes but that requires a complete reset of the device
ok, i might try that with my next one
you can test it by running something like "docker exec -it addon_core_xxxx /bin/bash" from the shell
and then do stuff in the matter addon directly
i thought HAOS was locked down and you can't really get shell access
no, you can do this with the normal "shell"
and you can also get shell access to the root os by mounting a volume with some ssh keys or sth
the matter docker container has also apt, so you could install sshd in it and directly connect to it from there
or just mount the path to the python code in HA and use the vscode server addon
Or make your own addon https://developers.home-assistant.io/docs/add-ons/tutorial/
correct, I have that as well. And there is also a more advanced ssh addon
with docker included so you can do docker exec from there
I use that all the time
this one: Advanced SSH & Web Terminal
yeah, i use that one too
i think the best solution might be to install sshd in the container and then open it as a remote with vscode
or another addon, which is probably the best long term solution
@kind sedge do you actually have any devboards to run demo matter apps? It can probably be really useful to see whats going on on the device to debug some stuff
yes I have some esp32 based boards for that but barely use them as the example apps are often outdated or wrong
I have some thread based nordic test boards on the way
ok - i guess i'll setup a test instance of HA or something and use that for dev - don't really want to mess with my main HA instance to that degree
you can export a backup from your main HA
disable the matter addon
import it in your test instance
and have all devices connected
makes sense. i’ve done similar for other addons
Hi @kind sedge , thanks for suggesting posting my question on this dev channel. Hello everybody, I have been trying to setup the python-matter-server project without much success, I understand I need the chip project so one attempt I did was to install the virtual environment of connectedhomeip creating a separate build using the command scripts/build_python.sh -m platform -i separate, then using this environment I was installing the server with the instruction pip install python-matter-server[server].
This indeed breaks the chip and when starting the server I am getting Segmentation fault such as
chip.exceptions.ChipStackError: src/platform/Linux/CHIPLinuxStorageIni.cpp:122: CHIP Error 0x000000AD: Open file failed
But the same exception happen if I create my virtual environment and just do the python-matter-install.
Can someone please enlighten me on how to setup correctly a development framework?
Another option I have explore is the docker image, I was able to build the image and start the container that runs the server but then I realize the client has dependencies on chip as well. How would you develop a client to interact with the server, any recommendation will be appreciated.
Great to see you. So you want to set-up the development environment to help out contributing to the matter server ? Great!
-
What OS/platform are you trying to set this up ?
Note that only MacOS and Linux are supported (where on MacOS you need to build core from scratch) -
We host the prebuilt wheels for the sdk's core and clusters on pypi, note that we only build linux aarch64 and am64 wheels.
-
Did you specify the server to run with a data folder that is accessible ?
-
The client is just hosted on the same repo for convenience reasons, thats it. It does not require the chip core (only the chip clusters) so running that is much easier. We include the client in Home Assistant.
- The docker image we publish (used for the matter add-on) is hosting the server only. As I said, the client is just for consuming the websockets.
Thanks for your response,
- I am using ubuntu to setup the development platform, I do also have raspberry pi at hand if that is handy or other linux boxes as well.
- I tried to install using pypi on my ubuntu box but it fails. I created a new venv and then I did (matter-server-env) :~/devel/vens$ pip install python-matter-server[server], then I try to run the python example.py in scripts. I got the following logs
- I know that for the docker image yes data folder is there when I build. Is that different when using the wheels package ?
- How can I do a simple test with the client using the HA repo source code? I presume the chip clusters is a python package or module that once imported is as you said independent from chip.
- good to know, I was trying to open a shell inside that docker image and see if I was able to run client from there but it turns out to be not easy or convinient and probably not possile.
I will appreciate any additional comments you can throw here to help me get started. Thanks a mil
I have issues uploading the logs, at the last line I am getting
chip.exceptions.ChipStackError: src/platform/Linux/CHIPLinuxStorageIni.cpp:122: CHIP Error 0x000000AD: Open file failed
Segmentation fault
@royal valley I converted your message into a file since it's above 15 lines :+1:
Yeah, that error is about that hardcoded path in the sdk where the files need to be stored.
It may be as simple as making sure that "/data" exists on your end.
Are you planning on making actual changed to the mater server or just in the client and HA implementation ? Because the server part is actually just hosting the SDK, add a messaging protocol (websockets) and then the translation of raw attributes -> sdk models is done in the client.
The client only relies on the chip-clusters wheel which is free of os dependent requirements.
So we use the client to talk to the server, receive attribute data and communicate with the server/sdk.
Hi if I have a problem with my thread (SONOFF_Zigbee_3.0_USB_Dongle_Plus_V2) Stick. Should I ask in this channel or the normal matter channel?
Thanks!
This channel is only for developers. Ask in the thread channel but be aware that the Sonoff plus stick is not thread but Zigbee.
Ok Thanks you!!
(It can be flashed to be thread)
Where does the /data folder should be in ?
Ok, I will start by implementing an client. Can you help on how to correctly setup the client? What is the best approach and can you point me in the right direction please?
I completely lost you here. Why do you want to implement a client. I have no clue what you are trying to achieve, Maybe you should just start by saying what your goals are. So why do you want to run the matter server in a development environment and what area do you want to develop/contribute. For example if you want to contribute to the HA integration you can just connect to an existing running server.
Hi @kind sedge You are probably right about the client, I want to have a way to create a custom control, for instance I have a matter switch that I want to monitor state and create some action based upon it's state change for instance, let's say I want to publish that change into an MQTT server. I thought I was needing a client for polling the server and then do the rest MQTT/protocol translation stuff. Please guide me if you see my approach is not correct, your comments are very useful. Thank you.
are you trying to avoid using home assistant? i would think you can do all that in home assistant automations/scripts
Not at all but I am having issues with some devices connecting to HA and I would like to setup a development environment, is that not more flexible?. Are you developing the server/client stuff always with HA OS?
no, but it sounds like your goal is to setup automations. in which case ha sounds like a great solution. so it makes sense to debug separately but i would still add to ha
Hi all, where can I find the source repository for the home-assistant-chip-core package? The package is only published to PyPI as a wheel, so I cannot recompile it on my system (FreeBSD).
The PyPI metadata points to https://github.com/project-chip/connectedhomeip. But there doesn't seem to be any home-assistant specific bits, nor any python packaging, and the tags don't line up. I'm guessing this is just out of date metadata.
Does anyone know where the source lives? Thank you!
that is where the source lives, what you don't have are the build incantations which lives here: https://github.com/home-assistant-libs/chip-wheels/blob/main/.github/workflows/build.yaml
core, clusters and repl all get built from the upstream chip repo in that workflow
that upstream repo uses scripts/build/gn_gen.sh and ninja to do the building, which is why you can't see the python packaging and why there isn't an sdist - its a big hairy c++ project that doesn't fit well inside an sdist.
HA does have 5 downstream patches to that repo you linked to; they are also in the repo i linked to.
@kind sedge
I was looking at transitionTime for bulbs and you had mentioned it in the past so I wanted to document a few notes.
Sadly a smooth transition isn't as straight forward as fixing the light on/off with optionsMask. Providing a non-zero transitionTime does work however, the problem is the number of transition steps. All of the MoveTo commands (MoveToHueAndSaturation, MoveToColor, MoveToColorTemperature) have transition steps that depend on transitionTime.
Specifically this is based either on the TRANSITION_STEPS_PER_1S fixed in the color-control-server header or the expression max<uint16_t>(transitionTime, 1). In either case this results in a fairly terrible experience; if you have a relatively short transitionTime (<1 sec) then there's a very few number of steps which looks pretty terrible. Higher transitionTime means more steps which does look good, but obviously takes longer and is undesirable.
I was able to also take a look at how this was handled in google home and it's the same crappy behavior which leads me to believe the transition we see in nanoleaf (smooth between colors) is their proprietary protocol.
tl;dr - smooth transitions using the sdk don't seem possible. I think a smooth transition is objectively better than an instant change, but absent that, it's kinda a personal preference, might not be worth implementing until the above details change (i.e., matter 1.3+)
Thanks! I had planned to look into this next week so this is helpful info, didn't look into it at all yet, I just know we still need to implement transitions. I'm now first finishing the diagnostics stuff and the config actions ion the frontend so that is hopefully right on time for next HA release and then I'll checkout transition
that is where the source lives, what you
Hi @kind sedge : I rephrase : "Sorry if I was not clear enough : I installed ghcr.io/home-assistant/home-assistant container with Docker. Then I aim to be in "developer" mode regarding matter addd-on so that I can modify the python source code , add some logs etc... That's why I 've installed the python matter server with pip install, then running the server failed because of targeted lybcrypto version not the good one when in ubuntu 22.04.3 .2024-01-31 08:39:05 nuc-2 matter_server.server.stack[4798] INFO Initializing CHIP/Matter Controller Stack... OSError: libcrypto.so.1.1: cannot open shared object file: No such file or directory. I'll try to figure out why chip native using nativeLibraryHandle = ctypes.CDLL(FindNativeLibraryPath()) is looking for this version"
OK, I wasnt aware you were actually trying to do development for the Matter server. As we do not support user installs other than the add-on (due to all added complexity and OS requirements).
My best hunch for now is that you need to have openssl installed
but you should also have a look at our docker build what OS dependencies we include.
I'm developing on MacOS myself but I'm also building the core sdk myself (which is kind of cumbersome) - on Linux you should be able to just install our prebuilt wheels for the sdk
Ok then, thanks for the tips, and any way, congrats the whole dev team for gettting HA such a great tool !
Yep, with good openssl version , works fine
FWIW, there was a discussion about OpenSSL version here:
https://github.com/home-assistant-libs/chip-wheels/issues/24
I haven't checked latest upstream Matter, maybe they've updated now 🤔
Hi @kind sedge and @solid mountain : Also, I wonder about this note "chip-device-ctrl is no longer maintained and should not be used."' in https://github.com/project-chip/connectedhomeip/blob/fda14c69563aaaaccf87ffa8e7afdb262274316e/docs/guides/python_chip_controller_building.md as matter HA python server is binded to the ChipDeviceCtrl.so from chip-device-ctrl. Any comment on this ?
chip-device-ctrl (as in https://github.com/project-chip/connectedhomeip/blob/v1.2.0.1/src/controller/python/chip-device-ctrl.py), was the first attempt of a CHIP tool or anything years back. It drove the development of the initial Python bindings. Therefor it also drove lots of it's design/API today. However, the Python bindings are today used by the Matter Python REPL (entry point being https://github.com/project-chip/connectedhomeip/blob/v1.2.0.1/src/controller/python/chip-repl.py). Both rely on the Python bindings. The Python bindings compile the SDK, and the SDK is named ChipDeviceCtrl.so... So this is essentially just legacy naming.
Maybe ChipCtrlForPython.so would be better 😅
It is essentially a C++ library (the Matter SDK) compiled with controller functionality, and the Python specific binding parts (as in, this stuff https://github.com/project-chip/connectedhomeip/tree/v1.2.0.1/src/controller/python).
tl;dr, ChipDeviceCtrl.so is just weird naming of the native code for the Python bindings. The Python bindings per se are not considered deprecated/legacy. They are used for testing etc.
Got it ! Thanks for the tips
Hi, seems matter server project board for status updates : https://github.com/orgs/home-assistant-libs/projects/1 is broken link; Any hint ?
Yeah we no longer use this, so it got removed. Did you found a link to it?
I am playing around with the Light Switch App. To get it to work, an ACL has to be sent to another Light App that the Light Switch is trying to control. I've put together some simple Python code to send a "write_attribute" command to the Matter Server socket API. It feels like what I have done is close to working, but its still not quite working. I'm sending: "args": {
"node_id": 3,\ "attribute_path": "0/31/0",
"value": [ {"fabricindex": 1, "privilege": 5, "authMode": 2, "subjects": [ 112233 ], "targets": null } ] but Matter is returning "Field [0]..targets.targets was not optional, but encountered None". But targets is nullable, so I'm missing something still I guess in the formatting. Any thoughts? BTW for comparison, here is what the chip-tool command looks like
chip-tool accesscontrol write acl '[{"fabricIndex": 1, "privilege": 5, "authMode": 2, "subjects": [112233], "targets": null }
Did you try to omit targets ?
Just tried it by removing: "targets": null. It returned with the same response.
Yeah, there's a a bug actually
Ah, OK
This bug should be fixed in the next matter server release
Hi
I am looking for some help to known how to add a python file in the ha core matter directory.
Is it possible to access the homeassistant/components/matter directory from the web interface's file editor?
If not, does this require recompiling the entire ha core? This is for my PR https://github.com/home-assistant/core/pull/111212
My device is ready and works fine with iOS. I'd like to continue integrating this Fan type into HA.
I saw your PR for the fan. Its however not going to work in its current shape.
I think you copied from the cover platform ? A better start would maybe have been the switch platform as its more basic and then look at e.g. zwave or zigbee how to do fan speed control for a fan next to turn on and off.
So even if you would path your own HA to use this file it wont work at all.
We have planned to add fan support for the next HA release (so not 2024.3 but 2024.4), can it wait until then ?
If you want to finish the fan platform PR then let me know and I don't start with it but help you review your PR
Yes I copied it from cover type but it don’t know how to test it. I will try to use switch as you recommend
I'd like to know if I need to compile ha core each time I modify the fan.py script for testing purposes, or if it's possible to modify the file locally in HAOS?
I'd like to try redoing the script and then publishing it. If that doesn't work, I'll wait for the next version of course.
Uusally you don't develop on HAOS but locally on your machine.
Just let me know if that works for you. Otherwise I can pick it up next week
thanks 🙏
Just tried this out again and it works!! thanks 🙂
@solid mountain Regarding this https://github.com/home-assistant-libs/chip-wheels/pull/33 Do you even think this would get accepted into the SDK? I have been thinking to just modify the existing macro instead to keep the change to just the macro, that is probably cleaner
They are usually quite open to any contribution, as long as it has a reasonable merit and the PR testing light up green 😅
Hey Team, has anyone had issues connecting nanoleaf matter light bulbs to home assistant? It's connected to a my thread network, but I can't seem to connect all of them, so I resetted all of them to start fresh, because nanoleaf app kept saying that it was connected to the matter controller (home assistant) but it wasn't. Now for some reason it can't find any of them which is strange. As for my router I just have a the asus ax6000, do you recommend to change any setting on there?
Any help is appreciated, cheers 😆
Sorry, I read a message earlier saying that this section of the forum is only for developers, ill use the other 'thread' forum, however I'm happy to post some error data here just to help out if you want 😀?
Oh haha thanks mercel
https://github.com/project-chip/connectedhomeip/pull/32550#issuecomment-1995906943 @solid mountain @kind sedge do you have any opinion about where the node id should be logged? Looking at this log https://dpaste.org/arL3R I'm thinking that all error messages showing the exchange id should be enough.
@dreamy veldt if we have the nodeid +exchange id logged once in the same or higher log level (as in higher precedence), I am fine. We could add a post process on a higher level.
On the other hand, code size at least on Linux is not really a concern. So maybe a opt-in compile time option would still be nice 🤔 I'd guess the runtime overhead is negligible as well 🤔
yeah, in my current implementation i have just made it opt-in
im thinking about figuring out what exactly causes the code increase though
and maybe put everything into a function (even though this has other kinds over overheads)
But that can be a deep rabbithole 😄
Yeah adding a function most likely will have slightly runtime implications...
Its merged now, ill update my pr to the wheel repo when i come home
@solid mountain should i just close my PR or will you keep on using an older SDK version for a while?
Can you update with your latest patch? I think then we can apply that to our build already for v1.2.0.1 and ship it.
I don't mind patching our SDK. I just like to have that patchset minimal. And since yours got merged upstream, we know the patch will go away eventually 😅
sure, will do that tomorrow 🙂
can i stop Matter Server in HA somehow? whenever i press stop in the ui, it starts again.
i want to debug an issue with mDNS, but it is difficult when i can't selectively control what is running in HA..
Afaik that is the integration starting the add-on again. You should be able to stop the add-on after disabling the integration.
@solid mountain thanks, that worked.
Hello, community. I am considering integrating the Matter Server directly into the Home Assistant Core, or finding a way for the Core to support Matter directly. I understand that currently, "Running Matter on a Home Assistant Core installation is not supported". Despite this, I am eager to explore the possibility of implementing my idea. Could anyone provide some guidance or a general direction on how to proceed?
It's not possible. Its 2024. You can easily spin up a container.
Hello again, and thank you for your suggestion about using containers. I appreciate the efficiency of that approach; however, my goal is a bit different. I'm aiming to provide a seamless, one-click installation of Home Assistant Core that includes the Matter Server directly, especially for users who plan to run it on a Raspberry Pi as a local hub. This would ideally simplify the setup process for less technical users who might not manage Docker containers comfortably. Could you offer any guidance on how to integrate the Matter Server into the Home Assistant Core installation package or create a streamlined setup process that can be easily deployed on a Pi device? Any advice or resources would be greatly appreciated. Thank you. ☺️
We already have that: its called Home Assistant OS
Apologies if this is the wrong channel;
Is anyone here experimenting with creating their own matter compatible devices in a DIY/Hobby capacity? Are there any recommended resources, tutorials or getting started guides? I quick google search landed me on silicon labs website and there are some guides there. Just wondering if thats what the community would recommend to get started with
Depends what hardware you want to use for that. The project CHIP/Mattere SDK has sample apps for all sorts of chips. We've compiled some of the example apps for ESP32 and have them online, this might a good starting point: https://github.com/NabuCasa/matter-example-apps/
What hardware would you recommend to get started with?
You can use an ESP32-C3 board for a basic project.
Thanks @kind sedge for Matter dashboard to explore Node value. It helps a lot.
@uneven creek I converted your message into a file since it's above 15 lines :+1:
Hello @kind sedge
Is it possible to use chiptool from the command line of a HomeAssistant instance?
The goal is to test and control a Matter 1.2 device type not currently supported in the Home Assistant web interface.
No, but we have chip tool as a dev addon if that makes sense
Thanks. I managed to install CHIP Tool with Home Assistant Developer Add-ons.
This is what I was looking for.
I want to discuss here about device credentials generation for Matter devices. Today the code that is on Android code (I believe same will be for iOS). Would it be possible to add a credentials generation method in HA (core?) so that the apps can generate from there instead of relying on Android/IOS? I am a software engineer willing to contribute for that in case it is feasible and I can get some minor support by HA team.
Not sure where to put this but could one of the maintainers check out the following PR. Everyone updating to 6.0 in docker is going to end up with a non functional matter server because of paa certs. https://github.com/home-assistant-libs/python-matter-server/pull/706
Just wait for somebody to review the PR. Running the Matter server in docker is officially not supported so fixes go on a best-effort base.
I’d be curious why the add on version which I assume is basically the same and I’m sure is in a container wouldn’t see this? You override the paa certs directory for it?
I’m not sure either. Stefan handles the addon stuff. I think it might indeed be true that the docker image is not the same as the addon as that is tailored for HA
Yes, this: We set it to /data so the PAA certificates persist. I think it makes sense to do the same for container installations, I created a PR for this:
https://github.com/home-assistant-libs/python-matter-server/pull/708
does Home Assistant use Matter over TCP? or does anything use it over TCP?
it looks like the Matter core specification R1.2 vs R1.3 changed the protocol in an incompatible way
I'm not sure how outside implementers are supposed to know "nobody uses this one feature in practice yet so the protocol could be changed in the future" but here we are
I'm running into some issues with Thread sleepy end devices timing out on commands. The device is a thread blind motor.
matter-server | 2024-05-26 15:41:03.681 (Dummy-2) CHIP_ERROR [chip.native.EM] Failed to Send CHIP MessageCounter:91681122 on exchange 26613i with Node: <0000000000000034, 1> sendCount: 4 max retries: 4
matter-server | 2024-05-26 15:41:10.813 (MainThread) ERROR [matter_server.server.client_handler] [281473450374288] Error while handling: device_command (node 52): src/app/CommandSender.cpp:328: CHIP Error 0x00000032: Timeout
If I send the command again eventually it seems like communciation is successful:
matter-server | 2024-05-26 15:42:57.993 (MainThread) INFO [root] Re-subscription succeeded!
and the command gets sent.
It looks like this timeout is computed by the SDK if not set; looks like there was a recent commit to CHIP that supposedly addresses it (https://github.com/project-chip/connectedhomeip/commit/3e93ba6e7a1830ff20623b1f892d5e6540fbb2e7). I'm trying to update CHIP - it looks like its getting pulled in by home-assistant-libs/chip-wheels. Is forking and pointed to a manually built wheel the easiest way to test this?
Well, I've managed to rebuild the wheel for chip-wheels, but now I'm getting an issue with GetTLVAttributes. It seems like this was added recently but I don't see any reference to it in the chip repository on SubscriptionTransaction
You need to have a look at our wheels build process because we do patches on top of them. Simply check the github actions. But maybe we can just receive the PR and build the wheel from there ?
@solid mountain anything more to add here ? Is this the issue with ICD maybe ?
I ran the entire process in CI (I have my own fork with arm64 runner), so it should be the same as your process (https://github.com/no2chem/chip-wheels/actions/runs/9249315694). I just used the artifacts from that fork
ah yeah, that should work indeed.
I didn't see GetTLVAttributes injected anywhere. Either way I reverted back to tag 6.0.1 but it seems like I'm still getting some timeout issue
GetTLVAttributes was added last week so its rather new
I think the only PR thats in the chip-wheels repository is essentially what I did (update the CHIP submodule)
anyhow I can't tell if its my thread network; python-matter-server or chip that's the issue . It might really be a CHIP issue but it seems like the rount trip time might be really variable if the device goes to sleep
Well, what you describe sounds like the CASE session was lost to the device
hm, indeed: matter-server | 2024-05-27 06:31:36.041 (Dummy-2) CHIP_ERROR [chip.native.SC] CASESession timed out while waiting for a response from peer <0000000000000027, 1>. Current state was 1
It successfully re-establishes it, but I think that it should retry sending the command perhaps? Not really sure what the best steps would be.
(i have to send the command again after it gets automatically re-established)
on another matter though; is anyone actively working on the matter cover integration? The rollers I have expose a few attributes such as limits that I'd like to expose to HA. I'm wondering if it would be best to actually expose them as entities since they're one time settings (maybe marked as diagnostics); or if it'd be better to just have a service in HA to manually set/get attributes?
i'm happy to submit a PR
Well, the problem is that the SDK didn't even realize that the session was lost at that point so I advice start with checking why the device looses its connection. At the same time a retry may be worth it anyways to catch edge cases. We use a rather high subscription ceiling for battery powered devices so we may also consider lowering that to detect a broken case session sooner.
I see. yeah, I'm not quite a matter expert... the devices are connected via an ethernet-backhauled thread network so it shouldn't be the network in theory...
That sounds like just adding a few extra sensors, just update the discovery schema for the sensor platform. But if these are actual settings, I think we need to use other platforms.
We are planning to add the remaining platforms (like number, fan, button) in the next few weeks and then we're going to fit the remaining models into those platforms. Configuration params (and things like filter resets etc) are a very good fit for number platform and button
Let me know what attributes we're talking about. Then we can have a chat how we could fit it in now.
I see. I'm actually not sure if they're settable or not, but for window covering: https://leconiot.com/matter/1.1/appclusters.html#_attributes_9
for example - InstalledOpenLimitLift, InstalledClosedLimitLift
Note that most of those attributes are optional and I have seen very little devices so far that actually implement them.
And yeah, these sound like (very advanced) config sensors to me
Well they do show up but I guess it is a question if they are implemented
when i browse in python-matter-server
if they show up as config sensor (vs number etc) then they wouldn't be editable though
well, I found the WRITE_ATTRIBUTE ws api call, I guess they all return 136=UNSUPPORTED_WRITE so the attributes must not be marked writeable anyway
Well, in the Matter server's own UI we actually only show the attributes that actually have a value.
So if you really want/need to see these values in HA, they need to be configured as config-type sensors. So simply add a discovery schema at the sensor platform will suffice. But tbh I'm not so sure if these particular values are important enough to import into HA as they can also be read out through the matter server UI.
yeah true. I've noticed the UserLabel cluster seems to work, maybe that would be useful. Guess I'll poke around to see if there's actually anything useful that hasn't been exposed
It is only on the release branch currently, are you using main?
I'm using main, I see the patch in release now
Well, it is tricky, trying to resend forever and block the caller forever is wrong too. The Matter protocol has it's own MRP (message reliability protocol), which does resending and whatnot. In the end the question is how long/many times should it retry?
yeah. it would be useful to have some diagnostics show up on the webui, perhaps a ping button or something
right now thread is a bit of a headache because it's quite opaque
We have that on HA side.
But I usually end up copying the IP and run a continuous ping and monitor that a bit. The single ping only tells you so much.
yeah
Yeah I think it doesn't. But usally the problem is intermittend, even if it would tell you a value there, it might fluctuate quite a bit
Is that a device which is released/publicly available?
yeah its a "JLM Smart Window Shade Tubular Motor"
What is the negotiated livnesss timeout?
We had seen issues with other ICD devices, but I don't think that commands time out there.
is that an attribute?
No, that is part of the attribute subscription
i see, what's the easiest way to see it? (this is the timeout that the CHIP sdk negotiates?)
So what we have seen is that ICD SIT devices liveness check failed. E.g. when doing a Matter attribute subscription, the controller (aka client) automaticallyi gets updates for subscribed attributes. However, if nothing changes, there is a upper limit until the device has to check-in (aka Liveness check), to essentially establish that the CASE session is still alive. For battery operating devices that is set to 600s. The device however can for battery optimization purposes request a higher time. The value is printed in the logs when the subscription is established.
I see. there is a PR in the CHIP repository that supposedly fixes something
I mean commit*
You mean the one you linked above? Yeah I saw that, intersting find.
I'll rebuild the wheel on the release branch and see if it helps over a day
Cool yeah. I mean we can easily backport that PR if it does, seems like a sensible change.
right now sometimes when there are 5 or so blinds in a room sometimes 1 of the blinds misses the command to open, so yeah
Hm, so you send 5 at once?
well, i assume HA translates that into 5 different calls
The MRP does 4 resends normally, but I guess if the Thread network gets temporarily congested, it might loose all of those 😢
yeah. my thread network is all ethernet connected ESP32s+ESP32H2s soo it shouldn't get too easily congested
not with 5 open cover commands, hopefully.
but who knows maybe the esp32s don't have enough of a openthread buffer.
Ethernet connected esp border routers?
yeah, POE ones actually.
One of the downsides of that is I don’t believe they have TREL, and Linux doesn’t have routing metrics for the other side of the ESPs, so it can’t pick the “best” ESP for the first hop. That means you might actually double or even worse the amount of thread traffic because Linux will pick a random node, then that will have to forward it through the mesh.
Hm, I see. Honestly I don't trust the ESP32 BR to much at this point 🙈 😅
Oh, is there something you recommend then? I have a lot of Google nests but they seem on insisting to pick channel 14 which is really bad
It would definitly be interesting if the problems go away with Linux based OTBRs or one of the Apple/Google ones.
I suppose I can try killing all the ESP32 otbrs
I have 1 ZBDongle-E linux OTBR and 4 esp32 ones, so I can see if that helps
It’s kinda hard to recommend anything. I stick to HomePods exclusively, and make sure to version match. Because I have a small mesh, working TREL is even more important. But we’ve seen problems mixing and matching versions and vendors.
Oh - in that setup it will always uses the ZBDongle for the first hop
If you have a dongle on the same box as HA it will always have priority routing wise. So you are better off adding more mains powered thread devices of any sort than BRs In particular.
oh well i have 0 mains powered thread devices so that probably doesn't help
other than the BRs, but there are a 5 of them, or so i thought.
The only advantage to your setup is on the return path, the replies should egress the closest BR. But that doesn’t seem to be a factor:
traceroute seems to suggest they are routing correctly to the nearest otbr though
and actually nothing seems to be going to the ZBDongle-E (its in the attic so, makes sense)...
well, they're in docker containers, guess i can drop into that container
Host mode network?
So the way such a device is supposed to work (from what I understand/on a high level):
- The device operates as SIT (Short Idle Time) ICD (Intermittend Connected Devices)
- That means it's TX side is not always on. It advertises it's SESSION_IDLE_INTERVAL how long that is.
- This value is then also used as MRP (message reliability protocol) retry interval
- When sending a command, the MRP tries sending four times this packet to the device, each time it should at least wait as long as the SII.
These timeouts should align with what is set on Thread level, of course. And the Thread devices/BRs should adhere to them (buffer packets that long etc. etc.)
The SII is advertised through mDNS, so you can check this value. My Eve Motion Blinds here advertise this:
SII=1800 SAI=1100 T=0
So 1.8s. The default is 0.5s (when nothign is advertised).
When pinging a device, you should get responses within SII, always. Otherwise something is wrong or you have a congested/bad (Thread) network.
For my Eve this works out nicely:
$ ping BE06C2262B6658CA.local.
PING BE06C2262B6658CA.local. (fd40:190:dc8e:1:dfd8:e3ff:4562:74e4) 56 data bytes
64 bytes from fd40:190:dc8e:1:dfd8:e3ff:4562:74e4: icmp_seq=1 ttl=62 time=832 ms
64 bytes from fd40:190:dc8e:1:dfd8:e3ff:4562:74e4: icmp_seq=2 ttl=62 time=830 ms
But if a device advertises wrong SII, then it could be a device side problem. But I'd hope that this is all tested/catched when going through certification. 😅
yes, but seems like theres no traceroute in the container,guess ill fix that
Ah, the patch I’m thinking of might only be in the HA version of OTBR. I believe stock OTBR is never used when there are “external” BRs.
@solid mountain I converted your message into a file since it's above 15 lines :+1:
It’s a fix that @solid mountain had to make for HA because of a route loop of some sort with TREL and Apple.
cool thanks.
I see SII=2800 SAI=1000 T=0 for these devices
so that should be good as long as the pings are consistent
@solid mountain iirc traceroute can’t see thread mesh hops right?
Yeah nope you would not see those through traceroute.
From all that I know, the BR selection in the end is essentially random. There is nothing in the IPv6/routing protocol which tries to choose the best BR (also not in higher up Matter or whatever). So a packet just hits "a" BR. The question is then waht that BR does with it. With TREL enabled, it tries to search the best path and incorporates WiFi/Ethernet links.
yeah okay so it does indeed look like packets are getting routed to the different otbrs:
traceroute to fda1:1776:a38b:1:d1ef:53f1:6169:bcd2 (fda1:1776:a38b:1:d1ef:53f1:6169:bcd2), 30 hops max, 80 byte packets
1 fd45:4d83:702a:f8cc:a2b7:65ff:fef0:7ce3 (fd45:4d83:702a:f8cc:a2b7:65ff:fef0:7ce3) 1.671 ms 1.615 ms 1.594 ms
2 fda1:1776:a38b:1:d1ef:53f1:6169:bcd2 (fda1:1776:a38b:1:d1ef:53f1:6169:bcd2) 1689.725 ms 1719.880 ms *
traceroute to fda1:1776:a38b:1:84e5:730a:9e8c:21c5 (fda1:1776:a38b:1:84e5:730a:9e8c:21c5), 30 hops max, 80 byte packets
1 fd45:4d83:702a:f8cc:dea6:32ff:fe4f:a940 (fd45:4d83:702a:f8cc:dea6:32ff:fe4f:a940) 0.724 ms 0.670 ms 0.649 ms
2 * * *
3 * fda1:1776:a38b:1:84e5:730a:9e8c:21c5 (fda1:1776:a38b:1:84e5:730a:9e8c:21c5) 285.343 ms 327.567 ms
@opal linden but yeah there was something where the TREL would not work for some reason, but I honstely lost on the details now 🙈 I don't think the fix was in OTBR.
now I guess the question is if they're just random or closest
When the routing metrics are the same (ip -6 route) it’s effectively random
(the pings vary between 800 and 1800 for some reason, btw)
64 bytes from fda1:1776:a38b:1:d1ef:53f1:6169:bcd2: icmp_seq=1 ttl=63 time=1856 ms
64 bytes from fda1:1776:a38b:1:d1ef:53f1:6169:bcd2: icmp_seq=2 ttl=63 time=857 ms
64 bytes from fda1:1776:a38b:1:d1ef:53f1:6169:bcd2: icmp_seq=3 ttl=63 time=1874 ms
64 bytes from fda1:1776:a38b:1:d1ef:53f1:6169:bcd2: icmp_seq=4 ttl=63 time=903 ms
64 bytes from fda1:1776:a38b:1:d1ef:53f1:6169:bcd2: icmp_seq=5 ttl=63 time=1983 ms
64 bytes from fda1:1776:a38b:1:d1ef:53f1:6169:bcd2: icmp_seq=6 ttl=63 time=973 ms
64 bytes from fda1:1776:a38b:1:d1ef:53f1:6169:bcd2: icmp_seq=7 ttl=63 time=1995 ms
64 bytes from fda1:1776:a38b:1:d1ef:53f1:6169:bcd2: icmp_seq=8 ttl=63 time=992 ms
What I don’t understand is what happens in a partition with no trel. I think each partition elects a leader. But I don’t know if the infrastructure network can talk to both partitions, or it’s pot luck about which partition you hit.
That’s the sleep interval in play
Pings get queued at the nearest router until the device wakes up
Yeah that looks very similar when pinging a Eve device. ping just sends out every 1s. It seems the sleep time is aroudn 2s, so now two ICMP get processed at once.
We actually have a bug in homekit over thread for the same reason
Coap timeout less than sleepninterval so retries and device gets 2 copies of the same message
I guess one of the partition has to change the IP range no? Also not sure, never really looked into what exactly happens when Thread partitions. I think I had once a case where the network partitioned, but that was due to a buggy router device (the S4 smart plug to be specific). It recently got a new FW, I really hope this is gone 🤞
Hm, I guess the MRP takes care of potential (UDP) message deduplication in Matter. Nothing of that sort in CoAP?
ok after figuring out how to get the mac address from ipv6 addresses, it looks like indeed the messages are routed randomly 😦
Which isn't necessarily a bad thign, as long as they find the target 😅
haha I have a horrible 2.4GHz environment so
@hollow bronze you are not using HAOS right? Are you using Network Manager?
no i'm just using a docker container with host passthrough and ipv6 sysctls
Yeah that might be problematic 🙈 . Thread is a rather "weak" player in the 2.4GHz battle.
So the best option for TREL right now is a fleet of HomePods
yeah the problem I have with the vendor stuff is its impossible to control
Ok, so you rely on the Linux kernel's RA processing, which with the sysctl should be fine.
yeah
However, there is still that which might be problematic in your environment:
https://github.com/home-assistant/operating-system/blob/dev/buildroot-external/patches/linux/0001-ipv6-add-option-to-explicitly-enable-reachability-te.patch
With docker and host passthrough yes was just going to say
And I am still blanking on what the fix was in that TREL routing issue I've been seeing 🙈
It was the route metric that otbr uses
hmm
Was that it? But why though 🤔
It was lower than Apple
@hollow bronze it is not suuuper important, it just takes longer for the network to stabilize when routers come and go.
I see. yeah I can try adding it to my kernel, the routers don't really come and go
I think your theory was that Apple was sending stuff to us via trel but then their routes had priority so we sent it back to Apple
So you flipped the priority
K. Just something you need to be aware about. If a router disappears, your Linux host might send packets to it for up to 30min or so (typical RA timeout value) to /dev/null essentially 🙈
oof
yeah well, guess ill patch the kernel sooner rather than later lol
suppose I'll go look at implementing TREL on this esp32 otbr
it seems like it doesn't need a change to the RCP so shouldn't be that bad
@opal linden right! And this was the fix:
https://github.com/home-assistant/addons/blob/master/openthread_border_router/0003-openthread-set-netif-route-metric-lower.patch
For the kernel patch, The other option is to change the forwarding sysctl, right? (And if it conflicts with docker, move your otbr container to use macvlan?)
But I think the problem was the other way around, and an entirly IP problem: The OTBR received a packet, but forwarded it to another BR because the metric was lower than the local netwokr interface.
I thought it was TREL related etc, but I think this was a pure IP problem with OTBR
Yeah it is tied to IPv6 forwarding.
Good question, it is quite possible that with macvlan you can sidestep the issue 🤔
Ahhhhh
I run my matter server container in macvlan mode and it seems to work anyway
Looking at the patch again it does seem as reachability probe is only affected when changing the all forwarding setting. So I guess if you only change forwarding for a particular namespace/interface etc.
strict |= flags & RT6_LOOKUP_F_IFACE;
strict |= flags & RT6_LOOKUP_F_IGNORE_LINKSTATE;
- if (net->ipv6.devconf_all->forwarding == 0)
+ if (net->ipv6.devconf_all->forwarding == 0 ||
+ IS_ENABLED(CONFIG_IPV6_REACHABILITY_PROBE))
strict |= RT6_LOOKUP_F_REACHABLE;
IPv6 has that per network interface forwarding setting.
Altough, I don't quite understand how it is working 🤔
Yeah I think this would be a good idea for HAOS as well. I mean, it is IPv6, we would not even need any IPv4 config I think.
Do you have IPv4 config in your Matter container?
Not sysctl wise no
I mean just IPv4 addressing
Yeah I have an ip and route, HA connects to it over ipv4.
@hollow bronze wait, a blind motor? How is it powered?
A lithium battery?
I'm just wondering what has enough power and battery life to drive a motor yet not enough to be a regular non-ICD Matter device 😅
In that case, it's strange indeed.
It's powered by a lithium battery, these things as Zigbee, ZWave and now Thread motors are pretty common and usually not intermittently connected
Yeah I thought ICD / Thread SED was more for "sensors running off a tiny coin cell"
ah yeah. Well, don't want to run around charging these things too often, they actually seem to be remarkably good at battery life
maybe if they implemented SSED the latency issue would be better
well, this ESP32 otbr implementation appears to be closed source. But I wonder if I can just setup the ESP32 device to forward the UART to a posix-otbr
in that vein, maybe it'd be useful if HA could manage more than one otbr (it seems like it assumes just one right now)
Technically it (sometimes anyway) needs the HA fork of OTBR
But it was being considered at one point I think
(The api posix OTBR has is more or less driven by ha. God knows what Apple does, but Google has their own dbus api)
Really needs auth…
There is a PR open even, but frontend code is missing currently
Ah I see. I'll take a look into it
It's alive btw:
otbr | May 28 02:35:39 cloudcutter otbr-agent[136]: 67d.09:46:00.449 [I] P-SpinelDrive-: co-processor reset: RESET_POWER_ON
otbr | May 28 02:35:39 cloudcutter otbr-agent[136]: 67d.09:46:00.449 [C] P-SpinelDrive-: Software reset co-processor successfully
otbr | May 28 02:35:39 cloudcutter otbr-agent[136]: 67d.09:46:00.449 [D] P-SpinelDrive-: Waiting response: key=1
otbr | May 28 02:35:39 cloudcutter otbr-agent[136]: 67d.09:46:00.465 [D] P-SpinelDrive-: Received spinel frame, flg:0x2, iid:0, tid:1, cmd:PROP_VALUE_IS, key:PROTOCOL_VERSION, major:4, minor:3
otbr | May 28 02:35:39 cloudcutter otbr-agent[136]: 67d.09:46:00.465 [D] P-SpinelDrive-: Waiting response: key=2
otbr | May 28 02:35:39 cloudcutter otbr-agent[136]: 67d.09:46:00.487 [D] P-SpinelDrive-: Received spinel frame, flg:0x2, iid:0, tid:1, cmd:PROP_VALUE_IS, key:NCP_VERSION, version:openthread-esp32/e486f3b944-456c44828; esp32h2; 2024-05-23 19:05:16 UTC
otbr | May 28 02:35:39 cloudcutter otbr-agent[136]: 67d.09:46:00.487 [D] P-SpinelDrive-: Waiting response: key=5
otbr | May 28 02:35:39 cloudcutter otbr-agent[136]: 67d.09:46:00.538 [D] P-SpinelDrive-: Received spinel frame, flg:0x2, iid:0, tid:1, cmd:PROP_VALUE_IS, key:CAPS, caps:COUNTERS UNSOL_UPDATE_FILTER 802_15_4_2450MHZ_OQPSK CONFIG_RADIO MAC_RAW RCP_API_VERSION RCP_MIN_HOST_API_VERSION
otbr | May 28 02:35:39 cloudcutter otbr-agent[136]: 67d.09:46:00.538 [D] P-RadioSpinel-: Wait response: tid=1 key=8
ESP32H2 RCP <-> ESP32 POE over Ethernet <-> socat virtual serial port <-> otbr-posix
i guess with some vlan priority rules it should be pretty good
460800 bps is like .5 mbps.
Now to figure out how to launch multiple otbrs using docker-compose
Well got it working with TREL: seems like you need to set arg OTBR_OPTIONS=-DOTBR_TREL=ON to turn it on (maybe the HA otbr already does this
Yeah HA Add-on does this already.
Btw, it would be nice if we could release a official HA OTBR container which people can run alongside the Matter Server. Similar to Matter, I'd then base the add-on on that container as well.
Yeah that would be nice (isn't there an add on though ?) though after turning on TREL in otbr-posix, I see that the esp32-otbr also produces TREL traffic
There is an add-on, but it contains patches not in the upstream one
Sometimes even api differences as I said yesterday
So it would make sense to have a container as well, so that non HAOS users don’t run into trouble already patches in the addon.
It would be nice to have docker users and HAOS run the same revision too, which isn’t true of the current setup.
Interesting that esp BRs seem to support trel - they were very uninterested in supporting that a few months ago when ha users asked. (From what I remember). Do you see a _trel._udp mdns service ?
No, they don't have the trel service but they are sending TREL packets (at least otbr-posix reports TREL traffic from them).
@kind sedge Thanks for your help with the Matter fan device type.
I'd expect that most esp32 based thread brs are probably based on the espressif example code https://github.com/espressif/esp-thread-br and if you can figure out which gpios are used to communicate to the rcp you should be able to compile that for the device. The example's really basic tho.
(They have an open issue for TREL: https://github.com/espressif/esp-thread-br/issues/43 )
Seems like there's some limitations in their mdns stack that need to be fixed before they can work on TREL.
the source code there links to a closed sourced library, unfortunately.
(if you dig deeper, you'll find that the thread code is in esp-idf with the border router code - and that code links to the library here: https://github.com/espressif/esp-thread-lib/tree/5ae57e156e4cd2ccd8dc51e90266b16b284e64de)
I found that the ESP-based routers crashed pretty frequently with ethernet, and if they're going to be closed source you might as well just get a homekit
er, apple homepods or whatever
those are precompiled libraries, but I think they're more or less just openthread and are only really there to speed up builds. But yeah, they don't seem to say anywhere whether or how it's patched or how to reproduce those builds :/
nah, its openthread with a bunch of their modifications, looks like someone asked for the source and was told no https://github.com/espressif/esp-thread-lib/issues/1
ah, that's annoying.
weird that it's only the thread border router portion that's closed source.
yeah. though it seems like just piping the serial stream to otbr-posix works fine with the h2. I guess i'll build a few PCBs with esp32 + ethernet + poe -> esp32h2 at some point
though, otbr-posix isn't without its own issues either..
(it looks like the ncp firmware for the h2 can be built using open source openthread + port source code in esp-idf)
yeah that part is open source thankfully
it'd be nice if the H2 had an ethernet MAC but I guess it doesn't... then you could just have it dump spinel
although I guess you could hook a W5500 to it
fwiw, i've been running the thread border router devkit for a while as my only thread br (with the W5500 expansion board) and it's been mostly fine... once i increased the number of mdns entries it could handle above the default 10 :/
that's a kinda ridiculous default; i went to add a 4th thread device and it just never showed up in mdns.
haha yeah, I have 30 or so thread devices so idk if they keep crashing because they run out of entries (i set it to 50)
but I don't have the W5500 - I used an olimex ESP32-POE board and hooked it up to a h2-devkit
yeah, crashing might be running out of ram :/ I haven't really looked into memory usage much.
I have slowly resumed work on my Matter dissector for Wireshark...
I should find a CSA member company willing to hire me >.>
Nice, happy to report that the ot-br-posix -> esp32 ethernet serial bridge -> esp32h2 RCP is working way better than the espressif border router closed source trash. 3 docker compose images running over macvlan and its working great
pretty cheap way to get a large stable thread network going considering a esp32h2 devkits can run as low as 5USD
Nice. So that’s the only change and now your curtains are all good?
I think there was a matter patch you were looking at so wondered if that was needed as well?
How do I access the data file for the Node configurations at the Python Matter Server? I'm using HAOS. I can't find where the Data directory for the Docker container are stored.
Normally you would not need to access that data - also there is no such thing as node configurations
The data is stored in the /data folder - you would need to exec into the container to access it
or access it from the HAOS console
Ok, how from console?
I want to search through the Clusters per device type and also save them to be able to compare older versions to newer when a device is upgraded to, for example Matter v1.3. The GUI is not suited for this.
Just go to HA settings --> Integrations --> Matter and download the diagnostics
It will give you that output
Note that this is just a cache from the server for the device attributes - only the device itself has the actual truth but it should basically get what you seek. The attributes are stored in the raw form, keyed on attribute path
The info in the diagnostic file "config_entry-matter-xxx" is not what I'm really interested in, I need the details and format from the Python Matter Server. Is this not available from HAOS console, do I need to access the container?
Forget my above question, I understand now 😉 The file at the container is exactly the same from downloading the diagnostic file 👍
I hoped that the names of the IDs was also in the stored config file, but that's not the case but it's parsed in the GUI. Where for example "0/31/0" = Endpoint #/Cluster ID/Attribute ID = Endpoint 0/Access Control/ACL.
So what tried to achieve was this list but including the readable names and the ID as Hex. Then it's easy to read and also easy to look-up detailed info in the Matter specification documents. Is this useful for someone else, shall I do a feature request for his (like a Diagnostic Enhanced file)?
sort of, it looks like a few (3-4) nodes never rejoined the network. trying to figure out what the best way to debug that is...
related, it would be nice to be able to see the node ids in the device list view in ha. it seems like 'device info' is loaded async which I click on the device
it'd also be nice if python-matter-server was able to get the entity name from ha - but just having the node id in the device list view would make it a lot easier
Exactly - its stored in the raw/compact format to limit size.
That is where we have the Matter server UI for - you can even import an old file into the matter server UI and it will create a fake/virtual node for you. Try it out.
So You can use that Matter Server UI as a "viewer" for those dump files, and even how it looks like in the whole chain. Removing it again removes all traces
Sorry, that is not possible (for now) as HA is not natively aware of those Node ID's, its purely an implemenation detail of Matter in this case, hence its loaded in that small block of diagnostics info.
Also the Matter Server is not aware of HA entities (HA is just a consumer of the server) so showing entity id's there is also not possible. Remember that
hmmmm the Matter spec explains how to drop duplicate received messages and how to retransmit unacknowledged sent messages, but it doesn't seem to say anything about out-of-order messages
I can't find code in the SDK handling packet reordering either
Oh maybe I didn't mention this before: the basics are already upstream, on Wireshark 4.2 and later you can right-click a UDP packet and select "Decode As" -> "Matter"
Cool! Will the fake device also be visible in HA? Unfortunately, it doesn't work well as viewer for me as I can't easy search for a specific hex ID or the name of the cluster or attribute.
I'm really wondering why you want all that tbh - Open the file in a text editor and search all you want.
The fake device will also be in HA btw.
If you want anything else, I'm afraid you'll have to build something yourselve or PR some additional features to the server's UI.
i wonder if there's actually any case where multiple messages in flight could happen such that they could get out of order. my (admittedly kinda high level) recollection is that all the flows have it wait for an ack before sending another message (other than a retransmit)?
I didn't implement decryption yet so I don't know what they are 😅 but it was in a commissioning flow / PASE session
311dc00 and 311dc01 could get reordered by the network
I see. It does make it pretty difficult to debug issues. Right now I just want to do the simple task of figuring out what children are attached to a router
From otbr I can get the child IPs using the childip command
python-matter-server knows the device IPs but doesn't expose them anywhere (except the API call HA makes)
HA has it, but it takes a few clicks and theres no way to get a list
The reverse is a little easier - if I click on the child in HA with the ipaddress I can just run traceroute6 and figure out the ipv6 of the border router.
btw, even though the network seems to work okay now, it seems that my thread network is still quite random with devices connecting to far away routers. can't figure out how to get the children to move yet
to my understanding, if a node changes its IP address while having an active session, the other node talking to it will notice the missing ACKs, do DNS-SD discovery to find the new IP, and resume communication without negotiating a new session, just resending the lost packets and continuing like normal
could someone send me a packet dump of that scenario? I'm sure someone here can replicate it much more easily than I can (I don't even have a functional HA setup right now)
btw, even though the network seems to work okay now, it seems that my thread network is still quite random with devices connecting to far away routers. can't figure out how to get the children to move yet
They really should connect to the "best" router by default, no interaction should be needed. However, from Zigbee devices I know that at times link quality estimates are off, which leads to wrong parents selected. But this is very hard to actually prove: Just proximity isn't all. Maybe that other router has better receiver antenna, and despite being further away, still receives messages more reliable... 🤔 🤷♂️
There is the sequence number in the MRP which should make it easy to check/reorder no (4.6. Message Counters)? That said, I also didn't find something about ordering, but to me that feels kinda implied with a message counter no? I don't know if something is implemented in the SDK currently, but I would highly expect so... 🤷♂️
I do see IP changes when taking Thread BRs offline etc. so this could be a way to simulate a real world scenario. Otherwise just changing IP of a system running one of the Linux examples (I made recently a GH Action workflow which builds those for Linux x86-64/aarch64, see https://github.com/agners/matter-linux-example-apps).
I probably could make one. Encrypted fine for that? Happen to have a tcpdump command handy? 😅
hm its weird; today I woke up this morning to all my nodes showing offline in python-matter-server.
example:
matter-server | 2024-06-03 18:19:50.146 (MainThread) INFO [matter_server.server.device_controller.mdns] Node 43 discovered on MDNS
matter-server | 2024-06-03 18:19:50.147 (MainThread) INFO [matter_server.server.device_controller.node_43] Setting-up node...
matter-server | 2024-06-03 18:20:24.663 (Dummy-2) CHIP_ERROR [chip.native.EM] Failed to Send CHIP MessageCounter:158684862 on exchange 30524i with Node: <0000000000000000, 0> sendCount: 4 max retries: 4
matter-server | 2024-06-03 18:20:31.818 (Dummy-2) CHIP_ERROR [chip.native.SC] CASESession timed out while waiting for a response from the peer. Current state was 1
It seems the device is pingable: but I don't know exactly what address python_matter_server resolved using mdns. Guess I'll add some debug statements
seems like the IP is not available before calling
await self._chip_device_controller.find_or_establish_case_session.
ie
await self._chip_device_controller.get_address_and_port gives None
is there a way to turn on more verbose logging in CHIP?
er never mind I guess log-level=debug does it but there's no logging that helps
There is a separate setting for SDK which gives more information
From the snipped above it seems the device is not responding? 🤔
all of the devices are 'not responding' suddenly, but I can still ping them fine
I guess I can't tell if CHIP can't communicate with them, or if the CASE session establishment is failing for some reason
This is very unusual. What type of devices do you have? WiFi/Thread? Any common failure which could be a t play here?
they're all thread devices -
Where do you ping from? Same device?
the python-matter-server docker container
docker compose exec -it matter-server /bin/bash
ping6 fd0e:e57f:fc6f:1:63de:6d9d:e36:c201
yeah but I can't tell if python-matter-server is using that address
It might do another resolve. Are there multiple addresses which resolve to the same Matter node?
I don't think so - I think this is the address in mdns... one second while I try avahi-browse...
= eth0 IPv6 F92CB6C76E31E254-000000000000002B _matter._tcp local
hostname = [5EC8C87641D6F39F.local]
address = [fd0e:e57f:fc6f:1:63de:6d9d:e36:c201]
seems that theres only one address in mdns
Is this reproducibel even accross matter server reboots?
yeah, ive rebooted it several times by now
so far i've traced it to FindOrEstablishSession in src/app/CASESessionManager.cpp... there are several ChipLogDetail( calls I don't see in python-matter-server logs, is there a way to turn that on?
for instance:
ChipLogDetail(CASESessionManager, "FindOrEstablishSession: PeerId = [%d:" ChipLogFormatX64 "]", peerId.GetFabricIndex(),
ChipLogValueX64(peerId.GetNodeId()));
is the first line in
void CASESessionManager::FindOrEstablishSessionHelper(const ScopedNodeId & peerId,
but I don't see it in the logs even with log_level=debug
Yeah there is a separate flag for SDK logs
--log-level-sdk progress should show them
Or rather, for that particular one --log-level-sdk detail is enough (there is error -> detail -> progress -> automation in SDK IIRC)
Did you mayeb loose server side certificates/credentials? Where were they stored? 🤔
@hollow bronze I converted your message into a file since it's above 15 lines :+1:
in that folder I see a credentials dir and a 17954926782082835028.json among other things
Do you use our wheels or did you build your own? We do carry a patch which makes sure that credentials are stored in /data instead /tmp ..
The ones I am worried are:
chip.json
chip_config.ini
chip_counters.ini
chip_factory.ini
chip.json being the most important one. I think that is where the operational certificates live etc.
those appear to be there. its using the wheels from chip-wheels (it was running the stock 6.0.1 image when this happened, just switched it to local build to debug)
Hm, yeah then it is kinda weird. Unless chip.json corrupted or something.
To me it seems like the server doesn't have the right certificates to communicate with the device.
hmm ok, will restart with the sdk detail to see more of whats going on
not really sure if any of these would be an issue, but I see that mdns discovery happens all interfaces and theres a key thats not found:
matter-server | 2024-06-03 21:30:43.175 (MainThread) INFO [matter_server.server.sdk.node_1] Attempting to establish CASE session... (attempt 2 of 2)
matter-server | 2024-06-03 21:30:43.176 (Dummy-2) CHIP_DETAIL [chip.native.CSM] FindOrEstablishSession: PeerId = [1:0000000000000001]
matter-server | 2024-06-03 21:30:43.176 (Dummy-2) CHIP_DETAIL [chip.native.CSM] FindOrEstablishSession: No existing OperationalSessionSetup instance found
matter-server | 2024-06-03 21:30:43.176 (Dummy-2) CHIP_DETAIL [chip.native.DIS] OperationalSessionSetup[1:0000000000000001]: State change 1 --> 2
matter-server | 2024-06-03 21:30:43.176 (Dummy-2) CHIP_DETAIL [chip.native.DIS] Warning: Attempt to mDNS broadcast failed on rndis0: src/inet/UDPEndPointImplSockets.cpp:416: OS Error 0x02000065: Network is unreachable
matter-server | 2024-06-03 21:30:43.177 (Dummy-2) CHIP_DETAIL [chip.native.DIS] Warning: Attempt to mDNS broadcast failed on usb0: src/inet/UDPEndPointImplSockets.cpp:416: OS Error 0x02000065: Network is unreachable
matter-server | 2024-06-03 21:30:43.177 (Dummy-2) CHIP_DETAIL [chip.native.DIS] Warning: Attempt to mDNS broadcast failed on br-d5c6b56b5314: src/inet/UDPEndPointImplSockets.cpp:416: OS Error 0x02000065: Network is unreachable
matter-server | 2024-06-03 21:30:43.177 (Dummy-2) CHIP_DETAIL [chip.native.DIS] Warning: Attempt to mDNS broadcast failed on br-018e80234074: src/inet/UDPEndPointImplSockets.cpp:416: OS Error 0x02000065: Network is unreachable
matter-server | 2024-06-03 21:30:43.178 (Dummy-2) CHIP_DETAIL [chip.native.DIS] mDNS broadcast had only partial success: 25 successes and 4 failures.
and then:
matter-server | 2024-06-03 21:28:35.539 (Dummy-2) CHIP_DETAIL [chip.native.CTL] StorageAdapter::GetKeyValue: Key = f/1/g, Value = 0xffff8fffdd20 (128)
matter-server | 2024-06-03 21:28:35.540 (Dummy-2) CHIP_DETAIL [chip.native.CTL] Key Found 23
matter-server |
matter-server | 2024-06-03 21:28:35.540 (Dummy-2) CHIP_DETAIL [chip.native.CTL] StorageAdapter::GetKeyValue: Key = f/1/k/0, Value = 0xffff8fffde68 (128)
matter-server | 2024-06-03 21:28:35.540 (Dummy-2) CHIP_DETAIL [chip.native.CTL] Key Found 97
matter-server |
matter-server | 2024-06-03 21:28:35.540 (Dummy-2) CHIP_DETAIL [chip.native.CTL] StorageAdapter::GetKeyValue: Key = f/1/s/0000000000000027, Value = 0xffff8fffdf58 (74)
matter-server | 2024-06-03 21:28:35.540 (Dummy-2) CHIP_DETAIL [chip.native.CTL] Key Not Found
matter-server |
Hm, that last one kinda sounded like it did not find the certificate for that node? 🤔
0000000000000027 looks like node id
was that node 39 (decimal?)
yeah well even stranger behavior, I just restarted it and now my node count shows as 0
39 is a node, yeah
yes very bizzare: so it appears after this most recent restart its deciding to load my persistent storage from a different json file.
before it was 17954926782082835028.json (from the mounted docker volume) and now it is /root/.matter_server/2605312944352314667.json
maybe the command: --log-level=debug --log-level-sdk=detail is overriding something in docker? lets see..
Ah
yeah we pass it a default data directory normally no?
How do you pass these commands?
well i didn't have a command line until I started debugging so it looks I was just using the defaults until I overrode the line
Default CMD sets storage path... So if you overwrite cmd, you have to pass that too.
Maybe we need to make those part of entrypoint 🤔
well
Technically you can choose a different path/volume for very specific needs 😅
I was using the devcontainer before
which automatically selects /data
as part of docker-entrypoint.sh
Kk, yeah let's see what debuggin shows with data path correctly set.
hm yeah thats promising, things appear to be coming online now
well not sure exactly what was the issue before, though I did recover 17954926782082835028.json from backup when I suspected corruption
thanks... I suppose I learned a lot about debugging CHIP and python-matter-server now, heh
Hm, yeah then kinda whole fabric falls appart. Which then kinda supports the CASE session setup issue as well.
No problem!
Hm, so I have an issue with the same window covering - its a "Yooksmart Matter Motor" which reports as a JLM window covering.
It seems like it doesn't properly update the OperationalStatus - so ha never sees the covering as 'opening' or 'closing'. It's a little weird because its a Matter device, shouldn't the certification process require that the OperationalStatus be updated properly?
Either way, it seems that it is easy to figure out 'opening' and 'closing' by detecting the difference between "TargetPositionLiftPercent100ths" and "CurrentPositionLiftPercent100ths". Current position doesn't seem to be updated until it reaches target --- so
closing = TargetPositionLiftPercent100ths > CurrentPositionLiftPercent100ths
opening = CurrentPositionLiftPercent100ths > TargetPositionLiftPercent100ths
But I wonder if such a per device hack is a good idea? Maybe have it be configurable?
We had this with homekit where allegedly certified devices would generate invalid JSON or not be able to parse valid JSON. One smart shade, they managed to put the hw rev in the serial number field. At the time we had been using that field as the unique id…
We took the line that if it works in iOS with the official Apple app we would make it work in HA, even if it was technically broken
There are devices where we tried to support broken interfaces and I regret it
Also console on Server side doesn't show updates for that property?
We can consider work arounds, ideally we make them device specific and such. Ideally we'd need some infrastructure to make this a bit generic and separated from the regular flow 🤔
Did you ask the manufacturer? Currently there are still chances to get this fixed as it's early days Matter and original firmware devs are still around/active etc...
Hm, I'll try reaching out to the manufacturer and see if they can do anything...
No, the console doesn't show anything and I've tried calling read attribute on the OperatingStatus attribute and its always 0 even while opening.
I suppose we could have a list of 'quirks' and this 'quirk' would be 'NO_OPERATIONAL_STATUS'... we could check the device name/model/manufacturer/firmware and apply the correct quirks when the entity is added
I know someone who worked at Apple for a while, when asked what team he said
HomeKit QA. Hard working, heavy drinkers. Mostly because they dealt with the random garbage IoT vendors would try to get certified
It tracks. Some of the bugs we have seen they’ve worked around.. I’d be a heavy drinker too.
Ah ok, so it is not only the reporting which is missing, it is really that they don't update the attribute. Sad times 😢
Yeah major bummer since I was hoping to have a button toggle the cover, but stop the cover if it was opening/closing already... Pretty useful status to have! (Fwiw my esphome tuya curtains don't report either, so I guess mfrs just don't feel it's important)
if anyone here is in the Alliance... you may want to check if that's actually a certification requirement and/or if there's a testing procedure for it
It is marked Provisional, so most likely it is not checked in certification.
Oh
Hm - is there a bug in the HA ping interface?
I have a device that fell off the network. Under device info there's no IP address.
When I press ping I see this in the log:
matter-server | 2024-06-07 02:44:22.193 (MainThread) INFO [matter_server.server.device_controller.node_52] Node could not be discovered on the network, returning cached IP's
In HA it says
"Ping device complete."
Which makes you think the ping succeeded somehow.
However, I assume the ping failed?
Unless, I guess the ping actually succeded and the isue is MDNS isn't popping up for this device?
I'm running log-level debug and I don't see this line:
node_logger.debug("Pinging address %s", clean_ip)
So i suspect if cached_ips = [], then it returns result which is empty?
Hm, yeah, that looks like a bug 🤔
Okay well after i take a look at the HA side of things I can submit a PR
I just checked, and yeah I can reproduce.
I wonder if it would be useful to have a "re-interview all devices" and a "ping all devices" function too..
But: We return a dictionary with IP addresses checked. And this happens to be empty. I think the interpretation of that is wrong on the UI side
UI should not claim "Ping device complete.", but "No address could be found to be pinged"
Or something.
yeah. I guess it probably only happens if you restart python-matter-server and the node disappears from mdns
otherwise theres a cached address
Yeah I think we cache forever essentially. So as soon as we have an address, we hold on to it.
But restart is not uncommon, and device being turned off is a use case. So I think this is worth fixing.
Is there any type of documentation and/or diagram explaining the Matter commissioning steps and the calls between the device, HA components (Matter Server, Companion app) and border routers (in case of Thread)? I am trying to get my head around the networking specifically.
The openthread site is your best bet for understanding the thread networking stuff
But the core of it is that your border router sends icmp6 messages that tell neighbours on the same subnet that it’s a router for your thread network. If you have multiple border routers, there are multiple routes. They are all active at the same time.
Icmp6 isn’t something that’s routed between subnets, which is why there is a no vlan requirement. And that means HA needs to be on the same subnet as all your border routers.
Your phone is used to get the thread device onto the thread network over Bluetooth. So target device has to be in Bluetooth range of your phone and thread range of your.. thread mesh. It uses apple and google sdks. And they do the matter onboarding too, so need to see the icmp6 messages too, so they can route traffic to thread. So your phone, HA and all border routers need to be on the same subnet.
Once a device is on the mesh, devices on your lan will see its ipv6 address in zeroconf, and connect to it just like it’s on wifi. Only the route information from icmp6 will mean the packets go to a random BR which will then do the thread bit.
AIUI behind the scenes what actually happens is your phone commissions the device on to a temporary fabric, and then shares it to HA. I think that’s to protect the static key from an untrusted controller?
Thanks a lot @opal linden , it is a bit more clear. I will also read the rest of docs of openthread website
Using the standalone matter docker image I was able to run a matter server. Through websockets, I was able to commission and control matter virtual devices(by google) running on my system.
But the issue is, I am not getting any proper response from the matter server, even though devices are getting commissioned, switching on/off. Any work around this.
Also check out our state of Matter stream. I made a technical deep dive part about commissioning, it should give you the basics of how we do Matter commissioning in HA:
https://youtu.be/rEugjMk-4II?t=7090
The Google Matter primer is a good resources for Matter commissioning in general:
https://developers.home.google.com/matter/primer
❤️ @solid mountain
Hello,
For my masters thesis, We've made a honeypot with a Matter over Thread and WiFi network using homeassistant. I would like to know if some people in here would be down to try and attack that network. We are not aware if a lot of attacks can be done remotely but if any of you have some expertise in the field to even help us try to attack it locally and could assist us in creating such attacks, that would be huge.
Thanks a lot
Hello
I would like to add attributes to the "EveCluster" cluster.
EveCluster Attributes for Eve Door:
TimesOpened: 319422470 (0x00130a0006)
Here's one attempt: https://github.com/home-assistant-libs/python-matter-server/pull/754/files
Looks fine - that is how we define custom clusters/attributes
I've restarted the "addon-matter-server" Docker container but that doesn't seem to have had any effect.
Is there anything else I can do that I've forgotten?
We need to rebuild the server before you can see that have effect
Oh, right. It all makes sense
So step 1 is the PR and then it will be in the next release
and once the lib version is bumped in HA, they can also be used in HA discovery schemas
we bump the lib every once in a while
next week I need to add a bunch of other custom attributes and clusters as well so if you finish the PR(s) now, it can go in one sweep
That would be perfect. Is this also for EveCluster/Eve attributes?
So all I have to do now is correct the formatting problems (lint).
yes
Is there a recommended VScode extension for this?
just use pre-commit
from within your workingdir/venv
pip install ".[test]"
and then pre-commit install
that will run pre-commit with every commit you do
and to run it manually once simply do "pre-commit run --all-files"
Thanks for the explanation. I'll make a note of it.
All the lights are green: https://github.com/home-assistant-libs/python-matter-server/pull/755
Do I need to modify another module to display this attribute in the WebUI?
No, like I said above you need to wait for the build process
Thanks
If you want to build it locally, install node + npm
I'll try that.
If you run dashboard/script/build you trigger a local build of the dashboard
after that is done, restart the server and it should work
this is the build script for the dashboard
https://github.com/home-assistant-libs/python-matter-server/blob/main/dashboard/script/build
h btw before building the dashboard you also need to build the definitions
so before building the dashboard, run python3 scripts/generate_descriptions.py
and after that run dashboard/script/build
Hi Guys, I am enjoying the new matter addon dashboard! Well done! Quick question. Can you help me understand the correct format of the json file that is used to import a node? I successfully connected a new matter Meross smart plug to my homeassistant instance and downloaded the device diagnostics. I thought I would be able to import this file into my test environment set up but I get an error "Failed to import test node 'int' object is not iterable". I am probably doing something really silly 😉 Where do I get the file that I can import? Many thanks Ivo
Yes the device diagnostics file is exactly the file that is needed - it should work.
what HA version ? what matter server version ?
@lapis hinge I converted your message into a file since it's above 15 lines :+1:
and python matter server version is: 6.1.2
Was is a device diagnostics dump or a dump of the netire integration ?
Can you share the dump with me ? (no worries, sensitive info is redacted in the file)
Hi, heres a gist containing my device diagnostics dump. I couldnt upload a file here on discord. https://gist.github.com/oidebrett/bc8adb22da7d535a85dda163870b6bfe
I had no problem importing your diag file.
Matter Server: 6.1.2
SDK Wheels Version: 2024.6.0
I had no problem importing your diag
Silicon Labs Matter Simplicity SDK Extension v2.3.0-1.3 https://github.com/SiliconLabs/matter_extension/releases/tag/v2.3.0
Features
This is the Silicon Labs Matter v2.3.0-1.3 release, which provides the functionality to build Matter applications in the Simplicity Studio environment. This release is intended for developers who wish to run a Matter Demo over Thread (15.4) or Wi-Fi, and also manually build examples through Simplicity Studio, SLC-CLI or Visual Studio Code.
This release is certifiable to the Connectivity Standards Alliance (CSA) Matter 1.3 certification program (https://csa-iot.org/) for Thread (MG24 / MG26) and Wi-Fi NCP platform (MG24/WF200).
Perhaps this will help to bring out new Matter 1.3 products.
It also introduces the Matter Zigbee CMP (concurrent multi-protocol) Lighting example application which demonstrates the usage of the Matter Stack alongside the Silicon Labs Zigbee stack.
It doesn't scare me at all 🙈 😅
For those of us eagerly awaiting the LIT ICD support, Silicon Labs has some updated info in their documentation 👍😊:
"Long Idle Time ICDs are ready for integration in the Matter 1.3 release. The core feature-set for ICDs has been implemented through the ICDManager. LIT ICDs should be certifiable with the Matter 1.4 release. Splitting the two milestones in different releases is to allow more in depth interoperability testing to validate the proposed feature-set achieves it's power consumption and usability goals."
Source: https://docs.silabs.com/matter/2.3.0/matter-overview-guides/matter-icd#long-idle-ic-ds
I think Eve already plans to already enable it in their 1.3 firmware updates. So we probably can even test it with real world devices.
On the controller side, the Python bindings also gained ICD support through this PR: https://github.com/project-chip/connectedhomeip/pull/33533
well, I got esphome working on thread on a esp32h2 board:
INFO Starting log output from fd79:2d04:874c:0001:dbc2:2929:7236:3eb6 using esphome API
INFO Successfully connected to esp32-h2-test @ fd79:2d04:874c:1:dbc2:2929:7236:3eb6 in 0.120s
INFO Successful handshake with esp32-h2-test @ fd79:2d04:874c:1:dbc2:2929:7236:3eb6 in 0.357s
[01:03:42][I][app:100]: ESPHome version 2024.6.1 compiled on Jun 21 2024, 01:00:35
[01:03:42][C][logger:185]: Logger:
[01:03:42][C][logger:186]: Level: DEBUG
not bad but its a real pain in the butt to try to figure out what the IP address of your device is, maybe if i can fix mdns it would be better
It would be great if you could share what was required for this in the esphome discord 🙂
oh sure! just cleaning up the custom component that I built and will push it soon
still working on that custom component, but on the topic of thread,
is there a way to add a node that reports offline by ip address?
I have a node (well several) that was previously commissioned by python-matter-server, for some reason they aren't advertising the matter address on mdns anymore
but I can still ping them on the thread network
there seems to be a fallback_node_scanner but I restarted the matter server and the cached addresses are lost
If they aren’t visible on mdns (even with a third party discovery tool on your phone) then it’s possibly a BR problem. AIUI there’s only one dns service at a time. And if that’s fallen over all matter addresses would be missing.
Apple border routers seem to have the new replication RFC implemented but it’s still a draft PR on the open source BR.
If you removed the HA fabric (e.g. in Apple/Google Home and remove the Nabu Casa/4939 service) then the device won't advertise for our fabric anymore. Technically, a device could be in a state that it is not commissioned to any fabric, but is on the Thread network. Not sure though how you can bring a typical consumer device into that state, I don't think you can remove the last fabric through Matter, and when doing a full device reset it should wipe the Thread credentials as well.
Yeah cached are only at runtime. I am not sure if that caching mechansim is all that helpful in practice. It could help bridge temporary mDNS name resolution problems, but if the device doesn't advertise at all, something is wrong anyway. 🤷♂️
Yeah, it might well be a problem with the BR; or the device I'm not sure so wanted to debug through it. It looks like if I kill all the BRs and turn them back on, only about 2/3 of the _matter._tcp nodes show back up and the only way I figured out how to get them back is the recommision the device, which is painful.
So was trying to debug if the devices lose their matter commissioning somehow, or if SRP (thread mdns) isn't working properly somehow
the cached ips are internal to python-matter-server right? it looks like they aren't passed on to chip but just used to check if a node is online?
anyone have an idea on how i could bridge mqtt messages into a matter device?
ive had this idea stuck in my head for a very long time
To try out the latest dev version of Matter, follow the Matter workshop instructions https://docs.google.com/document/d/1MldgA337wHTEx-vPkoxlCqKHrhVm5QIcHV32iLsv_2k/edit#
YouTube Stream: Matter in Home Assistant. Matter Workshop https://www.youtube.com/watch?v=9fOHBl5w0_k
If I can help with something, be free
Congratulations with the main entire demo, flawless!
Worked great for me too.
If you guys want to learn more about Matter I recommend this link:
https://blog.espressif.com/matter-38ccf1d60bcd
nice work!
Great demonstration
👍
Reporting from YouTube, how will Matter over Thread work with multiple controllers? Today, Nest sets up its own Thread network, an AppleTV or HomePod acting as a border router makes its own, etc. The commissioning key is never exposed.
Unlike wifi where you can tell the matter controller your wifi network's credentials.
Thanks for the great demo! Its a long time since i have been THIS excited about new tech
Thanks for the workshop, wasn't able to follow it due to technical limitations but I don't mind - my setup is weird (HA non-OS without supervisor running on a CentOS 7 NAS, esp32 devboards already in use for a CO2 meter, firefox only), but I have way more information to work on starting integrating my DIY sensors into HA using matter
Do you need to have IPv6 enabled on your network?
Its about fabrics, each controller has the device in its own fabric
I think you have because Matter will use IPv6
Yes and no. Your network gear needs to understand IPv6 and not block it or drop it, but that's it.
No need for IPv6 from your ISP, and no need for internal IPv6.
Google WiFi mesh has it enabled
Will Google WiFi be matter capable and compatible? I am sure the providers will make this information known
Also, flashing an esp32 from the browser was a demo I didn't expect to see. Really useful and user-friendly for workshops like that, but learning that Chrome and Edge provide that feature is freaking.-me.-out. security-wise. A nice find !
I meant -- I expect a particular Thread device to only have one radio and be on one thread network. So there needs to be coordination from the controllers to let all the border routers be on the same Thread network.
Today Nest and Apple devices implicitly make their own Thread network and the commissioning credentials are not exposed to users.
I imagine that will need to change and be more like Wifi -- I will pick a thread network name and credential and be able to configure border routers (or maybe "HomeKit" and "Google" and "Home Assistant" -- and all the border routers they control) with the same Thread network configuration so they can all talk.
I am sure that will change now due to Matter? They will push OTA firmware updates to these 'hubs'? Philips Hue and IKEA hubs, for example?
Indeed.
I just setup it up without IPv6 in the demo. My router isnt configured for IPv6 and my m5stamp and ha were on different subnets that have to pass through the router
So there is no need, jfroy told too that it wasn't required
My bad
I want to migrate from RPI4 to Yellow hardware. Hopefully a restore from backup of everything will work to being over everything I have setup so far to the new hardware? (When the hardware is available)
I am not a Matter expert, but I imagine it uses either link-local addresses (https://en.wikipedia.org/wiki/Link-local_address) or unique local addresses (https://en.wikipedia.org/wiki/Unique_local_address), neither of which require any configuration on any router or switch.
Just that L2 has functional IPv6 routing and that no firewall drops that traffic.
Thread networks definitely use ULAs
I thought so as well but as far as i can tell there isn't any ipv6 traffic passing through
In the fd00::/8 block.
My bad. I didn't have ipv6 blocked and as soon as i enabled the firewall rule the connection dropped and it stopped working.
When you enabled the firewall (meaning when you started blocking traffic?) it stopped working (which would make sense)?
A good resource to read also is that from google:
https://developers.home.google.com/matter/overview
Yes.
There you go 🙂
You also need mDNS to work. Matter is largely based on homekit and that heavily relies on DNS service discovery.
Yea I have a mdns fowarding sorta service setup on the firewall to allow the devices on the wired network and wireless to find each other.
It's not uncommon for APs to drop or mess with mDNS (looking at you Ubiquiti)
Looks like this matter server docker image really wants a host called "supervisor"
HA add-ons are docker containers managed by the supervisor container so that makes sense
deleting the env vars in /etc/s6-overlay/s6-rc.d/matter-server/run fixes that
🤔 So would that work inside Kubernetes? (Maybe requires a DinD setup?)
I agree. Devs matter!
I was definetly expecting "Nothing else matters" as the (pre-show)waiting music yesterday!
Great workshop! You guys mentioned that there will be around 20-25 device types initially supported. Do you maybe have a list of which ones those might be?
Any idea how Matter will work with certified and non/self-created devices and controllers?
is this a true dev channel... or can we ask a failed user question.... all geared up yesterday, only to find the installation failed notice, and resetting the device didnt work either, so lost from there..https://community.home-assistant.io/t/matter-in-home-assistant-workshop-announcement/426129/112
@bold basalt You need to install the drivers for the serial port
hi! you mean these? they are installed succesfully https://www.silabs.com/developers/usb-to-uart-bridge-vcp-drivers
made me wonder now if the usb cable transfers data...
btw, not explicitly mentioned in the instructions, but do we need to enable the device_tracker for bluetooth?
I dunno, I'm not a windows user, so no clue what you would need. Its documented in the UI. Looking at your screenshot, the serial port isn't showing up, so hence I assume you don't have the right drivers.
made me wonder now if the usb cable transfers data...
🤷♂️
but do we need to enable the device_tracker for bluetooth
? Not sure what it means even... but whatever it is, its no. Nothing in this stuff is related to device trackers at all
right, thx. its because Paulus explicitly metioned those cables, and yes that appears to have made the difference...! just found an ancient Nokia 8 micro usb, and that connects right away..
Hi!
Awesome presentation yesterday ! So hyped for the future of Matter & Home Assistant.
Quick question for the devs:
Multi-Admin seems like a cool feature to share a device across multiple vendor's ecosystems, but what about sharing control inside the same fabric ?
I understand how the commissioning procedure works for accessories, however I'm struggling to find out how one should go about commissioning an additional controller in an existing fabric. Do all controllers share the same special key with "controller" privileges ? Or can I commission an accessory, elevate its privileges, and have it act like a controller ?
Thanks in advance !
that's a good question!
I'm just going through the espressifdocs, it seems like it would fine, the 'controller' is just a cluster client.
i wasnt super eager to jump into it, but then i watched the livestream.
cool, made it to the end of the workshop after all 😉 What I do notice that when I disconnect the ESP32 dev kit (as in unplug it from the USB socket), I still see the Dimmable light as available, and can switch it in the device panel for it. That wouldnt be correct now would it? it is logged correctly btw: matter_server.client.exceptions.FailedCommand: Command failed: Chip Stack Error 50
We don't have a good "Liveness" detection right now. It's something on the todo list. Missing Matter Subscriptions should allow to detect when a device disappears quite easily and relibably.
Related to that problem is subscription resumption after a device disappears. The Stack tries to resubscribe to a device automatically, however, currently that fails because the encrypted session (called CASE session) is not valid anymore. Right now, it seems to require a work around on our end to invalidate the old session, so that a new session gets created. I am working on that work around currenlty.
Are there plans to also expose non Matter devices via a Matter bridge, so that for example Siri can see the "old" devices?
I tried getting it working with a HA container on my intelnuc using the built in bluetooth - doesn't look to be working unfortunately as it always says the bluetooth device is not ready
But the good news is I can connect it to wifi via the console and then commission it through HA and now I can control it
Working on bumping CHIP Stack version to 5d8599d195a93dfe5473f64e4f888c322e5df1d2 as this is used in a Pre-SVE (Specification Validation Event)
I use also a nuc but with a ub500 stick and its not commissioning either, but with no errors. any tips ?
Got it to work now , did updates on the integration and matter server. Nice work off the team!
I've added a new script that you can run on a dump of a node to see how it will be represented in Home Assistant https://github.com/home-assistant-libs/python-matter-server/runs/6945745918?check_suite_focus=true#step:8:1
It can also work directly on the storage file of the matter_experimental custom integration
Potentially dumb question - does the controller have to have Wi-Fi ? My HA instance is running on a Blue so wondering whether the add on will work for me or not. I did get a Bluetooth dongle for it
Hi, I want to know if there is a way to get the apk file of the chip-tool for android ready for installation or if there is a beginner's guide to get it from the source code. Thanks
No, the controller just needs network access and bluetooth. You'll need WiFi in your home of course if you want to commission one of the ESP32 devices in the workshop.
I've done the workshop on an Odroid n2+ and bluetooth dongle. 👍
@summer basin Android chip-tool instructions are here: https://github.com/project-chip/connectedhomeip/blob/master/docs/guides/android_building.md You have to build it from the command line first, then you can use Android Studio to work on the UI. I would fork the CHIP git tree and work inside the tree, don't copy it out of tree. CHIP is under continuous development and you need to be able to fetch updates every couple of days.
Hello. Thanks for the reply. my problem is the configuration of the java environment ..
@summer basin Install Android Studio and set up the environment variables as described. Android Studio includes the needed Java environment
Ok thanks
Thank you for your efforts! Will Home Assistant be a Matter Hub to be able to proxy all current HA devices to another Matter server (I.e Apple, Google, etc)
While technically possible, its not something we are aiming for right now. First priority is to be a Matter Controller ourselfs.
That’s cool for sure, but HA as a hub immediately gives Matter support to everything HA supports.
If matter supports the device type, yes
The Matter sample apps get now built by a GitHub Action. All our configuration customizations as well as patches are part of the repository now (https://github.com/NabuCasa/matter-example-apps), this allows us to bump to a new project-chip/connectedhomeip version easily.
Also bumpted the firmware to the same pre-SVE git hash 5d8599d.
Heya, i've poked about this on the discourse thread, but will an integration manager similar to the current HomeKit one launch? So that I may expose legacy products that i have on my HA to Matter, so any fabric can control it
ah i just saw this message, thanks
I'm planning to migrate my Home Assistant installation into Kubernetes and if I understood it correctly the Matter server needs to be on the same L2 network as any other Matter device. Will it be possible to let the Matter server run standalone (so that I can put it in the correct L2 net) and connect it securely to HA?
Add-ons (like matter server) are basically docker containers and those can also run in k8s too. I run a couple add-ons in kubernetes this way
I think that server does take advantage of hardware too like Bluetooth so that's interesting to consider also (the add-on server uses host network and dbus in the config.yaml)
in our ideal set up, the host wouldn't need bluetooth, as the phone apps will take care of that
but you would need a thread stick
It looks like the Matter server currently uses a plain WebSocket. I assume Home Assistant would support it if I put a reverse proxy for TLS in front of the matter server, right?
So do matter devices have to be on the same network segment or do you just need the ipv6 routing setup between the segments?
not sure about the matter integration but if you just pass the appropriate WS url (prefix wss) then it should just work
definitely works for zwave js and the matter server and integration is modeled off of it so I have to imagine it will work the same
Is there a plan for HA assistant to act as a matter bridge, so it can expose its entities/devices to Google assistant locally without cloud?
PR to merge device mapping and entity description https://github.com/home-assistant-libs/python-matter-server/pull/39
Will you be able to configure and change custom parameters/attributes of Matter devices through Home Assistant? With current devices you need to do that in manufacturer's proprietary apps (eg. setting delay timeout on a motion sensor). As I have read Matter enables adding custom attributes to devices but I don't know if this will work this way in the real world, but it would be great.
We do this for Zwave and zigbee so yes, eventually will come to HA too
I just merged support for bridge Devices like Hue and IKEA. We got a dump during plug fest but sadly are not allowed to share publicly. I have added a fake fixture if a bridge device instead
I also added tests that allow loading a matter dump and verify how it will look inside Home Assistant, make sure the correct entities are created
I would love some help to expand this so we have fixtures covering all devices.
For those who clone the Matter SDK for local development, by default the script/bootstrap.sh script clones all submodules. However, when executing the following script after cloning (instead of sourcing script/bootstrap.sh), it will only clone the necessary stuff for that platform (not with all the SDK for all the chip vendors out there). Then just use source scripts/activate.sh
scripts/checkout_submodules.py --shallow --platform linux
source scripts/activate.sh
I guess platform would be darwin for MacOS. Definitly useful for CI and such
This PR (https://github.com/project-chip/connectedhomeip/pull/19950) adds a sphinx based matter documentation, preview here https://gautesl.github.io/connectedhomeip/docs/index.html
it is much prettier and easier to read the docs
Hi, is there any way to use thread to link devices? I tried the app but when I try to link devices, the app close immediately
I mean with the android thread app
You can pair thread devices with our Matter integration
This is not a channel/server about the app
Thank you. I thank that the only way to add devices was with open thread addon and the android thread commissioning app.
The Matter folks created a SVE branch, that is meant to be used during the SVE events which are coming up https://github.com/project-chip/connectedhomeip/tree/sve.
[...] we’re adding a 9th test event this spring. That will be followed by our final gate, the Matter Specification Validation Event (SVE), now planned for summer. This validation event will be the Alliance’s most complex and largest ever, as we expect to see more than 130 devices representing 15 device and sensor types from more than 50 member companies. Unlike regular test events, SVEs produce formal compliance results and are crucial to certification of these first products, validating the final specification, and readying our test labs for the start of our formal certification program. Given this, we will devote the time and resources needed to do it right.
(from https://csa-iot.org/newsroom/matter-march-update/)
So this branch is meant to be used during this event. It is not the final Matter 1.0 branch. Today master and sve is the same, and since it will be the base of lots of testing I'll start bumping our add-on to that version as well.
Hey all! Finally got around to watching the Home Assistant Workshop. This looks amazing! I know that the first thing being worked on is the home assistant matter network, but any plans to also have a Matter Bridge as well?
hello , using c3 devkit m1 ,follow matter workshop, everything is ok.
problem: after press boot button on c3 esp32 board for light control testing, a moment later , cannot control c3’s led light in homeassistnst’s light entity at all. board’s uart logs repeat ‘chip[IN] data receiced on unknown session’. But the same time, using chiptool addon ui, command ‘chip-tool one-off toggle 2323 1 ‘ , working good. 🤣Thx!
Will the development boards flashed with the sdk samples be compatible throughout the matter ecosystem? Or will only finished products that have passed certification be compatible?
it will be compatible
but you might have to install an updated version of the example app
SVE branch was just tagged so no major breaking changes are expected, but slight incompatibilities can still happen
Hi, is esp32-dev-kitC compatible with esp-matter and home assistant?
Any of you happen to be at MCH2022?
we've only made available the test apps based on esp32 c3
Ok..thank you for reply...today i bought this https://www.ebay.it/itm/284729972100 and this one https://www.ebay.it/itm/224846294206
Is there any way to install matter or chip addons in home assistant supervised?
Hi, I'm following the tutorial here which was a workshop from a few weeks ago - https://www.youtube.com/watch?v=9fOHBl5w0_k
My HomeAssistant VM doesn't have Bluetooth, but I've got the Matter ESP32 to connect to Wi-Fi via the serial console. I can't pair it with any of the codes to HomeAssistant though... no methods seem to work, any ideas?
Do we know roughly when OT will implement thread 1.3? The public embargo seems to have lifted today, but I don't follow OT very closely.