Get yourself 5 ESP boards and some breadboards, total cost ~ £40, and a 5 port USB powered hub to power them. Configure the ESP-Mesh from Espressif and run their examples to get a basic setup going... then start building up your platform getting the underlying infrastructure right. ESP32 has the FreeRTOS operating system built-in so make use of its features too. Get MQTT installed and set up a simple topic structure for your server node to subscribe to as a listener and fit a couple of nodes with temperature sensors, eg DHT22 or similar, and have them publish their temperatures. I can't recommend MQTT enough as the basic plumbing, it'll make life a lot simpler for you - it runs on just about anything so making it easy to get data into your database server. Define your message structures and node classes (you are going to write this as co-operating objects right and not an unholy mess of spaghetti?). Before long you'll have the backbone of the functionality you need and a good
understanding of the system.

MQTT Overview and MQTT Basics/Tutorial

MQTT ESP32 example/tutorial uses Raspberry Pi as MQTT Broker, but I'd make your main server the broker in reality since most messages will be node <> server not node<>node

 

Get yourself 5 ESP boards and some breadboards, total cost ~ £40, and a 5 port USB powered hub to power them. Configure the ESP-Mesh from Espressif and run their examples to get a basic setup going... then start building up your platform getting the underlying infrastructure right. ESP32 has the FreeRTOS operating system built-in so make use of its features too. Get MQTT installed and set up a simple topic structure for your server node to subscribe to as a listener and fit a couple of nodes with temperature sensors, eg DHT22 or similar, and have them publish their temperatures. I can't recommend MQTT enough as the basic plumbing, it'll make life a lot simpler for you - it runs on just about anything so making it easy to get data into your database server. Define your message structures and node classes (you are going to write this as co-operating objects right and not an unholy mess of spaghetti?). Before long you'll have the backbone of the functionality you need and a good
understanding of the system.

MQTT Overview and MQTT Basics/Tutorial

MQTT ESP32 example/tutorial uses Raspberry Pi as MQTT Broker, but I'd make your main server the broker in reality since most messages will be node <> server not node<>node

Okay il try that. What do you mean make your main server the broker? My raspberry PI will be main server

 

OK, well that works then

I had assumed, wrongly, your database server was a PC or similar.

 

Re an earlier comment about teensey boards.

The teensey 4.1 is an 600 plus Mhz SBC, that has ethernet built in,

https://www.pjrc.com/store/teensy41.html

and its small

 

Yes, they are great boards, and fast. I I've used them as well. But theyre not that cheap ($30+) including the external Ethernet connector + cabling, when compared to an ESP32 Wi-Fi mesh at ~$10 a node.

Mind you, anything is faster and better vfm than an Arduino and a shield...

 

Thank you @Irving, I must have another look at the ESP32 , not looked for years, as they were to expensive.

 

Does data transfer using TCP/IP work both ways? Can I send data from the server to individual nodes and from the individual nodes to a server?

 

Yes of course.. Tcp/ip is the protocol that runs the internet. Most conversations are 2-way even if they appear not to be.

 

Cool. I have ordered a few esp32 dev boards and some sensors. Il see how it goes. Im a bit worried about signal interference when I connect 50 or so nodes at a close proximity

 

Shouldn't be an issue and Wi-Fi can turn the wick down based on received signal strength if need be.

I do a tutorial for a class of 30 on real-time IoT each with two Wi-Fi connections and never seen a problem yet...

It's very similar to the MQTT tutorial I linked above but with a central broker for all students running on a PC. They each have a link to the database on the main PC. They capture temperature, pressure and humidity from a BME280 sensor on the IoT board into MATLAB on their laptops where they graph the data and also log it in the database.

 

Okay! Thats cool. I really appreciate all the help and guidance here! I will keep posted what results I get. Might take a while for the order process to go through.. I had 1 weemos mini D1 device that I will try to find and play around with MQTT publish and subscribe to get a better understanding.

 

I suppose I should say 'did a tutorial' because this year is all distance learning so we're going to be sending kit out to students, conversing over Microsoft Teams and using a public central broker, either HiveMQ or a paid subscription on CloudMQTT.

 

I love the Wi-Fi solution - very reliable and robust

A bit late now but personally I would recommend RS-485 for a few reasons:
- There are isolated RS-485 modules / chips available
- RS-485 was approved in 1998 whereas Ethernet was approved late 80's early 90's so I am curious about the comments stating EIA-485 is older than Ethernet
- The system was designed for high noise environments specifically for industrial environments
-- https://blog.robotiq.com/what-is-rs485-communication-protocol
-- In fact the protocol is still widely used. Well, the systems I have worked on use it anyway
- The speeds go up to 20 Mbaud by standard and many manufacturers push this further (I have seen 50 Mbaud but the distance does drop to 20 ft)
- It is a multi-drop system which sounds like what you want
-- The spec calls for 32 "unit" loads where 1 U.L. = 12 kOhm. Sometimes ICs will specify (1/8) U.L. which means you can have 256 devices connected
-- https://www.ti.com/lit/an/slla272c/...31118&ref_url=https%3A%2F%2Fwww.google.com%2F
- Since RS-485 is multidrop you do not need any switches (which can become expensive)
- You can control the clock speed if the distance is too long
- You can use the modular connectors and cat5e/cat6 cables for transmission (impedance is close enough to spec in my experience)
- You can use more reliable connectors if need be (in terms of availability)

 

I love the Wi-Fi solution - very reliable and robust

A bit late now but personally I would recommend RS-485 for a few reasons:
- There are isolated RS-485 modules / chips available
- RS-485 was approved in 1998 whereas Ethernet was approved late 80's early 90's so I am curious about the comments stating EIA-485 is older than Ethernet
- The system was designed for high noise environments specifically for industrial environments
-- https://blog.robotiq.com/what-is-rs485-communication-protocol
-- In fact the protocol is still widely used. Well, the systems I have worked on use it anyway
- The speeds go up to 20 Mbaud by standard and many manufacturers push this further (I have seen 50 Mbaud but the distance does drop to 20 ft)
- It is a multi-drop system which sounds like what you want
-- The spec calls for 32 "unit" loads where 1 U.L. = 12 kOhm. Sometimes ICs will specify (1/8) U.L. which means you can have 256 devices connected
-- https://www.ti.com/lit/an/slla272c/slla272c.pdf?ts=1595079831118&ref_url=https%3A%2F%2Fwww.google.com%2F
- Since RS-485 is multidrop you do not need any switches (which can become expensive)
- You can control the clock speed if the distance is too long
- You can use the modular connectors and cat5e/cat6 cables for transmission (impedance is close enough to spec in my experience)
- You can use more reliable connectors if need be (in terms of availability)

All valid stuff, but that doesn't make the current solution less acceptable.

About the date, its interesting how things appear differently.

In 1983/84 I was working for a UK minicomputer manufacturer (long since vanished) on a factory automation project for a large UK car manufacturer at their London engine factory. They had a large number of PLC-like devices interconnected via a 9600baud multidrop network. While I don't recall the product details it was RS485-like in all but name. The problem was that the engine plant was so large it had exceeded the length of cable the system would reliably work over. Another division of our company had just signed a deal to be the European distributor of Sytek LocalNet20 RF modems; based on CATV technology it offered a 19.2k capability over a CSMA/CD network. Suffice to say it did the job stunningly well, despite major pushback from the other supplier and their pet client employees who made out it couldn't work because of all the interference from factory machinery. About 2 years later Sytek, who had been one of the organisations who worked in the background on the 802.3 10base5 standard, released an 802.3 gateway and async 802.3 modem under the same LocalNet20 branding. But we'd already made the decision and developed our next factory interconnect product on 3Com's 802.3 product offerings. The last project I worked on with that product was in 1987/8 for the data distribution of flight information to displays at Gatwick's North Terminal.

 

We have used RS485 for many years in our industrial control designs.
It was earlier that 1998. I think 1998 was a revised standard. The earlier one was at least 1983.
RS485 is very robust and a successful method of comms between devices. And the availability now of off the shelf isolated drivers just makes it better still.
So I second @sjsdorsay 's recommendations.

 

Thanks everyone for the answers. Since I have progressed with my project a little bit, I can elaborate a little bit:

So if I havent mentioned, the automation system that I am building is pack_to_light system to guide people collect certain items from certain boxes.

Why I like the wifi solution so far:

1.Since I have my raspberry PI running as a server and database, I can easily transfer data from each remote device to the server and database and vice versa.

2. When the system will be fully built, the remote devices will sit at a very uncomfortable position. I have implemented an OTA flashing so I can update/flash each device without the need of connecting a cable.

3. I am using node-red as UI and that makes very easy to monitor the current state of each device and etc.



4. Every device on the network is using the same source code, except that I need to change 1 line of code to give a device unique ID name. This unique ID is used for MQTT communications to sending and receive data between the nodes and the server.

I am not sure if such things (or even simmilar) are easily implemented when using MODBUS or simmilar communications.


I am not sure about the problems I am going to face when I connect more and more of these devices but so far everything is much simpler than I thought it would be. I could even switch to RS-485 if something goes wrong since all the ESP8266 devices that I use has a UART port so I should be able to implement RS-485 chain for them.
From what I heard, when connecting many devices to RS-485 chain, you face certain stability problems, especially when one of the devices fail.

 

You could easily have the same code for all devices by using MAC address (or just last 3 bytes) as name... its already got a unique ID!

 

RS485 is old school. It was in use way before 1998. If I'm not mistaken, it's a hardware protocol and many industrial software protocols and even other industrial hardware protocols are based on it. MODBUS RTU, DeviceNet, Profibus, et. al.

Just as Ethernet has many industrial protocols based on it. Ethernet/IP, MODBUS TCP, EtherCAT, ProfiNET, et. al.

I have worked with numerous existing automation systems and designed numerous new automation systems around both RS485 and Ethernet. My experiences have led me to standardize on physical ethernet for all new systems. That can mean Ethernet/IP, ProfiNet, or any of the others, as long as it's physical ethernet. All shielded CAT6 cable. I have much more reliability this way and ease of implementation is unbeatable. Well, maybe it could be beaten by WiFi, but wireless compromises reliability (in my experience).

In industrial automation, cost is not (or should not be) the primary driving concern. Safety, reliability, efficiency, initial cost, in that order, IMO. I personally would not design an industrial Automation system around Raspberry PI, Arduino, or other dev boards, and especially not over WiFi. If this is a home Automation project in my own home, certainly I would consider it. I will always be here to tinker with it, reset routers, unplug devices and count to 10, you know, all the stuff that we are used to doing with consumer electronics. But in an industrial setting, time and data are money. Every minor hiccup results in lost profits and as a system grows, these hiccups can culminate into a situation where your budget-based hobbyist-component system is costing your company or your customer more annually than a properly designed robust industrial system would have. AND you're the only one who can troubleshoot it. Maybe that's job security for you, but a begrudging client-customer relationship is not a sustainable business model.

PLCs cost money, but they exist for a reason. A PLC/PAC- based system on a hardware ethernet network, just... works. Out of the box. And for a long time, reliably, no fuss, no muss. The devices are designed to communicate with each other, they want to communicate, and they integrate seamlessly. The handshakes, routing, negotiation, etc. all happen in the background. Unlike with RS485 you don't need to worry about polling intervals, message buffers, etc. Very easy, very efficient, very reliable. I cannot stress those things enough.

If you're as hard headed as I am, then this is probably a lesson that you need to learn for yourself. Or maybe it's up the chain of command where the lesson learning is needed. I would encourage you firstly to abandon this Raspberry PI/Arduino over WiFi folly and go with tried & true Industrial Automation components, but if that isn't going to happen, secondly I would encourage you to forge ahead through the doors of the school of hard knocks. Learn everything you can from what lies ahead. Your system might work or it might be one big lesson; either way your time is not wasted. The knowledge and experience will be priceless. But the system will definitely have a price tag, especially if it has to be designed twice.

 

RS485 is old school. It was in use way before 1998. If I'm not mistaken, it's a hardware protocol and many industrial software protocols and even other industrial hardware protocols are based on it. MODBUS RTU, DeviceNet, Profibus, et. al.

Just as Ethernet has many industrial protocols based on it. Ethernet/IP, MODBUS TCP, EtherCAT, ProfiNET, et. al.

I have worked with numerous existing automation systems and designed numerous new automation systems around both RS485 and Ethernet. My experiences have led me to standardize on physical ethernet for all new systems. That can mean Ethernet/IP, ProfiNet, or any of the others, as long as it's physical ethernet. All shielded CAT6 cable. I have much more reliability this way and ease of implementation is unbeatable. Well, maybe it could be beaten by WiFi, but wireless compromises reliability (in my experience).

In industrial automation, cost is not (or should not be) the primary driving concern. Safety, reliability, efficiency, initial cost, in that order, IMO. I personally would not design an industrial Automation system around Raspberry PI, Arduino, or other dev boards, and especially not over WiFi. If this is a home Automation project in my own home, certainly I would consider it. I will always be here to tinker with it, reset routers, unplug devices and count to 10, you know, all the stuff that we are used to doing with consumer electronics. But in an industrial setting, time and data are money. Every minor hiccup results in lost profits and as a system grows, these hiccups can culminate into a situation where your budget-based hobbyist-component system is costing your company or your customer more annually than a properly designed robust industrial system would have. AND you're the only one who can troubleshoot it. Maybe that's job security for you, but a begrudging client-customer relationship is not a sustainable business model.

PLCs cost money, but they exist for a reason. A PLC/PAC- based system on a hardware ethernet network, just... works. Out of the box. And for a long time, reliably, no fuss, no muss. The devices are designed to communicate with each other, they want to communicate, and they integrate seamlessly. The handshakes, routing, negotiation, etc. all happen in the background. Unlike with RS485 you don't need to worry about polling intervals, message buffers, etc. Very easy, very efficient, very reliable. I cannot stress those things enough.

If you're as hard headed as I am, then this is probably a lesson that you need to learn for yourself. Or maybe it's up the chain of command where the lesson learning is needed. I would encourage you firstly to abandon this Raspberry PI/Arduino over WiFi folly and go with tried & true Industrial Automation components, but if that isn't going to happen, secondly I would encourage you to forge ahead through the doors of the school of hard knocks. Learn everything you can from what lies ahead. Your system might work or it might be one big lesson; either way your time is not wasted. The knowledge and experience will be priceless. But the system will definitely have a price tag, especially if it has to be designed twice.

I appreciate your comment. I actually had a glimpse at a PLC based solution. But since I havent used PLC in my life neither I have any knowledge about it, I thought I might use something that I am more comfortable with.

Since the price is not a major problem for this project, I could easily switch to PLC solution and try out few things there and see how it works..

Could you help me imagine how the complete system would look like if I used PLC solution.

The way I currently Imagine the system is I have lets say 10 boxes to control. Each esp8266 module is connected to one of the boxes. ESP8266 measures the sensor values and toggles the light to signal the operator which box to take item from.. So this is a basic idea on how it all works. Obviously raspberry pi is doing more things such as running a database ,webserver, telling each esp8266 what to do and etc.

Could you help me imagine how the complete system would look like if I used PLC solution. I mean give some hardware examples on which components could be used since I have no experience or knowledge about PLCS.

 

Strantor;
Fully agree with your very wise advice on “the school of hard knocks”.
Haven’t most if not all of us, when we were young and fearless and ignorant, been there at least once?
The hardest knock is the cost of doing it again, paying stuff from your own pocket, with an upset customer giving you a hard time and working nights, weekends and even holidays.