I understand your point, but as I said, it doesn't feel right.
My flows would become way more complex and ugly, for instance, how this one would look like with the addition of those delays?
Maybe there could be a node to set up the Node-RED integration to add a delay between HTTP requests and set the number of parallel requests. Then I would set it a single request and 100ms delay before executing some flows, and set it back to zero 30 seconds later for example.
Or better, if the delay is higher than zero, then it already disables parallel requests.
I totally agree. I had the same issue and suggested running in the turn off to a smaller number of devices with a break between each group.
Not sure if this has been tried yet.
While I notice some delay in the lights being turned off if ALL lights are on, they all do turn off within a minute of two.
I do check the status of the lights (I believe it is cached in the node so doesn't need to go to the device) and only send the command if the lights are on. This may not work in your case since it looks like you are setting the lights to a specific "dim" level but just something to check.
I also put my Zigbee lights in groups (3 in one, and 2 in the other). One observation is that the Z-wave lights do take longer to turn off than the Zigbee lights - not sure if you have a mix or only one protocol.
EDIT:
You could try putting a "delay" node between groups of lights after the "%" change node (e.g. first set of 5 lights - no delay, second set - 5 sec delay, third set - 10 sec etc). That would keep the aesthetic of your flow but may avoid the missing actions. It would, however, give you the "popcorn" effect
This is correct. I do something similar. I save the state of each light in a variable. And then turn or turn off a light only if its state doesn't match the desired state.
Interesting... I just use the status node for the device to avoid creating dozens of variables. But I guess there are many ways to get to the same destination!
Very interesting!
I don't need that level of reliability, I just want to avoid failures that happen too often, not exceptional failures.
I really believe that this is the best place to solve the kind of problems I'm having:
Maybe there could be a node to set up the Node-RED integration to add a delay between HTTP requests and set the number of parallel requests. Then I would set it a single request and 100ms delay before executing some flows, and set it back to zero 30 seconds later for example.
Or better, if the delay is higher than zero, then it already disables parallel requests.
If that is somehow not acceptable, I'd still prefer to have new fields for those settings in the current configuration node (Advanced tab) than having to deal with the problem in the flows. It is simpler and more elegant.
The command node will output the message only if the code response is < 400. Otherwise the node status will be changed to the error, but no message will be sent output
I started (some years ago), a PR to always send message on the node output and be easier to trigger logic and make retry on the flow, but it has never been merged
Are you able to hack the code (on the acquireLock) and add await sleep(100); to see if you still have issues. It will slowdown all your requests, but could give us some input if it fix something
At the time of writing this integration, I didn't have a lot of devices and wasn't able to reproduce this behavior. But now I have dozens of devices and I can test more easily
edit: nvm about the sleep ... it will just delay the problem
I don't see errors in the nodes' statuses. I'll try to check inside my server (Ubuntu).
Maybe the requests are not failing and the problem is only the flooded Zigbee mesh. It would be great to be able to confirm that.
Did that now.
Yesterday I added a sleep before executing a request, but I'm not sure if it worked.
There is "request" related code inside config.js and request.js. I didn't put the time to learn which one was the proper place.
A New version has been released: 1.9.0 with the PR merged
Now the command node will have an output message with the following attribute: msg.responseStatus that correspond to the HTTP status code (200, 400, 500, etc..)
You could trigger logic or save msg somewhere to help to debug
At least you will be able to eliminate a component/theory from your debugging
From my side, I tried to DOS the HE, without any success. The only message I have was an error in the HE logs
java.lang.IllegalStateException: Queue full
But it was achieve with a recurse loop of ~ 1000 requests. Definitively not your issue
I also tried, to make a slow HE driver response, but nothing bad happen except a slow command
About delaying requests between two commands, I don't want to introduce slowdown without certainty that is the real issue
For the first time all lights turned on as expected!
What I did:
Updated to 1.9.0
Removed node-red-contrib-hubitat from my project modules
Because it just updated in the parent and I didn't know how to update for the project
To be sure which code was being used. I have the impression that my previous changes were not being effective and the previous results might have been due to a placebo effect.
Changed the config.js to allow a single request and to add a sleep in the acquireLock, but I have set to 200ms instead of 100ms, I have reduced it now to 100ms to see if it still works.
In my opinion the idea below would be the ideal solution, since most flows don't change too many devices at once, so a delay being applied by default would be just a nuisance.
Edit: Even better, a node to set a delay for the next X seconds, otherwise it might be complicated and error prone to turn the delay off.
Edit 2: For 22 devices 100ms delay is not enough, I tested with 150ms and still had issues. 200ms works.
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.
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.
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