I'm not a computer scientist. I don't know about buffers or bytes---nor do I want to.
I'm an engineer. I struggle plenty with my calculus and linear algebra and systems control. It's too much as is, frankly.
But I have a device sending an array with two values---pressure and temperature, say---into node-red through a TCP connection.
And for some mind-boggling reason, those numbers come in as buffers of bytes. I can't work with bytes. Or strings. I need numbers. The two numbers that my device communicated to node-red.
So how how how does a human get those numbers out of this TCP node that insists on providing buffers?
All my schooling was done in decimal numbers. All my math. All my programming. I know nothing about bytes and I wish wish wish I knew why node-red can't just give me numbers when I transmit numbers.
Thanks, I've tried it, but still nothing resembling the numbers being transmitted into node-red! It's so frustrating having your hands full already with challenging projects and having to pick up yet another science just to... get your numbers back in order to use them? Oy.
It's the nature of the beast. Data is transmitted in bytes, often reversed. There is no escaping that fact unless you have control over the transmission and you format it into something extensible like JSON.
If you can post sample data and the specification (e.g which bytes are supposed to be what type and what value) I will show you how.
Well that's the thing, Steve: I don't know what the bytes in the buffer are supposed to represent nor do I know what specification they're based on.
I work with decimal numbers. I've worked with decimal numbers exclusively since I started math class as a little kid. I have never once dealt with buffers or bytes.
And decimal is what I transmit to node-red. I can make sense of decimal. But a buffer of bytes is as good to me as a transmission from an alien civilization trying to teach me science.
I know most people are the same way. Most of us aren't computer scientists. Most of us are lucky enough to know the little we know about decimal math. So why on earth does node-red seem to assume we can all just take off with buffer data?
I mean, I've spent two full days trying everything under the sun just to get some decimal numbers I can make sense of---and still nothing! I'm about to say goodbye to node-red frankly. What good is a tool if it requires that I pick yet another science, as if the many I've picked up over the years weren't enough? I need to be productive and all I seem to do is hit another wall that forces me to go learn another discipline.
It gets tiring after a few years of this. It shouldn't take this many sciences to bring a project to fruition. And it's especially frustrating when the stumbling block isn't even the control allocation algorithm of a rocket, say---the kind of thing I'd expect to truly struggle with---but... merely getting the decimal numbers I transmitted back as decimal numbers so that I can do normal math with them?
Is node-red not for people who do only decimal math? Why aren't buffers of bytes automatically converted back into decimal numbers if that's the format they were transmitted in? Is it reasonable to require users to manually undo what node-red automatically (and undesirably) did for us?
I don't get it. The more I learn about software the less I want to use software.
That's what protocols are for. If you know the protocol, you use it to unravel the data bytes.
And that will be your loss. Node-red is fantastic at what you tell it to do, you will be hard pushed to solve this without the tooling it provides. Especially as you have provided ZEEO information on the data.
Node-red red doesn't assume anything. You need to have a clue. TCP transmission IS designed to transmit bytes. It is the programmer of the device who arranges the bytes. If you are not aware of how the bytes are arranged, how can you expect node red to be? It just doesn't work like that.
You say "I transmitted" - is the data something you generate from another (programmable) device?
I can clearly see you are frustrated & if you want to just sound off or give up, fine, but if you really want solve this, you are gonna have to give me something to work with.
What is the device sending data?
What values should it be sending?
Have you noticed any repeating patterns in the data?
Have you used wireshark to analyse the data?
Provide some sample data - we might recognise the format as a protocol or simple ASCII
Answer the above and we will help if at all possible.
Hi
yes - I know it's a pain - but TCP knows nothing about what you want - it just moves bytes from one place to another... But there is always a way to get back what you want. How are you sending these decimal numbers ? Is this Node-RED at the sending end ? - Show us what you are sending and tell us how... and then at the receiving end can you show us what is coming out of the tcp node (by connecting it to a debug node) - ie so we can see what goes in and what comes out for some know piece of data.
Also which TCP node are you using ? The TCP-in node does have an option to show strings (if that is what is being sent) - but indeed maybe not the node you need if you do need to request data from the other end.
I finally got the Buffer Parser node to work. Half the problem was with the simulation software I was using to transmit doubles to node-red. There was no way to specify the encoding there, and there was no documentation on which encoding type was assumed, so I was bound to suffer this torment---until I switched to a different way of establishing a TCP connection.
The key was to have to control over the encoding on the sender side so that I could properly specify the decoding type on the receiver side---big-endian double in my case.
Sorry for all the venting. Super frustrated feeling placated by software that's supposed to enable certain features only to find I've simply replaced one wall for another. Lots of spinning my wheels, working day to night and beyond, with nothing really to show for time lost.
But now I have a path forward, so I'm feeling more optimistic and less cranky, and a "thank you" for putting up with me is in order. Thank you
