Nodered, refactoring code and autocompletion

Hello everyone,

I'm relatively new to nodered, and using it mainly for my home automation. I already learned a lot using this forum on another subject. I now have a question regarding refactoring code and autocompletions within nodered.

I'm at the point of having variables defined as flow variables in a flow that, in the end, I'd need to access from another flow. This should imply to have used my variables as global instead of flow.

I know that I can make searches on the var names for example and nodered returns all the instances where the result is found but it implies making manual changes on every instance.

  1. Is there an elegant way to perform such changes quite automatically, like for each instance of 'myvar' replace all the flow.set or flow.get by global.get/set? Including in all nodes like switch nodes or so?

  2. Is the option of modifying the flows.json file through an editor acceptable?

  3. Is there also a possibility for the editor to propose some autocompletion based on context variables names?

Thanks for your help and suggestions.

Hi,

For 3, it's done :wink: Add auto-complete to flow/global typedInput types by knolleary · Pull Request #4480 · node-red/node-red · GitHub

Be there soon :yum:

1 Like

Option 2 might be the way…

  1. Export all flows from the editor
  2. Find/Replace (in the file that gets exported)
  3. Re-import (you will have to remove old duplicates)

As said by @GogoVega version 3 does support auto complete, but that’s still in oven

Or you edit the flows.json file directly and restart NR :nerd_face:

You will have to make sure nothing is written to or modifies the flows file if going down that route.

I don’t know if something gets written whilst restarting :man_shrugging:

Modifying the flows file whilst it’s running seems risky

This file is only modified when deploying (plus a difference), so you can modify it while NR is running without problem. Of course you can stop it, modify the file then restart the instance

I think you are confusing with the context files Marcus :grin:

No, I’m referring to making changes to the flows file that is in use by Node RED directly.

Personally I would be careful in doing so :woozy_face:

Yes, since the file is only loaded on Node-RED start, you can do this. Though the Editor might toss you a mr angry message. :slight_smile:

Oh so very YES. :rofl: Make sure you have a copy of the file. I've done it on occasion and yes, on occasion messed it up. :confounded:

2 Likes

You’re all crazy!! :fearful:

Making changes to the live flows file by hand!
As long as caution is practiced, I suppose I’m out numbered :stuck_out_tongue_closed_eyes:

1 Like

Makes sense :sweat_smile:

1 Like

If you are moving towards more global variables, I suspect that you may be misunderstanding the nature of flow based programming. Instead of saving data as variables, you should try to attach it to each message as it passes through the flow.

Here is one way to tackle a simple task in Node-red using small flows to populate context variables.

And an alternate way attaching calculated data to the message as it travels through the flow:

Of course you sometimes want to combine data from multiple inputs and context variables can help here, but again it's generally better if possible to literally combine the messages with a join node.

Sorry if that's not a good explanation!

It's always interesting thanks :wink:

To illustrate, I have a flow handling my solar system and providing a calculated value about import/export of power from/to the network
I also have another flow managing data from my water heater and it's attached solar router.
Initially I included the logic nodes driving my solar router directly within the heater flow.

But now I want to create a new flow, dedicated to managing loads, that will combine data available from different flows to control many loads, like water heater, EV charger etc. That's why some vars that were local to water heater flow for example must now be accessible from another flow.

I thought about implementing a solution using message flow. linkIn+function node (pulling local context var and returning that to payload )+linkOut. From another flow I can call this with a link call, pass the var name in the topic and get my value in the msg.payload.

msg.payload=flow.get(msg.topic);
return msg;

But I wonder it this is appropriate as it seems to be a kind of workaround of the local/global structure of the variables. Pro is that it's probably faster and simpler to implement than refactoring all my code manually (and risking to miss an instance of my variable somewhere), cons is that it adds another mechanism to get a var through flows, and such a trick has to be copied in each flow where I have to pull some data.

Yeah i do a horses for courses approach on this - if i am calculating information and then using the calculated result in another flow (which may operate on a different timeframe/basis) then i will usually use Global variables. I also put some thought into horizontal scaling of my system - either through sheer ease of use or for performance reasons.

If i left a single VM running all my stuff i would have approx 80 flows which i find is too much to manage (from my brain perspective) - i prefer to hive flows off to other Virtual machines when i get about 30 or so - i then try and group flows that make sense on the same VM rather than having everything communicating through MQTT etc.

So i have a VM which is dedicated to all the energy stuff in the house - solar, batteries, power monitoring etc.

I have another one that is dedicated to all the automation stuff - lights, media, swimming pool etc etc

I do pass a lot of information as objects within messages also.

I sometimes wonder what the overhead of large message objects are as compared to accessing an Object/array in Global memory.

Either way as i run my NR under a VM i am not fussed as i can always throw more hardware at it.

Craig

2 Likes