Node-RED - Flow-based programming for the Internet of Things
-
Source
https://github.com/node-redNode-RED - Wikipedia
https://en.wikipedia.org/wiki/Node-REDNode Red in 5 minutes - YouTube
Open Source Self-Hosted Node-RED Alternatives
https://alternativeto.net/software/node-red/?license=opensource&platform=self-hosted -
Here is a good 3 part series:
1-
2-
3-The main interfaces or node RED are raspberry pi and conventional arduino boards but there is also a more industrial PLC: https://www.controllino.biz/ that use the arduino framework and in turn can leverage node-RED
My main use cases are for Smart Home Automation & Microgreens
This would be such a valuable addition! -
We can sponsor this if someone wants to package?
-
There is an industrial grade PLC that is 100% Arduino compatible = https://www.controllino.biz/
I will have to dig up the additional resources I had but all in all you one can use: Node-RED + Arduino IDE + Controllino PLC
-
Another upvote for this app!
-
I'm a long-time Node-RED user. I was able to get a custom app packaged for Cloudron. So far, so good...
-
I'm a long-time Node-RED user. I was able to get a custom app packaged for Cloudron. So far, so good...
@staypath Very cool!
-
-
@robi Cloudron customizations are in the docker-custom folder
https://github.com/jsonsmth/node-red-docker
Feedback is welcome as this is my first foray into Cloudron app customization.
@staypath That's a good start! I haven't used node-red before but does it require "plugins" or arbitrary node modules to be installed to be usable? A quick look into your package suggests that you decided to put everything into
/app/data. Is it because of that? -
@staypath That's a good start! I haven't used node-red before but does it require "plugins" or arbitrary node modules to be installed to be usable? A quick look into your package suggests that you decided to put everything into
/app/data. Is it because of that?@girish Yes. Any new "plugins" installed are node modules that would be installed in /app/data/data/node_modules
I installed a couple of Node-RED modules (plugins), took a backup of the app in Cloudron, cloned the app from backup, etc... and all seemed to work well. Anything I'm missing? Thanks!
-
@girish Yes. Any new "plugins" installed are node modules that would be installed in /app/data/data/node_modules
I installed a couple of Node-RED modules (plugins), took a backup of the app in Cloudron, cloned the app from backup, etc... and all seemed to work well. Anything I'm missing? Thanks!
@staypath Usually, we keep the code in Cloudron read-only. As a convention, the code is placed in
/app/code. The data the app generates is put in/app/dataand this is backed up. The idea is when we have an update, we can just throw out the old container, replace it with the new container, keep /app/data alone as-is (it's mounted into the new container) and things will work.If the code itself is in
/app/data, then it's part of the backup and also the update path is not clear. All the operations like backup/clone etc will work. Only update is an issue. Do you have any idea how to solve this?One idea, if it's possible, is to put node-red code and npm install in /app/code in the Dockerfile. For additional plugins, if we can set some node module path which can be picked up from say /app/data/node_modules or something, that would be ideal. Is that possible though?
-
Per https://nodejs.org/api/modules.html#modules_loading_from_the_global_folders, we can maybe set
NODE_PATH=/app/data/node_modulesmaybe? -
@staypath Usually, we keep the code in Cloudron read-only. As a convention, the code is placed in
/app/code. The data the app generates is put in/app/dataand this is backed up. The idea is when we have an update, we can just throw out the old container, replace it with the new container, keep /app/data alone as-is (it's mounted into the new container) and things will work.If the code itself is in
/app/data, then it's part of the backup and also the update path is not clear. All the operations like backup/clone etc will work. Only update is an issue. Do you have any idea how to solve this?One idea, if it's possible, is to put node-red code and npm install in /app/code in the Dockerfile. For additional plugins, if we can set some node module path which can be picked up from say /app/data/node_modules or something, that would be ideal. Is that possible though?
@girish Ok, I understand a bit more about the Cloudron build process now. I have updated my Dockerfile.cloudron and moved the repo here:
https://github.com/jsonsmth/node-red-docker-cloudron
The updated build process stores all app code in /app/code and only the user-specific data (including user node_modules) in /app/data.
-
@staypath Usually, we keep the code in Cloudron read-only. As a convention, the code is placed in
/app/code. The data the app generates is put in/app/dataand this is backed up. The idea is when we have an update, we can just throw out the old container, replace it with the new container, keep /app/data alone as-is (it's mounted into the new container) and things will work.If the code itself is in
/app/data, then it's part of the backup and also the update path is not clear. All the operations like backup/clone etc will work. Only update is an issue. Do you have any idea how to solve this?One idea, if it's possible, is to put node-red code and npm install in /app/code in the Dockerfile. For additional plugins, if we can set some node module path which can be picked up from say /app/data/node_modules or something, that would be ideal. Is that possible though?
-
I have updated the repo here with built-in LDAP auth:
-
Repo has been updated to include the following:
- split the Dockerfile into
Dockerfile.cloudronandstart.shto match Cloudron app standards - built-in LDAP auth
I've tested backup,restore and package upgrade.
https://github.com/jsonsmth/node-red-docker-cloudron
Thanks!
- split the Dockerfile into
-
Repo has been updated to include the following:
- split the Dockerfile into
Dockerfile.cloudronandstart.shto match Cloudron app standards - built-in LDAP auth
I've tested backup,restore and package upgrade.
https://github.com/jsonsmth/node-red-docker-cloudron
Thanks!
@staypath awesome, I will take a look later this week!
- split the Dockerfile into
-
I've been working on a Cloudron-app for Node-RED as well. Using node-red-docker and adapting it to Cloudron felt too complicated to me. So, as opposed to the app package that @staypath has been working on, I started with a Cloudron package from scratch.
You can find my repo here: https://git.vereint-digital.de/hendrik/node-red-app
Node-RED itself is simply installed through npm, so the code does not come bundled in the repo itself. Since Node-RED does rely on npm quite a lot anyhow, that seemed more straightforward to me. Plus it makes the Dockerfile really simple.
The code of Node-RED itself (including three modules that are installed out of the box) is located in /app/code. The node-red userdir is in /app/data. So updates of node-red should work, but I've not been testing it long enough to tell.
The app package uses the Cloudron sendmail and mongodb addons. Mails can be sent using node-red-contrib-sendmail and the database can be accessed using node-red-contrib-mongodb4. Both modules come preinstalled and are preconfigured using the environment variables that Cloudron exports.
I must say though, that I do not feel too confident about my solution to send mails. I initially thought, that it would be easier to utilize a command line mail utility, but it turned out to be quite complex as well. In the end, I had to write my own script to act as mail utility, so that it matches the assumptions of node-red-contrib-sendmail. Writing a custom Node-RED module that uses Nodemailer and accesses the Cloudron environment variables probably would have been a better approach.
For authorization, I currently use Cloudron proxyauth and only leave one route (/public) unprotected. Since custom user authentication can be implemented in Node-RED quite easily, it would be highly beneficial to have the authenticated user as part of the request headers, as discussed here. Implementing LDAP, as @staypath has done, also has its benefits though. I'm currently a bit indecisive which approach is preferable.
I hope this is helpful to others, who want to use Node-RED on Cloudron. And maybe we get the discussion on including Node-RED in the app-store going again.
-
I've been working on a Cloudron-app for Node-RED as well. Using node-red-docker and adapting it to Cloudron felt too complicated to me. So, as opposed to the app package that @staypath has been working on, I started with a Cloudron package from scratch.
You can find my repo here: https://git.vereint-digital.de/hendrik/node-red-app
Node-RED itself is simply installed through npm, so the code does not come bundled in the repo itself. Since Node-RED does rely on npm quite a lot anyhow, that seemed more straightforward to me. Plus it makes the Dockerfile really simple.
The code of Node-RED itself (including three modules that are installed out of the box) is located in /app/code. The node-red userdir is in /app/data. So updates of node-red should work, but I've not been testing it long enough to tell.
The app package uses the Cloudron sendmail and mongodb addons. Mails can be sent using node-red-contrib-sendmail and the database can be accessed using node-red-contrib-mongodb4. Both modules come preinstalled and are preconfigured using the environment variables that Cloudron exports.
I must say though, that I do not feel too confident about my solution to send mails. I initially thought, that it would be easier to utilize a command line mail utility, but it turned out to be quite complex as well. In the end, I had to write my own script to act as mail utility, so that it matches the assumptions of node-red-contrib-sendmail. Writing a custom Node-RED module that uses Nodemailer and accesses the Cloudron environment variables probably would have been a better approach.
For authorization, I currently use Cloudron proxyauth and only leave one route (/public) unprotected. Since custom user authentication can be implemented in Node-RED quite easily, it would be highly beneficial to have the authenticated user as part of the request headers, as discussed here. Implementing LDAP, as @staypath has done, also has its benefits though. I'm currently a bit indecisive which approach is preferable.
I hope this is helpful to others, who want to use Node-RED on Cloudron. And maybe we get the discussion on including Node-RED in the app-store going again.
@hendrikvl This is awesome! Thanks for working on this.
The app package uses the Cloudron sendmail and mongodb addons. Mails can be sent using node-red-contrib-sendmail and the database can be accessed using node-red-contrib-mongodb4. Both modules come preinstalled and are preconfigured using the environment variables that Cloudron exports.
Nice, as expected of any cloudron app email and db are auto-configured.
Implementing LDAP, as @staypath has done, also has its benefits though. I'm currently a bit indecisive which approach is preferable.
Does node-red have a real concept of users and roles ? Meaning, can individual users create and manage separate flows? When LDAP is implemented, who provides the login page? Is this part of some plugin?
