Hello!
Most likely topics like this have been answered a 100 times before elsewhere, please feel free to yell at me.
I'm building a (surprise coming) home automation system, with multiple arduinos communicating over a common bus of a twisted pair of (originally part of a UTP) cables. (All devices will be on common ground additionally.)
I have bought a couple of RS485 modules, and I know I can just use Serial, but I'd like to spare myself of building up a whole communication standard.
Ideally, I'd like to achieve the following things:
Send 'instant' short status updates (when something changes: solenoid opens, relay closes, etc), or user commands
Periodically (5-10 sec) send bigger data packets (readouts from multiple DHT / OneWire sensors, state of all components)
Be able to address messages to one node, or to all of them
Handle losing and regaining connection to a node
Be relatively easy to comprehend (have a library available)
I have a Mega as the master and unos/nanos/megas as slaves, all behind RS modules. Currently there would be 3 slaves, but the system should be able to be upgraded to 10 slaves max. The furthest away slave is in ~40 metres (in another garage building).
I have heard of a rolling master solution, but that would not allow for drastically different message sizes and delay requirements as I understood. I've thought of the master pinging all slaves one-by-one, that would lose the instant factor and messages would pile up in buffer.
So with all this, what do you recommend, and which of my requirements must I give up on?
The command structure and parsing itself I'd gladly write, I just need something to relieve collisions and such.
Thanks for any help or redirection to another forum thread where similar issues have been talked about in detail.
All communication protocols are based on what wildbill told you. More complex will start with error detection and recovery, but that may or may not be necessary depending on your physical environment.
Be aware that including a common ground to all your devices may find some with slightly hot grounds due to electrical wiring problems. RS-485 was designed to avoid that. But you can discover that as you deploy the slaves.
Thank you for the replies!
The sense I'm getting from you is that there is no easy and straight forward way to implement a multi-master protocol. Since I'm not very experienced with this stuff, I will not attempt this now.
My plan right now is to have the master poll the slaves, but after one gets polled, it can send as many and as long commands as it wants, and then will send a finish command.
If a slave doesn't respond in 200ms, it will be considered offline.
Every 50 cycles all offline slaves will get a poll too, so they can become online again.
If I don't forget, I'll post my code as it progresses, if somebody is interested. It might take a long while, I have lots of other stuff to do.
If anybody else has an idea or a library to recommend, I'm still very much open to it!
Edit, a few moths later: I didn't have to develop the above stated system, right now I'm only using one node with a simple Blynk integration. Didn't have time to do more.
redyau:
Thank you for the replies!
The sense I'm getting from you is that there is no easy and straight forward way to implement a multi-master protocol. Since I'm not very experienced with this stuff, I will not attempt this now.
My plan right now is to have the master poll the slaves, but after one gets polled, it can send as many and as long commands as it wants, and then will send a finish command.
If a slave doesn't respond in 200ms, it will be considered offline.
Every 50 cycles all offline slaves will get a poll too, so they can become online again.
If I don't forget, I'll post my code as it progresses, if somebody is interested. It might take a long while, I have lots of other stuff to do.
If anybody else has an idea or a library to recommend, I'm still very much open to it!
Try to include a space in each an every message for a slave address. And if doing multiple message from the same terminal, tell the master the sequence number of each message, beginning with zero. If
either the last message, or the ONLY message, make that message number 99.