I’m trying to connect Matter Devices to my Home Assistant but receive an Error.
I got to connect a the nRF SDK sample light_bulb running on nRF52840DK, but when I try to add another device via the Mobile App, then it says “An Error occurred” without further information.
In the Matter Server Log of my Home Assistant I can find this:
2024-01-08 08:34:09 core-matter-server matter_server.server.device_controller[126] INFO Starting Matter commissioning on network using Node ID 5.
2024-01-08 08:34:39 core-matter-server chip.CTL[126] ERROR Mdns discovery timed out
2024-01-08 08:34:39 core-matter-server matter_server.server.client_handler[126] ERROR [548351953232] Error handling message: CommandMessage(message_id='afe520bcea0e4fdc8fcc09c8a1dd984d', command='commission_on_network', args={'setup_pin_code': 6859429, 'ip_addr': None})
Traceback (most recent call last):
File "/usr/local/lib/python3.11/site-packages/matter_server/server/client_handler.py", line 188, in _run_handler
result = await result
^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/matter_server/server/device_controller.py", line 261, in commission_on_network
raise NodeCommissionFailed(
matter_server.common.errors.NodeCommissionFailed: Commission on network failed for node 5
I found out that I probably have to activate mDNS in my network configuration but all I can find is “Dynamic DNS”. I’m using a Fritz!Box 6850 LTE Router with SIM Card.
When mDNS needs to be enabled but isn’t, how was I able to connect the light_bulb in the first place? And what do I have to do to connect other devices?
Hi
I’m still looking for a solution. Did anyone cross a similar problem?
I contaced the nRF support thinking it may be a problem with the Sample-Software I was running(light_switch). This is the discussion: https://devzone.nordicsemi.com/f/nordic-q-a/107100/unable-to-connect-matter-light-switch-to-home-assistant.
I tried out different device types and they didn’t seem to have a problem connecting. Except the light_switch.
Might this be a problem with the functionality of the light_switch software? Using it, it is possible to turn on/turn off and even dim lights so no special function, which the Home Assistant doesn’t support.
Yes sorry. I’m pretty new to this topic.
It is Thread based. I’m using a Raspberry Pi as Thread Border Router as well as the Home Assistant. The Home Assistant App runs on my Android Smartphone.
I connected the light_bulb the same way I tried to connect the switch. By flashing the sample and scanning the Matter-QR-Code provided in the Boot-Log with the HA App. The device then showed in my device list and I was able to switch it on/off with the App.
Doing the exact same thing with the light_switch brought me the above error. The device connected with the BR but not with the HA.
I then found the Matter Example Apps example by Home Assistant and tried with this light_switch. This I got to connect and even show in the device list. But wasn’t able to operate it. My device information showed this:
It means “Not availabe” as if the switching attribute of the device isn’t working.
Let me see if I understand this correctly and correct anything that is not incorrect:
RPi running HA with OTBR AddOn using SkyConnect
“Light Bulb” is nRF52480 Development Kit/Board running sample light-bulb code which makes the board act as a Matter/Thread light bulb. You were able to commission this to HA OTBR and Matter using Android based HA Companion App, and you can control this light bulb using HA.
“Light Switch” is nRF52480DK board running sample light-switch code. You also used Android HA Companion App to commission it but this time the commissioning failed. ERROR Mdns discovery timed out… Commission on network failed for node 5
nRF52480 Development Kit/Board was used running NabuCasa’s " Light Switch App for ESP32-C3-DevKitM-1" example code which is for an ESP32-C3. It commissioned successfully with HA Matter but shows as unavailable.
#4 - The sample code is for an ESP32-C3 which is WiFi based as it doesn’t have a Thread radio. I’m surprised you got this to commission running this code on an nRF board…maybe I’m misunderstanding. If you really are using an ESP32-C3 then I would focus on it because if that’s not working, then you should post an issue with HA team about this.
#2 - shows an mDNS discovery timeout. If you were successful commissioning in #1 on a Thread network, but not #2 (same Thread network), then it means your network is not likely the issue concerning mDNS, because the commissioning process should be the same for both light-bulb and light-switch. From what I recall, BT is used initially to get the Matter device semi-connected to Thread, and the device registers with the TBR who in turn proxies an mDNS advertisement about the device for HA/Matter to see and HA/Matter in turn tries to connect to the device based on the info in the mDNS advertisement. If HA/Matter is not seeing this mDNS advertisement for light-switch, then my best guess is that there is something wrong with the light-switch software. Maybe try getting logs from the light_switch code running on the nRF board.
I’m using two separate RaspberryPis. One with the Home Assistant and the other with the OpenThread Border Router which uses a nRF52840 Dongle to make it Thread-capable.
#4 I am aware that it is a Wifi/Matter device. I wanted to try this thinking it might not work with the nRF sample and the Home Assistant. I used a ESP32-C3 device for this but it didn’t work. Sorry for not clarifying that.
#2 I read in another Thread (Another Matter, HA, Eve Window&Door Problem - I surrender - #6 by EmilS) that someone might have solved the mDNS problem by switching out their FritzBox. But I’m not sure if I got that right.
In my device log of the nRF Board there seems to be nothing wrong. This was stated by the Nordic Developers in their Forum-Thread.
Sadly I’m unable to post the log here, as it is too long. But I posted it in
OK, I don’t have any experience with this. Is the source code for this TBR directly from openthread.io? Reading this, I think the answer is yes.
Although I don’t have a FritzBox, I have seen a few other posts about it relative to Matter/Thread too. But since you were successful in commissioning the “light-bulb” through the RPi-OTBR, and mDNS was used in that case too, it tells me the network is passing the mDNS successfully.
If possible, do a tcpdump/wireshark capture of traffic leaving the RPI’s Ethernet when trying to commission the “light-switch” to see if it is actually sending mDNS/DNS-SD, and in particular either matter._udp or matterc._udp. If you don’t see any, then there is more likely a Thread setup problem, where the OTBR is not seeing the “light-switch” come up on the Thread network
Meanwhile I got a Google Nest, which also has a Thread Border Router included. Having the Home Assistant and the Google Nest in the same Network I can connect and operate Matter Devices (eg. Eve Energy) with my Home Assistant, without using my Raspberry Pi OTBR.
Trying to connect my nRF light switch device, the Matter Server Log of the Home Assistant shows this:
2024-01-30 10:57:22 core-matter-server matter_server.server.device_controller[126] INFO Starting Matter commissioning with code using Node ID 19 (attempt 0/3).
2024-01-30 10:57:28 core-matter-server chip.DIS[126] ERROR Timeout waiting for mDNS resolution.
2024-01-30 10:57:28 core-matter-server chip.DIS[126] ERROR Timeout waiting for mDNS resolution.
2024-01-30 10:57:32 core-matter-server matter_server.server.device_controller[126] INFO Matter commissioning of Node ID 19 successful.
2024-01-30 10:57:32 core-matter-server matter_server.server.device_controller[126] INFO Interviewing node: 19
2024-01-30 10:57:37 core-matter-server matter_server.server.device_controller.[node 19][126] INFO Setting up attributes and events subscription.
2024-01-30 10:57:39 core-matter-server matter_server.server.device_controller.[node 19][126] INFO Subscription succeeded
2024-01-30 10:57:39 core-matter-server matter_server.server.device_controller[126] INFO Commissioning of Node ID 19 completed.
2024-01-30 10:57:42 core-matter-server chip.DIS[126] ERROR OperationalSessionSetup[1:000000000000000A]: operational discovery failed: src/lib/address_resolve/AddressResolve_DefaultImpl.cpp:119: CHIP Error 0x00000032: Timeout
2024-01-30 10:57:42 core-matter-server chip.DIS[126] ERROR OperationalSessionSetup[1:0000000000000010]: operational discovery failed: src/lib/address_resolve/AddressResolve_DefaultImpl.cpp:119: CHIP Error 0x00000032: Timeout
It states that the commissioning of Node ID 19 was successfull. Sadly the device wasn’t added to my device list.
Additionally I found out that Google Nest doesn’t support switch functionalities (https://developers.home.google.com/matter/supported-devices?authuser=1#onoff_light_switches) but it is possible to commision them and the App even recognized it is a switch even though there is no possibility to implement a funtion of the device.
Home Assistant itself should be compatible with many types of switches as I read. So why does it not get transferred?
Hmmm…An OperationalSessionSetup is where the Matter server attempts to setup a secure communication path directly with the end device after it has been attached to a Thread network, so this would be using IPv6. I’m not sure about the AddressResolve error, but sort of a guess that the Matter server got a mDNS/SD message with a name of the device along with its IPv6 address, but somehow couldn’t connect to the device. Again, no idea why its the case here, if you were able to commission other thread devices via google Home to HA
Oh wow, that was not what I was expecting of this “light-switch”. This seems to be about “binding” a device (the light-switch) to control another device directly. AFAIK Binding is not supported yet in HA, but not sure if that is an OTBR limit, or something else. So its not a typical light switch which I thought would merely activates/deactivates an electrical relay…
Actually I am just trying to include a normal light_switch. Are there different types?
Is there another way of controlling a device via this switch without “binding” it?
The ESP32 Nabu Casa Matter switch should be compatible with the Home Assistant right? Because I’m having lots of trouble connecting it and getting it to work.
Sometimes I’m able to connect the ESP32 to my Home Assistant getting this:
A few times I wasn’t even able to connect it without an Error
As you said before, would it be a good idea of opening an issue?
I have been successful in commissioning the “Lighting App” for the ESP32-C3 and the only trouble I ran into was that the Companion App on the mobile phone is the one that provides the WiFi credentials to the ESP32-C3 and if the phone is on a 5G WiFi band, it tries to use that band but the ESP32 only supports 2.4G. So I finally figured that out and reconnected the mobile phone to 2.4G and then the commissioning worked.
I’ll be honest and say I don’t really know much about this “Light-Switch”. The terminology that I’m use to seeing calls a light switch an “End Device” that has a mechanical relay for completing a wiring circuit to an actual light, and this only operates in the ON or OFF state, and in this case a controller is used to communicate with this end device to tell it to turn ON (close the relay) or OFF (open the relay).
So this “Light-Switch” app is something I’m not familiar with and I’ll need to look into more.
I also tested the Lightning App and this worked perfectly for me.
I’m more focused on the Light-Switch but I get that this is a topic still in development.
Anyways, I will be looking into it more, but if you stumble over any new information I’d be happy if you shared it with me.
Thanks for your help!
So I downloaded the Light-Switch App onto my ESP32-C3 and added it to HA Matter successfully, and the device shows up as “unknown” same as what you show above. This may not be ideal, but operationally, I think this is OK. I also have an ESP32-H2 that I use for the Lighting-App device.
Within the ESP32-C3 there is a CLI that allows you to enter Matter commands directly, and some of these are “bind” commands. I seem to have gotten this to work, but whenever the C3 sends an On/Off command to the Lighting App, the Lighting App throws a log message denying the request.
According to this doc, one needs to add a couple of ACLs to the Light App device so that it will accept commands from the Light-Switch. This is where I ran into a roadblock. The doc uses “chip-tool” for sending these ACLs. I don’t have chip-tool, however I was able to write a simple Python program which would call the Matter Server’s websocket API to write the ACL as an attribute. The Matter Server however in trying to parse through this websocket data is throwing errors, and the developer on the Matter Server thinks its a bug.
So anyway, that’s as far as I have been able to take things.
UPDATE…
The devs fixed the parsing bug last week in the Matter Server, and this past weekend I was successful in sending the necessary ACLs to the Lighting-App using the Matter Server websocket APIs. By doing this, the Lighting-App will now accept commands directly from the Light-Switch. So now I can get the Light-Switch (ESP32-C3) to toggle the light ON/OFF on the Lighting-App (ESP32-H2) .
Just as a side note: I mostly use the Light-Switch’s CLI: matter switch onoff to send the “turn light on” or “turn light off” request to the Lighting App. One is suppose to be able to tap the “boot” button on the ESP32-C3 (Light-Switch) to get it to send a toggle to the Lighting App. The “boot” button does work, but it is not being debounced, so a single tap may result in 3 or 4 rapid-fire toggle commands being sent which doesn’t always end up toggling the light visually.
What I haven’t tried to do yet, is send a binding command to the Light-Switch remotely. The doc again uses the chip-tool to do this, but I’m thinking there may be a way to use the Matter Server websocket to do this, but at this point I haven’t investigated enough to know.
UPDATE…
I managed to figure out how to set a binding on the Light-Switch App using the Matter Server websocket API, so no longer need the Light-Switch’s CLI to do this.
Could you detail how to achieve a bind? I have been wondering on how to achieve that (I want to make certain fan controllers and fan remotes with Matter) and the theory says that it should work but I have been unable to find how.
A standalone post with your experience would be much appreciated, if it is not too much of a burden. Please and thank you!
I can for now provide a fairly detailed overview…(I can come back later and re-edit this post with even more levels of details if you’re still interested).
The solution uses the HA Matter Server Websocket API, so one has to know how to use it. Some use a browser’s console and from it they run javascript code, others use Python code. I’ll show a Python example later.
It will also be good to have the Matter Spec for the Cluster Library.
Have both the switch/remote device and the target device being controlled commissioned on the same HA Matter Fabric.
Determine the node ids of the switch/remote device and the target device being controlled. One way is to use the UI’s Diagnostics for that particular device and look for node_id.
Determine what the fabric_index is for the device’s use with the HA Matter Fabric. It is not necessarily the same as the “fabric_id” one finds in the diagnostics. I’ve not found a good way to determine this, so it may be through trial and error. The fabric index starts with 1 the first time a device is commissioned, and increments by one for each additional fabric the device is commissioned with. If you commissioned the device only using the HA Matter websocket, then it should be 1. If you used the HA Companion App to commission a device, it is likely to be 2 as the App commissions the device to the App itself and then commissions a device to HA Matter.
For the device being controlled (in my case the Lighting App):
a) Get the current ACL(s) in use. Use the websocket API for read_attribute and specify the “attribute path” (EndPoint/Cluster/AttributeID) for the ACL which is 0/31/0. You can also find the current ACL in the diagnostic file downloaded from above by also looking for 0/31/0.
b) Add an ACL to the existing ones which will give permission to receive commands from the switch/remote device.
Use the websocket API for write_attribute and write a list of ACLs which includes the ones just read along with the new one that will give the permissions to receive from the switch/remote device. The format for the write is a little different from the read, so some mappings have to be done. The “fabric_index” is also key. The reading of the ACLs will include a “key” of 254 which corresponds to the fabric index, but there may be multiple “values” (1,2,etc.) in the list. When writing the list back, only use the list of ACLs for the fabric index corresponding to HA Matter fabric.
For the Switch/Remote device:
a) read the current binding. Use the websocket API for read_attribute and specify the “attribute path” for 1/30/0. For the Light Switch App, 30 is the Cluster-Id for Binding, and it resides on Endpoint=1, and the attribute-id=0 which contains the list of target devices/groups to bind with. Most likely this reading will show an empty list since no bindings have yet to be performed.
b) Write the Binding(s) to the switch/remote device. Use the websocket api for write_attribute and write a list of Bindings which includes the ones just read along with the new one that will tell the switch/remote device what the target device is. The format for the write is a little different from the read, so some mappings have to be done.
For the target device (in my case the Lighting App), the target’s node-id has to be specified, along with the endpoint and cluster-id the switch/remote cluster client will use to request to the target device’s cluster server, and for “light on/off” its endpoint=1, cluster-id=6. The fabric index also has to be specified, so use the one associated with the HA Matter Fabric.
At this point, one should be able to use the switch/remote device
Fantastic overview! I hope that this can become something that can be done from Home Assistant more easily, (you know, to raise the WAF and make life easier). But for now, the first read has make me understand a lot of misconceptions I had regarding how the binding was set up
.