It's not running in a sandbox, which is where the 'unsafe' word comes from.
If you're writing the JS code, then I think using the unsafe version for speed is acceptable, but if you're importing Flows, I wouldn't want to sidestep the protection.
2 Likes
If one is importing flows, then that imported flow will just use the stock/sandboxed function node and it's not "sidestepping" anything unless the user goes in there manually replaces them
Something like OwnTracks on the other hand, which you have in "Group 3 useful in HE", is a very complicated setup full of pitfalls, data exposure risk, for sure at least an "advanced" thing. And it isn't not too useful in a HE environment because it has absolutely nothing to do with HE.
I like the idea of something for new NR users to reference, but there is no context to any of it. My 2 cents is putting the palettes in groups based on functionality instead of making the decision for someone they "need" this or should use that, which is impossible without knowing what the person is actually trying to do..
Your list's suggestions grouped by purpose
2 Likes
I updated the first post to replace my ordered list to: "By Purpose", as suggested by @morningz
1 Like
I think I would swap pushover for email in the first category.. Pushover is specifically great for HE. Email is just generally useful. Also suggest adding dashboard to group 1 and "node-red-contrib-time-range-switch" as well maybe. Bigtimer is very useful too but I think it belongs where it is.
1 Like
Maybe this isn't a common choice, but it provides a method to use Alexa to trigger sequences. And works well.
1 Like
When used with Network UPS Tools (NUT) it makes for a nice way to monitor your UPS and create a controlled shutdown routine. @guyeeba also has great device driver set for use with RM - I've gone for redundancy doing both.
Useful guide for setting up NUT on a Pi.
Just note that the nut node set requires nut to be installed on the base OS.
So if you are running node-red in a docker container, you can't easily use that set of nodes (as you can't easily install nut on the base OS).
I was unaware of the option. Very cool.
Any good chrome cast suggestions?
Castv2. Out of all the ones I tried, it worked the best and has been the most reliable.
2 Likes
+1
I know that it uses non-standard naming for the palette, but has anyone tried do-red which is at:
I thought for aesthetic organization of really long linear flows the Task-Lists looks interesting. The regular loop could also be a useful tool. I see the author of the palette notes that all of this could be done with link nodes.
Would love feedback on what others think.
2 Likes
That is a cool node - the fact that you can sequentially go through tasks is interesting. Kind of a primitive FSM (tasklist).. For simple loops it may be overkill.. was playing around with my mudroom motion light sequence.. if I'm doing it correctly that is.. top is original sequence, bottom is with do-red
For more complex stuff I bet this would be handy - not in this case however 
. Thanks for posting this!!
That doesn't seem "better" to me. I would much rather connect the dots / follow the lines. But each to their own!
That is one of the great things about programmable systems, people can use them in ways that makes sense to THEM / no one size fits all.
1 Like
I agree - in this instance it's not worth it.
The fact that the node has the capability to do multiple sequential tasks with "done" moving on to the next is kinda cool.
1 Like
I haven't used it, but I like the idea of being able to group various parts of long sequences. For a short sequence, it doesn't seem worth it unless you are very opposed to crossing lines. That said, I am really looking forward to the grouping function that is likely part of Node-Red 1.1. This ability to group and label said group of nodes will really help me figure out what a sequence is trying to accomplish when I reexamine it months later.
Here is the link to the preview: [preview] Grouping Nodes - Core Development - Node-RED Forum
3 Likes
I was reading about grouping the other day. I will use that.
It doesn't affect execution or anything - is purely cosmetic - but since I like to have my node defined such that their function is understandable WITHOUT opening the node config (appropriate naming, and no function node unless 100% required), this will further assist in that.
Since I have close to 200 flows across 3 different node-red installs, it will be a welcome change.
As an alternative to stoptimer2 .. there's also stoptimer-varidelay. It takes stoptimer2 and extends it to allow for dynamically changing the delay (and soon the units too) via the incoming message.
1 Like
Actually I support a lot more than 3 installs if I include work ones....
For personal use, though, I have a production one, a development one, and then one on the node-red dev branch for testing new features/releases.
I run them (and everything else I possibly can) in docker containers. Can put them on my AMD EPYC cpu based Unraid server, or my Atomic Pi based docker swarm.
