Just started a project to do something more interesting with outdoor Christmas lights this year - so just under a year to deliver. I have several strings of addressable WS2811 and 2812 LED's (total 1250 lights and counting), some 5V non addressable strings, an assortment of 31V three wire icicle strings and 240V landscape spotlights. I have got the LED's working with Arduino Uno R3 and with Mega 2560 as separate units with FastLED - in basic routines so far but enough to see a way forward. I have also made a controller to emulate the PWM patterns of the dreaded 31V wall plug for the three wire sets and now control those with a bit more functionality and less mad flashing. Similarly, I have decoded the spotlamps' IR codes and now control those. I have 6 different controllers so far. I can combine some of them into a single Arduino but there will be at least one secondary controller or group thereof located about 30m away (or 50m cable run).
I have a number of controllers, all Arduino based and I am stuck on how to get the various controllers to communicate. I have looked at I2C which does just what I need but not over distance, I purchased some NodeMCU's, ethernet shields and an R4 ready for a couple of weeks study and trying out. So I have fired the parts cannon at the problem but without knowing what technology I should be looking at that is likely a distraction. I am reading about RS485, MQTT, OTA, etc,etc and going around in circles. Whilst I am doing this for fun and learning, I do want to end up with something tangible and I am looking for guidance. Specifically on what technology should I focus if I want to have say a master controller and one or more secondary controllers such that I can sync timing and maintain that and send commands. The objective is to coordinate instructions to several lighting displays.
For wired, low data rate I would consider RS485, probably with Modbus. Higher data rates you could consider Ethernet.
Wireless, probably wifi, but there are other radio methods that are simpler.
Thx your reply. Still in the foothills of learning curve, so I am not able to be specific but I envisage having a dozen illumination features whose output is coordinated - not that they will all do the same thing - but there does need to be a common timeframe. I am assuming that will require milli rather than micro s accuracy but the sync will have to be maintained. There will be two locations under control. For reasons of this layout I am thinking of two controllers each controlling its own components in the display with a menu of routines but one of the controllers will have to tell the other which routine to play and when to start and that plus, the clock sync is the only data transfer. It doesn't need to be wireless; I have heaps of ethernet cable and two shields on order.
Start with that device. Besides the controlling the other devices, it can also provide the syncing clock signal if that is what you want. Test your code with a single remote device until you get all the bugs out and then add another, one at a time, until all is tested.
I guess I wouldn't need to synchronise clocks if the controllers had nominally the same clock speed even if they were working to different sketches because they would get fresh instructions every few minutes? Not like a sensor waiting for hours for contact.
I don't think that the clock is that relevant; for all boards that are programmed using the Arduino IDE, e.g. the millis() function is what it is: 0.001 seconds. It does not matter if you're using a 8 MHz SparkFun Micro, a 16 MHz Mega or a 600 MHz Teensy.
We are dealing with communications syncing, NOTHING to do with the microcontroller. This to do the sync timing you asked about!
You do that with a signal to any digital pin and have your code watch and wait for that signal before continuing. What all that means to your project is up to you. But you will have sync timing.