Update DebugNode to full NR capabilities

[ralphwetzel]

This is a small (but capable) change to the DebugNode: It emits the incoming msg back to the plugin. The input flag tells the plugin to feed this msg into the dedicated node - as if the flow would run in its standard environment.

This idea has some limitations - of course.

For the DebugNode it yet offers several advantages:

• There's no need for the MCU to handle all the different aspects that are managed in standard NR DebugNode; the this.#toStatus code e.g. is obsolete then.
• There's no need to flag jsonata as NotImplemented. It's not present on the MCU - but in the editor. Thus it should be enough to log a compile time info stating this detail.
• Less Code on the MCU.
• Full capabilities at (almost) no effort - in the NR editor.

That said, the output of the DebugNode could be further optimized to meet the demands of xsbug - without the need to respect NR standard requirements.

Additionally I would vote to consider a dedicated communication channel (back to the editor) as alternative to the trace interface. There's currently a lot of noise in the sidebar due to all these messages sent...

[phoddie]

I'm not sure it is correct to remove the onStatus support. The status update not is only for the Node-RED editor. Any Status node can also receive the updated status. At least that is my understanding.

[phoddie]

@ralphwetzel – any further thoughts on this?

[ralphwetzel]

Well... closing this PR was not intended.

[ralphwetzel]

This done: I've reconsidered some stuff regarding this PR!

First I checked the original code. This lead to two relevant changes.

1. There's now a guard to prevent endless loops of StatusNode -> DebugNode (when this emits a status msg).
2. DebugNode now only sends a status msg, when its content is different from the last one.

Additionally, I've re-enabled the functionality to set the status of the DebugNode - based on your comment. To be consistent w/ the standard definitely is mandatory here.

I've kept (with a minor mod) the idea to send the input msg - as it is - back to the editor, to let the standard node process it as required.

We could develop this into a feature to be provided not only to the DebugNode, but as well to other nodes - on request. The concept:

• We define a property (function) in the node's definition, that is being called when flows.json is processed.
• This function returns a set of parameters to configure it's setup for mcu. This set (object) will be merged into the flows.json definition of the dedicated node.
• nodered2mcu validates these parameters, pre-processes the nodes as requested & then deletes the set from the config.

The first feature implemented like this could be - as stated - the functionality to send each msg back to the editor: The request will be defined via flows.json. nodered2mcu processes flows.json & on request prepends the trace.left command to the source of onMessage. Additional features could be added in the future in the same way, when they come up...

[phoddie]

Thanks for the updates. This looks good now. I'll merge it.

I've kept (with a minor mod) the idea to send the input msg - as it is - back to the editor, to let the standard node process it as required

That seems good.

We could develop this into a feature to be provided not only to the DebugNode, but as well to other nodes - on request. The concept...

I like the idea of providing better visibly into the runtime through the editor. That's great for debugging. I hesitate to add a very general purpose mechanism without a very specific use. Maybe we should wait until that comes into focus?