This might contain a few questions regarding this subject. Mostly just trying to gather some thoughts on the concept. I’m thinking of trying to setup a small program on an Arduino that will have some analog and digital inputs as well as outputs controlled by the Arduino program. There will be remaining empty io as well as some controlling of the Arduino program I’d like to do with node red. The Arduino has an ethernet shield and will be on the same network as node red. What would be the best way to communicate back and forth between the two. It’s seems there are a few options that can be setup on the Arduino including Modbus and MQTT, maybe others. Anyone doing something similar that would be willing to share some information on this concept? What if we simplify it one step further and pretend the Arduino doesn’t have any logic other than hosting the physical IO for NR? Seems like that should be a common application since Arduino price per IO is very cost effective.
Why are you even considering Modbus? Have you developed an affiliation for hexadecimal buffers since you posted that in another thread?
That's an effective strategy.
Keep your logic in one place and just exchange commands and sensor readings with your remote devices.
Personally I use ESP32s rather than Arduinos, smaller, cheaper and with on-board networking.
There must be advantages to Arduino boards but I've not discovered them.
I think most would agree that MQTT is the easiest way to communicate.
The advantages I see with modbus is versatility with other platforms and not requiring a broker. That’s one less thing to fail. There has to be a reason it’s commonly used on high availability control platforms still??? Regarding hex, I’ve built most of my electronics/programming knowledge in the automotive world so hex is already familiar because of my experience with can systems (possibly another option although not IP Ethernet based). With that being said, MQTT has been reliable any time I’ve used it and doesn’t require a spreadsheet to diagnose a month later. I guess that comes with the exception of having to restart the machine with the broker on it.
The advantage of Arduino over the ESPs is Ethernet functionality pretty much right out of the box with huge amounts of IO all on the same board. WiFi is cool, but again, just another point of failure. NodeRed <-> network switch <-> Arduino seems like almost the most reliable way to do this before going straight serial or can.
It wasn’t part of my original post but I’d like to be able to unplug as many things as possible with any application I’d use this topology for. I’m thinking things like building controls, compressor systems, HVAC, access control… Maybe high availability and Arduino don’t belong in the same category
I don't think I have ever known Mosquitto to fail.
It's called inertia, and maintaining compatibility with existing kit.
It sounds like modbus is the approach you are familiar and comfortable with, so your choice is made.
As I understand it, modbus is a serial protocol, so in order to work over ethernet there it presumably a process to convert it to TCP/IP at the origin and back again at the destination. No doubt it's totally reliable but nevertheless, one more possible point of failure.
Yes, you need to take special precautions with MQTT if you must not miss a message when the broker is rebooted.
A robust system should be designed to handle missed messages. There should be mechanisms to inform you if any component of the system falls silent.
My MQTT broker was last rebooted 120 days ago, but then it's Linux not Windows
My limited understanding of Arduinos is that they have zero network capability right out of the box.
For sure ethernet is better than wifi, as long as you don't run out of places to plug in the wires.
You didn't say if your question related to home or an industrial setting. If you have the network infrastructure, ethernet is the best option.
For what it's worth, ESP32s come with wifi but you can get them with ethernet on board.
How far apparat are the two appliances?
I have used serial to connect a Raspberry PI running Node-Red to a Arduino, controlling the IO on the Arduino and getting data from the ADC.
There is also now modbus over TCP, which is supported by node-red-contrib-modbus
@jbudd I don’t think my mind is made up. I’m just brainstorming the pros and cons. It sounds like your fear of hex has solidified your commitment to MQTT. Haha
I think technically you are right, there is some serial to TCP stuff happening on both ends but it seems like that is pretty much seamless at this point. Modbus pallet on the NR side handles this natively and Arduino has some libraries but I haven’t experimented with that yet.
Regarding application, in think both but never worried about a place to plug things in. Infrastructure gets built to suite. I’m looking for a more practical and reliable way to get big amounts of IO into NodeRed for cheap. It’s more of a concept than an immediate application but one of the first things I have in mind for something like this is monitoring the status of a multiple compressor pressurized air system in an industrial setting.
This sounds like something that could set me on the right track. How does it all work? Are there libraries for the Arduino and then just plug it straight into the Pi via usb/serial. What protocol do they use to talk to each other. I see openPLC has some software to do this that gets installed on both ends.
I think with modbus or mqtt I’d be building my own program for the Arduino to communicate with the IOs. Did you have to do that for serial communication as well?
Oh and to answer your question, specific application I’d like to develop the strategy on puts these parts pretty far away. I’d probably do the node red testing on a VM in one of my servers and the Arduino just on the bench. Future use for a setup like this could put these things close together.
You just send the data as plain text to the Arduino serial port, separating each metric with a symbol, something like
Use the serial node in node-red to connect to the Arduino (double check your port number)
In a function node
let data = msg.payload
let myArray = data.split("-")
msg.temp = myArray
msg.hum = myArray
msg.pres = myArray
msg.rain = myArray
As I know the order the Arduino assembled the data, I know where in the array my data is.
What does the data going the other way around look like? How does NR receive it? What is running on the Arduino side?
Both ways you send a string with symbols (delimiter) to use to split it up on the other side.
What are you running node-red on(PC, Raspberry PI)?
Really, it is so much easier to use MQTT.
delimited strings is so 1980s, inextensible, zero error-checking, error prone (i could go on)
And yes, the OP could add CRC checks, add length data, escape the delimiters, add quoting for strings vs numbers, add typings for booleans, etc, etc
The op could chose a protocol that has already thought of all these things.
@Billy_C If you are communicating over distance or to a VM, it is likely you will need something more flexible and more far reaching than pure/physical serial connection. That takes you to the next logical step - Ethernet.
Next, if you wish to communicate to other hardware (without Node-RED) then sure, head for Modbus or some other industrial protocol, however, if this is for communicating with Node-RED, then being an events based application, polling Modbus is not the ideal choice. Additionally, Modbus has no security. Additionally, search the forum for Modbus "connecting" issues to see your future!
Personally, I would favour MQTT for its simplicity, built in data integrity and number/string/boolean parsing OOTB, zero effort.
I'm looking for a versatile, reliable, cost effective solution to use for a variety of automation projects, mostly industrial type applications but certainly not limited to that. I'd like to avoid Wifi. Serial isn't totally out of the question for some of the applications.
MQTT has been rock solid for me as well. I have a large network of MQTTed devices at one of my properties that really hasn't missed a beat in about 2 years other than down time to service network devices and reboot the server. MQTT broker is on Home Assistant in that application. I've only messed with the QOS types a little so would have to do more research on that if it's is required for data integrity. I'll see what I can dig up for Arduino + MQTT.
The Modbus security thing is another great point. Modbus is pretty much just wide open. I've actually wondered about this for other applications. On an isolated system this seems acceptable, but assuming all these devices just live on a general network, I see the issues although I don't actually know the extent of venerability beyond just the Modbus data.
The idea of upload sketch, set IP, ethernet, start receiving and sending big IO within minutes to NodeRed sounds like a real awesome thing with tons of potential. Focusing time on programming and not messing around with IT stuff sounds fantastic.
Good old 1980
For connections a few millimeters via usb cable, I think you need forward error correction, security layer....
So if you need if flexible you can send it in json, there is a library for that.
Before everyone goes nuts, I still plan to explore MQTT for this application. In the mean time I had a chance to play around with modbus and it works pretty well. I had it working in about 30 minutes just using these instructions for the basic setup.
I don't have a vanilla Arduino in front of me right now but the Controllino should be similar.
Mudbus.h library (yes, it's spelled "mudbus" for this), the mapping is pretty straightforward.
Registers - 16 bit (number values)
- 0 is the address
- FC3 to read an input or output register
- FC6 to write an output register
Coils - boolean or 1-0
- 0 is the address
- FC1 to read an input or output coil
- FC5 to write a coil
There really isn't much else to it. Setup the Arduino with the libraries, set IP address, map all the IO to Mb.Cs or Mb.Rs and it's good to go. The standard Modbus pallet works out of the box on the NodeRed side, just fill in the IP and port info, the rest are defaults. I'll get a sample code uploaded when I'm back at the work bench. I'll also dig out the regular Arduino Mega with Ethernet hat to test but should be identical.