There is a already a native Delay node in Node Red that does just that or can also rate-limit messages.
1 Like
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
1 Like
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
3 Likes
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:
3 Likes
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?
5 Likes
Thank you for notifying. Indeed, it could be a nice feature.
I'll see what I can do with it
5 Likes
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!
1 Like
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.)
1 Like
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?
1 Like
Congratulations!
2 Likes
2 Likes
That's funny that you think things will go back to "normal". This is your new "normal"! Congrats!
3 Likes
@fblackburn Have you installed Node Red 4.0 Beta to çonfirm there are not breaking changes to your node package. Hopefully there are not. The new Node Red release is supposed to happen in a few weeks.
1 Like
Congratulations!
1 Like
Thats funny. You are in your new norm 
1 Like
