#when adding a new Matter device is it

1 messages ยท Page 1 of 1 (latest)

sonic coral
#

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.

cunning forum
#

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).

sonic coral
#

OK cool, that is step 1

cunning forum
#

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

sonic coral
#

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.

cunning forum
#

Yep, 100% agree that Unifi's MDNS implementation is a hot pile of garbage

sonic coral
#

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 ?

cunning forum
#

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.

sonic coral
#

that wont work either

cunning forum
#

how so?

sonic coral
#

you CAN NOT route the traffic

#

its ipv6 multicast traffic

cunning forum
#

I understand that, and tcpdumps I have done can see ff02::1 traffic

sonic coral
#

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

cunning forum
#

HA is already in the same VLAN as the IOT gear

sonic coral
#

OK so that is great then. In that case temporary disable your mdns relayer

#

and see if it works

cunning forum
#

if it does, that poses a bigger problem for me but sure, just a moment.

sonic coral
#

also make sure to have your phone on tyhat same network while commissioning

cunning forum
#

the original commissioning was done by websocket

sonic coral
sonic coral
cunning forum
#

from your perspective, does avahi-daemon qualify as a relay?

sonic coral
#

Best to just use our apps for now

sonic coral
cunning forum
sonic coral
cunning forum
#

avahi-daemon is now disabled

#

no mdns relay/reflectors in place

#

in disabling avahi, homeassistant.local has now stopped functioning also

sonic coral
cunning forum
#

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.

sonic coral
#

OK, I assume you are running HAOS ? Or are you running HA yourself ? In that case even a lot more possible causes.

cunning forum
#

HAOS via VM on an Unraid host

#

The VM is on the same VLAN as the IoT gear I have

sonic coral
#

OK, there is also a small possibility that there is something wrong in the network stack of Unraid.

cunning forum
#

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.

sonic coral
#

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

cunning forum
#

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

sonic coral
#

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 ?

cunning forum
#

nope, brand new out of box

sonic coral
#

So, step 1 is using the android HA Companion app

cunning forum
#

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

sonic coral
#

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 ?

cunning forum
#

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.

cunning forum
sonic coral
#

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

cunning forum
#

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.

sonic coral
#

in that case your phone was unable to contact the device

#

some fitering going on perhaps ?

#

like client isolation

cunning forum
#

how would that be possible when network connectivity is last in the onboarding process

sonic coral
cunning forum
#

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

sonic coral
cunning forum
#

no network filtering

sonic coral
#

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

cunning forum
sonic coral
#

magic mystery

cunning forum
#

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.

sonic coral
#

huh that is interesting indeed

#

so you can actually see the network key in the NL app ?

cunning forum
#

after a successful commission, yes

sonic coral
#

The HA Companion app actually syncs the credentials to/from Android

cunning forum
#

well it didn't in this case

sonic coral
#

so I'm now guessing that is where things go wrong

cunning forum
#

not so far

sonic coral
#

There should be a button somewhere in the app to force sync it

cunning forum
#

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).

sonic coral
#

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

cunning forum
#

Application Credentials?

sonic coral
#

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

cunning forum
#

there's no dropdown for anything Matter or Thread in that section.

sonic coral
#

Anyways, great discovery!

cunning forum
#

would I be able to DM you what I can see? I'd hate to be called a liar ๐Ÿ™ƒ

sonic coral
#

hahaha, yeah go ahead

cunning forum
#

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).

sonic coral
#

ah yes, I'm aware, I wrote it ๐Ÿ˜‰

cunning forum
#

lol, and you say it wouldn't work? ๐Ÿคฃ

sonic coral
#

hahaha, call it setting expectations ๐Ÿ˜‚

cunning forum
#

they need to be a little bit higher mate, lol

sonic coral
#

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 ๐Ÿ™‚

cunning forum
#

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));
});```
sonic coral
#

Ah so you are setting the dataset that is visible in the Nanoleaf app

cunning forum
#

correct

#

like I mentioned before ๐Ÿ™ƒ

sonic coral
#

OK, thanks for the info. Now I go wondering why we have the wrong creds ๐Ÿ™‚

cunning forum
#

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

cunning forum
#

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 ๐Ÿ™‚

outer forum
#

Wrt stale route: Are you using Supervised? There are some infos in the python matter server repo

cunning forum
cunning forum
#

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 ๐Ÿ‘

cunning forum
#

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
sonic coral
#

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

cunning forum
#

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).

sonic coral
#

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

cunning forum
#

Sure, ok