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

I'm documenting my experience of using node-red-matter-bridge to control my home IoT, in case it helps or motivates others to give it a try :smiley:

My knowledge of matter is very limited, so this is my interpretation, but please correct me if I'm wrong, and I'll update this post.

First Steps

  • Matter, works by communicating via your local area network, either by wifi or ethernet, and its essential that you have the same LAN between the device your Node-RED is running on and your Matter controller (Google Home, Nest Mini etc).
  • Matter also needs a 'hub' to translate messages to the local network. There are many standalone Hubs, but they are already built into most smart speakers such as Google Home, Nest, Nest Minis, etc. Googling will give you the full current list. For the purposes of this post, I'm using a Google Home speaker (1st generation).

Add the @sammachin/node-red-matter-bridge nodes to your palette, and drop a 'On-Off Light' node onto your workspace (although any of the nodes would do), give it a name

and add a new configuration, add a config name, and set the correct network interface (the one your controller is also in) in my example below I'm using lo0 (localhost). Leave the other settings unchanged.

Deploy your changes, and after a few seconds, you should get a green 'ready' light

3

At this stage, open up the node, and open the configuration again, but this time you should now see that a QR code has been generated & added at the bottom of the config page.

Using your phone, open up a QR reader app (any will do), and scan the QR code, which will produce a weird string of letters/numbers that looks nothing like a URL, but open it, and it should present you with this screen

Choose Google Home

and Agree

I'm Ready, and you may get this warning (because it's not a real certified device, but pseudo devices in node-RED.

Set up anyway, and if all's gone well, finally...

Now, after a few seconds, the pseudo device (Test Light) should be active in your dashboard, and can also be seen as an entry in the Google Home app on your phone.
Test if it's working by adding a debug node, and asking google to "switch the Test Light on", and you should see an output in the debug pane.

A typical output from the 'On-Off Light' is an object {state: true} or of course {state: false} which can then be mapped to control any device, such as a shelly, tasmota, MQTT etc.

Controlling devices from a dashboard switch

Taking this a stage further, it may be that you would wish to also control the device from a dashboard, as well as voice commands. This can be done by selecting 'Passthrough input msg to Output' in the node config, and feed in the same objects into the 'On-Off Light' node input.
This would result in the Google Home App being updated with that status, and the msg emerging from it's output which is mapped to the device.

inputtest

5 Likes

Hi @Paul-Reed Thanks for this its really useful.

However the part about matter only working on 2.4Ghz isn't quite correct!
Matter is an IP based protocol which works on a local network (no cloud servers)
It relies on DNS-SD (Service Discovery) to allow a controller (hub) or commisioner (phone) to discover the device on the local network.
Some people have separate VLANs or other isolation between their 2.4GHz and 5GHz WiFi networks on their routers, or indeed between their Wired and Wireless LANs.
Also a lot of consumer matter devices only support 2.4Ghz as they use devices like ESP32's as their silicon.

Therefore its possible to end up with these split networks and devices can't be discovered, the 2.4Ghz is a bit of a misnomer though, dumbed down by marketing for the masses :smiley:

So long as your have the same LAN between the device your Node-RED is running on and your Matter controller then it should all be fine. I'm doing most of my testing with Node-RED on the wired network and wireless controllers. I have a UniFi network at home.

Also Docker/K8S gets really complicated here, for now I'm saying its not supported until we have more time to test and figure out what settings you actually need there!

EDIT 17/11 - Paul
My original post now updated with this info

4 Likes

Also on the screenshot for configuring the Bridge config node you said to only add a Name and leave the others as default,

However its also important to set the correct network interface (the one your controller is also in) your example there has defaulted to lo0 (localhost)
I want to improve the default here but its tricky as so many systems have different interface names, binding to all isn't an option as that causes problems with multicast, If anyone knows a reliable way to get the interface name for the default route from a system in node (across multiple OS') then let me know!

EDIT 17/11 - Paul
My original post now updated with this info

3 Likes

Hi @Paul-Reed
Thanks a lot! When I saw the new node from @sammachin arriving, I had no clue at all that this kind of stuff was possible with it. Very cool.

I am trying to see the big picture, but some things are not clear yet for me:

  1. So this means you don't need a public tunnel anymore, and no fulfillment url anymore in your Google Action console for callbacks?
  2. I assume voice fragments are still being send by the Google Home device to the Google data centers, so it will still not work when being offline?

Bart

Hi Bart,

Yes Matter itself is purely a local network protocol, what this node does is expose virtual "devices" created in Node-RED to the Matter controller on your local network, That controller is typically in your home hub likst a Nest Speaker, Amazon Echo, Apple Home Pod Home Assistant, or LG TV!
There's no need for any tunnels to node-red or configuring URLs in the developer consoles.
Also I'm not running any cloud services to support this so its more sustainable, even if I get hit by a bus tmw your controler will still work

However, how that controller gets its commands is up to the individual platform, so in the case of the voice assistants like google they still rely on the cloud to do the voice processesing and that returns a command to the speaker which invokes the local Matter functionality.
Those speakers don't work without an internet connection, but some controllers do, notably Home Assistant.
Equally if you use the app for the controller then it may send the command locally from your phone to the hub, which then invokes the Matter control/

1 Like

But I assume that if the system went offline, users could resort to using their Google 'Home app' to control things, instead of voice commands???

Probbably! I'm not quite sure if the google home app functions without an internet connection though.
Certainly from the Matter perspective it will work offline

First post above updated with example to control devices via a dashboard switch as well as voice.
Also updated with Sam's comments.

Brilliant! Creativitiy of the highest level...

Did some quick reading to gain some insight but:

  • Above the terms "hub" and "controller" seem to refer to the same kind of component. Is that just another name for the same component? Because I read somewhere that a controller controls smart home devices, while a hub manages controllers. So that a Google Nest mini contains a controller but no hub?
  • You use the @project-chip/matter.js library. Am I correct that that is a controller implementation? If so, how can you use it because your node isn't a controller but a bridge :exploding_head:

I think I am mixing things up...

I have always assumed that the state of your devices (e.g. light off) is stored somewhere in the cloud, so that it can only work when you are online.

Moreover suppose you have N Google nest mini devices, which means you have N Matter controllers running. On which one would your state be stored, if you are offline...

Yes the terminology is a bit of a mess!
In strict matter terms there's no such thing as a Hub, but that term is often used to refer to the combination of an Matter Administrator and a Matter Controller, and is usually manifested as some sort of in home device that is always on and doesn't leave the home, so smart speakers like Nest Hub or Alexa are good places to implement that.
The 'Hub' usually works in conjunction with a phone app which implments the Matter Commisioner function and some part of the controller, either as just the UI to the logic in the Hub via some propriatary interface or it could be a controller within the fabric itself. (while its on the home network)

The nest mini contains an Administrator which is the key component to managing a fabric (network) with the associated access control credentials to devices.

You can have multiple controllers in a fabric its simply a device capable of sending commands and reading/writing attributes on another device. So a simple smart switch/button could be a controller (although there's nothing on the market like that yet!)

Matter,js can implement any of the functions in the matter spec, so it can be an adminstrator & controller for devices in its own fabric, or it can create a bridge or it can create an end device (a bridge is really just a special kind of device that aggregates devices)
I've been working fairly closley with the dev behind matter.js for a few months now.

The state within matter is actually held within the individual devices and controllers read that state when they need to, they can also subscribe to values within a device to be notified when they change.

This is down to the indiviudal ecosystem (eg Apple, Google etc) but most of them syncronise the admin credentials to some sort of cloud server associated with your account and then will just nominate one device in the network at a time to send the control messages, but that function could move around your devices.

In general matter is far more of a p2p type of architecture than some sort of centralised control.

1 Like

Thanks @sammachin for the extensive feedback!! Would have taken me MUCH longer to find that info on the web...

I have runned out of luck (already quite some time ago ...).
Have tried it multiple times, but it takes quite a long time and then I get this over and over again:

I have a couple of Google Home mini devices running in my house (not Google Nest mini). There are all on the same LAN, as is my smartphone at the moment.

In see in one of your screenshots above "power on your new device and make sure that it's in setup mode". Did you do anything special with your Google Home mini devices?

What interface have you selected in the config node for your node-red flow? the Bridge needs to bind to the interface on the same network as your google home minis
Also making sure you don't have any kind of client isolation on in your wifi network.

Finally make sure its less than 5mins since you did a full deploy/restart on node-red as the broadcast times out. (I need to improve the handling here)

Is this on a windows system or docker or what Bart?

Also, is IPV6 enabled on the network adapter?

On my Raspberry running Node-RED I have the following interfaces:

The last one is because all my devices (smartphone, raspberry, ...) are in a tailscale vpn mesh network. The Google Home Mini devices are not in that network (because they don't run a Tailscale agent), but normally everything normal within my LAN is interconnected (as long as I don't use tailscale virtual hostnames).

I have tried them all 3 (within 5 minutes after deploy), but no luck.

Node-RED is running on a Raspberry (Raspberry OS), installed via Dave's script. No Docker.

Yes I have an fe80::... address for my eth0 interface.

Should be fine with eth0 then,
Although thats the wired interface right? its possible that some home routers separate traffic on wired and wireless networks. Need to ensure that mDNS passes between the networks

My speakers all connect via WiFi to the same router as my Raspberry pi, except the pi is connected via ethernet.
I've used lo0 (as I don't really understand the protocol).

Is that <5 minutes between getting the node green 'ready' indicator, and reaching 'Device connected'?

Thats very odd it shouldn't be working via lo0 as thats localhost!

Its 5 mins between the bridge node starting (which happens on node-red startup or on a full deploy and the commisioner app discovering the device.

1 Like

Yes my Raspberry uses a wired ethernet connection, no WIFI.

Seems that I have both a Google Home Mini and Google Nest Mini. I can ping both devices without problems from my Raspberry Pi (using their ipv4 address).

whats your router? ping via IP address isn't the same as multicast working though

Not sure whether I understand that correctly?
I am not aware of any isolation between my wifi and ethernet network. My wifi is made up of a series of Unifi access points.

Ok. Do you perhaps have some commands that I can run to test the connection. Or can I perhaps look somehow at some traffic, or anything else I could use to troubleshoot?