Configuring @sammachin/node-red-matter-bridge to work with Google/Nest speakers

General
21

It works now. Can't explain it yet..

  • I had opened my Node-RED flow editor via the virtual tailscale hostname of my raspberry:
    https://<my-raspberry-virtual-hostname>/xxx
    Then the discovery fails.
  • However when I open my flow editor via the raspberry physical ip address:
    http://<my-raspberry-physical-ipv4-address/xxx
    Then it works fine.
22

Check firewalls are not blocking udp ports 5353, 5540 (mDNS port and Matter operational discovery port).

Enable debug mode on the bridge config and look for an address like xxxxxx.xxxx.local then in a terminal execute dns-sd -B B9FF2C43EDFAE87F._matterc. _udp.local

EDIT

nevermind. You got it going.

1 Like
23

I have no clue what happens if I scan the qr code.
If somehow my domain name (used to access my flow editor) is being used by my google home device, then I assume it is normal that it doesn't work: because a device not running a Tailscale daemon will not be able a tailscale virtual hostname. But I assume that is not the case, because we are dealing here with some kind of broadcast.

Well I hope it will stay working. Because I had planned to setup ip tables rules, to make sure you can only access the flow editor via the tailscale agent (i.e. via the virtual tailscale name of the raspberry). But I have now circumvented the tailscale agent to be able to scan that qr code.

My time is up for today.

24

Glad you got it working, there does seem to be an element of giving things a little time to settle with matter! doesn't make sense technically but I wonder if there's some learning of mutlicast paths that needs to go on in the home network or something.

In terms of securing your node-red the QR code has nothing to do with the hostname or address of the pi it just contains a passcode and id numbers that allow the controller to identify it has the right device that is broadcasting in DNS-SD and the uses the passcode to authenticate the initial session, and exchange certificates that are used for future auth.

So securing the node-red editor should have no bearing on the matter connection

1 Like
25

@Paul-Reed,
Perhaps it is better to split my posts into another discussion. Because it seems like my issue is Tailscale related, or perhaps a more general issue for all private vpn mesh networks (also ZeroTier, ...). Don't want to pollute your tutorial discussion.
Thanks!

@sammachin

Ok that is clear. But once the initial handshake (= perhaps not the correct matter term...) is over, the controller of the Google Home will directly send the commands to my Pi via the hostname that has been exchanged during the inital setup? It would be nice if you could share some more info about the handshake (e.g. is your node listening to some port, and so on...)

I am wondering if perhaps your node has received the broadcast signal, but the handshake failed? Perhaps that gives another error screen...

Can I repeat somehow the process with extra logging? I assume I can create new config nodes to test it over and over again? Although I assume I am polluting that way the controller in my Google Home devices, which I most probably shouldn't do...

P.S. I will to try afterwards to contribute a troubleshooting guide to your repo, to make sure other users can benefit from the time you have spend on my particular issue. This is my starting point:

image
image1122Ɨ577 70.7 KB

26

I initially tried to set up my config whilst using my domain address - https://my domain.co.uk but that didn't work for me (like you using your tailscale address?).
Some time later, I tried my local IP address instead, and it configured straight away.
So maybe not so different.

1 Like
27

No idea if some of the ideas here will help - Testing Multicast Traffic on Linux Ā· GitHub - but yes multicast can be fiddly... not least as it often only transmits on one network port and which one it picks first can be not obvious.

2 Likes
28

Yes the network interface issue is tricky with multicast so the matter-bridge nodes have a config to allow you to select which interface it should use.
Although I'm not 100% that its always doing what its told.

29

I'll try and write up a better explainer later this week (quite a lot on with $dayjob) but for now this is a good overview of how the discovery/connection works,
Commisioing Discovery is only used for finding new commisionable devices to link to a Controller/Hub and operational discovery is for already paired systems
https://handbook.buildwithmatter.com/howitworks/discovery/

3 Likes