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