Can EPIC Serial Module GRV-CSERI-4 be used with Node-RED?

Happy Monday. Can the GRV-CSERI-4 be used with Node-RED? Specifically, we have one in place that is reading RS232 data from a scale and using that reading / data in PAC Control, but now wanted to know if one of the groov Nodes could be used with this EPIC module so that we can view (and use) the data in Node-RED.

Happy Monday as well.

The CSERI serial ports show up as linux serial ports, so you can use a serial node to open and communicate. I use node-red-node-serialport with the USB-serial adapters on RIOs. It should work on the CSERI as well. The CSERI serial device show up like: /dev/ttySerMod0.0

I think this post here will answer all your questions, if not, come back and ask (But we may wrap your questions into that thread so its all in one place).

Thank you both, but I am missing something…

Here is my CSERI:

Here is my Serial Port config:

Here is the Serial Port node config:

I have the green “connected” dot, and I got this output (and yes, the 00180 makes sense because there is 1.8 lbs on the scale), but I am not seeing anything ‘streaming’. I was hoping to see a continuously refreshing value in the Debug pane since the scale is set to continuously transmit data.

Also, I read in the forum post linked by Ben that there could be a conflict between PAC Control and Node RED, so maybe I should disable PAC Control for the moment?

You can set a delimiter on the serial port configuration to output whenever it is received. There are other options as well, such as character count and delays.

Currently it is waiting for the buffer to fill up (32768 bytes) and then outputting all at once.


Thank you! I think I have something similar set up in my PAC Control flow (which is on another PC at the moment). Am sure I can get everything straightened out from here.

Is it indeed a bad idea to run PAC Control at the same time as this Serial node (since both are querying the same RS232 data)?

It’s probably not a good idea.

You could have Node-RED send the data back to PAC Control by sending the data back to a TCP node and having the PAC Control comm handle connect and listen on the TCP socket instead of the serial port. Would take about 30 seconds to do:


I set the tcp to listen on 10500 in this case.


I just now re-read this for 10th time and I just want to clear this up in case there is a misunderstanding…

There is only a conflict if you have the same serial port configured in the PAC Control Strategy and are using commands in the strategy to address that comm port.
If so, you have two programs, PAC Control strategy and Node-RED, addressing the same serial port and you will not get the results you expect in either.

Running PAC Control and Node-RED at the same time is not a problem.

Put more simply, you would see the exact same behavior with PAC Control and Node-RED both controlling the same digital output point… It could be done, but you better know what you are doing. < grin >

The method @philip points out is a great solution as you will only have Node-RED accessing and controlling the serial data via the hardware module, but you will have the exact serial data in PAC Control to do what it needs. (Flip Philips solution around if you need PAC Control to write some data back out the port at any time).

Thank you for explaining further. I am indeed going to try the solution mentioned by @philip but got dragged in another direction this past week (Amazon Web Service headaches, anyone?) and have not been able to get back at this. Will try to do so soon and report back.

So here I am ~8 weeks later and about to resume working on this.

Here is my Communication Handle in PAC Control:


If I want to have the PAC Control comm handle connect and listen on the TCP socket instead of the serial port, what do I change / configure in the above?

Also, it is in this block where I use the above Communication Handle. I presume that once I sort out the above, the rest of the PAC Control strategy will run fine.

You set your comm handle to the IP address of the device running Node-RED with the port that the node is listening on:


1 Like

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.).

Verify that USB is enabled:

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.