I have a project which involves a series of boxes, each with their own light strip, which will (hopefully) communicate between each other. I would like each box to get a 'start' command and, when finished lighting the LED's in a strip, transmit a 'start' command to the next box.
I have been fiddling with the ESP8266 wifi doohickey for the past few days, but after looking at the complications of Soft Access Point and Stations, I have reached a dead end in capability and understanding of the scope of what I want to achieve.
So what I am asking is which protocol I should be using for this kind of project. I was thinking OSC, allowing future work on the development of this project (ie, controlling floodlights over the various boxes so they turn off when lit from inside)
There will be between twelve and 25 of these 'boxes' in a given installation. Each will be battery operated (recharged overnight with a 10000mAh battery).
Do I set each up as an soft-access-point/station (which apparently you can do) or as only soft-access-points (letting me access each one by name)
Do I use TCP/IP or will OSC be better to send complex controls?
Is an Arduino/ESP system the best way to achieve this (I have raspberry pi zero w's as well, but arduinos are more robust)
I am hoping to collect the completed process in a github as the online solutions currently available don't really suit my needs.
Right now I am using two arduino Mega 2560's for initial testing, two ESP8266-01 wifi modules and an open-smart USB to ESP-01 adapter for flashing.
It's not clear how much I/O you need at each "box". Maybe the ESP8266 without an Arduino board would be sufficient?
If not, then I wonder if you actually need WiFi at all or if the simpler communication using nRF24L01+ transceivers would be more appropriate. If interested, have a look at this Simple nRF24L01+ Tutorial
If you do wish to use ESP8266 modules and if an ESP8266 on its own is sufficient and if the communication between them is limited then you may be interested in the ESP-NOW capability.
I'm not sure if an ESP8266 module by itself would be able to run an AP102 (?) LED strip. The arduino Mega may be overkill right now, but it's easier to program a paired set of boards while testing communications (and I already have them)
The idea of the light moving through the boxes (one pixel moving along a strip) is only part of the final concept. There will be other commands needed to light specific LED's, and in some cases a box may encompass an entire room (the LED's casting a shadow on a wall as they move) and in some cases servos may be involved (to be done) For now just understanding the method of sending a start/stop command between 2 or more is what I need.
While those nRF24L01 do look interesting, I am unsure if they will make things easier, or figuring out how they work will take more time. They are also not carried locally (discontinued). The code you have linked to (thank you) appears to be driven by 2-way communication. Since it is broadcasting by radio, can these be used with multiple arduinos to choreograph their behavior?
gersart:
Since it is broadcasting by radio, can these be used with multiple arduinos to choreograph their behavior?
You need to explain in more detail what you have in mind.
You can easily arrange for a master nRF24 to send a message to several slaves by giving all the slaves the same address.
Or, if you need two-way communication or confirmation of reception, you could arrange for the master to call each slave in turn. A single message with an acknowledgement takes less than 5 millisecs.
You could use a single master nRF24 with several slaves that all use the same wireless address but have a different software node number.
The master sends a start to the first node and it replies to say the message was received and sends another when the LED sequence is finished. The master then increments the node number and repeats. If a node does not reply within an expected time the master moves on to the next node.
Another option is to give each node a number and when it receives a start message that matches it's node number it does the LED sequence then increments the node number and re-transmits it for the next node.
The ESP8266 -Now looks interesting, as long as there can be more than one slave.
The system you describe for nRF24 could (theoretically) be done with the ESP8266 modules (which I have) in much the same fashion. Each of those could be set up as a Soft Access Point as well as a Station.
I am exploring how to incorporate multiple raspberry-pi-zero-w's into this concept of boxes with travelling light. While I prefer the idea of a controller specific to the task (arduino designed to do just this one thing) the Raspberry pi's may give more control.
And I still don't know the protocol to use for communicating this, which was the original question.
gersart:
And I still don't know the protocol to use for communicating this, which was the original question.
Do you mean that you want a "cascade" of action as in A starts B, when B is finished it starts C, when C is finished ....
You could do that with nRF24s with B listening for A and in due course sending a message to B
I'm not sure what would be the best way to do the same thing with WiFi. Maybe use one device as a central server that receives GET requests from the others acting as clients. All of the slaves could send requests effectively asking if its precursor is finished. When (for example) B is finished its request tell the server and that can then be picked up by C etc etc.
I'm not sure if there is a limit on the number of connections an ESP AP can handle but 12-25 of them seems a lot. Even using a wireless router that all the ESP's connect to so you don't need to create AP's is going to work hard for that many wireless connections.
Having slept on it, if I was doing this then I would probably use the one master many slave model I outlined above with nRF24s.
The other method I outlined where each node talks to the next in line is not so great because if one node fails you will get nothing beyond that point but with the master system a missing node can be stepped over.
Riva:
The other method I outlined where each node talks to the next in line is not so great because if one node fails you will get nothing beyond that point but with the master system a missing node can be stepped over.
Except when the master is the one that fails?
I think if the system is to be designed with resilience against failure a much more elaborate scheme will be needed.
However it would not be difficult for a slave to send a message to the master when it has completed its task and for the master to then send a "start" message to the next slave in line rather than have the slave send the message to the next slave.