Node-Red-Matter-Bridge - Proper Setup?

General
1

@sammachin Thanks for starting up this project. This approach seems more in alignment with how I want to use matter nodes.

So I've successfully setup a bridge tied to a dimmable light node, setup a Google Home Project to validate it and have it installed in the Google Home App. But I'm not 100% sure I understand the right setup. In Google Home I see the controllable device and a bridge device.

Based on this article (What is a Matter Bridge? | Know-how | matter-smarthome) I was thinking that meant that I just had to tie other device nodes to that same Bridge in Node-Red. I added two more devices (so have two dimmable lamps and one on/off lamp) to that same validated bridge and they both also showed up in Google Home but then I saw that the two dimmable lamps are showing as "Not Running" in Node-Red and I was seeing this error in my bug reports "Error: Endpoint ID 4 exists twice".

I am able to capture output from one of the dimmable lamps and the "running" on/off lamp.

Any guidance would be appreciated, thanks.

2

HI @rgerrans

Thanks, yes I think using Node-RED as just a bridge makes the most sense in Matter.

It sounds like you've got things setup right, basically the "bridge" itself is a config node which is then used by each of the device nodes that you add to your canvas.
You should then need to only commision the bridge node once with an initial device node and any further device nodes that you add using that bridge node should be discovered by your Matter controller, I have seen that it can sometimes take a controller some time (30mins+) to discover new nodes.

The problem you mention about Not Running on the new nodes sounds like maybe the bridge node wasn't restarted when you added the new nodes? Did you do a full deploy or just changed nodes?
Its a tricky one as at the moment restarting the bridge too often causes errors with the matter fabric which can take a while to sort themselves out (its like there are old hung sessions) But adding a new device to the bridge would need the bridge to be restarted in order to allow the devices to register.

I'd try a full deploy if not a node-red restart and see if that helps things, this is all still very much work in progress both on the nodes and the underlying matter.js library.

3

Thanks, good to know on the full deploy and not doing them too frequent. I'll give this a try and report back if that doesn't solve the issue

One other item I noticed was the output for the dimmable light looks like it is scaling from 0-255 not 0-100.

4

Yes the Matter specification uses 0-255 for dimmable level, I haven't yet decided if its better to map that to a percentage or not.

5

It's obviously easy enough to do it as an add on node, but my vote would be to do it in the Matter node to save the extra step.

6

Some feedback. I've used the following Flow connected to Alexa.

image
image844Ă—205 8.95 KB

[{"id":"71982e92b78ed209","type":"tab","label":"Flow 1","disabled":false,"info":"","env":[]},{"id":"53c0ebf3e0a091e2","type":"debug","z":"71982e92b78ed209","name":"debug 1","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":800,"y":300,"wires":[]},{"id":"7a6a0d332795c247","type":"ui_switch","z":"71982e92b78ed209","name":"","label":"switch-1","tooltip":"","group":"61e6d4c4.e7619c","order":0,"width":0,"height":0,"passthru":true,"decouple":"false","topic":"state","topicType":"str","style":"","onvalue":"true","onvalueType":"bool","onicon":"","oncolor":"","offvalue":"false","offvalueType":"bool","officon":"","offcolor":"","animate":false,"className":"","x":580,"y":300,"wires":[["53c0ebf3e0a091e2","5bf2f8a3b9d8cfd3"]]},{"id":"cc002be580542179","type":"rbe","z":"71982e92b78ed209","name":"","func":"rbe","gap":"","start":"","inout":"out","septopics":true,"property":"payload","topi":"topic","x":350,"y":300,"wires":[["7a6a0d332795c247"]]},{"id":"074cf23fdd15cf1c","type":"debug","z":"71982e92b78ed209","name":"debug 2","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":340,"y":240,"wires":[]},{"id":"5bf2f8a3b9d8cfd3","type":"matteronofflight","z":"71982e92b78ed209","name":"switch 1","bridge":"106746443e4b4655","x":180,"y":300,"wires":[["cc002be580542179","074cf23fdd15cf1c"]]},{"id":"61e6d4c4.e7619c","type":"ui_group","name":"RF Plugs","tab":"d680797a.2f8b88","order":1,"disp":true,"width":"5","collapse":false,"className":""},{"id":"106746443e4b4655","type":"matterbridge","name":"switch 1br","vendorId":"0xFFF1","productId":"0x8000","vendorName":"Node-RED-Matter","productName":"Node-RED-Bridge","networkInterface":"wlan0","logLevel":"ERROR"},{"id":"d680797a.2f8b88","type":"ui_tab","name":"Home","icon":"dashboard","disabled":false,"hidden":false}]

While, when functioning well, it allows the Switch to be operated from Alexa voice, Alexa App, or the Flow Dashboard with appropriate State update on the devices, it is not always responsive. I've attached a snippet of the log to show the errors.

    at ExchangeManager.onMessage (/home/pi/.node-red/node_modules/@project-chip/matter.js/dist/cjs/protocol/ExchangeManager.js:88:16)
    at /home/pi/.node-red/node_modules/@project-chip/matter.js/dist/cjs/protocol/ExchangeManager.js:58:18
    at /home/pi/.node-red/node_modules/@project-chip/matter.js/dist/cjs/net/UdpInterface.js:38:80
    at Socket.messageListener (/home/pi/.node-red/node_modules/@project-chip/matter-node.js/dist/net/UdpChannelNode.js:96:13)
    at Socket.emit (node:events:517:28)
2023-09-25 21:18:22.617 ERROR SubscriptionHandler Error sending subscription update message (error count=21): Error
    at MessageExchange.retransmitMessage (/home/pi/.node-red/node_modules/@project-chip/matter.js/dist/cjs/protocol/MessageExchange.js:219:44)
    at TimerNode.callback (/home/pi/.node-red/node_modules/@project-chip/matter.js/dist/cjs/protocol/MessageExchange.js:234:100)
    at Timeout._onTimeout (/home/pi/.node-red/node_modules/@project-chip/matter-node.js/dist/time/TimeNode.js:25:18)
    at listOnTimeout (node:internal/timers:569:17)
    at process.processTimers (node:internal/timers:512:7)
2023-09-25 21:18:22.618 ERROR SubscriptionHandler Sending update failed 3 times in a row, canceling subscription 2394764860 and let controller subscribe again.
2023-09-25 21:18:23.963 ERROR ExchangeManager Cannot find a session for ID 7312
    at ExchangeManager.<anonymous> (/home/pi/.node-red/node_modules/@project-chip/matter.js/dist/cjs/protocol/ExchangeManager.js:94:23)
    at Generator.next (<anonymous>)
    at /home/pi/.node-red/node_modules/@project-chip/matter.js/dist/cjs/protocol/ExchangeManager.js:13:71
    at new Promise (<anonymous>)
    at __awaiter (/home/pi/.node-red/node_modules/@project-chip/matter.js/dist/cjs/protocol/ExchangeManager.js:9:12)
    at ExchangeManager.onMessage (/home/pi/.node-red/node_modules/@project-chip/matter.js/dist/cjs/protocol/ExchangeManager.js:88:16)
    at /home/pi/.node-red/node_modules/@project-chip/matter.js/dist/cjs/protocol/ExchangeManager.js:58:18
    at /home/pi/.node-red/node_modules/@project-chip/matter.js/dist/cjs/net/UdpInterface.js:38:80
    at Socket.messageListener (/home/pi/.node-red/node_modules/@project-chip/matter-node.js/dist/net/UdpChannelNode.js:96:13)
    at Socket.emit (node:events:517:28)
2023-09-25 21:18:32.962 ERROR ExchangeManager Cannot find a session for ID 24397
    at ExchangeManager.<anonymous> (/home/pi/.node-red/node_modules/@project-chip/matter.js/dist/cjs/protocol/ExchangeManager.js:94:23)
    at Generator.next (<anonymous>)
    at /home/pi/.node-red/node_modules/@project-chip/matter.js/dist/cjs/protocol/ExchangeManager.js:13:71
    at new Promise (<anonymous>)
    at __awaiter (/home/pi/.node-red/node_modules/@project-chip/matter.js/dist/cjs/protocol/ExchangeManager.js:9:12)
    at ExchangeManager.onMessage (/home/pi/.node-red/node_modules/@project-chip/matter.js/dist/cjs/protocol/ExchangeManager.js:88:16)
    at /home/pi/.node-red/node_modules/@project-chip/matter.js/dist/cjs/protocol/ExchangeManager.js:58:18
    at /home/pi/.node-red/node_modules/@project-chip/matter.js/dist/cjs/net/UdpInterface.js:38:80
    at Socket.messageListener (/home/pi/.node-red/node_modules/@project-chip/matter-node.js/dist/net/UdpChannelNode.js:96:13)
    at Socket.emit (node:events:517:28)
2023-09-25 21:18:38.178 ERROR SubscriptionHandler Error sending subscription update message (error count=36): Error
    at MessageExchange.retransmitMessage (/home/pi/.node-red/node_modules/@project-chip/matter.js/dist/cjs/protocol/MessageExchange.js:219:44)
    at TimerNode.callback (/home/pi/.node-red/node_modules/@project-chip/matter.js/dist/cjs/protocol/MessageExchange.js:234:100)
    at Timeout._onTimeout (/home/pi/.node-red/node_modules/@project-chip/matter-node.js/dist/time/TimeNode.js:25:18)
    at listOnTimeout (node:internal/timers:569:17)
    at process.processTimers (node:internal/timers:512:7)
2023-09-25 21:18:38.179 ERROR SubscriptionHandler Sending update failed 3 times in a row, canceling subscription 1012964284 and let controller subscribe again.

Hope it proves useful for debugging.

It has the potential for a being a really useful node. I currently use node-red-contrib-wemo-emulator as a simple Alexa control switch in Flows, but of course it is not interactive as a switch state can't be sent from the Flow dashboard to the Alexa App.

7

@sammachin So did you change it to 1-100 out? I had to reinstall it from the command line (don't ask :wink: ) and noticed the node outputs were now matching.

The issue I'm currently having is any input of a number is just getting passed through and the node isn't changing to reflect the value in Google Home (I'm pretty sure earlier that the node was not passing through input commands)?

On the restart, I tried isolating my Matter nodes to a single flow hoping to avoid doing a full deploy if I was working on other flows, but it looks like I need to do a full deploy no matter the change? And yes, I'm running into the system being out for a little while it cleans up.

Edit:
Did some more testing and what I'm seeing is if I inject a payload value (numeric or true/false), it passes through the value (and doesn't change the dim level turn on/off in Google Home). If I change the dim level in Google Home it's sending the 1-255 value.

I could have sworn when I tested last week, injected true/false or values were changing the node so not sure if something else is going on

Edit 2:
Looks like the updates is something with Google Home. If I turn my screen on/off it refreshes. Though now my level changes injected seem to be based on the 1-255 as well for the Google Home dim level

Hopefully you can make some sense of this post....

8

I've not made any changes since adding the dimmable light.

Yes at the moment I'm not sure the UX is right on the dimmable unit, basically there are 2 things you can control in the node, the dim level and the on/off state.
So inputting a bool, the strings on/off/toggle, or a 0 or 1 digit will controll the on/off state.
Inputting a number between 2 and 255 will control the dim level.
In theory you can adjust the dim level of an off device and the new level will then show when its turned on.
The output isn't directly connected to the input but when the device state changes in the matter fabric the node will output its new state, so if you input a true once the light has turned on it will output a true but its not the same msg object.
I'm currently using the msg.topic in the output to indicate what state has changed eg dim or switch, but might modify this to all be in the payload object.

I've found the google home app to be pretty slow to update when something else changes the state of a matter device, you sometimes need to exit and go back into it too see the changes.

In general matter seems to work fine for actual use in terms of refresh/responsiveness but its not always so clear when you are testing!

9

Thanks.

This is different from your in-node documentation, you have it as 0-100. Easy enough to put in a range node to translate from my Zwave devices.

It has been one of my wish items that ZWave supported this (or the lights I used supported this)....but unfortunately they don't so I end up doing my TOD adjustments after they turn on.

It would be helpful if there was anyway to filter these out inside the node (or provide it as a node option like NORA does). I'm going to add a filter to run both the input and output through to block the feedback loop that currently gets created in my setup.

Good to know. I didn't notice this before and can use that to switch my node paths. Along those lines, another feature wish list would be to be able to set the output types in the node (once again, similar to how NORA does this). That way I can skip the step of changing the true/false to the 255/0 I need for ZWave. And if you do this for the on/off then it similarly giving the option for 1-255 or 1-100 for dim input/output would be helpful.

That's what I was seeing. As long as I cycled the screen or the view it would update. Never saw that before with NORA but not a huge deal since I'm usually not watching it change accept when I test.

One other feature request would be to add the current state of the node as a status on the node (on/off and %dim)

Thanks for all the great work on this.

10

I'm not seeing this in the output object from the Matter node?

Edit: One other observation on the pass through values. They happen even immediately after deployment when the fabriq is still repairing itself (i.e. before I see the changes reflected in Google Home / communication from Google Home back to Node-Red happening w/o erroring out)

11

For anyone following this thread here is what I've setup for now to handle the situation.
image

The change node adds a msg.topic = "Matter In"
The function node:

  • Filters out any outputs matching the input
  • Converts true/false to 255/0 (needed for my Zwave Devices)
  • Converts and dim level to 1-100 value from the 1-255 value

Here is the function node code:

// Declare a context variable to hold the filter value
var filterValue = context.get('filterValue');

// Check the msg.topic
if (msg.topic === "Matter In") {
    // Store the value in the filter variable
    filterValue = msg.payload;
    context.set('filterValue', filterValue);
    return null; // End the function
} else {
    // Explicitly compare the value to the filter variable
    if (filterValue !== undefined && msg.payload === filterValue) {
        // Clear the filter variable
        context.set('filterValue', undefined);
        return null; // End the function
    } else {
        // Process the msg.payload
        if (msg.payload === true) {
            msg.payload = 255;
        } else if (msg.payload === false) {
            msg.payload = 0;
        } else if (typeof msg.payload === 'number' && msg.payload >= 1 && msg.payload <= 255) {
            msg.payload = Math.round((msg.payload / 255) * 100);
        }
        
        // Return the processed msg
        return msg;
    }
}
1 Like
12

Perhaps I'm missing something or hoping for the impossible. I have set up the dimmable light switch in Node Red and it is recognised in the Alexa App as a Device. The Alexa App controls a dimmable TCP wifi Smart light, but I can't see how it is possible to link the two devices so as to control the light via the Node Red dimmable light switch. Any thoughts or suggestions?

13

The bridge exposes devices controlled by Node-Red as matter devices, not the other way around. You'd need to control the light in Node-Red then expose it to Alexa

14

Thanks, and that's what I suspected, but was just hoping for the impossible. I suppose it might be possible to use IFTTT to interlink routines within Alexa to get the control needed. I presume there is no chance of the Matter Bridge ever recognising wifi devices on the wlan?

15

I'd be surprised if you can't find a contrib that controls your wifi device

16

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.