Global variables not retaining

[Glenn]

Can someone help not sure if its my setup. But every time I press deploy my global variables are getting deleted and I don't know why.

I just set them this way global.set(msg.payload, test) in a function
and do get with an inject node global.test

It didn't happen in v.0.17 but on v.0.18.2 it is happening.

Tried several times and I don't know what's causing it.

[Colin Law]

On 11 February 2018 at 03:19, Glenn <glo...@gmail.com> wrote:
> Can someone help not sure if its my setup. But every time I press deploy my
> global variables are getting deleted and I don't know why.
>
> I just set them this way global.set(msg.payload, test) in a function
> and do get with an inject node global.test

You have that syntax wrong, it should be
global.set("test", msg.payload)

>
> It didn't happen in v.0.17 but on v.0.18.2 it is happening.

I thought that global context have always got cleared if you do a
*full* deploy, but I make a point of never using globals so I am not
certain of that.

Colin

[Julian Knight]

I think that a full deploy MAY reset globals but they are sometimes retained. I've seen today that a flow variable was retained even with a full deploy.

[Glenn]

Not in front of my computer so might have it the wrong way round point I am trying to make is on v.17 it worked now even on part deploy not server reboot it is loosing the global context how do I stop it.

[Glenn]

Just tested and yes my first post was the wrong way round.

Full deploy does keep global variables using v.17.5 but v.18.2 does not.

Can anyone help?

[Colin Law]

On 11 February 2018 at 23:00, Julian Knight <j.kni...@gmail.com> wrote:
> I think that a full deploy MAY reset globals but they are sometimes
> retained. I've seen today that a flow variable was retained even with a full
> deploy.

Does that count as a bug? I would expect it be defined one way or the other.

Colin

>
> On Sunday, 11 February 2018 09:42:32 UTC, Colin Law wrote:
>>
>>
>> I thought that global context have always got cleared if you do a
>> *full* deploy, but I make a point of never using globals so I am not
>> certain of that.
>>
>> Colin
>

> --
> http://nodered.org
>
> Join us on Slack to continue the conversation: http://nodered.org/slack
> ---
> 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.
> To post to this group, send email to node...@googlegroups.com.
> Visit this group at https://groups.google.com/group/node-red.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/node-red/722c2f67-564a-4005-8ae1-ed352ef0b1d2%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

[Colin Law]

On 12 February 2018 at 04:32, Glenn <glo...@gmail.com> wrote:
> Not in front of my computer so might have it the wrong way round point I am
> trying to make is on v.17 it worked now even on part deploy not server
> reboot it is loosing the global context how do I stop it.

That depends on what you are using the variables for.
If the values are known in advance and do not change then you can set
them up in settings.js
If they reflect process state, such as switch positions, process
setpoints and so on then the option preferred by many is to use
retained variables in MQTT, then you know that on startup or redeploy
the current state will automatically be loaded into your flow and
dashboards.

Colin

[Julian Knight]

Yes, I set up some globals that may change a little from time to time using an inject on the 1st tab. You could also use MQTT with a retained msg in a similar way. Things that change very rarely go into a globals.js file that I require() in settings.js.

Problem is likely to go away by the time we get to v1.

[Julian Knight]

I'd have to say that resetting globals on full deploy would be what I would expect. But certainly worth checking in with Nick.

[Glenn]

The values are not known in advance
They come from websocket, mqtt and http connections which are fed into lots of flows.

MQTT is half a solution as you can't inject to get a mqtt value into a flow.

I use global variables for events that are timed.

[Colin Law]

All of those can easily be handled without using globals. For example here is a simple flow that will give you the latest mqtt value every 10 seconds, and will not trigger until there is valid data available thus avoiding the problem that is common with global variables that everywhere you use them you must allow for the fact that they may not have been initialised yet. Also it makes it clear where the data is used, whereas a reference to a global variable buried in a function node can be very opaque.

Colin

[{"id":"afb730bf.dd8d08","type":"inject","z":"85d85acc.3f1898","name":"","topic":"trigger","payload":"true","payloadType":"bool","repeat":"10","crontab":"","once":false,"onceDelay":0.1,"x":150,"y":140,"wires":[["5628da26.d06e14"]]},{"id":"4e7bf4bc.b2bb5c","type":"inject","z":"85d85acc.3f1898","name":"","topic":"some/topic/from/mqtt","payload":"7","payloadType":"num","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":180,"y":250,"wires":[["5628da26.d06e14"]]},{"id":"5628da26.d06e14","type":"join","z":"85d85acc.3f1898","name":"","mode":"custom","build":"object","property":"payload","propertyType":"msg","key":"topic","joiner":"\\n","joinerType":"str","accumulate":true,"timeout":"","count":"2","reduceRight":false,"reduceExp":"","reduceInit":"","reduceInitType":"","reduceFixup":"","x":390,"y":200,"wires":[["f694a614.6409c"]]},{"id":"f694a614.6409c","type":"debug","z":"85d85acc.3f1898","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","x":550,"y":200,"wires":[]},{"id":"4c36a5a4.5c6344","type":"inject","z":"85d85acc.3f1898","name":"","topic":"some/topic/from/mqtt","payload":"0","payloadType":"num","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":181,"y":281,"wires":[["5628da26.d06e14"]]},{"id":"a4e0c1d5.9251f8","type":"comment","z":"85d85acc.3f1898","name":"These simulate data from mqtt","info":"","x":149,"y":218,"wires":[]}]

 

--
http://nodered.org

Join us on Slack to continue the conversation: http://nodered.org/slack
---
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+unsubscribe@googlegroups.com.
To post to this group, send an email to node...@googlegroups.com.

Visit this group at https://groups.google.com/group/node-red.

To view this discussion on the web, visit https://groups.google.com/d/msgid/node-red/68bbc9f3-aa99-4ec3-a49f-ec8b37996fdd%40googlegroups.com.

[Walter Kraembring]

If they reflect process state, such as switch positions, process 
setpoints and so on then the option preferred by many is to use 
retained variables in MQTT, then you know that on startup or redeploy 
the current state will automatically be loaded into your flow and 
dashboards. 

There is for sure a need to keep current states of variables and also having them survive reboots, not only NR restarts. Personally I use a simple file on a usb stick where I just flush a "State" object (holding my many variables and current states) via a RBE node; means every change is then written to the file. At startup (on tab one), the file content is read once and pushed into my NR state mechanism.

For sure, I could instead use MQTT for this. But, to "survive" a NR machine reboot, the broker should be running on a separate machine (i.e. running on separate Pi in my case). Or you should use a broker in the cloud. Because when you restart the broker, I assume it will lose the data supposed to be retained??? Or not? Otherwise, how to solve it so the state data "survives" a reboot of the broker machine? Are we then anyway looking at a solution using persistence that can feed the broker with current state information at startup?

/Walter

[Colin Law]

When publishing a value to an MQTT broker there is a Retain flag available (for each topic posted). If this is set then the value is retained over re-boot and a soon as a client (an MQTT In node for example) connects all retained topics that match that specified in the In node will be sent out to the flow.  This provides the same functionality as you get with your file, but with much less effort.

Have a look at this very readable guide to see what MQTT is all about

https://www.hivemq.com/blog/mqtt-essentials-part-1-introducing-mqtt

Colin

 

[Julian Knight]

As Colin says, any decent broker retains the data to a simple file database and reloads on restart.

When running NR in a production environment on Linux, you would naturally use systemd to start all required services. One of the advantages of systemd is that you can make startups dependent on each other. So on my Pi for example, Node-RED startup is delayed until first the network and then the broker are up and running.

[Glenn]

The one thing you are all missing is that it worked on v0.17.

I'm not asking for a new feature I'm asking for something to be fixed that was working previously?

Thanks for the advice on MQTT I'm already using it but this is for something different. Do I need to post an issue on GitHub?

[Nick O'Leary]

Hi Glenn,

I have created a simple test case that injects a timestamp into global and then a second inject that retrieves that value and passes it to debug.

I have tested this flow in 0.17.5 and 0.18.3. At neither level do I see global being wiped when I do a full deploy. So I'm not sure what's happening with your case.

Could you try this flow to see how you get on?

[{"id":"b9a67f3b.d4b81","type":"inject","z":"14f3f7b.047a008","name":"","topic":"","payload":"","payloadType":"date","repeat":"","crontab":"","once":false,"x":180,"y":500,"wires":[["d7ee88b0.809db8"]]},{"id":"f999b110.184fc","type":"debug","z":"14f3f7b.047a008","name":"","active":true,"console":false,"complete":"true","x":330,"y":540,"wires":[]},{"id":"d7ee88b0.809db8","type":"change","z":"14f3f7b.047a008","name":"","rules":[{"t":"set","p":"test","pt":"global","to":"payload","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":360,"y":500,"wires":[[]]},{"id":"95356976.17d8c8","type":"inject","z":"14f3f7b.047a008","name":"","topic":"","payload":"test","payloadType":"global","repeat":"","crontab":"","once":false,"x":180,"y":540,"wires":[["f999b110.184fc"]]}]

--

http://nodered.org
 
Join us on Slack to continue the conversation: http://nodered.org/slack
---
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+unsubscribe@googlegroups.com.

To post to this group, send email to node...@googlegroups.com.

Visit this group at https://groups.google.com/group/node-red.

To view this discussion on the web, visit https://groups.google.com/d/msgid/node-red/54168711-984d-4da9-845a-3ac13f4708ba%40googlegroups.com.

[Glenn]

Thanks Nick.

Will test and respond back. Maybe something happened in my test environment

[Glenn]

On first glance it seems it's a problem with my test enviroment.

I think an uninstall and reinstall of node-red is in order. Will try that and report back.

I think it might be getting confused as it's using NVM and tries to run the wrong version of Node-Red