Rbe deadband stops first message

Not sure if I am just doing it wrong or if it is a bug/feature.
I have this flow

flow

[
    {
        "id": "b8d72e2a.9d72e",
        "type": "tab",
        "label": "test flow",
        "disabled": false,
        "info": ""
    },
    {
        "id": "e7ec6f0b.b335d",
        "type": "debug",
        "z": "b8d72e2a.9d72e",
        "name": "",
        "active": true,
        "tosidebar": true,
        "console": false,
        "tostatus": false,
        "complete": "false",
        "x": 590,
        "y": 100,
        "wires": []
    },
    {
        "id": "8a30d072.af479",
        "type": "inject",
        "z": "b8d72e2a.9d72e",
        "name": "",
        "topic": "",
        "payload": "6",
        "payloadType": "num",
        "repeat": "",
        "crontab": "",
        "once": false,
        "onceDelay": 0.1,
        "x": 90,
        "y": 100,
        "wires": [
            [
                "f306d32b.28dea"
            ]
        ]
    },
    {
        "id": "f306d32b.28dea",
        "type": "rbe",
        "z": "b8d72e2a.9d72e",
        "name": "",
        "func": "deadband",
        "gap": "1",
        "start": "",
        "inout": "out",
        "property": "payload",
        "x": 340,
        "y": 120,
        "wires": [
            [
                "e7ec6f0b.b335d"
            ]
        ]
    }
]

But no matter if I set the mode to compared to last input value or compared to last valid output value, the first message sent is getting blocked. I'm using the block unless value change greater than, then the value is 1.

So what can I do to make it let the first message go through? Like it does when you set the mode to block unless value changes.

Completely Off-topic - but how did you insert your flow so nicely into the forum?

What method did you use?

No problem, thanks for the compliment.

First to get it in a expandable "box", you can use this

<details>
<summary>Something</summary>

What ever you want inside. Remember the empty lines over and under.

</details>

For the code you use the three backticks. You can also write for example json after the first three backticks to express what code you are writing (Remember a space between the ticks and the code language).

4 Likes

Or use

This

For those who are confused, click the word This and a picture revealing how to do this will be revealed.

For those who prefer words...

Click the cog, click hide details.

[details="the title"]
The hidden stuff here
[/details]

(Its built in to discourse forum tools)

2 Likes

Well - Its very hard to get the mind around all the possible things that node will do under different circumstances that could arise.

But if there was a block unless value change greater than (ignore initial value) - would that do what you are after?

Does it work if you put an out of range value in Start Value. I interpret that as meaning the value that the first input will be compared to, so putting an out of range value in there should mean the the first data value should be passed through.

Thanks for your reply.

Do you mean like the block unless value changes vs block unless value changes (ignore initial value)?
Cause when I tested the block unless value changes does let the first value through, while the block unless value changes (ignore initial value) does not.

And I want the block unless value change greater thanto have an option where it lets the first message go through like the block unless value changesdoes.

Thanks for your reply.
What do you mean out of range?

I want the rbe to let the first message (first meaning when the flow has been restarted) go through.
When I test I don't find any difference between compared to last input value or compared to last valid output value regarding the first message going through the flow.

Well if you are expecting values to be maybe between 0 and 100 then put -100 in there so that when it gets it first payload value it compares it the to that and will see a large change and pass it through. Unless I am misinterpreting what that field is for.

I tested with 0 and 1000. And switching between those two options in mode.
But no matter what I did, the first message sent is never going through.

When I had it set to 1000, I first sent the number 60, that was blocked, then I sent the number 600, and that went through. But the 60 compared to 600 is not 1000! I think something is wrong with this, or I don't understand anything about this deadband setting.

This is working for me. Make sure you remember to do a full deploy (or Restart Flows) whenever you want to start from the beginning again, otherwise the node will carry on from the last input it got, which can be confusing.

image

[{"id":"9a6168f8.ccad1","type":"rbe","z":"bdd7be38.d3b55","name":"","func":"deadbandEq","gap":"10","start":"","inout":"out","property":"payload","x":349,"y":799,"wires":[["8cd2321d.fb1098"]]},{"id":"8cd2321d.fb1098","type":"debug","z":"bdd7be38.d3b55","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","x":553,"y":798,"wires":[]},{"id":"9f1eacf7.c7129","type":"inject","z":"bdd7be38.d3b55","name":"","topic":"","payload":"10","payloadType":"num","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":117,"y":802,"wires":[["9a6168f8.ccad1"]]},{"id":"d173e328.a8628","type":"inject","z":"bdd7be38.d3b55","name":"","topic":"","payload":"24","payloadType":"num","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":117,"y":903,"wires":[["9a6168f8.ccad1"]]},{"id":"3ef0cb00.410a26","type":"inject","z":"bdd7be38.d3b55","name":"","topic":"","payload":"15","payloadType":"num","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":119,"y":849,"wires":[["9a6168f8.ccad1"]]}]

I think Colin has found the "issue" or "feature" :slight_smile:

I think this might be down to the RBE node not clearing an internal state when its re-deployed

I tried Colin's flow and it let the 10 thru 1st time - but then when I modified the node slightly and used my normal Modified Flows deploy - it didn't let the 10 thru 1st time when I tried again.

Yes I have been aware of this. And that what makes it so difficult.
Cause I tested @Colin 's flow, and that works as expected, and how I want it to work.
But still, my flow does now work in that way (even if I do a full deploy or a restart). I have to dig a bit deeper comparing both the json codes.

Bah.

@Colin you did not use the mode block unless value change greater than, you used the block unless value change greater or equal to.

In my flow I need to check the time of a message that comes, then it has to be greater than, not greater than or equal to.
And to be 100% sure everything works as it should I need the first message after a deploy or restart to go trough.

@Colin But thank you for trying something else. It is good to have some other eyes on this and see other solutions!

By some unknown reason I got to see another option in the GUI, I can't reproduce it but it said something about start value if none is something something. (Maybe a different bug)
This made me look at the json and I tested the "start" variable.
But unfortunately it did not make any difference on letting the first message go through.

Should I create a issue on github for these things I have encountered?

Lets see if @dceejay has some thoughts on it first

1 Like

Yes, you are right, it works with block unless value change greater or equal to but with block unless value change is greater than then it never lets the first one through.
A bug I think, subject to confirmation by @dceejay.

As a workaround to keep you going you could add an inject node configured to inject a value of 0 (or whatever) once on startup. Don't forget to take that out if a fix comes along though.

The other select box appears for one of the other options.

Yes - look like a bug. All the other modes (except the explicit ignore first message one) pass the first message through.

Thanks for your reply.

What do you mean? Are they doing that now or should they pass the first message through?
Since I am/we are experiencing that block unless value change is greater than is not passing the first message through.