RBE not "working" as I thought

General
21

So hang on:
If I get a repeating message that is:
payload = "" and topic = "ONE"
One will go through.
Then when it changes to:
payload = "" and topic = "TWO" (repeating)
The first one of the second will go through.

HOWEVER

If the message then goes back to the first one it won't change because it has already blocked that one.

So not only does it block repeating messages, but it also remembers previous messages and blocks them as well.

Right?

22

I don't understand what that means. Per vs On.

Too technical for me. I don't know the terminology.

23

Once a message with a payload = "xxxx" on topic ="topic1" has gone through, the RBE will block any other messages on topic="topic1" with payload ="xxxx"

If you send another message with payload = "xxxx" on topic ="topic2", RBE will send that through but will then block any other messages on topic="topic2" with payload ="xxxx"

And it will continue to block messages on topic="topic1" with payload ="xxxx"

24

So ........

Let me check again for clarity.

payload = "xxx" on topic1 goes through ONCE.
As soon as the message changes to
payload="xxx" on topic2, that will go through once - also.
And if it goes back to
payload ="xxx" on topic1 it will not get through. It will continue to block.

This may explain some weird things that are happening with other flows where I have RBE.

This raises the question:
What happens if I only want to block concurrent messages of the same structure?

So going back to your example:

payload="xxx" topic1 PASS
payload="xxx" topic1 BLOCK
payload="xxx" topic1 BLOCK
payload="xxx" topic2 PASS
payload="xxx" topic2 BLOCK
payload="xxx" topic1 PASS

25

Nope last one for topic 1 is still blocked. Your example should break out to this:

payload="xxx" topic1 PASS
payload="xxx" topic1 BLOCK
payload="xxx" topic1 BLOCK
payload="xxx" topic1 PASS <=============this will be blocked, the payload has not changed for topic1

payload="xxx" topic2 PASS
payload="xxx" topic2 BLOCK

26

I think you are still slightly missing the point. The logic the RBE node goes through is first to look at the topic, then it says 'is the payload for this message the same as the payload we got last time for this topic?' If the answer is yes then it blocks it, if no then it passes it.

27

Zenofmud.

I meant to show the output like that.

It confirms what Colin just said.

So that does explain the other weird faults other flows have.

Ok. Got how RBE works now.

How do I clear any existing blocks?

Say I want to do what my previous post suggested.
I want this to happen:

payload="xxx" topic1 PASS
payload="xxx" topic1 BLOCK
payload="xxx" topic1 BLOCK

payload="xxx" topic2 PASS
payload="xxx" topic2 BLOCK

payload="xxx" topic1 PASS
(and what ever happens next)

28

I think possibly you just need to switch what you have in topic and payload. It is difficult to be sure though, because you have shown the same payload (xxxx) for all cases. If you give us an example of the real data then we may understand better what you are trying to do.

29

Go read the info tab for the node.

30

Zenofmud.

Mia Culpa.

RESET.

I am trying to get/build an example of the data I see.

Seems that isn't as easy as I thought it should/would be.

It is basically:

topic: "brown"
payload: ""
background: "brown"
device_ID: "ALL"
state: 0
_msgid: "2722dc5e.e3b8f4"

Repeating every ..... 6 seconds.

Now and then it changes to:

topic: "lime"
payload: ""
background: "lime"
device_ID: "ALL"
state: 0
_msgid: "513605a9.3a52bc"

I put the stream into the FILE node and saved it to a file.

All I get is a .... blank file. No text.

So, those are the two variants.

This is the code that creates it:
(Deja vous)

var colour = (msg.payload === "On-line")?"lime":"brown";
//node.warn("Selected colour is " + colour);
var msg2 = { topic:colour,payload:"", background:colour, device_ID:"ALL", state:0};
node.status({text:colour});
return msg2

It gets the colour and creates a message. Colour and State.
Device_ID may also change, but not in great ways. Only with a name.

I can play with where the values are stored.

It is like it is with what names are used because of..... well, let's leave that in the past.

31

Yes, because the payload of each of those messages is blank and the File Out node writes the payload to the file.

32

I think I had better call it a day.

8 hours of solid programming and I think I have exceeded my good time for today.

I re-built 24 buttons trying to get them working better. And after all that, the original ones are actually better than the new ones.

And they keep changing how they work. Sometimes they do one thing and later they do something else.

21:34 local time...... Yeah, I think I've done enough.

33

Yes, sometimes it all becomes clearer after a nights sleep.

A series of programming steps always does what you tell it do do, which might not be what you want it to do :slight_smile:

3 Likes
34

You are absolutely correct!

Had a good night's sleep.

Stupid me, I WAS thinking about it but doing what solved the problem earlier but took "the easy way out" and used a pre-built node: RBE.

This is the solution (part of flow):

[{"id":"1967a0da.a953a7","type":"inject","z":"381d953d.4cf092","name":"","topic":"","payload":"","payloadType":"date","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":530,"y":2670,"wires":[["7b52c4bb.c03114","462cc6a2.507bf","d76537f9.7882f8","c73af06d.ae1b68","389cc073.037a1","a6aa5bdc.99626","d24e6ebe.7187b","4afb6475.d88664"]]},{"id":"b220c30e.93ede8","type":"ui_switch","z":"381d953d.4cf092","name":"","label":"86","group":"fc79d2d2.27186","order":3,"width":"2","height":"1","passthru":true,"decouple":"false","topic":"","style":"","onvalue":"On-line","onvalueType":"str","onicon":"","oncolor":"","offvalue":"Off-line","offvalueType":"str","officon":"","offcolor":"","x":661.1111450195312,"y":2907.5556030273438,"wires":[["d76537f9.7882f8","bfaf8242.cda53"]]},{"id":"d76537f9.7882f8","type":"function","z":"381d953d.4cf092","name":"","func":"var colour = (msg.payload === \"On-line\")?\"lime\":\"brown\";\n//node.warn(\"Selected colour is \" + colour);\nvar last = context.get('last') || \"blank\";\ncontext.set('last',colour);\nif (colour !== last)\n{\n    //\n    var msg2 = { topic:colour,payload:\"\", background:colour, device_ID:\"ALL\", state:0};\n    node.status({text:colour});\n    context.set('last',colour);\n    node.status({fill:\"green\",shape:\"dot\",text:\"Passed\"});\n    return msg2\n} else\n{\n    node.status({fill:\"red\",shape:\"dot\",text:\"Blocked\"});\n}\n","outputs":1,"noerr":0,"x":790,"y":2907,"wires":[["6b739592.24387c","c4e6e5c9.62241"]]},{"id":"fc79d2d2.27186","type":"ui_group","z":"","name":"Indicators","tab":"3776e46e.a7d894","order":2,"disp":false,"width":"16","collapse":false},{"id":"3776e46e.a7d894","type":"ui_tab","z":"","name":"Master Control","icon":"dashboard","order":4}]

(Edited part)
Sorry, just in case anyone else is reading:
The node does what it did in the original part: change the incoming message to a message needed by the next stage.

Now it also looks at the message and sees if it is the same are the previous.
If it isn't it sends on the message.
If it is, it just doesn't send anything.
Oh, there is also a bit of code in there that shows you what the node is doing with the node.status command.

35

Anyone got "humble pie"? (Though that may not be the right analogy.)

Ok, here is where/how I shot myself in the foot:

[{"id":"aeec02b6.7b7bb","type":"function","z":"5ebb71d4.83ed7","name":"","func":"//node.warn(msg.payload);\nvar colour = (msg.payload === \"On-line\")?\"lime\":\"brown\";\n//node.warn(\"Selected colour is \" + colour);\nvar last = context.get('last') || \"blank\";\nif (colour !== last)\n{\n    var msg2 = { topic:colour,payload:\"\", background:colour, device_ID:\"MusicPi\", state:4};\n    node.status({text:colour});\n    context.set('last',colour);\n    node.status({fill:\"green\",shape:\"dot\",text:\"Passed\"});\n    return msg2\n} else\n{\n    node.status({fill:\"red\",shape:\"dot\",text:\"Blocked\"});\n}\n","outputs":1,"noerr":0,"x":320,"y":1120,"wires":[["6b4401ea.d9da2"]]},{"id":"115ef8a5.53ca8f","type":"inject","z":"5ebb71d4.83ed7","name":"Loop","topic":"","payload":"{\"topic\":\"192.168.0.82\",\"host\":\"192.168.0.82\",\"_msgid\":\"c5e09a3a.547618\",\"_topic\":\"MusicPi\",\"payload\":\"Off-line\",\"_event\":\"node:14780718.82f8a9\"}","payloadType":"json","repeat":"3","crontab":"","once":false,"onceDelay":0.1,"x":90,"y":1120,"wires":[["aeec02b6.7b7bb","350a858d.97dec2"]]},{"id":"6b4401ea.d9da2","type":"debug","z":"5ebb71d4.83ed7","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","x":520,"y":1120,"wires":[]},{"id":"dbd95e64.9f3f58","type":"inject","z":"5ebb71d4.83ed7","name":"","topic":"","payload":"","payloadType":"date","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":90,"y":1070,"wires":[["aeec02b6.7b7bb","5d74bdf5.e6fdd4"]]},{"id":"5d74bdf5.e6fdd4","type":"debug","z":"5ebb71d4.83ed7","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","x":310,"y":1060,"wires":[]},{"id":"350a858d.97dec2","type":"debug","z":"5ebb71d4.83ed7","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","x":310,"y":1180,"wires":[]}]

The node keeps injecting the message over and over. Every 3 seconds.

The function node allows the first, then blocks.

To simulate a change of the message, I press the inject node, expecting to see that ONE timestamp come out.

It doesn't.

C'mon! The logic in the node isn't rocket science.
Get the colour. (first line)
Get the previous value. (Line 2)
Compare the two (line 3)
If they are different:
Construct a new message payload.
Set the node.status
Save the new value
Return the new message
else
Set the node status to blocked and do NOT send any message.

I know/have heard this is a "non-cocha" way and all nodes should have a "return msg at the end"
But... As NR is asyncronous, the timing of message arrival is unknown.
If the payload doesn't meet the requirements, it is simply dropped.

var colour = (msg.payload === "On-line")?"lime":"brown";
//node.warn("Selected colour is " + colour);
var last = context.get('last') || "blank";
if (colour !== last)
{
    var msg2 = { topic:colour,payload:"", background:colour, device_ID:"MusicPi", state:4};
    node.status({text:colour});
    context.set('last',colour);
    node.status({fill:"green",shape:"dot",text:"Passed"});
    return msg2
} else
{
    node.status({fill:"red",shape:"dot",text:"Blocked"});
}