Suggested (hobby grade) hardware architecture for process monitoring/mgmt (e.g. lots control i/o)

Hi folks. I'm tinkering with a process that will require a reasonable number of hardware integration points (temp/pressure/current). I've had very encouraging results with using node red on a Raspberry Pi to orchestrate this process, but am quickly going to exceed the I/O capability of a single board. (I'm also running into an issue with 1-wire polling causing everything to pause, but I think that might just need to be moved to a separate flow or instance of node-red)

So now i'm thinking about how to partition this a bit and leave node red on the Pi to do high level monitoring and control. My initial thought is to use arduinos to interface with the hardware, then put them on a common bus of some form to communicate with the Pi running node red. But then I think about the fact that I might end up breaking a lot of hardware-specific nodes that expect to talk with the device over a gpio pin or i2c bus. I also think about managing all of the sketches being a possible pain point as well.

Another option would be to find a big hat that expands what the single Pi can do.sufficiently to meet my needs. This is an attractive option if it just overlays the new I/O capability with existing (elg GPIO pins 30-50 or whatever) but then i start thinking about resource contention on the Pi.

I'm going to experiment with the arduino idea this weekend, but would love to hear from people that have gone down this path. Conceptually think of the application like a fully automated brewing station with mashing/sparging/boiling/pumping/etc all done by node-red.


Can you give us a better idea of what and how many sensors and outputs you need to access/drive?

The cheapest IO modules I could find was from King Pigeon. They have digital and analog input/output modules, maximum analog resolution is 12 bit (which is probably sufficient for your application?). They have a store on Ali Express.

Fair question but that's still developing. Minimally the following, mix of gpio/i2c/analog interfaces.

8-10 thermocouples (ds18b20 currently using 1-wire protocol)
2 hall effect current monitors (presently using a ads1115 adc over i2c)
2 load cells - tbd
2 solid state voltage regulators - pwm or dac driven
2 peristaltic pumps - unclear, probably gpio
2-4 servos

If you're looking to keep with 1-wire, take a look at unipi. They have some pretty good gear. I've used the 1.1 before, and I've recently used a neuron s103 model, both were a good value.

I've also used advantech WISE 4000 series modules in some applications and they're pretty good. The price is reasonable also.

WHy not use an Arduino Mega with an Ethernet shield (which becomes your common bus to communicate with the Pi) - you could look at an integrated solution like the Ethermega from Australia that is a Mega with Ethernet interface inbuilt - you could deploy a couple of these as needed.

If Wireless was an option i would personally look at multiple ESP8266 with one of the prepackaged flashes (EspEasy, Tasmota etc)


@RedShift - Thanks for the heads up on King Pigeon. Saw a few promising options after a quick glance through their pretty extensive catalog.

@gemini86 - Also thanks for the heads up. I like the Pi integration, will also look at their options.

@craigcurtin - I have a couple NodeMcu ESP8266's floating around here, might just try it out to see how it goes. I could be overthinking it.

Thanks everybody!

I originally did my setup similar to yours where i was using a centralised Arduino Ethermega and it was great - but keep the Arduino sketch under control was a nightmare - i have gradually migrated functionality from this setup to discrete NodeMCUs/Sonoffs and have found it much easier to manage and update/work with on an ongoing basis.


I use this and this as my starting point (cost is about $125). Your Pi will just fit into this board. From there, you can add a myriad of input / output modules to meet your needs.

There are so many ways you can achieve this, you will probably get a multitude of different answers.

A brief overview of my setup:

  1. Multiple RPi running servers (NR, VPN, Samba, MySQL, Grafana, NextCloud, MotioneyeOS, WifiAP .....)

  2. IoT nodes, mainly ESP series modules (started with ESP8266 - standardised on esp07s modules with external ant. for outside. Moved over to ESP8285 modules). These are all standard 2.4g wifi modules.
    Plus Arduino based MCUs with NRF24L01 wifi modules for long distance comms.

  3. I have also standardised on a dev PCB for the ESP07 for quick deployment.

The above setup is not that expensive, is reliable, and easily scalable. But is obviously time consuming to set up initially. You do not need to start big though, and you do not need industrial (read expensive) hardware either.

Whoa tons of options. Thanks!

Are you able to manage the software on these without pulling them out of the field? E..g if you update a sketch how do you write it to the device? I like the idea of having a gang of esp8266 or similar doing discrete chunks of work, but only if i build a setup where I can manage the firmware in-situ. LIke if i ran an ansible container on the pi to push sketches to all of them via wifi or serial, i'd be gtg.

Both the espeasy and tasmota firmwares for esp support Over The Air (OTA) upgrades.

To add to what @dceejay stated, the ESP range does support OTA in bare metal form as well. You can do it all yourself, without proprietary firmwares.Same with the Arduino.

There are also handy utils around like which allow you to OTA flash without the need of using your toolchain.

And of course, I left out the most important thing. All this can be controlled via NR. :wink:


@dceejay @Bobo - Thanks folks! I got an esp8266 up and running last night on tasmoto. Process was relatively painless once i realized that it had the usb->serial chip built in and i didn't need any additional hardware to upload the new firmware. (I tried the Arduino IDE approch first but Tasmotizer was dirt simple)

It's presently reporting weight from an hx711 to a flow via mqtt. I'd like to update the refresh rate a good bit and am still figuring out how to command it via the message queue, but overall this is very encouraging. The fact that i could put this in a little case and run it off batteries is even better.

Thanks folks for all the help and suggestions!

1 Like

And plus 10 points for pointing out Tasmotizer... not seen that before... very handy.

1 Like

The espXXXX approach gives you battery power, wireless connectivity, and good I/O performance but gets you into another software ecosystem. Sometimes, if all you need is more GPIO pins or an extra I2C bus, you can get by with a Pi Zero (with usb ethernet adapter) or a Pi Zero W running another instance of Node-RED. The cost is comparable, and MQTT makes comms simple across both environments.

Also think about distributing the control. If, for example, you have a vat that needs to be temperature controlled then you can use a Sonoff TH10 with a DS18B20 and run tasmota with the PID control built in (it uses the same algorithm as node-red-contrib-pid), then the control of the vat will continue even if the Pi or whatever doing the top level control temporarily goes AWOL.


Colin's last point is very important in that, ideally, each sub control module should be able to run independently of the master control. In addition to the sonoff devices you can Tasmotize a Wemos D1 mini to gain more IO pins. Personally for your project I would go the Arduino Mega route with an ethernet board (nothing beats wired!!) because of the high IO pin count, supreme flexibility and low cost. I would also use I2C devices for sensor / control functions. Two quickly come to mind ADS1115 AD and MCP23017 16 pin port expander. The latter is particularly good with the Wemos to get more IO. I would also suggest using JSON for your control messages using the brilliant ArduinoJson library.
All this happily integrates with MQTT, Node-RED of course! Grafana and use BLYNK on smart phone to change parameters. Lots to choose from and lots of fun!.

Chainduino is an option if you’re going down the Arduino path. It supports power and data over same cable and speaks rs-485 so good for long distances.

To make the programming easier, make a template and use the board identifier to make the code for that specific hardware. Having standard pinout would allow you to connect the same kind of sensor to any board. Use MQTT and then make the friendly names at your HMI.