Exec node send an output payload on more than one message

General
21

You haven't included the flush command.

22

It does seem that something is badly broken between the exec node and Python 2.7.
I tested on a Pi running RPiOS Buster. but the OP says the same happens on Windows.

Flushing stdout makes no difference, nor does substantially reducing the size of the output.

I don't see the same problem if I change the exec node to call python3. (As @Colin says, the script #! line is ignored.)
@Lupin_III if you are on a Raspberry Pi , why do you have to use python 2?

23

Did you add the flush and remove the -u? That is working perfectly for me on a pi running Buster.

24 
import time
import sys
while True:

    a=[402.17, 10.16, 17.2, 3482.43, 138.55, 27.76, 27.64]
    print (a)
    sys.stdout.flush()
    time.sleep(5)


python /home/pi/try

With this short output it only manifests as splitting the carriage return onto a seperate message sometimes

Untitled 2
Untitled 2500Ɨ681 32.7 KB

25

That is odd. What does python --version show?

26

python 2.7.16

But on that Pi, python3 is 3.7.3 and imho python3 should always be specified
On newly installed RpiOS 64 bit, python --version gives 3.9.2

27

I agree with you about python 3. We wait to hear why python 2 must be used here.
I have the same version of python 2, the same OS, but for me, with the flush and without -u it works perfectly. Strange.

28

@jbudd are you using node-red 3.0.2? Which version of nodejs?

29

Yes 3.0.2, node -v gives 16.19.0

30

I assume you mean node 16.19.0, which is the same as I am, so it isn't that.

1 Like
31

Don't forget that at the end of the day it is all running on a multi-tasking OS - so the process can yield to another and decide to send the buffer when it needs to - it doesn't have to wait for a flush.
Worst case you will have to rebuild the lines once they arrive in Node-RED. I "think" - (as in not done it for a while) that the split node does actually buffer things up until it sees the split character - so that may help (assuming there is always a charater to reliably split on.

32

It does seem more reliable for a short message at least if you flush before and after printing.
Not tried with Colin's long message.

33

Magic, I didn't realise it would do that.
@Lupin_III you can go back to your original flow, without the flush and with -u, and feed that into a Split node configured like this

image

That will then handle the stream of messages, join them, and then split on the newline.

34

Thanks to all. For the very nexrt days I won't be able to make other test.
Any way, just a couple of quick update:

  • Unfortunatly at the moment I have to use python 2 because the script needs some important adjustment in order to make it working on python 3. At the moment these changing are not feasable and the script is quite complex.
  • The best workaround I've found is to print iin python as json, like
    a=[-402.17, 10.16, 17.2, 3482.43, ..........]
    mydata = {
        "details" : a
    }
    print(json.dumps(mydata))

in this way, but only putting -u paramiter within the exec node, the message is always sent in a unique msg payload.Sometimes a special character for a new line is happened at the end (not always). But it is something easy enough to manage.

35

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.