I've been trying to digest Mikes idea of using linked lists, and trying to get my head around what would be needed... bearing in mind I'm not a programmer, so must use laymans logic.
First though, I seem to remember from somewhere that the serial buffer has an upper size limit (64 characters I think), so presumably my main priority must be to ensure I can keep pulling characters out of the serial buffer faster than it can be filled up, even though I may be too busy to do anything else with them at that time.
So my priority task is to keep on transferring characters from the serial buffer into a buffer of my own, which if I am understanding things correctly, could initially be an empty linked list with its start and end pointers pointing to the same address, and I assume that each character added would need to increment the end pointer.
But my main task is to look for the presence of a first-in delimiter in my linked-list buffer which I can remove along with any preceding characters, then use that delimited character string as appropriate. Which means I would then need to increment the start pointer according to how many characters were removed from the front of the linked-list.
I obviously can't just keep on incrementing start and end pointers indefinitely though, so presumably at some point I must make the end pointer wrap around to the vacated start, but as soon as I do, I think I would have pinned the tail to the nose and lost any ability for the linked-list to be able to expand if necessary (it makes me dizzy just thinking about this stuff).
The other thing I can't get my head around is how to keep track of an incoming delimiter.
It would be a great time-waster to have to keep counting forwards from the current beginning of the list when looking for the next delimiter (especially if one hasn't even arrived yet) so I guess it would probably be better to spot a delimiter whenever one is actually pulled from the serial buffer, and then record its absolute position in my buffer for later use. Can't do it for one without doing it for all though, else some could slip through and be lost, so presumably I would need a separate FIFO buffer to stuff any delimiter pointers into until they could be dealt with.
So am I pointing in the right direction with this, or just getting hopelessly lost?
In order to answer your previous questions, and help make things clearer, I'll step back a bit from specifics to give a better overall picture by way of an example:-
Lets say we have some PIR sensors, some relays, and an IR sender - all on different arduino nodes, all able to send plain text strings to each other, and all parsing any incoming strings for any recognised command keywords (plus optional data) against an internal list of recognisable commands according to their own local functionality.
Commands could be anything that any of the nodes have been programmed to respond to, so can easily include macro functions for things like timers and conditional execution dependent on other things such as Night or Day.
Rather than hardcoding these triggers and responses to any of the individual nodes, it would be more convenient for these configurations to be at a centralised and easily maintainable location such as a config file on SD. So lets add an SD node, and make it parse incoming serial for a command we will call "Action". If the SD node finds a match for "Action" during parsing it will know it also needs to parse out an accompanying triggering parameter, eg: "PIR3", which will have a corresponding matching entry in the config file. The config entry could be something like this...
"PIR3 (front porch): TVmute, Porchlight ON".
The SD node would then "Action" the appropriate "PIR3" entry by parsing out any delimited command strings and sending any it doesn't recognise as an internal command on out to the other nodes via serial port. So the IR node would then receive and parse out "TVmute" and transmit the corresponding IR signal, and the relay node would parse out "Porchlight" plus its "ON" parameter and activate the corresponding relay.
That is just a simplistic example to help illustrate the interactive communication between nodes for shared use of all available cluster functionality. But it also shows the open-ended opportunity for enhancement and expansion. For instance we could easily add a "Pause" command to the SD node for invoking an internal non-blocking delay function, and a "NoRetrigger" timer for preventing any unwanted repeat trigger actioning (both these macro commands would be accompanied by a specified 'duration' parameter). Let's also add a new voice node that recognises the command "Announce" plus an accompanying parameter. Now, the updated config file entry could be something like this...
"PIR3 (front porch): NoRetrigger 3 mins, TVmute, Porchlight ON, Announce Visitor, Pause 3 mins, TVunmute, Porchlight OFF".
That's already on the way to becoming an intelligent and useful automation system.
Obviously every trigger input would be assigned its own corresponding list of responses in the config file, 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 any 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)".
Sophistication could quickly grow, but so too could string length, hence the need for handling potentially long strings of variable length, and also for appropriate buffering to prevent anything being lost during the bursts of chatter caused by any multiple event triggers.
Assuming things are possible, it offers a way to take advantage of much more functionality than could be achieved by any lone arduino or ESP.
So I hope that has helped answer any questions and filled in any blanks guys, and I hope the concept is thought worthy enough of some support to help turn into a reality.