Hi
I have 2 Arduino YUN's connected on the same network now and I am trying to write sketch to get a command from one to turn an led on on the other. From my laptop I can send the following command via web browser HTTP://IP address/arduino/digital/12/1 to turn a LED on and off.
How do I put this same code into a sketch so that if a push button is pushed on the other arduino yun it will turn the same LED on and off?
Thanks for any help. 
I can think of a couple things you can try, maybe some other folks will chime in with other ideas.
To lessen the amount of code in the sketch, you can do it from the Linux side of the Yun. This would be a particularly good idea if your system already has some Linux side code involvement. Here is one way:
rhammell:
To make a URL request from a Python script, you can use the urllib module. To do this, first import the module at the top of your script and then open the URL using the function urllib.urlopen(). For example:import urllib
urllib.urlopen("http://root:arduino@127.0.0.1/mailbox/Hello from Python!")
You can automatically send the username and password to access the REST API by including those pieces of information before an @ symbol. If you turn off password protection for the REST API in the Arduino web panel, you can simply call:urllib.urlopen("http://127.0.0.1/mailbox/Hello from Python!")
In your case, you would substitute the URL to access the other Yun, including its IP address, but the call should be the same.
If you want to do it all in the sketch, then the HttpClient class might be what you're looking for. You can use it to send the URL, as in the example in the link, and you may or may not be interested in looking at the response.
I'm sure there are lots of other ways, as well.
Thanks for the ideas. I will go read up on them and see how things go.
Cheers
Still struggling............
Done lots of reading but I am not that switched on with which functions to use. I have set up one Yun as master and one as client.
I need to send a command from the master Yun that when a push button on the master is pushed it send a command to the other Yun to digital write to a pin to close a relay which will in turn on a light.
HELP needed.........
First off, I'm going to assume you know how to read and respond to a push button press on the master node, and how to control the output pin and relay on the remote node. If not, look at some of the basic digital I/O examples.
There are many ways to do the communications. It's easy to send a simple command as you are currently talking about. But the question is what is your end game? What additional things are you likely to do with this project? The best solution can vary depending on a bunch of questions:
There are many ways it can be done. Just about all of them can be implemented in the sketch side, or the Linux side. If you do it on the Linux side you have more power (faster processor, more RAM, and lots more code space) and you gain efficiency (anything done in the sketch has to pass through the Linux side first.) While the Linux side is more powerful, it's harder to find examples that are directly applicable, while there are many examples on how to do these things in a sketch. So, for this discussion, I'm going to concentrate on the sketch side examples, but that doesn't necessarily mean I'm advocating it as the best way to do it.
A simple way to do it is to use a REST API. This has the advantage of being relatively easy, and it has the advantage and disadvantage of being synchronous: the master won't continue on with what it's doing until the remote has finished its work. This is an advantage if the master needs to wait for a response telling that this did or did not work properly, but it's a disadvantage if the master should go on to do other things while the remote is processing the request. To get started, you can use the Bridge Example on the remote node. The example as it is now gives you low-level control over all of the I/O pins. You could use the example as is, or you could use it as a template for creating your own list of commands. For example, instead of the current command /arduino/digital/13/1 to turn on pin 13, you could give it a more meaningful command like /arduino/relay/on. You can use an ordinary web browser to test the code on the remote node. Once that's working, load the HttpClient Example on the master node. Change the URL in the code from "http://arduino.cc/asciilogo.txt" to the command you used in your web browser to control the remote node, and now the master will be doing the same thing.
If you need the master to keep on doing other things while the remote node processes the request, you can use the Bridge Class to read stored key values on the remote node. You use commands of the format http://address/data/put/key/value where address is the address of your remote Yun, key is the name for the stored value, and value is the actual value. Then, in the remote node's sketch, you would call Bridge.get() to read a specific key's value into a character buffer. You would then look to see what is in that character buffer and respond appropriately. For example, you could use the URL http://arduino.local/data/put/relay/on to store the value "on" under the key "relay" allowing you to call Bridge.get() with the key "relay" to read the desired state of your relay. The advantage here is that the master node makes the request and moves on, while the remote node can be busy doing other things. Eventually, it will read the key value, and act on it. The disadvantage is that the remote node isn't told when that value changes: it either needs to track the old value and see when it changed (important if the value is some sort of command that should only be done once) or if it's a simple state value like a relay state, it doesn't matter if the output is set to the same state over and over again. Once you have the remote node working and tested using a web browser, you can once again use the HttpClient Example as a template for making the master node send the command to the remote.
Depending on your needs, a potential disadvantage of that last method is if the remote node is busy and doesn't get around to reading the key value quickly enough, the master could update it a few times, and the remote would only see the last value. This is not an issue in the case of the relay output state. But if the values can come in quick bursts, and it's important for the remote node to see every value, then the MailboxReadMessage Example could be interesting. Sending commands to the remote node is similar, for example http://address/mailbox/command would send "command" to the remote node's mailbox. The remote node would call Mailbox.readMessage() to get the message and act on it, similar to what you would do with Bridge.get(). The advantage here is that if a burst of messages come in faster than they can be read, they will all be waiting to eventually be read in order.
All of these methods will work with occasional data, and they have the advantage of being easy to test the remote node using a web browser. If you know that the remote is fully working properly, it makes it much easier to debug things when you bring the master node into the picture: if it doesn't work, the problem is probably in the master node's code. If the remote node isn't fully debugged and tested, then if there is a problem, it makes it much harder to determine if the problem is in the master or the remote node.
But what if there is a large amount of data being sent frequently? The overhead of making an http call for each action might become an issue. Also, what if the remote node has to send data back to the master, but not in response to a direct command? A solution is to open a socket between the two nodes which acts like a serial port connection between them, but is over the network. You could use YunServer and YunClient objects on one side to accept an incoming connection, and a YunClient object on the other end to make the connection. Once connected, whatever one side writes to the YunClient object will be received on the other end - it works in both directions simultaneously. This is a more advanced method, and takes some programming effort to work out and implement the messages sent in both directions, but it can be very efficient and powerful.
These options are listed roughly in order from easiest to hardest. The first ones are easy to implement, but the later ones are more powerful. As stated in the initial series of questions, it all comes down to where you are planning on going with this...
I thank you very much for your help and I now have a little better understanding of the functions you have mentioned and what commands to use in each one.
I would like to, down the track, advance this system to multiple commands to and from multiple Yun's via one master but for me to learn this is heaps at one time.
Now to answer the following questions:
The second YUN does not need to respond very quickly and there is only an on and off command (possibly only 3 times a day) to be sent to the remote Yun with indication of on and off to be returned to the master.
Just a push button at the master to send a command to the remote to turn it on and then an indication back to let the master know that the light is on and then one push button at the master to turn off the light and an indication back from the remote to say it is off.
I know some people could probably write this sketch in no time but I am a real beginner and i am still trying to understand as there is a lot in it for me to digest.
Thanks again for all your wisdom and time. Please don't hesitate to give me any other pointers as it will help my learning process.
Cheers