I have the need for 3 "client" Arduino devices to communicate (both send and receive) with one Arduino master. I want to do this hardwired vs BLE or Wifi. I have lots of experience with Arduinos, ESP32, ESP8266, Particle, etc., but I haven't yet had the need to try something like this.
As far as some background, this is for a replacement security system upgrade. The master will replace the alarm panel (all hardwired sensors), and there are 3 remote keypads to each be replaced with an Arduino-driven touch screen. There are direct home runs (10 wires each) from each keypad location to the master location, so I have lots of signaling lines available. Furthest distance from keypad to master is about 50'. I expect to be using MKR1000's or similar devices.
Now the questions:
1-I've seen that one-way communication can be done between 2 Arduino devices. But can this be made to happen with 2-way communication and if so can you point me toward an example?
2-If #1 can be done, can I just have each client assigned a different I2C address and have them all on the same I2C bus?
3-Is 3 runs of 50' going to cause problems for I2C? The single I2C bus would essentially have 3 sets of lines in parallel extending up to 50' each.
4-Since each device could randomly decide to send information (either master to one of the clients, or a client to the master) - does this pose a problem? If needed I guess I could use one of the many spare signal wires to cyclically select each client for communication.
5-Would Serial be better? If so, could 3 clients live simultaneously on the same pair of Tx/Rx lines assuming I can use another signalling line to prevent multiple clients talking at the same time. Or would 2 of the clients hold the Tx line low while the other client was trying to transmit on it (or vice versa)?
Up to 32 nodes can exist on one RS485 Serial network, 1000 meter total length, very highl baud rates possible in the shorter realm. I've provided links to many others within the last two years on this forum, so search for those.
Take a look at CAN, it is a standard that works very well. You can go to about 4000 feet with standard components. The CAN control chip takes care of the overhead, decoding, priority, buss access, retrys etc without processor intervention.
What you're looking at is called multimaster. Multimaster in the Arduino world (or maybe the AVR world) does not really work. Further all devices must be "slaves" and only want to become "master" when they want to send. You're better off if the master polls the slaves (so the slaves only provide data when asked); I do not think that this will pose a problem in your scenario.
Serial (TTL signal levels) over longer distances will probably not work reliable although you can use slow a baud rate to improve.
For longer distances you can use RS232, RS422 and RS485. You can also consider wired Ethernet.
Although you can get RS485 working as multi-master, it requires a bit of work; see Gammon Forum : Electronics : Microprocessors : RS485 communications. Else it will have the same problem as with I2C where you can only have one master that polls the slaves. Again, I do not think that this will pose a problem in your scenario.
The CAN bus mentioned by @gilshultz does not suffer from this problem; it supports multimaster (reference: see Physical Organization in CAN bus - Wikipedia).
Your problem comes when two devices try to send data to the master at the same time. Connecting two outputs (Tx) together where one will send a HIGH bit and the other a LOW bit is unhealthy (you can work around this with resistors but that, to my knowledge, might pose problems over longer distances); it will also result in data corruption. This applies to TTL, RS232 and RS422.
Based on what I see, looks like RS485 will work. I found some detailed information on using a LTC1480 chip in a star configuration on a Github page & wiki from Nick Gammon. He also has a library that seems to address what I need.
Using that library, I can either set up a polling process to sequentially talk to each keypad processor and get any updates from it, or use a "select" line to each keypad processor to give each a chance to send information if it needs to.
Going to play with it to see which is most efficient and reliable.