Yes.
Of course if you have a home that only needs to work on Saturday and Sunday, you can leave it off for the other days 
Any flow you want to work, runs on the Node-Red server. It must be on to detect and respond to the criteria you built.
Thanks.
Hey @fblackburn, do you have plans to implement something like that?
If not, I might try and implement it myself. Node.js is not a framework I'm familiar with, but the delays when not needed are annoying me a little.
Of all my automations, only 3 need delays between HTTP requests.
There is a already a native Delay node in Node Red that does just that or can also rate-limit messages.
Yes I already implement it but not pushed (I wanted to try to make automated tests and be sure that doesn't feel weird as option). In my implementation, you will need to have 2 config nodes. One with custom delay, an another without delay
If you are willing to make test, I can push the branch in the next days
But I agree that this delay is an implementation detail that should not be visible (or impact) how you make your flow. IMHO, it should be better handled by HE (maybe a kind of an option to configure your ZigBee mesh?). Or maybe not ... it's far from my area of expertise 
I'm looking forward to testing it
PR is here: add delay commands option by fblackburn1 · Pull Request #158 · fblackburn1/node-red-contrib-hubitat · GitHub
It's a new option in the advanced tab of the config node
Feel free to comment / improve / reword doc
FYI, now that ad-hoc attributes can be requested from Maker API, it may be worth considering a new "on demand" node type/functionality that can fetch the hub attribute value instead of relying on whatever is in the cache on the node-red side?
If not, no biggie - end users can fairly easily just do it with an HTTP node as well.
Continuing the discussion from Release 2.3.8 Available:
I like making use this new Maker API functionality, but perhaps instead of a new node type, the functionality could be added to the existing Device node. For instance, by having a selectable "force-check" selector box. When selected, it would force requesting an update for whatever attribute the device node is configured for rather than using the cached value?
Thank you for notifying. Indeed, it could be a nice feature.
I'll see what I can do with it
Just curious, what could we use this for? It's probably one of those things that I could probably use but didn't know existed!
Hey @fblackburn, sorry for the long delay (no pun intended) on this one. I ended up entering a series of jobs and trips and just now I'm getting back to "normal" mode 
I have checked your PR now. I seems ok so far. But as I said, I have only 3 flows that require delays between commands. The way it is in the PR, the delay is global affecting all flows, which is not ideal.
Most of my flows change very few devices, and for those the delay is a bit annoying.
I found a problem, the value is not being saved in the configuration. I've set 200ms, clicked "Update", but when I go back to the Advanced tab, the field is empty.
I was also thinking, if there is a way to set this value via a node, I can take care of setting it only for the automations that need delay, returning to the default "no delay" setting after some seconds.
If you like the idea, please like the post or add a reply to help with visibility. Thanks!
Where do I post if I don't like the idea?? (joke, since I already replied to that Topic.)
Hi @eduardo, sorry I tried a longer delay to reply 
Just kidding, even after a few months with a baby I still can't figure out when
I can go back to "normal" mode ... 
Only if you send many commands a the same time.
The implementation is that commands are queued and delay will only exist if there is many commands at the same time. There is no fixed delay before each command
I don't understand how the delay impact you if most of your flows change few devices (i.e. not a lot command triggered at the same time)
Here's how I understand the delay issue
- Some mesh (or some device) could drop command because there is too much messages to process
- Mesh is built with the nearest device (acting as a repeater)
Based on that, I can see two scenarios
-
You don't know where the repeater is located and/or which devices will use this repeater.
- In this case, the global queued delay is the right solution / tradeoff to be sure to never drop a command
-
You know how the mesh is built and where the device that drop/limit messages are located. So you know which kind of flow may cause issues.
- In this case, the solution would be to create two config nodes to manage a "part" of the mesh separately
Did I miss something?
Congratulations!
That's funny that you think things will go back to "normal". This is your new "normal"! Congrats!