Skip to main content

Context in Node-Red

It's probably not news to anyone willing to read documentation, but I was able to simplify a number of Node-Red flows recently after a primer on context.

In Node-Red, each function node has a self-contained context. Variables are local to that node and nothing is permanent. Unless you use a different context.

It is possible to set flow-level and global-level variables that can be used to store values, provide them to multiple other nodes without links, and give the illusion of memory to Node-Red.

Setting flow context uses simple syntax:

  • flow.set('name of the variable', 'value of the variable')
This new flow-level variable can be called anywhere in the same Flow tab. This is great for recording values that don't change every time the flow runs (e.g. a maximum recorded value), or need to be used in isolation from the pathway that generates them.

Calling the value is relatively simple as well:

  • var varName = flow.get('name of the variable')
To use the value, it makes sense to associate it to a local variable, but it's not necessary (though probably best practice to do so). The variable varName now has the value 'value of the variable', per the earlier example.

If you're not sure there will be a value associated to flow variable, you can declare a default initial value:
  • var varName = flow.get('name of the variable')||'initial value'

The same usage applies to global context (global.get, global.set), but these values exist throughout your Node-Red instance, allowing flows to share variables. I haven't needed this myself, but the power of cross-communication is clearly significant.

So, relatively simple, but it adds a lot flexibility and has helped me reduce the visual spaghetti that complex flows can become.
Labels:

Comments

Post a Comment

Popular posts from this blog

Return to the garden

After the mediocre performance of my vegetable garden last year (50% of the plants produced), winter is the perfect time to reflect on what went wrong. First, I started the project with a simple idea and absolutely zero experimentation. Second, the methods I chose did not work as I had hoped they would and my fall back was too simple. Third, minor tech troubles exacerbated the issues caused in the previous two steps. To address item one, I have started prepping my solution as of the end of November 2017 with an eye on March 2018. This is giving me time to test and refine as I go. On item two, I had to look at what worked and what didn't. The pump system worked well, but needs to be reconfigured to deliver water at the soil level; even a moderate drop of four inches resulted in erosion and root exposure over time. The planters were acceptable, but the height differential was tough to deal with. New planters will be needed. The right microcontroller was not available immedia...
Post a Comment
Read more

Flask, uWSGI, and NGINX - a saga

I have been creating a web page for my wife. It is a booking site for her business and is written in a combination of jquery, HTML, CSS, CouchDB, and python. For the python side of the house I am using Flask. This micro-framework works well for me and allowed me more freedom than I saw reading about Django. It has taken some time, but the app works well. It can retrieve bookings from CouchDB, display them in a calendar, and accept new bookings from a form on the same page. Jquery handles the calendar display, as well as the AJAX call to populate it. Flask handles the data collection from Couch, the data, and the writing of new data to Couch. For cleanliness, two repositories are used for bookings: one for confirmed bookings and one for requests that have not been reviewed. Another repository provides a client list, but is not accessible from the website. Then came the fun part. To serve a website with Flask, the internal web server is insufficient. You need additional tools. In my...
Post a Comment
Read more