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
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.
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?
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.
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.
