Disable via msg.enabled error messages

[MadTooler]

I am enabling and disabling SVG nodes that are being used as buttons to control gui options.

Sending msg.enabled false/true with msg.payload either empty, 0, or deleted results in error A msg.payload is required

Is this the intended response?

Is there a cleaner enabled approach that is more appropriate?

Testing with sending enabled along with a payload with a string that does not match an expected command (tried "none") expectedly errors with The specified msg.topic is not supported

Thank you.

[bartbutenaers]

Hi @MadTooler, No - as far as I can remember - I have never added enabling/disabling support for the svg node. So you mean that all input events need to be ignored if the svg node is disabled? If so that indeed makes sense. I don't think there is a decent workaround. You could inject a message to disable or enable all events, but that is not a nice solution.

So normally I would immediately add this option. But I have not done Node-RED developments the last months due to nearly no free time. Moreover the official Node-RED dashboard 2.0 is arriving in the near future (see here) so it is not very useful anymore to spend my time on ui nodes for the old dashboard...

Bart

[MadTooler]

Thanks for the response, @bartbutenaers.

I understand lack of available time. I appreciate very much what you have already provided with all you have made available to others with your Node_RED contributions!

So you mean that all input events need to be ignored if the svg node is disabled?

Well, sort of what I was originally intending, but the way it is actually working is better. Right now, sending the msg.enabled=false fades the node in the dashboard and only "disables" the ability of the user to interact with it in the gui, which is exactly what I need. I can still send other inputs and it functions normally while disabled. The only downside is the warnings or alerts from the svg node, when I send the msg.enabled, that it didn't also get a msg.payload, or it didn't like my attempt at a null payload.

I could simply ignore the alerts filling up the debug. However, I would prefer to pacify the node and send it a "null" msg.payload of some sort, along with the msg.enabled, if there is a format of it that won't result in any change to what is currently displayed in the svg node. Otherwise, it is doing what I really need now.

Regarding dashboard 2.0, from what I can see, it is still very much under pre-release development with limited nodes. I am working on a pretty involved motion controller interface that is heavily using your svg nodes. From what I could tell, it looks like the svg nodes will not be compatible with dashboard 2. Is that accurate?

Thanks again.

[bartbutenaers]

The only downside is the warnings or alerts

Ok thanks for the clarification!!
To be honest, I was not aware that the dashboard does enabling/disabling out of the box already. Since it was only a small fix, I have pushed it to this Github repository. You can install and test it, by installing the fix from Github by executing following command (from within your .node-red folder!!):

npm install bartbutenaers/node-red-contrib-ui-svg

Note that you should have git installed in order to be able to execute this command. As soon as it fits your need, I will publish it on npm and in the Node-RED pallette.

I have also added a section in the readme page (see here) with an example flow and demo animation.

Would be nice if you could test this, and provide me with feedback...

Regarding dashboard 2.0, from what I can see, it is still very much under pre-release development with limited nodes

Yes true, but since their announcement on Discourse 3 weeks ago, they made already quite a lot of progress. So I would certainly keep an eye on this if I were you...

it looks like the svg nodes will not be compatible with dashboard 2.

Custom ui nodes are currently not supported yet in dashboard V2, but it will be added in the near future. But indeed it won't be a simple migration for the svg node, for a couple of reasons:

1. The old dashboard is based on AngularJs, while the new dashboard is based on Vue.js
2. The old dashboard has a series of parameters to control e.g. the msg behaviour, and these won't (hopefully) not all available in the new dashboard.
3. Based on a lot of feedback I received in the past for this svg node, I have requested to store the state on the server-side (instead of in the clients only). This will however have a large impact on this node in V2.
4. As you can see in my previous request they propose to have the svg node as a standard ui node in V2, i.e. not my personal contribution anymore. Which is fine for me, that means it probably will get a completely other look and feel.
5. Due to the huge amount of feature requests I received in the past, this svg node has become a little monster. So a lot of refactoring might be required to reduce the codebase again.

So it will probably need to be implemented again from scratch. And that will require a lot of time, which I don't have unfortunately at the moment.

[MadTooler]

That was surprising! I didn't expect you to have the spare time. I so very much appreciate it!

So far so good. I even used your terminal plugin from within node-red IDE to install the npm. I did have to restart after to get it rolling. FYI this is on an rpi 4b 64bit raspberry OS.

Would be nice if you could test this, and provide me with feedback...

per the nice demo you made and the notes there...

Note that all other msg properties (like topic, payload, ...) will be ignored in this case, so no command is being used (since this is a standard Node-RED dashboard feature).

It is working as shown, which is perfect, with the exception to the description being a bit fuzzy about other msg properties being ignored. It appears the other msg properties are completely ignored when the msg.enabled=false is present in the complete payload, but following messages that may arrive while it is still disabled are received and processed. Again, EXACTLY what I need for my application where the operator cannot click on the svg but other processes may still update the svg. I don't know if others could find the need to fully ignore all messages until it receives msg.enabled=true, but that may be dealt with under dashboard 2.0 if the desire becomes real ;)

Thank you for the further info regarding the next gen dashboard. I am glad to hear the developers recognize the power and usefulness of your svg node and would like to find a path to include those capabilities there too.

Many thanks!

[bartbutenaers]

You are welcome! Yes good point.
But in the dashboard readme I see this behaviour:

Any widget can be disabled by passing in a msg.enabled property set to false;. Note: this doesn't stop the widget receiving messages but does stop inputs being active and does re-style the widget.

I will add that to my new documentation section tomorrow.

[MadTooler]

But in the dashboard readme I see this behaviour:

An y widget can be disabled by passing in a msg.enabled property set to false;. Note: this doesn't stop the widget receiving messages but does stop inputs being active and does re-style the widget.

Not sure what to make of the suggested dashboard behavior. I did not check all message types since your node can do sooooo many things. What I did observe is while disabled in the dashboard, it still receives msg.payload, when not along with msg.enabled in same message, and both processed my changes to the svg and pinged back an error when I sent it a garbage string as the msg.payload.

If you need me to provide any sample flows to illustrate, let me know.

Have a good one.

[bartbutenaers]

I made two small changes:

• I only skip the msg (containing the enabled property) from further processing if both payload and topic don't exist.
• I have changed the readme a bit to indicate that input messages will be processed while the node is disabled.

You are the first one reporting this issue in all the years that this node exists, so - keeping in mind the old dashboard is end of life already quite some time - it won't be a life threatening feature anyway ;-)

Version 2.3.2 is now available in the palette:

Thanks for the extensive feedback!