Getter/Setter for global variables (new node)

[Julian Knight]

Hi all,

Just wanted to say that I have created a new node that gets or sets a global variable without needing to resort to a function node.

This is a quick and dirty solution pending future changes in Node-Red. It should work but it hasn't been extensively tested as yet. Because of this, I've not published it to NPM but you can install directly from github and the instructions are in the readme.

https://github.com/TotallyInformation/node-red-contrib-globalgetset

This is something I find myself needing to do rather a lot and I don't like creating a function node to do it as they can be prone to errors (due to my poor coding skills).

Regards, Julian.

[Dave C-J]

Julian,

when Nick pointed out we were working on this and we were discussing it in another thread... what is the point of pushing this out there apart from trying to annoy ?

[Julian Knight]

Because I needed it and it may be of use to others. As I understand it from Nick, the next update is not due for another month & there is a lot I can do between now and then. Nor do I know whether this is actually something that will make it into the next release. Nick has talked about extending context and context.global variables into the change and switch nodes but I'm not sure anything else was mentioned. This node has wider uses and is very simple.

I've not published it as such, github is used for backup of my source code and I see no need to keep this secret, it may help others understand some of the inner workings of nodes or it can be ignored. I've made it clear that it may get overtaken by core coding. I'll not be publishing to npm until it is clear whether or not it remains useful after the next NR update. If it doesn't, I'll update the readme to say so & keep it as a reference. Still useful for a couple of hours of work.

I'm not trying to annoy though it seems I may be anyway, I simply want to get on with things. I've been struggling for a while trying to find the best and simplest way to integrate global variables into the flow as another storage medium without needing to write function nodes everywhere. The conversation yesterday afternoon finally coalesced as set of thoughts. I can now easily move on with some more complex flows that will benefit from this simple way of integrating global variables.

[Nicholas O'Leary]

Out of interest, what wider uses does it have beyond getting/setting values from global context? When the Change node becomes context aware, that's exactly what you'll be able to do with it, without having to introduce another node to the palette. The change nodes sole purpose is to get/set values. If you have other use cases in mind, it would be good to understand them.

In terms of the future if this node, the way it accesses the global context directly is not a supported api and may well break - part of the work around context is to provide an api that any node can use, rather than this direct access method.

The next release will not include these changes, but they are next on the list for the following release.

By all means, go with your node if it helps you. I'm just wary of promoting it as the way to do this given the imminent changes. We're the ones who have to support users who try this stuff out.

Nick

--
http://nodered.org
---
You received this message because you are subscribed to the Google Groups "Node-RED" group.
To unsubscribe from this group and stop receiving emails from it, send an email to node-red+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Julian Knight]

I'm getting a little frustrated with the negativity here. As and when the API becomes available I will either kill this node off or update it, this is normal stuff, people don't stop creating just because some future update will require change!

How long will it be until the updates happen anyway? I think it will have been 3 months from the current to the next update, will it be another 3 months? 6 months to wait for such a simple but useful tool is a very long time to wait. That's why we like open source, so people are free to do what they want and are not tied down to what a vendor wants. I'm not criticising release schedules, simply pointing out that this is one of the benefits (to users) of open source.

I've made it clear both in my post and in the readme and by not publishing to NPM that this may be quickly overtaken by other events. So I'm not trying to promote this as some kind of alternative beyond what it is, a short term, quick and dirty, useful node that makes Node-Red a bit easier to use for here and now.

The uses it has are that I can now quickly take any value from an incoming msg and STORE it in memory just like we already can with MongoDB, Files, REDIS, SQlite, MySQL, ....  I can also just as easily recover it from the store and insert it into the msg flow. And I don't need a function node to do this. With any of the other stores, I have to get the information from the store if more complex ways - formulating queries and so on, with a memory store I don't need to do that. Quick, simple, easy.

Examples:

• I can have a very simple flow to listen for MQTT messages and update a global variable using SET.
• I can grab the latest value for something in memory and pass it to the next message in the flow (GET).
  I have a great many uses for this. For example, I pre-set the internal and external ports and IP addresses for my MQTT broker and websocket server in the global variables using the settings file on startup. I can now retrieve these and pass them directly out to a template node without the JavaScript function node I needed previously. Better still, I can wrap far better checks around the code than I'd every probably bother with when having to write a function node for every retrieval.
  Note that I don't need either a switch nor a "change" in this case, just a GET - yes I realise that some future version of "change" could be made to do this as well though I personally find that terminology confusing since I'm not really thinking about changing something only storing/retrieving it. But at the moment, a function is the only game in town and that requires me to carefully write the appropriate code and checks again and again.
• I want an present/absent value kept in memory and updated by various different flows. I want let's say light switch flows to do different things depending on whether the house is occupied or not. With this node, it is now easy to recover the value into the msg and then use switch or change nodes accordingly. I'll probably be able to do this with your future changes but not for months yet.
  

I think there are others but the red wine calls so it's time to tune out for a bit.

[Nicholas O'Leary]

Julian,

I apologise for the negativity - it simply felt you were not listening to what we were saying and forging ahead regardless. Yes open-source means you are free to do what you want. Equally, it is about collaborating and working together - at least, that's the approach I aspire to. We have previously seen instances where people come up with solutions to problems that go against our best advice and then start promoting them to new users - this just causes those of us who have to deal with supporting these users more headaches. If your node's are overtaken by events, then fine we can all move on - anyone who has picked them up will have to figure out how to do that.

I agree it is a very useful feature to have which is why we will get it done. The 'next' release has been delayed for reasons I'll get into in a new thread shortly. The following release I want to get done much quicker to ease the log-jam of features we currently have.

I think all of your use cases are absolutely valid. But they do all boil down to the ability to get/set a value from some convenient store. Do you think once the Change node is able to get/set values from context that would satisfy your needs? Or is there something else here?

Enjoy your wine.

Nick

 

[Dave C-J]

Julian,

And apologies from me also for snapping earlier. It was just putting it on a new thread made it look like an "announcement" rather than a "by the way my code is here" comment to the existing discussion. And having all the npm ready files in place made it look like a done deal.

Personally I think the template node could also make a case to have "direct access" to global, after all it is just a different kind of change node, and could make assembling web/data fragments much easier. (IMHO)

Anyway, apologies again.

PS. Trust me. Nick is as frustrated as the rest of us about the delays this i18n malarky is causing but hopefully there is light at the end of the tunnel.

[Nicholas O'Leary]

Oh yes, I always forget to include the Template node when I talk about the context stuff... but don't worry, it is on the list. We'll review all the core nodes to see how they may, or may not, benefit from more direct access to context.

Nick

--

[Julian Knight]

If the change node is able to set context, global and msg then I think it will do what I need it too.

My main concern (if I can call it that) I guess was that you are overloading the "change" node with more capabilities and you've - rightly probably - called me and others out for doing that with other ideas - is that the right approach? Not for me to say I'm sure but I remember trying to get my head around what the change node actually meant when getting started. In hindsight, perhaps it would be better to have separate get/set and change - not sure? Still, that could doubtless be dealt with via some decent help and documentation.

In terms of the template node - it would be nice to have access to global and msg, not sure context as such would be meaningful since context is about retaining state between executions. In any case, you will be able to achieve what is needed by a change node feeding into the msg so it isn't essential.

Anyway, now I can see a little more clearly what you are proposing. I wonder actually, whether it wouldn't be a good idea to spend a bit more time on documenting upcoming changes? I know that is just more overheads but it might help others to see where things are going. At present all we see is what drips into this forum and the limitations of the format mean it is very hard to keep everything straight. A timeline maybe? Is there anything we as a community can do to help? If there were some specific bits of documentation for example you wanted improving, I'm sure there are plenty of people who would chip in. Lack of documentation is the killer of some otherwise great open source projects I've always found.

BTW Dave, the npm elements in github are because I copied my previous release into a new folder and started by just changing the name. I didn't want to leave anything with the old name just in case I did ever want to publish it - easier to do it now and do it once. It also means that people (including myself) can install direct from github should they choose to.

Oh and the wine was good thanks but I need to work tomorrow so signing off now.

[al...@tzapu.com]

hi all

looking at the latest node-red it seems the change node still can;t set global vars. is there any kind of news realted to this?

better off using the node by Julian in the interim?

cheers

[Nicholas O'Leary]

Hi Alex,

if you take a look at our trello board (https://trello.com/b/R0O3CSrI/node-red-whiteboard) you'll see "Make Context a more widely used concept" is in the 'Current' column. Which is another way of saying it's what I'm working on at the moment. There are a few prerequisite pieces needed that may mean it doesn't make the cut for the 0.12 release, but it is coming.

In the meantime, you can use a Function node to access context.

Nick

[Alex]

HI,

Thanks for that, good to know.

Love the board. Is there any place where the new features and the ones in progress are being discussed/described?

Cheers

Alex

You received this message because you are subscribed to a topic in the Google Groups "Node-RED" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/node-red/YOs4F_Jcajo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to node-red+u...@googlegroups.com.

[Nicholas O'Leary]

A combination of that Trello board, issues on github (usually linked from the relevant trello card) and this mailing list.

Nick

[Julian Knight]

Trello is great! I've introduced it for my team at work and it is helping us manage some very complex workloads.

[Patrick Frey]

hi Julian,

I want to use your setter/getter node but there's something missing ( I guess).
There is a important use case : I want to store a value ( where the value is the payload) to a var (stored  is the topic of the message ). For example after a mqtt node to store the last value of every sensor.
 Can this node work in this way? If yes , how set the set parameters to do that?
Thanks a lot.
Patrick

[Patrick Frey]

hello Julian

I want to use the getter /setter node in a flow.
How do you set the parameters if you want to store/retreive something in which the var name  is the topic and the value is the payload.

I have tried many combinations but I can't find out the right parameters..
Thanks you a lot.

Patrick

Le lundi 25 mai 2015 17:53:11 UTC+2, Julian Knight a écrit :

[Julian Knight]

Hi patrick. I'm not near my NR setup just now so I can't give you exact details.

However, you can certainly store msg.topic into a variable. I think you can do the whole msg too if you want. Only the global var settings work as I couldn't find a way to do the context part, that is too closely integrated to the function node. This will all change with v0.12 when the extended global and context variables are introduced.

I'm out and about today but if you post a screen shot, I'll respond tonight.

[Patrick Frey]

Hijulian

Here's the wanted screen shot. thanks

[Julian Knight]

So with the settings you have, once the node has received a msg, msg.payload will be written to the variable "temporary". You can check that in a function node by doing something like:

node.warn(context.global.temporary);

You would see the content of the variable in the debug area.

Alternatively, you could add a second get/set node and use the get instead of set mode and feed the output to a debug node.

Does that help at all?

[Patrick Frey]

Hi Julian,
Thanks for your explanations, but I don't know if you unterstand well what I want to do:
I whant to use your get/setter to hold  (in memory ) the last value of my sensors ( for example one sensor could be BATHROOM/TEMP = 21). IN Node red "Bathroom/temp" is the topic and the values is the payload. So I want to use a setter node to store these values in memory ( The setter must get the var name from the topic of the msg and store the pair topic/payload into memory). The getter must have the variable name to retreive in the topic and the output msg of the getter has it's payload set with the value of this variable( topic).

Is it possible to set the parameters to do this?
Thanks
Greetings

[Nicholas O'Leary]

Hi Patrick,

I don't believe Julian's node allows you to dynamically set the property name.

You can do this with a Function node:

    context.global[msg.topic] = msg.payload;
    return msg.payload;

Regards,

Nick

--

[Julian Knight]

Ah, I'm being slow again. Thanks for the clarification. That was a use case I hadn't thought of for some reason.

Let me have a think and see if I can change it to accommodate as that sounds like a useful enhancement.

As Nick say's and as I pointed out I think at the start, you can certainly use a function node if you are happy with JavaScript. Of course, the purpose of my node was to remove the need for writing JavaScript so I'd like to fix my node.

[Dave C-J]

of course - if we can tempt / lure / cajole / frustrate people into wanting to fix / enhance it by writing a couple of lines of code then who knows what they may do next ? They may end up writing their own nodes :-) 

[Julian Knight]

I've added an enhancement request to Github:

https://github.com/TotallyInformation/node-red-contrib-globalgetset/issues/1

I'll work on it as soon as I can and let you know.

[Julian Knight]

Hi Patrick,

Many thanks for prompting me to revisit this node.

I've now re-written it. It is much simpler to use now and accommodates your use case by allowing either/or of the input and output variable names to be picked up from the input msg.topic.

I've done some basic testing and it seems OK to me, I'd be grateful if you could have a go with the new version and let me know if there are any issues. If you have a github account, you can raise issues directly in the repo.

I've also published this version on npm as it seems to me to now be useful enough for general use. Of course, I will still need to update it when context and global are more widely exposed in a future NR release and I've noted that in the readme and the help.

[Zenofmud]

FYI the github link at https://www.npmjs.com/package/node-red-contrib-global gets a 404. the link is:

github.com/totallyinformation/node-red-contrib-global

when it should be (I think):

github.com/totallyinformation/node-red-contrib-globalgetset

[Julian Knight]

Blast! Looks like I messed up the npm publish. 

Thanks for letting me know, I will fix it. There are too many places to define the name! Easy to get them out of step.

[Julian Knight]

Fixed now. Oddly the README.md is not displaying in npmjs though it is certainly there and works fine in github. Annoying.

[Dominic Böhler]

The README.md isn't shown on npmjs because you've specified readme in package.json.

 Just omit key/value pair.