#when adding a new Matter device is it
1 messages ยท Page 1 of 1 (latest)
I hope/assume you are NOT using the Unifi mDNS reflector ? HA, the thread border router(s) on the same (v)LAN ?
Nanoleaf Essential Bulbs are being reported as flaky a lot of times with Matter. Their own app uses a custom protocol and seems to be working fine (and even can fallback to bluetooth) but A Nanoleaf Essentials Matter light in Matter mode is being reported as unstable.
No, not using the Unifi mDNS reflector (though I am having mDNS issues, I know that for sure, as my ESPHome devices are all reporting offline (I know I can change it to report by ping). Yes, HA is in the same VLAN (in the IoT space in my case).
OK cool, that is step 1
The Homekit Nanoleaf bulbs I do have are working, but the logs are getting ever more increasing with self-destruct/decryption/invalid request errors. The automations work for the most part (times out from time to time)
and the Matter bulb I did end up adding yesterday worked once mDNS got its act together
at present, I have mDNS duty pushed off to an RPI4 running the multicast-relay docker
which works for my Chromecast and Sonos devices
I actually gave up on Unifi myself after seeing too many strange issues, most important mdns/multicast issues. As I'm working with Matter on a daily base that had become an absolute frustration for me.
The most stable situation I had with Unifi was disabling all their "optimization" stuff. So disable multicast enhancements.
Yep, 100% agree that Unifi's MDNS implementation is a hot pile of garbage
OK so you DO have an mdns reflector active in your network ?
Take that down to get thread and matter working reliable
What are you planning to use as Thread Border router ?
reflector, no (RPI has avahi-daemon by default has a reflector, but that is commented out by default and I haven't touched it). only the relay (which was implemented on my UDM Pro via Podman until Ubiquiti trashed any podman deployments in UbiOS v3).
Thread Border router is going to be the Skyconnect, using OTBR to my knowledge.
for context on said relay: https://hub.docker.com/r/scyto/multicast-relay
that wont work either
how so?
I understand that, and tcpdumps I have done can see ff02::1 traffic
flatten the network or put all IoT gear including HA on the same vLAN
It has been tested by many before and it will not work
HA is already in the same VLAN as the IOT gear
OK so that is great then. In that case temporary disable your mdns relayer
and see if it works
if it does, that poses a bigger problem for me but sure, just a moment.
also make sure to have your phone on tyhat same network while commissioning
the original commissioning was done by websocket
Well, our documentation is very clear that your network should be flat. This is a protocol meant for residential use, not for enterprise networking setups
OK, so you are doing it all manually ? In that case a lot more is involved, starting with the thread dataset
from your perspective, does avahi-daemon qualify as a relay?
Best to just use our apps for now
anything that translates mdns between different (v)LANS is a NO GO
manually = copy/paste 2 blocks of code, but yes.
Yes, but is more error prone hence its not the recommended route for now, only if you know what you are doing. This is all not yet finished.
I understand that. Unfortunately when I went to provision by app, Google Home refused to accept the Matter code on the side of the Nanoleaf bulb, which is why I went via websocket.
avahi-daemon is now disabled
no mdns relay/reflectors in place
in disabling avahi, homeassistant.local has now stopped functioning also
OK cool, so that makes the test setup a bit easier
works by IP only
which to my knowledge suggests mDNS is broken across the board
but I'll reboot HA and the RPI and see if it makes a difference.
OK, I assume you are running HAOS ? Or are you running HA yourself ? In that case even a lot more possible causes.
OK, there is also a small possibility that there is something wrong in the network stack of Unraid.
I don't believe so, based on the IPv6 route prints I've done and by scouring many forum posts (Jc2ks has been quite helpful). Both Unraid and HA can see most of the same v6 routes, and tcpdump on the same bridge interface for the VM can see the v6 multicast traffic
My understanding from a lot of trial and error is that is 90% of the requirements
the bulbs (when they are discoverable), the ULA addresses are pingable
but those addresses are only available when mDNS works
which as of right now, does not:
2023-10-11 00:55:32 core-matter-server matter_server.server.device_controller[126] DEBUG Attempting to resolve node 26... 2023-10-11 00:55:32 core-matter-server chip.CSM[126] DEBUG FindOrEstablishSession: PeerId = [1:000000000000001A] 2023-10-11 00:55:32 core-matter-server chip.CSM[126] DEBUG FindOrEstablishSession: No existing OperationalSessionSetup instance found 2023-10-11 00:55:32 core-matter-server chip.DIS[126] DEBUG OperationalSessionSetup[1:000000000000001A]: State change 1 --> 2 2023-10-11 00:55:32 core-matter-server chip.DIS[126] INFO Checking node lookup status after 200 ms 2023-10-11 00:56:03 core-matter-server chip.DIS[126] ERROR Timeout waiting for mDNS resolution. 2023-10-11 00:56:17 core-matter-server chip.DIS[126] INFO Checking node lookup status after 45000 ms 2023-10-11 00:56:17 core-matter-server chip.DIS[126] ERROR OperationalSessionSetup[1:000000000000001A]: operational discovery failed: src/lib/address_resolve/AddressResolve_DefaultImpl.cpp:114: CHIP Error 0x00000032: Timeout
I will try and add a brand new Matter bulb via HA (Devices > Add Matter Device) and see how I go.
Yes, you need to be using the HA Companion app as that will use the bluetooth from the phone to do the initiual commissiong of credentials
If you go the websocket route, you will also need a bluetooth adapter and that can interfere with the bluetooth intergration as it needs exclusive access
In short: You should not be using the websocket commands yourself, its not ready for prime time yet
the log files suggest otherwise as it attempts the commissioning via BLE as well as DNS-SD (or, mDNS). I have a bluetooth adapter in the server, but the websocket commissioning does not attempt to leverage it, and goes straight for DNS-SD. This was how the first Matter device appeared under the Matter (BETA) integration.
To be clear, I'm not challenging what you're saying (yes it's not ready for prime time)
more providing feedback on what I've attempted, as I've been at this for a while
Yeah that log is very confusing and the commissioning process is a bit dumb. If its a new device the device CAN NOT be reached over mdns yet, it first needs the bluetooth commissioning to even be on the network
Or did you already add it somehow ?
nope, brand new out of box
So, step 1 is using the android HA Companion app
yep
I'll try commissioning a new device now
not hopeful given everything mDNS is completely broken, but we'll see ๐คทโโ๏ธ
back shortly.
commissioning failed at 'check network connectivity'. phone was on the same IoT VLAN as HA and everything else IoT.
rebooting phone and trying again to see if that makes a difference
same issue
I would expect the Matter addon in HA to generate some kind of logs from a HA onboarding, but I haven't received anything
Nah, the matter add-on will only start generating logs as soon as the first step completed
so the commissioning itsel fis failing completely
stupid question maybe but the device is in pairing mode ?
It was (pairing mode I think only lasts 3 (?) minutes) so I did a complete reset (on/off 5 times, flash red 3 times) as well as unseat and reseat the bulb from the socket.
and that in itself doesn't help with any form of troubleshooting. makes it look like guess work from the apps perspective
Yeah, Like I said, this is not yet finished. You are trying to do something that is not yet fully developed and you're staring at a first MVP which still needs a lot of work.
Atm the stable solutions are based on existing Apple and Google border routers
so, after about a dozen attempts at onboarding via the HA app, every single time failed at network connectivity
however, websocket onboarding worked first time.
๐คทโโ๏ธ call it what you will, but if it works it works.
in that case your phone was unable to contact the device
some fitering going on perhaps ?
like client isolation
how would that be possible when network connectivity is last in the onboarding process
Yes, but be aware to not use the bluetooth integration
BLE timed out immediately, as I mentioned earlier.
the matter code was input, it identified as a Nanoleaf bulb, generated matter credentials, then checked network connectivity
there's no network isolation
- commission thread (or wifi) creds over bluetooth
- connect to the device on the new network
- commission the device to a temporary fabric on the phone itself
- share the device from the phone to HA fabric
no network filtering
strange... it screams that there is some sort of network issue going on
which might bite you later in the HA matter server as well
in 99% of the cases where we support issues, its mdns resolve issues
I have even seen cases where the router could mess things up
I've done what you've suggested, so if there's a network issue, your guess is as good as mine.
magic mystery
indeed
there is an interesting twist however
I did onboard the bulbs to the Nanoleaf app first, as all of the Matter lights needed a 'critical' firmware update (HA can't update the FW).
the app is seeing the home-assistant OTBR with a different dataset and network key than what home-assistant actually has set in HA.
the dataset used to provision came out of the Android Nanoleaf app, rather than HA.
huh that is interesting indeed
so you can actually see the network key in the NL app ?
after a successful commission, yes
The HA Companion app actually syncs the credentials to/from Android
well it didn't in this case
so I'm now guessing that is where things go wrong
not so far
There should be a button somewhere in the app to force sync it
yep, I did
and it highlights the HA BR
even ID's it's using the Skyconnect Silicon Multiprotocol addon
but the key and dataset are not the same
(if I could screenshot in this chat, I would).
I do not have a working android device at hand now but I'm pretty sure there is a hidden setting somwhere in the companion app to force the creds sync
Application Credentials?
So what possible could be happening is that the HA Companion app (which is utilizing the android framework for commissioning) is sending the wrong credentials
there's no dropdown for anything Matter or Thread in that section.
Possible... I'm on IOS myself and been a while since I tested the Android app. I have a test device here but its battery is empty ๐
Anyways, great discovery!
would I be able to DM you what I can see? I'd hate to be called a liar ๐
hahaha, yeah go ahead
before I do, here's the method of what worked via websocket, for your own reference/testing (use it, don't use it, doesn't bother me).
ah yes, I'm aware, I wrote it ๐
lol, and you say it wouldn't work? ๐คฃ
hahaha, call it setting expectations ๐
they need to be a little bit higher mate, lol
We hide that command on purpose atm as the UI is not yet finished and it clashes with the Bluetooth integration
so you are currently using some undocumented cutting edge stuff ๐
F12 -> Developer Tools in browser (I used Brave, but Chromium anything should work too):
socket.addEventListener("message", (event) => {
console.log("Message from server ", event.data);
});
socket.addEventListener("open", (event) => {
console.log("WebSocket is open");
var message = {
"message_id": "1",
"command": "set_thread_dataset",
"args": {
"dataset": "<dataset from Android Nanoleaf App>"
}
};
socket.send(JSON.stringify(message));
});```
then:
socket.addEventListener("message", (event) => {
console.log("Message from server ", event.data);
});
socket.addEventListener("open", (event) => {
console.log("WebSocket is open");
var message = {
"message_id": "2",
"command": "commission_with_code",
"args": {
"code": "<11 digit Matter code on Nanoleaf light>"
}
};
socket.send(JSON.stringify(message));
});```
Ah so you are setting the dataset that is visible in the Nanoleaf app
OK, thanks for the info. Now I go wondering why we have the wrong creds ๐
have DM'd you the successful response once commissioned
way too long of a message to copy/paste
but yeah, as soon as the websocket commission task is started
BLE provisioning is attempted, then surpressed about 3 seconds later
2023-10-11 02:31:39 core-matter-server chip.BLE[126] ERROR BLE scan error: src/platform/Linux/bluez/ChipDeviceScanner.cpp:154: CHIP Error 0x00000032: Timeout
then it runs with DNS-SD
so BLE isn't really a factor
ok, something else I've just found out; added a second Matter device successfully, but there is a process to follow.
The bulb must be adopted by the Android Nanoleaf app first AND updated to the latest firmware. Once updated, you then need to migrate it from BLE to the Thread network you have setup already on the Nanoleaf app (the Thread Network option will be Green and offer to move them across to Thread.
once moved, it'll show successful.
Then from the Websocket, you punch in those two codes above, adjust accordingly, and it shows in HA every time
(at the websocket part, it's possible the HA app may be able to intervene here)
sent you a screenshot DM of what I mean by the 'green' part in the Android app
I'll do more testing with a third light I have later on, but it's 3:30ish AM here, so I'm off.
thanks for your help ๐
Wrt stale route: Are you using Supervised? There are some infos in the python matter server repo
HAOS VM, not just supervised.
OK, so FWIW at the point where I did the websocket part, I can attempt to commission the device via the Android HA App and once it's verified network connectivity, it then shows 'connecting to Home Assistant'. The Matter Server logs show (in this example) an interview failure, but this at least proves that once it has gone through all the initial setups and verifies network connectivity, once it shows HA the Matter Server log files can see some traffic (this was not occurring before).
error in question:
2023-10-11 15:27:04 core-matter-server matter_server.server.helpers.paa_certificates[125] INFO Fetched 0 PAA root certificates from DCL.
2023-10-11 15:27:04 core-matter-server matter_server.server.helpers.paa_certificates[125] INFO Fetching the latest PAA root certificates from Git.
2023-10-11 15:27:04 core-matter-server matter_server.server.helpers.paa_certificates[125] INFO Fetched 0 PAA root certificates from Git.
2023-10-11 15:27:13 core-matter-server chip.EM[125] ERROR OnMessageReceived failed, err = src/messaging/ExchangeMgr.cpp:304: CHIP Error 0x00000070: Unsolicited msg with originator bit clear
2023-10-11 15:27:21 core-matter-server PersistentStorage[125] INFO SetSdkKey: f/1/s/0000000000000009 = b'\x150\x03\x10\x1a=\xbf\xc8\x90\x0b\xeb\x88D7\x00\xa2rn(\xb00\x04 \xbf\x08NDx\x178\xa9\x94\xe9\xadu\x1e(\x96%R\xf50a;l[D\xae\xc4\xe5\x97\xdf\xd9\x900\x05\x0c\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x18'
2023-10-11 15:27:21 core-matter-server PersistentStorage[125] INFO Committing...
2023-10-11 15:27:21 core-matter-server PersistentStorage[125] INFO SetSdkKey: g/s/Gj2/yJAL64hENwCicm4osA== = b'\x15$\x01\x01$\x02\t\x18'
2023-10-11 15:27:21 core-matter-server PersistentStorage[125] INFO Committing...
2023-10-11 15:27:21 core-matter-server PersistentStorage[125] INFO SetSdkKey: g/sri = b'\x16\x15$\x01\x01$\x02\x02\x18\x15$\x01\x01$\x02\x07\x18\x15$\x01\x01$\x02\x08\x18\x15$\x01\x01$\x02\t\x18\x18'
2023-10-11 15:27:21 core-matter-server PersistentStorage[125] INFO Committing...
2023-10-11 15:27:36 core-matter-server chip.DMG[125] ERROR Time out! failed to receive report data from Exchange: 48850i
2023-10-11 15:27:36 core-matter-server matter_server.server.client_handler[125] ERROR [140520234729552] Error handling message: CommandMessage(message_id='8f2c687da71e4992b8bd9bbcd74b90bf', command='commission_on_network', args={'setup_pin_code': 92664274})
Traceback (most recent call last):
File "/usr/local/lib/python3.11/site-packages/matter_server/server/device_controller.py", line 307, in interview_node
await self.chip_controller.Read(
File "/usr/local/lib/python3.11/site-packages/chip/ChipDeviceCtrl.py", line 1025, in Read
return await future
^^^^^^^^^^^^
chip.exceptions.ChipStackError: Chip Stack Error 50
The above exception was the direct cause of the following exception:
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 221, in commission_on_network
await self.interview_node(node_id)
File "/usr/local/lib/python3.11/site-packages/matter_server/server/device_controller.py", line 314, in interview_node
raise NodeInterviewFailed(f"Failed to interview node {node_id}") from err
matter_server.common.errors.NodeInterviewFailed: Failed to interview node 9```
I have seen the error before, but during websocket provisioning. it's possible it might be because I have the websocket port still open in browser and the phone can't interact, but I'll do some more testing.
making progress though ๐
ok, made more progress though now getting some weird behaviour with the matter credential exchange.
managed to get the HA app to see the bulb, generate matter creds, point the device to home assistant and have it come up as successful.
it then offers a prompt to add as a Matter device
after 2-3 minutes, it fails and prompts a retry.
the logs show the credential handshake has added a completely different Matter code to what is on the light
whereas commissioning via websocket, the code remains the same as what I enter
I'm under the impression that should not be expected behaviour?
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 171, in commission_with_code
raise NodeCommissionFailed(
matter_server.common.errors.NodeCommissionFailed: Commission with code failed for node 11```
for reference, 31847024200 is not the Matter code on the light
Is the light close enough to the SkyConnect ? The radio range of the SkyConnect dongle is a bit limited (for Thread at least) and many factors can make it worsem such as interference from another source like USB3 port etc. Did you use an extension cable ?
I have seen situations like this before where the commissioning (finally) succeeded but then the interview takes forever of fails where in that cases it was just a weak signal
they're not that close, no. I was under the impression the commission would leverage other Thread devices nearby to extend the range? (that's how I've interpreted most of the support documentation on Thread, and specifically Nanoleaf bulbs).
Yes, that is how it should work in theory but if the mesh is already unstable it would enhance the instability if you get what I mean
Sure, ok