Work on a Git branch of Project in the GUI without it going live

#1

What kind of solutions have people set up in order to work on a Git branch of Project in the GUI without it going live? I can imagine having two installations of Node-RED where one is set to dev branch and other master but how to prevent the dev one in actually running code and changing the real (home automation) environment? Am I totally missing something in this regard?

Help, for the sanity of my wife and children!

I want to clean up tabs and tabs of spaghetti wires and code, and just check it after a while.

#2

I have not used it but I believe that NR 0.20 has a --safe command line option that starts up the editor but not the flows, if I am right you could use that.

#3

Running the home automation on machine where you develop and do the experiments is not good practice anyhow. Some simple failure can ruin your system and it may happen that fixing things does not fit into your own day schedule. Then what?

#4

That should not happen since one can easily revert to the previous, working, version when using git

#5

As @Colin says, Git is a saviour when it gets that bad, and easily reverting (besides documenting and collaborating) is a big reason to do version control. In addition I experiment and develop on a different git branch than the production one, and merge when tested and happy with it.

Regarding your comment: my question was exactly how to set up a parallel node-red developer environment to avoid "running the home automation on [same stack] where you develop and do the experiments" (!).

Maybe a second installation of node-red, connected to same git cloud, running with the "--safe" option could be the answer.. really wish some pros had a best practice though.

#6

Best practice would be to use two machines, and have one designated as production, and one for dev. In my setup I have an rpi that is production, and sits with my router, hubs and other gear. And a laptop I use use playing / development. Once I’m comfortable when code or flows, they get promoted or copied from my development machine to the production machine.

Very stable

#7

Is the dev one in —safe mode and is it connected to the same devices as the production one? A physically separate machine will not let it control or react to the same devices (over an uncommon and expensive USB antenna for example) so in my case that would be in --safe mode and "blind", before pushing to the git repository of the production machine, which would then run a test in the production env anyway ...

I guess I'm asking for the impossible, or going about this fundamentally wrong, but I guess I have to redo all my flows to adhere to a "master switch" for writes and changes of states while still reading and reacting to all sensor data. And then run a separate node-red connected to another git branch of the same repository with an env property which says the master switch is off.

PS! Love HAP-nodered btw.

#8

Well, if you are using branches, it can't go live unless you do a PR to merge the branch back to master (assuming you are using master as the live branch).

The difficulty for me is not the project code but the installed nodes. Since all projects inherit the same installed nodes, projects have limited value for me. Especially if you wanted to, for example, test different versions of a node.

That is one of the reasons I don't use the default installation of Node-RED. I create a master folder and install Node-RED into that. I create a sub-folder to use as the userDir. I use npm scripts to make sure I don't have to remember lots of setup or how to start/stop things.

That way, I can have as many Node-RED installations as I like - I have to control the port of course - and I can have different versions of Node-RED, different Node-RED settings (projects on or off for example) and different nodes installed. And they can all run in parallel if I want them to.

Even backup and recovery is simple using this method (though bulky) as there is just one folder per configuration.

#9

I just start Node-RED from the command line and use different names for my flows like
node-red music box.json
node-red diy-operweather.json
node-red halloween.json

1 Like
#10

That will always be a problem. What I generally do with one-of-a-kind hardware is attach it to a production system through MQTT nodes as close as possible to the raw i/o of the device. Then developmental flows on another host (or another instance of NR) can use it (with great care) in testing without altering the production code. Of course, errors can cause strange events in the real world, and there may be health and safety concerns, but it avoids having to take down and restore the production system.