#I had the issues you descibed yesterday

1 messages · Page 1 of 1 (latest)

silk mica
#

I have an eve motion that went unavailable this morning actually - I've only had the yellow joined with the network since sometime earlier this week

#

I think for me to test this better though i need to setup a separate matter server. The one I have now has all my devices paired to it

#

is it possible to enable debug logs on the matter server in HAOS?

sinful sinew
silk mica
#

i guess it might just be a network issue on my system - i paired it to a new matter server running in HAOS and it worked

#

didn't change anything else about the network - yellows still paired

#

oh, wait - it's running Add-on version: 5.0.2 even though I selected beta

#

oh then it has Requirement already satisfied: python-matter-server[server] in /usr/local/lib/python3.11/site-packages (5.1.4)

#

so i guess it installs it on demand

sinful sinew
#

My issue came back just now. Theory is that it was routing through a homepod and now switched back to the yellow

sinful sinew
silk mica
#

i guess if it was related to the yellow routing though I would expect it to fail to pair on both my servers

sinful sinew
#

I assume your other server is using an Apple BR ?

silk mica
#

well, I didn't move the device - so it's still sitting next to the yellow OTBR - but there's a homepod on the other side of the room

sinful sinew
#

Yeah, I had that too but the device was connected to the homepod

#

so it doesnt choose it by close range or perse

silk mica
#

how do I check which device it's routing through?

#

wireshark?

sinful sinew
#

ip -6 route from the terminal of the matter server

traceroute6 -w <ip6ofdevice>

#

do you know how to get the ip of the device?

silk mica
#

I have them in some base64 encoding

sinful sinew
#

scroll down on the page I linked above

#

this section

#

soon we will have this in the HA interface but for now this is a bit exciting haha

silk mica
#

i was able to grab it from an mdns browser

#

but that is useful

#

so i guess i can ping it from the server that successfully paired, but not the one that failed

sinful sinew
#

well I think pinging succeeds

silk mica
#

so i guess it's probably more about which border router the server has as its route

sinful sinew
#

but maybe with packet loss

#

Yeah, we have the feeling that someything is wrong when you add the yellow as BR to the apple network

#

maybe incompatibility with TREL or whatever other mystery

silk mica
#

so if that is the main issue, I should be able to pair a non thread device still

sinful sinew
#

yes

sinful sinew
#

@silk mica lets continue here before we pollut ethe regular channel haha

#

This is where the app calls the HA websocket

#

and as you can see the request is forwarded as-is to the matter server

#

hmmm

silk mica
#

but yeah - seems very straightforward

sinful sinew
#

No, code is defined as str

#

You watched the server liogs right ?

#

and you saw the raw request being logged from the websocket call ?

silk mica
#

i haven't done it with debug logs on

#

does it matter if the matter server and ha server are on different hosts?

sinful sinew
#

no shouldnt matter

#

its just a websocket between ha and the matter server

#

this is a complete mystery to me

sinful sinew
#

@silk mica are you adding devices to HA only or also taking the appl ehome step in between ?

#

I have just identified a stupid mistake on our end ionvolving share from apple only

#

it induces a race condition

#

I am like 99% sure that adding a fresh device by QR code directly to HA would work reliable in all cases

silk mica
#
matter-server  | 2024-01-11 17:01:54 sdk4 chip.CTL[1] INFO Verifying attestation
matter-server  | 2024-01-11 17:01:54 sdk4 chip.CTL[1] ERROR Missing attestation information
matter-server  | 2024-01-11 17:01:54 sdk4 chip.CTL[1] INFO Error on commissioning step 'AttestationVerification': 'src/controller/CHIPDeviceController.cpp:2581: CHIP Error 0x0000002F: Invalid argument'
matter-server  | 2024-01-11 17:01:54 sdk4 chip.CTL[1] ERROR Failed to perform commissioning step 13
matter-server  | 2024-01-11 17:01:54 sdk4 chip.CTL[1] INFO Going from commissioning step 'AttestationVerification' with lastErr = 'src/controller/CHIPDeviceController.cpp:2581: CHIP Error 0x0000002F: Invalid argument' -> 'Cleanup'
matter-server  | 2024-01-11 17:01:54 sdk4 chip.CTL[1] INFO Performing next commissioning step 'Cleanup' with completion status = 'src/controller/CHIPDeviceController.cpp:2581: CHIP Error 0x0000002F: Invalid argument'
matter-server  | 2024-01-11 17:01:54 sdk4 chip.CTL[1] INFO Expiring failsafe on proxy 0x7f8c07f500```
#

it seems like the first commission try doesn't finish and then the second try starts

sinful sinew
#

We have identified the issue

#

we need to fix it in the companion app

silk mica
#

oh ok

sinful sinew
#

so sharing from apple home to HA is broken

#

oh well it has the race condition

#

because we use the same flow it is commisisoning to a temporary fabric now

#

and then shares it again

#

so the code you receive is not being sent to HA but to apple

silk mica
#

oh, so it's used up already by the time ha matter gets it?

sinful sinew
#

well, Apple kjust uses the regular flow and commisons the device to a temp fabric and then shares it AGAIN to HA

#

so instead of just passing that share code along its doing an intermediate step

#

and that could potentially lead to a race condition, especially on thread where traffic is a tiny bit slower

#

and nanoleaf which resets all the time

#

we should just hook into the apple framework and pass the code along

silk mica
#

interesting - that part is definitely over my head with what I know about this so far

sinful sinew
#

Yeah, I've asked our iOS app dev

#

I only realized this just now when I was tracing every part step by step