Node-RED nodes for hubitat

[eduardo]

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.

[bobbles]

@thebearmay

Sounds like you're flooding the mesh, try adding a small delay (50-100ms) in between each command.

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.

[rakeshg]

@eduardo

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?

I have a similar flow that turns off all lights at night:

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:

@eduardo

My flows would become way more complex and ugly, for instance, how this one would look like with the addition of those delays?

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

[aaiyar]

@rakeshg

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

[rakeshg]

@aaiyar

I save the state of each light in a variable.

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!

[aaiyar]

@eduardo

IMHO it should be fixed somewhere in the lower layers.

Your needs are similar to those of @robert.bruce as described in this thread:

Seeking Better Certainty of Device States

I apologize for the following post. It is very long. The issue is complicated. I use a C-7 Hub Mesh and Z-wave devices to control the physical environments in rooms of my house that I use for my Indigo Snake breeding operation. If lights stay ON when they are supposed to be OFF, or if heaters/air conditioners are in the wrong state, there is the potential that I could lose animals, eggs, and an entire year of income or more if I don't catch it in time. Over the past three years, I estimate tha…

His solution was to modify drivers such that commands were repeated until successful. I strongly recommend reading the thread.

[eduardo]

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.

[aaiyar]

@rakeshg

to avoid creating dozens of variables.

There are three reasons I create variables for device status.

1. Using a variable reduces the odds of something being added to the msg that interferes with a control node.
2. I use the status of the same device in multiple sequences.
3. Using Javascript, it is very easy to test for the value of multiple variables in a single switch node.

[fblackburn]

@eduardo

• Is your implementation checking for an OK (200) response for the requests?
• Does it retry if a request fails due to a server/network issue, for example 5XX response or timeout?

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

@eduardo

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

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

[eduardo]

@fblackburn

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

@fblackburn

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

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.

@fblackburn

edit: nvm about the sleep ... it will just delay the problem

[fblackburn]

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

[eduardo]

It worked!

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.

@eduardo

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.

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.

[user6734]

Is my understanding correct, that I must keep the node-red server running all the time for this to work?

[aaiyar]

@user6734

must keep the node-red server running all the time for this to work?

Yes. The logic of the flows and sequences is executed on the node-red server; not on your Hubitat.

[csteele]

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.

[user6734]

Thanks.

[eduardo]

@eduardo

a node to set a delay for the next X seconds

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.

[stephen_nutt]

There is a already a native Delay node in Node Red that does just that or can also rate-limit messages.

[fblackburn]

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

[fblackburn]

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