Arduino cluster functionality - feasibility advice for arduinos to communicate using variable-length long strings?

Question

My apologies. This is my first time on this site and I wasn't even aware that it wasn't some sort of discussion forum until receiving the automated response message to my already submitted vague and open-ended question.

Thank you Nick Gammon for pointing out Wanago's very interesting project, and I am sorry I did not provide enough information to show the difference in requirements. His solution is quite strictly structured and rigid (not just physically). But I wish to provide a solution that might allow anyone to fairly easily create an ad-hoc collection of any available arduino compatible hardware - which could also allow use of ESP devices for additional functionality if wished, but would not require ESPs as a means of connecting nodes. There may be a better solution than your RS485 Rolling Master for connecting nodes, but yours is the best solution I have yet seen so far, and not least because of the minimal resources required.

Thank you JBulmer for your clear overview and assessment, which does now give me a point of focus. In order to pursue this, I must try to aquire sufficient skills to add some form of multiple-chunk protocol layer on top of Nick Gammons Rolling Master protocol. I don't know if I'll manage it because I'm a hacker not a programmer, therefore I would appreciate if I could give my reasons for trying, because I would very much value your opinion as to whether you think it would be worth my efforts or not.

Nicks protocol already provides auto-negotiating of nodes and takes care of most fault-tolerance type issues. I believe it auto-detects nodes and assigns them IDs which are stored in each individuals EEPROM, so he has already taken care of most of the connectivity side of things.

And I think the main reason for him using a defined message length was in order for all nodes to be able to poll in timeslot sequence for opportunity to transmit as master, which means it ought to be possible to somehow sync up re-constitution of split message blocks.

So apart from the protocol extension for handling of long strings, I don't see any other major obstacles which I can't imagine a solution for in principle even if not yet aware of how. I hasten to add that I am pushing myself way out of my comfort zone to try to achieve this because I think (though perhaps wrongly) that it might offer much benefit to ordinary arduino amateurs (such as myself) who I feel arduino is mainly aimed at. So the following example is not any specific requirement of mine, just something to illustrate some of the potential that could be offered to non-professionals - hopefully after the initial scene-setting, things can become more apparent...

The majority of arduino project examples use the serial monitor as a quick and easy way for user interaction, which can then be expected to need customising for more practical methods of input and output - but clustered nodes communicating serially might allow many project examples to be used almost as is.

An Infra-Red sender makes a good starting point. The IRremote library IRsendDemo.ino monitors the serial port for a keypress then calls a send routine, eg: irsend.sendSony. The incoming serial trigger could be made to be anything the user wished to use as a command, such as MyIRblaster, and could also include an equivalent text string of any required parameters for appropriate data conversion before use, ie: MyIRblaster Sony(0xa90, 12) All this can be developed and tested in independent isolation using the serial monitor, then when happy, add a 'common' block of RS485-based cluster-talk code, allowing any other node the ability to then send it a MyIRblaster command and parameter to action when needed.

As the IR arduino is using the IRremote library anyway, we may as well also give it an IRread capability, which wouldn't even require any associated trigger command.

It would be an advantage to be able to save IR signals somewhere though, but trying to squeeze on additional SD and FAT libraries as well as IRremote might be a step too far, so perhaps better just to add a separate SD node for storage. The SD node could have a file of saved IR codes, perhaps each with an asscociated corresponding simple text description such as TVmute, and have a suitable command+parameter capability added such as "SendBlaster (name)". This would allow any node to issue eg: "SendBlaster TVmute" to the SD node which in turn could issue a corresponding MyIRblaster Sony(0xa90, 12) command to the IR node.

And similarly to action any other types of node functionality for that matter - it would be relatively trivial to add some relays to the IR node if wished, and make the node recognise a "Relay (name)" command+parameter for instructing it to control any relay as required.

But it would also be just as easy (if not easier from a software point of view) to add a separate Relay node if wished. And similarly, even a Trigger node perhaps offering 64 channels of interupt-driven inputs - which also wouldn't need to recognise any incoming command, just simply be able to issue perhaps a 'Triggered' command plus appropriate triggered channel number as a lookup instruction to the SD node. Every trigger input could be assigned its own corresponding list of responses in its config file entry, which could include any of the functionality that any of the nodes could respond to.

Adding new functionality to the cluster would be as simple as adding another command keyword to a relevent nodes list of commands to be parsed for, which when matched would branch to an appropriate internal function.

So adding a "WriteLOG" command to the SD node (and having it parse for an accompanying "Details" parameter) could provide a facility for every node to be able to record events to an event log just by sending the serial command "WriteLOG (details)"to the SD node.

Commands don't have to be external, they could include any locally recognised macro-type commands for accessing any of the internal capability. So for instance the SD node could recognise a "Pause (duration)" instruction to invoke a non-blocking delay if wished. This could allow the SD node to send multiple IR code commands with pauses between each transmission. It might also recognise a 'No_Retrigger (duration)' timer to prevent unwanted repeat triggering of PIRs etc.

To better appreciate the potential now, we could create a config file on SD that contains an appropriate channel entry # for every trigger input we might wish, be it IR receives, PIRs, switch contacts or whatever. The channel #3 doorbell entry could be something like this...

3 Doorbell, No_Retrigger (3mins), MyIRblaster (TVmute), Relay (Porchlight) (ON), Relay (Doorbell) (ON), Pause (3secs), Relay (Doorbell) (OFF), MyIRblaster (TVun_mute), Pause (5mins), Relay (Porchlight) (OFF).

If the SD node receives a 'Triggered Doorbell' instruction it simply parses the corresponding #3 entry and sends any extracted commands out for the other nodes to action as appropriate. In this case it would ignore subsequent PIR retriggering for 3 minutes, send commands to mute the TV, turn on the porch light, ring the doorbell for 3 seconds, unmute the TV, then turn the porch light off after 5 minutes. It could also easily include simple local conditional logic to only turn the Porchlight when dark etc, which could allow option for appropriate qualifiers to a commands parameters, ie: Porchlight (ON) (IF_dark).

PIR sensors could select CCTV cameras, or even send IR commands to point a PTZ cam to preset positions, and all using just the same cluster functionality being used above.

A voice node might be added to givie an "Announce (message)" command, then add appropriate config entries to provide appropriate voice announcements for any triggered events.

Even amateurs could evolve quite sophisticated flexible ad-hoc systems without needing any rocket science, and without hardware constraints other than needing cheap RS485 adapters and sufficient memory for running the protocol and parsing out any commands plus conversion of any parameters.

Although the SD node in the example above is tending towards becoming a systems co-ordinator, it is still just essentially another cluster peer node. But perhaps there could be good grounds for trying to modify Nicks Rolling Master to take advantage of what benefits an SD intelligent controller might offer, such as newly connecting nodes automatically obtaining assigned IDs plus other 'characteristics' and 'behaviour' from the centrally managed SD config file.

I'm willing to roll up my sleeves and prepare for the long slog if the concept is considered realistic and worthwhile, but I would certainly welcome informed opinion as to whether it might be or not.

-------Original---------

I am looking into the feasibility of linking multiple Arduinos together to form a cluster of Arduino and ESP8266 nodes capable of sending sequences of plain text commands plus optional parameters to each other.

This could offer a mechanism for any node to be able to access the functionality of any other node without having local burden of that functionality.

For instance, only the SDcard node would require the libraries and overheads for accessing a centralised config file on SD card, but any of the other nodes could request appropriate entries from the config file whenever needed, or have ability to write event entries to a log file.

Similarly for an InfraRed node and its IR libraries, allowing any other node to send it plain text commands and parameters to transmit any required IR code even though the other nodes don't have local IR functionality themselves.

Basically, each individual arduino might just be considered a black box that does something useful and can be programmed to respond to certain external text commands (so in fact any other platforms with similar blackbox functionality could also easily be integrated to the cluster if wished). Each node would parse an incoming string for a command that matched any of it's own local list of recognisable commands (ie: IRsend [code]) then branch as appropriate with any extracted accompanying parameters.

A cluster could be built up to include any and all required arduino functionality even though all of that functionality could never be squeezed onto any single arduino.

So an automation cluster could include things like voice announcements, web access, X-10 firecracker control etc just by including the appropriate nodes. Then tomorrow a voice recognition node might be easily added - needing to do nothing more than just issue appropriate text commands to also invoke any already existing functionality.

In principle, anyone could have the capability for doing almost anything they might wish, so although I don't know if this cluster functionality idea can be practically achieved or not, but the possible potential offers much incentive for trying.

And Nick Gammons excellent RS485 Rolling Master article brings the possibility so tantalisingly close... but it uses fixed-length messages to achieve it's clever self-negotiating fault-tolerance, and I'm afraid I don't know enough to be able to merge variable-length long string capability with his enticing communications system.

So I would appreciate any suggestions, even just informed advice telling me to forget it because it cannot be done (cos at least then I'd be able to get some sleep!).

Thanks, Robin Baker.

Answer 1

Someone (Wanago) has done a similar project here. However instead of ESP8266 he used I2C which sounds more practical to me.

See images:

He had the same basic idea - each board has a specific task, and the work is shared between them.

Answer 2

Many communication systems use fixed-length, or limited-length, data exchange at the lower levels. For example, the ethernet network, under TCP/IP, has a maximum package size of 1526 bytes.

However, that doesn't prevent us moving large chunks of data, e.g. a DVD across the Internet.

A common approach is to use a layered protocol suite. Each layer is responsible for providing a service to the higher layer by using the service of the lower layers.

We talk about layered protocols because it provides a powerful, yet simplified way of thinking about communication problems. Rather than get bogged down in lots of detailed issues which need to be solved to work, we try to organise the problem into simpler and simpler solutions. Eventually things which we can implement without too much difficulty can be built, then higher layers are built from the simpler capabilities of lower layers.

The highest level of your protocol would provide the sort of service you need. In this case, you want to be able to send long-ish string messages, so the highest level would do that by using a mid-level fixed-length service.

In its turn the mid-level fixed-length service might provide error-free fixed-length messages using a still-lower-level service which can move fixed-length messages, but can't correct some types of errors.

(This is just an illustration of the idea, please don't take this as a concrete suggestion on how to implement anything.)

So, don't think "I don't know enough to be able to merge variable-length long string capability with his enticing communications system"

Instead, ask the simpler question, "how could I use that existing fixed-length communication system to send variable length strings?"

The answer might be pretty simple if the underlying system guarantees the order that messages are received. For example, send a count of the message length (in one or more messages) then send that number of bytes. The receiver knows how much to expect, and needn't act to interpret the data until it is received.

Then how to tell the difference between the command and its parameters? The command might be the first 'parameter' in the string, and parameters come after it.

The way I interpret your question, there may be several problems beyond sending variable length strings. There are potential problems like: adding or removing nodes, nodes failing, allocating 'names' to services on nodes (so commands can be sent to the appropriate node), etc.

However, the fundamental problem of sending long strings over a fixed-length communication channel is straightforward, and can be solved in a few different ways (I mentioned one, above).