You set your comm handle to the IP address of the device running Node-RED with the port that the node is listening on:
tcp:127.0.0.1:10500
You set your comm handle to the IP address of the device running Node-RED with the port that the node is listening on:
tcp:127.0.0.1:10500
Thanks @philip. That seems obvious once you tell me!
But before I even get there, I am trying to get a weigh scale’s RS232 serial data via a 9-pin to USB adapter. When plugged into one of the EPIC’s USB ports, should I see somewhere that it’s connected?
No “USB” here:
And while Node-RED gives the green dot for the serial node, no data is flowing to the debug node. I tried all of the Serial Ports shown (/dev/ttyUSB0, .etc.).
Yep, I check that earlier.
I also tried two different brands of 9-pin to USB adapter, flipped my Tx and Rx just to see if I had something wrong, and restarted the EPIC several times. Still no data flowing.
This same 9-pin to USB adapter works fine with a Raspberry Pi (no drivers needed), so I presume it’s Linux-friendly.
Bad assumption.
But do you have shell? If so, you can check in /dev and see if its loaded (or lsusb and find it).
My bet is, since its not listed in groov Manage, the driver is not included in EPIC.
Raspberry Pi Linux !== EPIC Linux !== RIO Linux.
You can check your operating system log and see what messages you get when you plug in the adapter.
Thanks to both of you (as usual!). I was working on a ‘live’ machine and what was supposed to take 15 min. turned into 2 hours, so I had to wrap it up for today. I also came to the conclusion that it must be my cheapie 9-pin to USB adapter.
FWIW, my experience with USB adapters and groov products was always in the RS485 mode and I never had issues thanks to recommendations like this.
I will order this adapter since the above linked post lists it as tested and compatible with the Rio, as well as the Gearmo model listed in the Rio manual. Hoping that our EPIC will accept at least one of these.
I know typically it is the FTDI chip ones that are supported. Not sure on the Prolific. I have some prolific ones, but I don’t have them with me and never tested them in a EPIC or RIO. I could check later today though.
I am 85% sure that mine are both Prolific. I bought them ~9 years ago and found them buggy with Windows (they would time out after a certain period of time…not sure if it was Windows or the USB adapter).
You might want to not get the one you linked to on Amazon then. Sabrent makes some with FTDI too, so that would be a better choice.
As we say in Australia… Yeah, Nah.
The USB adapter drivers (like the wifi usb adapters) are not the same between the two platforms. More USB to serial adapters will work on the RIO than on the EPIC. Reason? The EPIC Linux is very different from the RIO Linux (more to say about this in the many months to come).
OK…Back in the Batcave now (i.e. my basement) and hooked up spare Rio with the SAME cheapie 9-pin to USB adapters and – as Ben predicted – the results are not the same as the EPIC. Plugging in either displays this:
I realized on my drive home that all I really want to accomplish at this point is using Node-RED to read my serial data, which was answered in this thread already. On the EPIC, I really don’t need the 9-pin to USB adapter…it must have been the 8-week hiatus that got me going down another path.
Thanks again guys!
PS: Also cancelled my order with Amazon for the other USB adapters (thanks Philip)
OK, almost there! (long story…I ended up changing to a Rice Lake weigh indicator and then had to fiddle with getting the Serial data out of that)
I have my scale weight being captured via Node-RED and sent via the TCP node per Philip’s suggestion:
And then in PAC Control, I rewrote some blocks from my existing program (where I was getting string data and converting to a float), to allow to obtain the data from the new Communication Handle. I can see the stream of RS232 data (50.27, 50.27, 50.27), but it gets chopped down to 50.2 (instead of 50.27) via the block shown. I have changed the 4 to a 5 and get no different result, so I must be doing something wrong?
Thanks in advance.
What is the length of Four_Digit_String_of_Weight? - maybe it needs to be Five_Digit_String_of_Weight.
Bingo. Thank you. It has been a few years since I went thru this program block-by-block.
And the finished product (middle panel is via MQTT)
Really appreciate the help!
Back to the subject of using the GRV-CSERI-4 EPIC module to read RS232 scale data, I am experiencing something unusual…
When I read (in Node-RED) the serial data from scale A, it comes across fine as a 17-character string. I parse the string using several change nodes to get the weight I want (7.0 lbs in this screenshot)…
Scale B also comes across as a 17-character string, though slightly different format. Again, after parsing the string using a change node, I get the correct weight of 16.1 lbs…
However, once I start running two different serial nodes at the time time, I get a different format. For example, I expect this:
But once I deploy both serial nodes (each configured to grab from a different channel / serial port of the CSERI), I get this:
So I can only conclude that there is something in Node-RED that gets confused when two different serial ports are sending data to the same flow?
FWIW, here are my serial node settings:
Scale A:
Scale B:
I have not seen anything like that here, but would need to try and set up a bit of a different test I suspect.
Are you able to share a screen shot of your flow around the serial nodes?
Here “scale A”
and here is “scale B”
When I disable one of them, the format changes, which in turn fouls up my change nodes to parse the data.
Update: I do not think this has anything to do with the CSERI or the serial-port node. I changed my settings to 7 data bits and 1 even parity bit and adjusted the other node-red serial port parameters from the manual (which I admittedly did not read prior to this…I just put 8, one and 1 and it seemingly worked). I will post an update once I have the rest figured out.
Update #2: It was definitely the RS232 scale output (not the CSERI or Node-RED) that was causing issues. Turns out there was a Start of Text (STX) character (0x2 in hex) that needed to be added, as well as adjustments to the parity, bits, etc. For a Mettler Toledo scale, this was the winning combination:
