You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've recently implemented support for environment variables in Node-RED MCU Edition. I'm opening this discussion thread as a place to explain some details of the implementation and ideas for future work.
Environment variables in Node-RED are present on flows, sub-flows, groups, and the system environment:
Environment variables are inherited. If a requested environment variable cannot be found in a node's containing group, that group's parent is searched next (which could be anther group, sub-flow, or flow), and so-on until the system environment is searched.
Environment variables within Node-RED are read-only. (confirmed with the Node-RED maintainers)
There are some automatic environment variables such as NR_NODE_NAME, NR_NODE_ID, NR_FLOW_NAME, etc. that are provided by the runtime. These make it appear that a node has environment variables, though there are no user-defined environment variables on nodes. (Presumably these automatic environment variables do not change during the lifetime of the objects which implies that the name and ID do not change either.)
System environment variables are not currently supported by Node-RED MCU Edition. This is because a typical MCU doesn't generally have environment variables.
It could be possible / reasonable to use the mc/config module in the Moddable SDK as system environment variables. This would be straightforward.
It seems possible that in some runtimes system environment variables can change at runtime (e.g. Node.js which runs Node-RED!)
Node-RED has a curious feature to allow environment variables to be used in nodes that do not support environment variables directly. From the Node-RED documentation:
Any node property can be set with an environment variable by setting its value to a string of the form ${ENV_VAR}. When the runtime loads the flows, it will substitute the value of that environment variable before passing it to the node.
Node-RED implements this by recursively scanning the JSON flows document for any string value of the form ${ENV_VAR} and then resolving the environment variable at the time the flow is loaded. Node-RED MCU Edition does not load the flow JSON on the MCU, but at build-time in the nodered2mcu tool. The nodered2mcu tool resolves all environment variables that are defined within the Node-RED environment, but cannot resolve system environment variables (since it is not running on the target system).
The current implementation resolves all other environment variables (those not defined using the ${ENV_VAR} string value special case) at runtime. This will allow them to work with system environment variables, if they are supported in the future. However, it is some runtime load. An alternative is try resolving them at build time. If that succeeds, the resolved value would be used. If not, it would be resolved at runtime as now. There is some tradeoff of performance versus memory use here, so whether this is appropriate depends largely on how environment variables are used in practice.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I've recently implemented support for environment variables in Node-RED MCU Edition. I'm opening this discussion thread as a place to explain some details of the implementation and ideas for future work.
Environment variables in Node-RED are present on flows, sub-flows, groups, and the system environment:
NR_NODE_NAME
,NR_NODE_ID
,NR_FLOW_NAME
, etc. that are provided by the runtime. These make it appear that a node has environment variables, though there are no user-defined environment variables on nodes. (Presumably these automatic environment variables do not change during the lifetime of the objects which implies that the name and ID do not change either.)System environment variables are not currently supported by Node-RED MCU Edition. This is because a typical MCU doesn't generally have environment variables.
mc/config
module in the Moddable SDK as system environment variables. This would be straightforward.Node-RED has a curious feature to allow environment variables to be used in nodes that do not support environment variables directly. From the Node-RED documentation:
Node-RED implements this by recursively scanning the JSON flows document for any string value of the form
${ENV_VAR}
and then resolving the environment variable at the time the flow is loaded. Node-RED MCU Edition does not load the flow JSON on the MCU, but at build-time in thenodered2mcu
tool. Thenodered2mcu
tool resolves all environment variables that are defined within the Node-RED environment, but cannot resolve system environment variables (since it is not running on the target system).The current implementation resolves all other environment variables (those not defined using the
${ENV_VAR}
string value special case) at runtime. This will allow them to work with system environment variables, if they are supported in the future. However, it is some runtime load. An alternative is try resolving them at build time. If that succeeds, the resolved value would be used. If not, it would be resolved at runtime as now. There is some tradeoff of performance versus memory use here, so whether this is appropriate depends largely on how environment variables are used in practice.Beta Was this translation helpful? Give feedback.
All reactions