Settings.js - question about "myDeviceName"

Alas I am in the fun stage of re-building a machine.

I set the computer's name in the settings.js file.

Extract:

    functionGlobalContext: {
        // os:require('os'),
        // jfive:require("johnny-five"),
        // j5board:require("johnny-five").Board({repl:false})
        myDeviceName: "MusicPi"
    },

Yet, when I load the page and look at contexts:

Screenshot from 2020-03-10 23-49-11

No name.

Yet, on other machines I see it.

Yes, I have restarted NR.

Screenshot from 2020-03-10 23-50-34

Sorry, but I just can't trust myself just now, and I kind of want to get to a point today (night) where I can be sure I have got a mile stone met.

  1. have you edited the right settings.js file? NR logs the full path to the file it is using when it starts up. Make sure you are editing the right file.

  2. Have you restarted NR since editing the settings file? Changes to the file are only picked up when NR starts.

I hope I have.

It is ~/.node-red/settings.js
Or,
/home/pi/.node-red/settings.js

I have just rebooted the machine.

No myDeviceName show in the context list.

Both NR 1.0.3
Top one not working. Second one is.

I really hope I am not missing any elephants.

I don't think this is to do with the problem, but this is seen when I start NR.

pi@MusicPi:~/.node-red$ node-red-start

Start Node-RED
 
Once Node-RED has started, point a browser at http://192.168.0.82:1880
On Pi Node-RED works better with the Firefox or Chrome browser
 
Use   node-red-stop                          to stop Node-RED
Use   node-red-start                         to start Node-RED again
Use   node-red-log                           to view the recent log output
Use   sudo systemctl enable nodered.service  to autostart Node-RED at every boot
Use   sudo systemctl disable nodered.service to disable autostart on boot
 
To find more nodes and example flows - go to http://flows.nodered.org
 
Starting as a systemd service.
10 Mar 23:56:39 - [info]
Welcome to Node-RED
===================
10 Mar 23:56:39 - [info] Node-RED version: v1.0.3
10 Mar 23:56:39 - [info] Node.js  version: v10.15.2
10 Mar 23:56:39 - [info] Linux 4.19.97-v7+ arm LE
10 Mar 23:56:43 - [info] Loading palette nodes
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named rpi_ws281x
10 Mar 23:56:48 - [warn] rpi-neopixels : rpi-gpio.errors.ignorenode
10 Mar 23:56:50 - [info] Dashboard version 2.19.4 started at /ui
10 Mar 23:56:51 - [info] Settings file  : /home/pi/.node-red/settings.js
10 Mar 23:56:51 - [info] HTTP Static    : /home/pi/.node-red/public
10 Mar 23:56:51 - [info] Context store  : 'default' [module=memory]
10 Mar 23:56:51 - [info] User directory : /home/pi/.node-red
10 Mar 23:56:51 - [warn] Projects di

Lines of interest:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named rpi_ws281x

Ok. I am driving NeoPixel LEDs.

But I can't find a node in the library rpi_ws281.....

In the top screenshot I can see you have set exportGlobalContextKeys to false. With that value set like that none of the global context values will be exported to the editor - which is why you don't see them.

Either comment out that line or change its value to true.

1 Like

That must be new.

Looking (just checked) the other machine. It doesn't have that in it's settings.

Stand by and I shall report back soon.

I did suspect the two settings files were different as that is near the bottom and on one it was visible and on the other it wasn't - the bottom of the file.

(Love ya!)

But just to put the cards on the table, this is from the other working machine and its settings.js file.

No sign of exportGlobal in the file.

I'm calling it a night!

Too much awake today.

I can't remember exactly which version of NR introduced the exportGlobal... option, but it was relatively recent - possibly 0.20.xx or 1.x. So it would have only started appearing in settings files generated by those releases. If you had a settings file that predated whatever version we added the option, then it won't have the option in.

Glad we figured it out!

Again:
Thanks.

I shall have to let that drift until tomorrow.

I had to re-build the whole machine and though I cheated in copying parts of the old file to the new one, that was more for the password.

The other two parts (public path and machine name) I did manually.

So I am a bit curious to how/why that is in it. But for now, sleep is 95% priority. Its 00:31 local and I have been up since 06:00 local. So it has been a long day.

And killing two machines and getting one nearly back to working is enough for me.

Thanks again.

Sorry.... But it is not all good news.

Quick explanation:
Ok, the problem was that the global context for the machine name wasn't visible when I looked at the global context list.

That is weird.
Because the flow was/is working and sending the machine name to my main machine.

More detailed list of events:
The machine (MusicPi) sends the CPU load and temperature to my main machine via MQTT.
The message is the machinename and the load and another one with machinename and temperature.

The main machine matches the machinename so it knows who is sending the data.
That was matching.
So despite the exporteglobabl option being set to false, the flow could still see it.

To check, I booted the machine this morning and set it back to false.
Stopped node-red and restarted it.

The flow seems to still be able to see the name.

Though maybe not exactly proving it, here is a (what's the word?) from the CLI:
I edited the settings.js file and set exportglobal to false and started Node-red.

pi@MusicPi:~/.node-red$ nano settings.js 
pi@MusicPi:~/.node-red$ node-red-start

Start Node-RED
 
Once Node-RED has started, point a browser at http://192.168.0.82:1880
On Pi Node-RED works better with the Firefox or Chrome browser
 
Use   node-red-stop                          to stop Node-RED
Use   node-red-start                         to start Node-RED again
Use   node-red-log                           to view the recent log output
Use   sudo systemctl enable nodered.service  to autostart Node-RED at every boot
Use   sudo systemctl disable nodered.service to disable autostart on boot
 
To find more nodes and example flows - go to http://flows.nodered.org
 
Starting as a systemd service.
11 Mar 08:48:47 - [info]
Welcome to Node-RED
===================
11 Mar 08:48:47 - [info] Node-RED version: v1.0.3
11 Mar 08:48:47 - [info] Node.js  version: v10.15.2
11 Mar 08:48:47 - [info] Linux 4.19.97-v7+ arm LE
11 Mar 08:48:51 - [info] Loading palette nodes
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named rpi_ws281x
11 Mar 08:48:55 - [warn] rpi-neopixels : rpi-gpio.errors.ignorenode
11 Mar 08:48:56 - [info] Dashboard version 2.19.4 started at /ui
11 Mar 08:48:56 - [info] Settings file  : /home/pi/.node-red/settings.js
11 Mar 08:48:56 - [info] HTTP Static    : /home/pi/.node-red/public
11 Mar 08:48:56 - [info] Context store  : 'default' [module=memory]
11 Mar 08:48:56 - [info] User directory : /home/pi/.node-red
11 Mar 08:48:56 - [warn] Projects disabled : editorTheme.projects.enabled=false
11 Mar 08:48:56 - [info] Flows file     : /home/pi/.node-red/flows_MusicPi.json
11 Mar 08:48:56 - [info] Server now running at http://127.0.0.1:1880/
11 Mar 08:48:56 - [warn]
---------------------------------------------------------------------
Your flow credentials file is encrypted using a system-generated key.
If the system-generated key is lost for any reason, your credentials
file will not be recoverable, you will have to delete it and re-enter
your credentials.
You should set your own key using the 'credentialSecret' option in
your settings file. Node-RED will then re-encrypt your credentials
file using your chosen key the next time you deploy a change.
---------------------------------------------------------------------
11 Mar 08:48:57 - [info] Starting flows
11 Mar 08:49:05 - [info] Started flows
11 Mar 08:49:05 - [info] [mqtt-broker:MQTT Host] Connected to broker: mqtt://192.168.0.99:1883
11 Mar 08:49:05 - [info] [mqtt-broker:MQTT host] Connected to broker: mqtt://192.168.0.99:1883
11 Mar 08:49:05 - [info] [mqtt-broker:MQTT host] Connected to broker: mqtt://192.168.0.99:1883
11 Mar 08:49:05 - [info] [mqtt-broker:MQTT host] Connected to broker: mqtt://192.168.0.99:1883
11 Mar 08:49:05 - [warn] [function:8d470685.db6a] Control signal received GO
11 Mar 08:49:06 - [warn] [vcgencmd:Other stuff] Previous vcgencmd command hasn't finished yet
^C
pi@MusicPi:~/.node-red$ node-red-stop

Stop Node-RED
 
Use   node-red-start   to start Node-RED again
 
pi@MusicPi:~/.node-red$ cat settings.js | grep Global
    // The following property can be used to seed Global Context with predefined
    //    functionGlobalContext: { os:require('os') }
    functionGlobalContext: {
    // following property can be used to hide any property set in `functionGlobalContext`
    exportGlobalContextKeys: false,
pi@MusicPi:~/.node-red$ 

Have I messed up something or......?

Not urgent, but I am mentioning it because it doesn't fit with what you said.

The exportGlobalContextKeys setting doesn't stop you using the global context values in your flows.

All its stops you from doing is:

  1. seeing it in the global context sidebar
  2. seeing it listed if you use the global.keys() api that returns a list of all keys in storage.

This setting was added due to concerns that if a user added API keys or other credentials to functionGlobalContext then they would be displayed in the clear in the editor sidebar. Setting the exportGlobalContextKeys to false stops it doing that so the won't get displayed.

But to repeat - if you know the name of the key already, you can still use global.get(...) to retrieve its value.

1 Like

Ok. (Again) My bad.

Sorry if I cried Wolf.

That machine is now working as expected to this point.

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