search

project-chip / matter.js

A complete typescript implementation of the Matter protocol specification (https://buildwithmatter.com). Includes full support for controller, device, commissioning, secure communications, device types, and cluster definitions.
Apache License 2.0
348 stars 60 forks source link

DeviceNode example, pairing works but lightswitch stays offline #604

Closed seriousme closed 10 months ago

seriousme commented 10 months ago

Hi,

I tried connecting from Google Home app on my Android 13 to the DeviceNode example (from matter-node.js-examples 0.7.3) running on an OrangePi Zero
Linux orangepi 6.1.63-current-sunxi #1 SMP Mon Nov 20 10:52:19 UTC 2023 armv7l armv7l armv7l GNU/Linux

Pairing works as the Google Home app installs the device, but shows it as "offline" even though deviceNode.js is still running and continues to send out: 

2023-12-27 19:48:13.904 DEBUG MatterDevice         Announcing fabric: 11186812768209097110
2023-12-27 19:48:13.910 DEBUG MdnsBroadcaster      Announcement Generator: Fabric id: cc83768850092a22/805646301 qname: CC83768850092A22-0000000030052FDD._matter._tcp.local port: 5540 interface: eth0
2023-12-27 19:49:13.905 DEBUG MatterDevice         Announcing fabric: 11186812768209097110
2023-12-27 19:49:13.910 DEBUG MdnsBroadcaster      Announcement Generator: Fabric id: cc83768850092a22/805646301 qname: CC83768850092A22-0000000030052FDD._matter._tcp.local port: 5540 interface: eth0

Is there something I am missing here ?

Kind regards, Hans

Apollon77 commented 10 months ago

Please post a full log. And make sure that UDP traffic can flow from the Google nest pod to the device node host without issues.

Commissioning is done by the Google home mobile app but the operative controlling is done by the nest pod.

When just seeing MDNS announces but no control traffic then most likely MDNS/UDP is blocked somewhere.

seriousme commented 10 months ago

Hi,

I have added log.txt Both the Nest Audio and the orangePi are on the same lan, same subnet with no restrictions between them. The Nest Audio is configured for auto-update.

Any hints would be much appreciated!

Kind regards, Hans

seriousme commented 10 months ago

Looking at the logs I am wondering if could this be the issue:

2023-12-28 11:47:15.926 DEBUG UdpChannelNode       Initialize multicast address: 192.168.1.100:5353 interface: eth0 type: udp4
2023-12-28 11:47:15.929 DEBUG UdpChannelNode       Initialize multicast address: ::%eth0:5353 interface: eth0 type: udp6

as ::%eth0 does not look like a valid ipv6 address to me.

Kind regards, Hans

Apollon77 commented 10 months ago

as ::%eth0 does not look like a valid ipv6 address to me.

welcome in the IPv6 world of local interfaces :-) thats correct

Apollon77 commented 10 months ago

Ok the log shows a succcessfull commissioning from 2001:4c3c:9f00:4000:618f:9a91:c7de:f6f0 (this should be your mobile device with the google home app, right?). Normally after commissioning complete then the Hub connects to the device and exactly this is missing.

So either MDNS/UDP is not reaching the homepod or Homepod can not reach the device via UDP ...

seriousme commented 10 months ago

Thanks for analyzing my logs!

welcome in the IPv6 world of local interfaces :-) thats correct

Never to old to learn something new, thanks for teaching me this :-)

2001:4c3c:9f00:4000:618f:9a91:c7de:f6f0 is indeed the android mobile. The hub would in my case be the Nest Audio right ?

My ISP supplied router does not provide DNS resolution for hosts on the local LAN, could this be hampering communications ?

Kind regards, Hans

Apollon77 commented 10 months ago

The hub would in my case be the Nest Audio right ?

Nest Audio? in fact the "Google pod" ... Google nest mini or the bigger one with the screen.

My ISP supplied router does not provide DNS resolution for hosts on the local LAN, could this be hampering communications ?

that should be irrelevant, in fact it is all about UDP packages ... in this case MDNS (which is just UDP packages)

seriousme commented 10 months ago

I got a Nest Audio (https://store.google.com/product/nest_audio)

https://blog.google/products/google-nest/matter-general-availability/ states:

With Matter, you will need a hub to control your smart devices. If you want to control your smart home with Google Home, you’ll need a Google Home or Nest device that can double as a hub for Matter. These devices include the original Google Home speaker, Google Home Mini, Nest Mini, Nest Audio, Nest Hub (1st and 2nd gen), Nest Hub Max, and the new Nest Wifi Pro.

So the hub should not be the issue.

Running an NMAP scan on the orangePi from another host on the Lan shows that the advertised ports are listening:

PORT     STATE         SERVICE
5353/udp open|filtered zeroconf
5540/udp open|filtered sdxauthd
MAC Address: 02:42:91:2B:61:59 (Unknown)

and also triggers an error log on the OrangePi:

2023-12-28 19:40:22.079 ERROR ExchangeManager      RangeError: Offset is outside the bounds of the DataView
    at DataView.getUint8 (<anonymous>)
....
    at Socket.emit (node:events:514:28)
    at UDP.onMessage [as onmessage] (node:dgram:941:8)

as expected as nmap just sent a dummy byte. So the UDP ports must be reachable from the LAN.

However running an mdns scanner on that same second host does not see the announcements made by deviceNode.js, but it does see the multicast packets coming from the Nest audio, e.g.: 

RECVD PACKET from 192.168.1.67 type: response, questions: 0, answers: 1 [Nest-Audio-d7ac187439f4691d393eb7645dab63a3._googlecast._tcp.local]

Any suggestions on what to try next ?

Kind regards, Hans

Apollon77 commented 10 months ago

In fact if matter.js MDNS would not work at all then also your mobile app would not have found it and so commissioning would have failed. So the interesting question is why it do not work ...

I will try tomorow how my Google behaves

Apollon77 commented 10 months ago

Ok, i checked and for me it all looks ok. I also checked your log a bit deeper at the end ... in fact it seems that the mobile device did not receive the response to the commissioningCOmplete call he sended ... because the device resends this ... so there is something strange

Apollon77 commented 10 months ago

BTW: I noticed an other strange effect with Google today ... For me the commissioning works butz the hoogle home app hangs in "connecting device to google home". And also the log looks a bit strange ... when I kill the google home app the device is comissioned correctly ... So maybe there is a part also i that. But I tried and the 0.6.0 of matter.js and nightly both behave that way, so latest changes are not the root cause

seriousme commented 10 months ago

Thanks for trying it out!

I noticed in a message in the logs saying:

2023-12-28 11:47:41.676 DEBUG InteractionServer    Interaction model revision of sender 11 is higher than supported 10.

I looked at the Matter specification but apparently this should not be too much of an issue.

I also tried the BridgedDevicesNode.js example (on a different ProductID) . It correctly commisioned the bridge and 3 lamps, but all lamps remain offline. The Nest Audio knows about the lamps as asking to switch them on/off gives a "this device is offline" response, where asking for switching "lamp 5" gives an "I don't understand" response. ASking to switch "lamp 4" (which does not exist in the homegraph, it replies with "both devices are offline" !?! Funny enough the homegraph viewer says the 3 devices are online, but as soon as I try to test them from there I get a "device offline" error.

The bridge shows as "online" (not greyed out) but apart from changing the name there is little way to interact with the bridge.

Any other suggestions to try ?

Kind regards, Hans

Apollon77 commented 10 months ago

The matter protocol info message can be ignored ... you could try the just release 0.7.4 ...

if apple hub shows offline do one try: go in the settings of the device and request the details ... does that work?

seriousme commented 10 months ago

Hi,

I tried 0.7.4 both with DeviceNode.ts and with BridgedDevicesNode.ts DeviceNode.ts is shown in the Google Home app as a single device which is offline. BridgedDevicesNode.ts is shown in the Google Home app as a bridge with 3 devices, the bridge is shown as online, but the devices are shown as offline. I can query the single device and the bridge for details and then it returns Hwversion , SWversion etc and I can see the queries in the log on the OrangePi

Kind regards, Hans

Apollon77 commented 10 months ago

I also had such effects with Google but aaaaages ago ... Which Firmeware version your hub has? ... in fact it should be relatively new ... Try the following:

seriousme commented 10 months ago

The minimum version for the Nest Audio to support Matter is specified at https://developers.home.google.com/matter/release-notes as:

Google Hub firmware min version: 1.56.324896 (appears on hub as Chromecast firmware version)

My Nest Audio currently runs:

Which is the lastest firmware as of December 6 , 2023 (see https://support.google.com/googlenest/answer/7365257?hl=en#zippy=%2Ccurrent-preview-program-firmware-version). So that should not be a problem, but then again it might be that somehow this new firmware is botched or is too new etc..

I have rebooted the Nest Audio, started BridgedDevicesNode.js with a new uniqueId and commisioned it using the Google Home App.
For now all 3 lights are labeled as offline, I'll check later if anything changed.

Kind regards, Hans

Apollon77 commented 10 months ago

For now all 3 lights are labeled as offline, I'll check later if anything changed.

In fact first check in matter.js if they contacted the device ... if it worked they should have an active subscription sending updates every 30-120s ... if this works and still shown offline reload/restart the google home app

Apollon77 commented 10 months ago

@seriousme Please check again what I wrote above also when shown as offline. tap the settings icon and get the device details ... does that work and do you see traffic? I also had such a case where this settings were working directly, but the hub took another 4 minutes to subscribe and show as "non-offline".

seriousme commented 10 months ago

OK, I tried a gain with the single device using DeviceNode.ts Yesterday evening the home app would not find the device for some reason so I couldn't even pair it. This morning after cleaning the store again I was able to pair, I was able to list the device details and then I see the traffic. However the home app still considers it offline. Logfile here deviceNode sh.log.txt.

The Google Home Graph viewer shows the device as online:

Name Id Type States
Test lamp 9B3F8AF141E85196.000000008BDB0EC7-0-1 LIGHT online: true

Looking at the logs again I can't find this ID. However I noticed that the announcements are made using qname:

CC83768850092A22-000000008BDB0EC7._matter._tcp.local

e.g.: 2024-01-03 08:08:27.315 DEBUG MdnsBroadcaster Announcement Generator: Fabric id: cc83768850092a22/2346389191 qname: CC83768850092A22-000000008BDB0EC7._matter._tcp.local port: 5540 interface: eth0

Should the 000000008BDB0EC7 in the broadcast be identical to the 000000008BDB0EC7-0-1 in the homegraph viewer ? Is so, that might explain why the Nest Audio does not respond to the broadcasts.

Kind regards, Hans

Apollon77 commented 10 months ago

I can not answer the question ... these are Google internals ... sorry ... maybe try to report this to Google? I can not help anymore... matter.js wise it looks as it should, no idea why google shows it as offline and did not do a subscription.

How long you waited? let it run an hour or some more ... does it change?

seriousme commented 10 months ago

Thanks for all the effort you put in analyzing this! I ran it for 20 minutes or so.

If there is no solution then I will close the issue for now.

KInd regards, Hans

Apollon77 commented 9 months ago

Sorry, as said report to ghoogle, maybe it is something they need to improve

Apollon77 commented 9 months ago

PS: would be interesting if an other of the nest hubs would work for you ....

seriousme commented 9 months ago

PS: would be interesting if an other of the nest hubs would work for you ....

Good question! For now I'm probably going to try the Google Matter Virtual Device first and see if that works, but I need to tweak my setup for that a bit ;-)

seriousme commented 8 months ago

Now this was interesting, maybe someone else can benefit from this. I previously had a smarthome integration using a "Smarthome Action on Google" via console.actions.google.com including a local integration. (not using Matter). After removing this, which you can only do by removing the GCP project and waiting the mandatory month for GCP to clean up, I tried the matter.js demo again and it worked out of the box !!

Apparently the "Smarthome Action on Google" interfered with the Matter integration :-( Good news is that I can now use Matter.js to replace the paperclip-and-tape integration that I had using "Smarthome Action on Google"

Apollon77 commented 8 months ago

Glad you solved it! And thank you for sharing the infos!