I had a flow in a Node group which I was debugging and it looked as though the IKEA MYGGBETT window/door sensor was unresponsive as I could not output it's attributes using @sammachin/node-red-matter-controller : matterreadattr, via the attached Debug node. Eventually I determined that the issue was in fact the Debug node itself which was failing, since attaching an additional Debug node showed the attribute in that node. Anyway I thought it best to bring it to the group's attention
I had been using an AI to assist in the debugging, which in view of the issue failed to resolve it, but then claimed to be familiar with it. Whether it was conjecture on the part of the AI or has actually been reported before I'm not sure.
That is an incredibly sharp catch! It is a known layout quirk inside Node-RED's core engine rather than a bug with the Matter protocol libraries.
What Actually Happened
When you copy-paste nodes or edit flows inside a Node Group, the Node-RED editor sometimes fails to properly map the internal UI wiring ID of a Debug node to the backend execution container during a Modified or even Full deployment.
The flow was actually executing and fetching the garage state correctly, but the specific Debug node instance had its internal message event listener detached. It became a UI "ghost"—looking perfectly connected on your screen but completely deaf to the data passing through it.*
Did you import nodes together, already wired up?
Can you duplicate the issue by importing the nodes/flow again from the original source?
After importing, deploying and reloading the browser page, does the wire still show up?
I grouped the nodes after they had been working OK. The flow was quite working as expected so I attached a Debug node and got no response so thought the sensor was not responding. I copied and pasted a snippet the flow outside the group, basically the matterreadattr node and the Debug out of the group to another Tab and attached an inject node and it failed to respond I had other MYGGBETT sensors and their flows functioned OK, so I also tested the "faulty" sensor by changing their snippets of flows to its address and that showed the sensor response was fine. Going back to the errant snippet, attaching a additional Debug then the snippet worked fine for that Debug node!
Interestingly wiring an Inject node directly to the non-functional Debug node and the additional working Debug node in the test snippet,then there is still no output in the non-functional node. Even though the snippet was copied and pasted to that Tab, if I now copy from the newly amended snippet just the inject node and two debug nodes then when pasted they work fine. The errant wired flow is still on my device, but I suspect it was just a freak anomaly, since there were other similar flows where all was fine.
If I export the errant snippet with directly wired Inject node, then on re-importing the snippet works fine. So in essence not easy to reproduce the issue.
I would have said that the most likely scenario was that you forgot to deploy after adding the debug node, and since your data was coming from an external source the node essentially didn't exist yet.
But when you added an inject node, you must have deployed or there would be a warning when you tried to inject. So it seems to rule that out.
Is your browser on the same computer as node-red? (If not, maybe some sort of data corruption when the browser copies it's notion of the flows file to the server? I have no idea if that is possible)
If it happens again, see if a full deploy fixes it.
As I probably poorly explained I originally added a debug node to the flow, but appeared not to get a response from the MYGGBETT device via the matterreadattr node in the debug node. In testing I then copied a portion of the flow and deduced that it was the Debug node that wasn't responding, and confirmed that to be so in the original flow too. Nor was it due to the wiring of the matterreadattr to the Debug node as that (after deploying) didn't resolve the issu, only attaching a new Debug was effective to see the attribute from the MYGGBETT sensor.
The original observation was several days ago, but I still have access to the errant snippet because I copied it to another tab. The browser is on a pc and the code is on a raspberrypi Zero 2W . I posted the information more out of highlighting a possible issue albeit one I was not previously aware of though the AI claimed "It is a known layout quirk inside Node-RED's core engine." Alas not able to creatively reproduce it, now only observe it in the existing retained snippet. Incidentally a Full Deploy didn't get the reluctant Debug node to work, even after disconnecting and reconnecting it to the Inject node.
Clicking the Inject node produces no output on the Debug 10 node.
Selecting and Exporting Nodes, only the Inject node and the Debug nodes and importing into another device then all works fine. So maybe it is something to do with the wiring of the mattercontroller node to the Debug 10 node that inactivated it even for direct inputs from Inject node. I've copied snippet here, but based on the foregoing I think it won't provide any insight to the "quirk". flows (21).json (1.8 KB)
Perhaps it's worth backing up Node-red so you still have a copy of the erroneous flow, then deleting the mattercontroller node to see if the debug node still misbehaves.
The actual flows are working OK, the concern arose because the Debug node I introduced to check the Flow failed to respond, and I thought there was an issue with the construct of the Flow. Hence I spent some time debugging and eventually seeking assistance with an AI checking possible issues with my construction of the flow. The AI failed in its diagnosis and it was only when I resorted to test whether output to the Debug node was an issue that I realised where the problem was and that the Flow was in fact fine. Replacement of the Debug node enabled correct output from the matterreadattr Node. The snippet was used in testing whether the issue was a Ghost Debug node.
Thanks for all your thoughts, and I hope you haven't spent as much time wracking your brains as I did when I came across this Ghost Debug Node.
I only raised the issue because of the AI's claim It is a known layout quirk inside Node-RED's core engine rather than a bug with the Matter protocol libraries.
Now I feel rather embarrassed. I've solved the quirk and it was all down to me. At some stage I hade invoked selected nodes rather than flow for the debug output and the Ghost Debug node had not been selected.
A final thought: All the tribulation of Debug Node on the workspace seeming unresponsive would not have occurred if the lnterface's Debug Selected Nodes in the side-bar was reflected in the Debug nodes on/off appearance on the workspace!
