Although the Commissioning node gives the option to enter the pairing code and the device label by entering them directly into the node I could not get this to work. Using an inject node with the relevant info in msg.payload.code & msg.payload.label did the trick
When you get the code in Alexa it looks like 1610-472-6310 , leave out the dashes when entering the code into the inject node (as a string)
There are also a few development opportunities
The Command node brings up the 'Sign in to access this site' popup whenever double clicked to edit.
I have a simple relay but at the moment if I want to be able to turn it On & Off (rather than Toggle as I may want to send either On or Off when the device is already in the state) I have to have 2 nodes. It would be great if the Cluster & Command could be selected by msg input.
The input for an OnOff state in the virtual Matter node allows 'on', 'off', 1, 0, true, false - the Command node does not allow 'on' or 'off'. Not a big deal but could be confusing.
Thanks for the writeup @Buckskin I'll try and respond to those points below
That sounds like a bug, I'll take a look those fields are set as typedInputs so you should be able to use them eitehr via input or config in the node, although in the case of commissioning the code & label are a one time thing so I wasn't sure how much sense it made to set them in node config anyway.
Ah yes Matter has some suggested formatting of pairing codes in a 4-3-4 format, I should just strip out the non numeric characters from the input (I'm a little surprised the Matter.js library doesn't do that already)
The Command node brings up the 'Sign in to access this site' popup whenever double clicked to edit.
[/quote]
Not sure what popup you're referrring to here? is this the node-red login? could you give me some more details and perhaps a screen grab, where are you running Node-RED?
The way the nodes are built the lists of clusters, commands & attributes are all 'discovered' from the underlying library which reads the device and populates the dropdowns that way, to make these typedInputs with the pre-populated options as well as msg/flow etc looks tricky, One option might be to allow fixed input values to overide the config eg msg.cluster msg.command etc, although in the case of clusters it is actually the numeric ID rather than the label that you see which is required, I'm also concerned that having something even lower level than we have already would open up to people having more issues with incorrect naming of commands etc.
I was thinking along the lines that people could build subflows with these nodes if they wanted to create more featured units of work.
This is related to the last point, I went with a different approach for the controller keeping it a bit closer to the raw matter protocol, the good thing here is that I don't have to write switch statements for every possible option, but it does mean that we are also limited to exactly whats in the Matter spec, Given that matter has getting on for 100 clusters, each with 10-20 attrubutes and commands it would be a huge task to implement everything, the Brigde nodes were a couple of months work (on and off) and we don't have full coverage of all device types in the spec (maybe 30%) The controller being "dumb" means that it will work with ANY matter device that meets the spec, and future updates just require an update to the underlying library with the new spec.
The inputs for the bridge nodes are what in Matter is known as "local control" think the physical button on the lamp or dial on the thermostat, and totally outside of the Matter spec itself, so I had a little more freedom here. Equally that on/off node was the first one I wrote and adding in all the different options took a while even for the simple node, the later ones were a bit more restrictive!
Tricky, in this instance I would think that just a straight text entry in the Commissioning node for the code because there would be no real need to have this info held elsewhere. The label may be held elsewhere (plus it can be changed) so the drop down options would only be required for this
I did wonder about that as each device has different clusters and each cluster has different attributes (although I hope that a cluster has the same attributes on all relevant devices). I will probably use link calls rather than sub-flows
Understood, as I mentioned as long as I am aware this is not a problem. The only thing I have noticed is that NR can get a bit temperamental if an invalid entry is input. Is there a list of valid entries in the Matter spec somewhere?
One other point - probably a Matter issue - when I set the Read Attribute node the read OnOff cluster onTime attribute I only ever get 0.
I have tried a few other nodes. The Write Attribute & Event nodes do not apply to the device I have so I have not tried them. The Read Attribute is limited in that you can only get 1 cluster / attribute per node (see above for reason for this) but it does enable you to - for example - get the OnOff state of a switch.
The Subscribe node is magic (although again limited as above). For example, it lets me know when my device has been switch On or Off from any source, Alexa, Google or Node-RED.
Ah ok so thats the basic auth for your node-red editor, I guess thats because the editor is making a call to an API in the nodes to get the lists of devices/clusters/commands, but I'm not sure why its prompting you for auth only on the command node, is it a particular refresh button that triggers it? Maybe I've got a slightly different URL format for one of thosse.
Tricky, in this instance I would think that just a straight text entry in the Commissioning node for the code because there would be no real need to have this info held elsewhere. The label may be held elsewhere (plus it can be changed) so the drop down options would only be required for this
The idea of making the values an input is that you may want to create your own commissioning UI with dashboard or similar, or to be able to pass the input from a QR code scanner with the pairing code.
Also my long term plan for being able to commission devices without needing another Matter controller first will likely mean a mobile app to handle the BLE stuff, so then being able to pass a pairing code to the controller via an API will be needed.
I'll do some experiements with a form including a submit button inside the node editor for commisioning too so you don't even have to exectute the flow.
I did wonder about that as each device has different clusters and each cluster has different attributes (although I hope that a cluster has the same attributes on all relevant devices). I will probably use link calls rather than sub-flows
Its not quite that simple, clusters have a defined set of attributes yes, but some values are mandatory and others are optional or depend on the feature-set of the device.
Understood, as I mentioned as long as I am aware this is not a problem. The only thing I have noticed is that NR can get a bit temperamental if an invalid entry is input. Is there a list of valid entries in the Matter spec somewhere?
the bottom of the command node has a small yellow text area with a refresh button, this should give you a sort of mangled templated JSON for what parameters are expected on a command, You can also download all the matter specs from csa-iot.org (its behind an email form but they don't spam you at all!) however there's several docs running to 100's of pages, you'd mostly want to look at the Application Cluster Spec document.
This seems about right. the OnTime attribute is defined in S.1.5.6.4 of the Application Cluster Specification as
I am just playing at the moment because I mostly use zigbee devices (so I am making good use of the Bridge nodes) but these nodes may persuade me to use more physical Matter devices. I would like to thank you again for both the virtual & physical Matter device nodes. Great work on the updates.
Hadn't even thought of that, good call.
I misunderstood what it represented. A shame because actual On time would have been a handy attribute to monitor.
I have actually found a use for the Write attribute node, setting the startupOnOff attribute. However I am having some problems. The param suggestion is
so I tried that in msg.payload and got an error message Error: (ValidationDatatypeMismatchError/128) Expected number, got object.
So I tried 0 - 2 (as per the spec for StartUpOnOffEnum) and that did not give an error. I also tried msg.payload = null (that also appeared to be accepted - Power outage memory)
But when I tried to Read the attribute I got another error TypeError: Cannot convert undefined or null to object. So I do not know if it worked.
Yes I'm not totally happy with the way the suggestions are presented yet but I'm pulling the data out of the Matter library as there's far to many to manually edit.
Generally an attribute will be a single value not an object, in this case it should be a Number 0,1 or 2.
In this case make sure that you're setting the typed input to a number not a string as well (see screenshot.
I've just tested it here with a Matter light bulb, I can set the value to 0 or 1 but on this device it doesn't seem to make any difference to the behaviour, unfortunatly a lot of matter devices while they implement the data model in the specifcation don't actually let these values affect how the hardware behaves, In the most part the testing just checks for spec compliance not user experience
