Listener Data Source for Radio/Analog Architecture?
We're testing new Radio/Analog hardware that pushes a value every x seconds. We have set up a TCP/IP data source to poll the IP:port every x seconds, and we get most of the packets, but miss quite a few as well.
When working with the vendor, they performed a couple tests and were able to get 100% of the packets. The packets are being sent by a 4-20mA unit. They used Node-Red to view and capture packets, as well as TCP/IP viewer. Both got all the packets.
I was wondering if there is some sort of listener data source that we could use to keep an open connection to the port:ip and record all packet values as they are updated.
terrypacker last edited by
@cmusselm if they were HTTP requests you could try the HTTP data source(s) or in 4.0 you can write a script in the filestore and process POST requests with it. Since you didn't mention that I'll assume they are some custom TCP/IP protocol of the device.
You could try using a Serial data source (which is event driven by messages on the wire). In this setup you would use either a physical TCP/IP to Serial converter or try a Mango Virtual Serial Port listening on the chosen TCP Port.
Thanks, Terry, for the suggestions. I'll check these out and see if we can get anything going.
Is the comment you made here: https://forum.mango-os.com/topic/4691/virtual-serial-client/24 still valid? This seems like the exact situation we have.
This device is a black box, and cannot connect to our IP:port, we have to open a socket to it and just listen to capture packets that it sends out. Based on your note, it sounds like using a Virtual Serial Client with a Serial data source won't work.
If that's the case, is the only real solution to create some middleware/applet that connects to the host and reads the data, then pass it along to Mango in a way it can read?
We thought that if the device passes data every 6 seconds, and we use a TCP/IP Data Source to poll it every 3 seconds, we'd be guaranteed to get all of the packets, but that actually made the results worse, and we got fewer packets than when we had it polling every 6.3 seconds. (Don't know why adding the 0.3 seconds makes a difference, but it definitely does.)