Reacting to central config node change

Developing Nodes
1

Can anybody explain or clarify how to create a node that uses a central config node for a global config? What I'm trying do is this:

  1. Open regular node.
  2. Open parent config node.
  3. Update config.
  4. Close config node.
  5. Apply any changes to regular node UI elements.

I've been able to create an event listener that reacts to the changes when the config node is closed. The problem is that a new listener is created every time the config node is opened leading towards a big mess. Additionally, a new change listener is created for every other "regular node" that uses the central config. I end up with dozens of listeners all firing for any change.

Questions are: how many listeners do I need? Just one that can be utilized in all nodes? Or one per node? And how do I properly close a listener so they don't keep piling up? I see the in the docs a note on how to close a listener but it doesn't seem to work.

Thanks,
Gregg

2

Can you describe your scenario a bit more?

It sounds like you want to modify a node's configuration in the editor based on changes to a config node? That isn't a typical use case for config nodes, so it would be helpful to understand a bit more about your scenario. There might be a better approach available.

3

Look at the source code for MQTT nodes node. Changing the MQTT config from v3.1 to v5 doesn't change any settings on the regular MQTT node (as Nick suggests) but it does change the available options visible on the MQTT node. Does that suit your requirements?

4

So, here are details. And thanks for the responses!

  1. Config node holds list of devices. Each device has a guid which is what the other nodes use for reference.
  2. Each device also has a label. The labels of each device is shown in a dropdown selector on the other nodes that use the config node.
  3. When I change device label in the config node and close it, the changes take and the config is marked as updated. Listener fires.
  4. This is the point that where I want the dropdown to repopulate and show all the new labels. This is the point of issue.
  5. Note that if I then close the regular node, even if I don't "Deploy", opening it again will redraw it with the new values for all the labels. I'm trying to avoid this unnecessary close/reopen.

When the listener fires, I can see all the new values when I dump the return values to console. I want to use the values and can access them but another issue is that the listeners never seem to close. I try closing them via the HTML file under "oneditcancel" and "oneditsave" but it doesn't work. I think if I got rid of these runaway numbers of listeners I would be ok but I'm not sure. I guess I want a central listener that can respond to the config node change but be accessed on every node that uses it as its parent.

Does that explain it? I know it's a lot.

Thanks!intel

5

@Vahdettin

In essence: When the config node closes, the config node selector ui element in the regular node changes. Listening to this event, you may then update your other ui elements.

From the source of the MQTT nodes:

            $("#node-input-broker").on("change",function(d){
                updateVisibility();
            });
2 Likes
6

Thanks. I can certainly do it via a standard jQuery event but does this API not perform the same function in the Node-RED context?

https://nodered.org/docs/api/ui/events/

Thanks!

7

I believe that the closing of the config node edit panel causes a RED.events change event, you'd have to try to confirm. But you can only listen for all change events and then you'd have to filter for changes on the specific config node you're attached to, and then reach into the other node to retrieve the data.

An alternative I would consider is to create a separate connection between the two nodes. Specifically, expose a "onChange" registration method on the config node, have the regular node register its handler using onChange, and then have the config node trigger the handlers when it changes, passing the relevant data. This way you have a clearly defined interface that doesn't depend on reaching into the fields or HTML elements of other nodes.

8

The node-red events are purely for specific events occurring inside node-red. They can, of course be listened to and used in your own nodes but they really only cover things happening at the node-red level.

If you want to handle changes within your own node's configuration in the Editor, the example that Ralph gave using jQuery is the best to use. As is noted in the node-red documentation on custom nodes. jQuery gives you access to what is happening NOW in your config panel, the node-red events tell you what is happening to node-red.

9

Thanks for all the useful info. It seems that a basic jQuery listener is the best way to go.

10

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