Arduino-Yun Wifi - Internet Commands?

Hello-

I've got a standard push button program connected to a NO relay which closes when the 'button' is pushed, thereby connecting my Arduino's 5v pin to pin #3.

This standard button program constantly monitors the #3 pin state.

On my Arduino is a Yun wifi shield already connected to my LAN. Because of the Yun shield setup, I don't really have an easy method of monitoring the shield via a serial monitor (nor do I think I need one). What I do want to do though is insert appropriate programming commands to send a call to this API at an internet site (if/when the button is pushed and the pin state = High). Here are the instructions (from the internet site) as to how to send the call appropriately so that I'll be notified by the website:

PushingBox API is really simple, to launch a scenario of notifications you can send an HTTP request or an email. The only argument you should attach is the DeviceID. This is the unique key that identify the scenario you want to launch. The DeviceID can be found on the Scenario Page.
You can also put more arguments to define customs notifications text using your own variables.

HTTP API

Using command line in a terminal

GET Method curl "http://api.pushingbox.com/pushingbox?devid=v0123456789ABCDE"

POST Method curl -d "devid=v0123456789ABCDE" http://api.pushingbox.com/pushingbox

With PHP
$ch = curl_init('http://api.pushingbox.com/pushingbox?devid=v0123456789ABCDE');
curl_exec ($ch);
curl_close ($ch);

Can someone assist me with inserting language in my void loop (below) such that my Yun shield, which is already connected to the internet via my LAN, will execute this call (above):

void loop() {
// read the state of the pushbutton value:
buttonState = digitalRead(buttonPin);

// check if the pushbutton is pressed.
// if it is, the buttonState is HIGH:
if (buttonState == HIGH) {
// turn LED on:
digitalWrite(ledPin, HIGH);
} else {
// turn LED off:
digitalWrite(ledPin, LOW);
}
}

Thanks in advance for any help you can provide... I'm thinking the POST method might be most effective, but I'm not certain how to set it up...

Take a look at the Bridge Library Process Tutorial.

That example shows using the curl command to retrieve an ASCII text file. You will need to change it to use the required command for your API service.

For example, something like:

 Process p;           
  p.begin("curl");     
  p.addParameter("-d");
  p.addParameter("\"devid=v0123456789ABCDE\"");
  p.addParameter("http://api.pushingbox.com/pushingbox");
  p.run();

I did not try to compile or run that, so you may have to make some changes to get it to work, but it's a starting point. Also, as mentioned in the tutorial, you will need to include process.h and call Bridge.begin().

Note that the parameter that includes the devid string includes quote characters inside the string, which are escaped with a backslash character. When updating the devid string, be careful not to delete the backslash that is escaping the ending quote character.

Thanks for the assistance!

I think you're right- I have a lot to learn as it relates to the bridge stuff...

For starters, I'm curious what exactly it means when it says ...

In setup(), you'll want to initialize Bridge and start a serial connection. Before running the rest of setup() wait for a serial connection to become active.

So when you add the Bridge.begin(); and Serial.begin(9600); under void setup(), does that mean that a serial monitor window will randomly pop up or is there something else I'll need to do to get a serial monitor session working?

Also- is this the standard m.o. for serial monitoring with the Dragino Yun?

Thanks

stgeorge:
In setup(), you'll want to initialize Bridge and start a serial connection. Before running the rest of setup() wait for a serial connection to become active.

The key is that you need to call Bridge.begin() before doing anything with a Process class object (or any of the other classes that are in the Bridge Library.

Opening up the serial port is not a required part of the using the Process class. That example has you open the serial port because it is using the Process class to call the curl command to retrieve a text file from an HTTP server. It then displays the retrieved data on the serial port. For your use, you do not need the serial port, unless you want to use it for debugging purposes or to see any error messages returned by the curl request.

So when you add the Bridge.begin(); and Serial.begin(9600); under void setup(), does that mean that a serial monitor window will randomly pop up or is there something else I'll need to do to get a serial monitor session working?

It will not automatically open a serial monitor window. You will need to manually open the Arduino Serial Monitor from within the Arduino IDE, or you will have to use some other serial terminal emulator program. That is, of course, if you decide you want to use the serial output.

Because this example sketch immediately loads the remote text file, and only does it once, it includes this line of code:

 while (!Serial);

This causes the sketch to wait until a USB serial connection is established - in other words, for the Serial Monitor to be opened. This way, the output from the Process command will be visible. Without this delay until a connection is made, the output would likely be displayed before you had a chance to open the serial monitor, and you would never see the output.

While that bit of code can be handy for debugging, you will probably not want it in your final sketch - if you include it, you would need to open a serial monitor each time you power up or restart your sketch. That's generally not a normal operating scenario for a finished product.

Also- is this the standard m.o. for serial monitoring with the Dragino Yun?

No, that's the standard debug output method for the official Arduino Yun board. That board uses an ATmega32U processor which has a USB serial port (Serial) for use by the Serial Monitor over the USB connection, and a second hardware serial port on pins 0 and 1 (Serial1) that talks to the Linux processor using the Bridge library.

The Dragino Yun Shield is different - it doesn't have an AVR processor to run a sketch, instead it is a shield to connect to an Arduino processor board. Since there are different boards it can be used with, and they have different processors, the ability to use a serial port for debugging and the Serial Monitor will vary. For example, if you are connecting the shield to an Uno, the only serial port available is connected to pins 0 and 1, which will need to be used for Linux communications with the Yun Shield. That means that the USB serial port needs to be disabled and Serial Monitor communications are not possible. If you are using it with an Arduino Leonardo, then that will be much closer to the official Yun, and you will have the USB serial port that you can use with the Serial Monitor. Other Arduino boards will have different limitations and abilities when used with the Dragino Yun Shield.

The Dragino site will be the prime place to go for information specific to the Dragino Yun Shield. That shield is similar to an official Yun, especially when connected to a Leonardo, but there are differences. Any Bridge library examples that come with the Arduino IDE or from this site will assume that you are using an official Arduino Yun, so some changes and allowances will have to be made to accommodate the differences from the Dragino Yun Shield. I have no direct experience with that shield, so I can't give you specific changes that will need to be made.

Thanks- this might be getting to the bottom of a long standing problem that I've been having. That is, with my Dragino Yun wifi shield connected to an Arduino Mega2560 board, I simply cannot seem to get the serial monitor to work with any of the examples from the Arduino IDE. There must be something simple that I'm not doing or some programming language imbedded in the standard sketches which is causing my board to not communicate properly. Odd because I thought this combination was going to be a very easy and capable setup to use.

Also, I find it quite confusing when people call it Serial Monitor, Serial Port, and Console Port...? I've been to the Dragino website quite a bit and can't quite seem to figure this thing out. None of the examples really seem to work when it comes to monitoring what is actually going on. If it is a simple blink the led or something, that does work, but not much more....

stgeorge:
...
Also, I find it quite confusing when people call it Serial Monitor, Serial Port, and Console Port...?

If it helps, the Console is somewhat different than the Serial Monitor.
The Serial Monitor is only going to work if you have the Arduino side physically connector to your computer.

I find the Console a lot more useful since it communicates with your computer over the local network (wireless or wired). The syntax is very similar ( Console.begin() , Console.println() , etc ). You will have to include "Console.h" and have Console.being() after the Bridge has started.

If the Arduino side is physically connected to the computer, Ctrl+Shift+M will open the Serial Monitor.
If the Arduino side is not connected to the computer and you're communicating via the IP address, Ctrl+Shift+M will open the Console.

I constantly use Console.println() to send debug information back to my computer when I'm working on a program.

stgeorge:
That is, with my Dragino Yun wifi shield connected to an Arduino Mega2560 board, I simply cannot seem to get the serial monitor to work with any of the examples from the Arduino IDE.

That is to be expected. If you take a closer look at the Yun Shield's Mega2560 installation guide, it talks about a conflict between the shield communications and the Arduino's USB communications: the first step is to disable the USB serial port. None of the Arduino example sketches that make use of the Serial communications class or the Serial Monitor will work with your setup.

Odd because I thought this combination was going to be a very easy and capable setup to use.

Capable: yes. Easy: not so much. Any examples that come with the Arduino IDE will assume you are using an official Arduino board or one that is fully compatible. This is especially true of the Bridge library examples: they assume you are using a genuine Arduino Yun board. Dragino states that their shield gives you similar capabilities to the Yun, but it is not exactly the same. There are some subtle and not so subtle differences, and dealing with those differences are a more advanced topic requiring some experience and understanding of the issues.

If you want an easy to use system, one where all of the examples will work without modification, then use an actual Arduino Yun board, not a clone. Once you understand the way things work and know the differences and their implications, then go with the shield coupled with a more advanced processor board like the Mega2560. But be aware that it will require more effort and finesse - a trade-off for the greater power and flexibility. That's just my opinion.

To be fair, I have no personal experience with the Dragino Yun Shield. But I've seen many people come here with various issues that make many of the subtle differences apparent. And I've studied Dragino's wiki on the shield, as well as the schematics, so I think I understand what is causing many of these differences. The Yun Shield is quite capable, and it does much of the same things, but it is not exactly the same as an actual Yun.

Also, I find it quite confusing when people call it Serial Monitor, Serial Port, and Console Port...?

Some people use the terms loosely or improperly, but basically:

• Serial Monitor: a serial terminal emulator window that is part of the Arduino IDE which allows you to connect to a serial port and send commands out that port and see the responses from that port.
• Serial Port: a physical serial communications port that can send and receive data. In this context, they are typically USB ports: one on the Arduino, and one on the host computer, which are connected by a cable. You use the Serial class in your sketch to control the Arduino's serial port, and you select the corresponding host computer serial port for use with the IDE's Monitor window.
• Console Port: a networked version of a serial port. In the sketch, you use the Bridge library's Console class to communicate over this port. In the IDE, if you have a network address selected in the Port menu, the Serial Monitor will communicate over the network with the Console class in the sketch. It works much like the serial port, but over the network and without a USB connection.

Hey- thanks for your thoughtful explanation- very helpful!

I guess what attracted me to Dragino's version is the wifi aspect of it since I don't have an easy ethernet solution to where I'd prefer for my Mega2560 to be located. That being said, and given your explanation, I'm now thinking of getting a Yun and working out an ethernet cable to that spot.

Sadly, I get the sense too that the Dragino is very capable, but unfortunately, the folks at Dragino are very Chinese if you know what I mean- their support needs a bit of western interpretation help. If I could communicate with someone there who could talk to me in western fashion (i.e. not just English, but with helpful explanation of what my troubles are etc), I'd probably stick it out. Until then, I'll probably hook up a Yun if I can find one that is not too expensive.

stgeorge:
That being said, and given your explanation, I'm now thinking of getting a Yun and working out an ethernet cable to that spot.

The official Arduino Yun does have the same WiFi abilities as the Dragino Shield. It has both a WiFi interface, and wired Ethernet interface. I routinely use one or the other, or even both at times.

Sadly, I get the sense too that the Dragino is very capable, but unfortunately, the folks at Dragino are very Chinese if you know what I mean- their support needs a bit of western interpretation help.

Yes, I fully understand. It's that way with a lot of products that come out the Shanzhai product copying culture. It's common to duplicate a product and undercut a price - they can afford to do that since they didn't spend a lot of money on the initial engineering development - they just copied an existing product. Support often suffers on such products. To be fair, the Dragino Yun Shield does have some original work behind it to remove the AVR processor and turn it into a shield. But it is those changes that cause the potential problems due to the new incompatibilities with the original product. And I think that their support may be lacking not only because of the language communications issues, but also because they don't have the original engineering experience that went into the original product, and they simply might not understand the product as well.

Until then, I'll probably hook up a Yun if I can find one that is not too expensive.

Yes, the official Arduino Yun boards are expensive, and can be hard to find. But mine have been rock solid performers, with great support from the Arduino IDE (everything just plain works) and from this community. That's priceless, in my mind.

Thanks again.

Where do you typically source yours? I typically troll Amazon and/or Ebay.

I bought a bunch of them from SparkFun when they were a relatively new product. A little more expensive than some sellers, but easy to get free shipping, and I like to support them since they do so much for the open source and maker communities.

OK- now I'm cooking with gas, but the following sketch fails to compile....any assistance would be appreciated!

Setup is Arduino Leonardo with a Dragino Yun shield on top

#include <process.h>

void setup() {
Bridge.begin();
Serial.begin(9600);
while (!Serial);
runCurl();
runCpuInfo();
}

void loop() {

}

void runCurl() {
Process p;
p.begin("curl");
p.addParameter("-d");
p.addParameter(""devid=vBECAF1F4A7D765"");
p.addParameter("http://api.pushingbox.com/pushingbox");
p.run();

while (p.available()>0)
char c = p.read();
Serial.print(c);
Serial.flush();
}
void runCpuInfo() {
Process p;
p.begin("cat");
p.addParameter("/proc/cpuinfo");
p.run();

while (p.available()>0) {
char c = p.read();
Serial.print(c);
}
Serial.flush();
}

Question: When an Arduino sketch fails to compile....how does one trace back to the problem? i'm not seeing it!

Compare this line by line to what you had.
You were missing several closing }'s.
You had a ; after a while statement instead of a {.
I don't know exactly what format this is supposed to be:
p.addParameter(""devid=vBECAF1F4A7D765"");
but I added another \ to escape the other ".
Bridge needed to be included.

#include <Bridge.h>
#include <Process.h>

void setup() {
  Bridge.begin();
  Serial.begin(9600);
  while (!Serial) {
    runCurl();
    runCpuInfo();
  }
}

void loop() {

}

void runCurl() {
  Process p;
  p.begin("curl");
  p.addParameter("-d");
  p.addParameter("\"devid=vBECAF1F4A7D765\"");
  p.addParameter("http://api.pushingbox.com/pushingbox");
  p.run();

  while (p.available() > 0) {
    char c = p.read();
    Serial.print(c);
    Serial.flush();
  }

}

void runCpuInfo() {
  Process p;
  p.begin("cat");
  p.addParameter("/proc/cpuinfo");
  p.run();

  while (p.available() > 0) {
    char c = p.read();
    Serial.print(c);
  }
  Serial.flush();
}

The errors all appear at the bottom of the screen, but you have to troubleshoot them pretty much 1 at a time.

stgeorge:
Question: When an Arduino sketch fails to compile....how does one trace back to the problem? i'm not seeing it!

The error message will include a (sometimes cryptic) description of the problem, and a line number. Look carefully at that indicated line, and see if there is anything wrong the actual error could possibly be on the line or two above the line mentioned in the message. It could be a simple spelling mistake, a missing comma, semicolon, curly brace, or something like that. It could be using the wrong data type, the wrong number of parameters in a function call, or many other details. The compiler is very picky, and wants things to be just so - being close to the right syntax is not good enough, you've got to pay attention to all of the little details.

Start with the first error message and work down the list. Often times, an error in one place can trigger another error later in the code. For that reason, don't start by looking at messages in the middle or end of the list: that code might be perfectly fine, and it was an earlier error that caused the message. For example, an error in a line of code declaring a variable will cause the variable to not actually be declared, or declared incorrectly. Any later line of code that references that variable might have an error message because of that, but there isn't anything to fix on that line, and that error will go away once the original error is fixed.

I start at the beginning of the error message list and work down. If a later message looks like it may have been caused by a previous error, I skip it for now (like if it says a variable is undefined, and I just fixed the declaration statement a moment ago.) If a later message just doesn't make sense, and I fixed a previous problem, I stop looking at messages and recompile (verify in Arduino IDE parlance) to get a new list of messages. By fixing the earlier problem, it often eliminates later messages, or changes them into something more meaningful.

Fixing compilation errors, and debugging code is as much an art as it is a science. It's a learned skill that's difficult to learn, but gets better with experience.

I'm now back at my computer (was using a tablet for the post above) and I tried compiling your sketch.

At first, I only got one error: "fatal error: process.h: No such file or directory" and pointing at the first line where process.h is being included. I changed "process" to "Process" and it compiles past that point. Very curious: I'm on Windows and I thought file names were not case sensitive? But here, it seems to make a difference (looking at the examples, they all seem to use Process with a capital "P" when including the file.)

Fixing that, and recompiling, there are more errors:

• Line 19: missing terminating " character - You have a string that starts with a double quote character (the second quote in the string is escaped with a backslash, putting the double quote character in the string) but at the end, you just have two double quote characters with no escaping backslash. The first double quote ends the string. The next double quote starts a new string with the characters ");" in it (adjacent constant strings are automatically concatenated) but then you have the end of the line, so the compiler complains about the missing double quote to terminate that second string. You could fix the error by adding another quote at the end of the string, and that would make the compiler happy, but that would not fix your problem, as you would not have a double quote as part of the devid string. You need to add a backslash between the 5 in the devid string, and the double quote that you want to be part of the string. That will include that quote character in the string itself. The next quote that follows it will then properly terminate the string instead of trying to create a new one.
• Line 20: expected ')' before 'p' - This is an example of an error being caused by a previous error. In the line above, the compiler took the closing parenthesis and semicolon as part of the unterminated character string, so it doesn't realize you were intending to end that statement. Therefore, it reads the next statement as a continuation of the previous statement, but it doesn't make sense. So it complains that it thinks there should be a closing parenthesis there. Of course, nothing is missing there, and nothing needs to be fixed on that line. That line will compile properly when the line above it is fixed.
• Line 25: 'c' was not declared in this scope - It's complaining that the variable c is not declared in the Serial.print(c) statement. But it is declared in the line immediately above. So why is this a problem? The line above the declaration is a while statement. That will execute the next single statement as long as the condition is true. That next statement is a new declaration scope. The statement in that scope after the while statement is the definition of the variable c, and a statement to read from the process. The scope of that variable is only that one statement associated with the while loop. The next statement (the print) is not part of the while loop, and the scope goes back to the scope that existed before the while statement, and that scope does not include the variable c. That triggers the error. The real problem is that you want to have two statements that are part of the while loop, and the solution is to use curly braces after the while statement to start a new block. Everything that is inside the opening and closing braces is treated as a single statement by the while loop. The definition of c at the beginning of that block of statements (in this case it would be two statements) remains valid until the end of the block (the closing curly brace) so the print statement will then compile.

This last error is a common one. This is the code in question:

 while (p.available()>0)
   char c = p.read();
   Serial.print(c);
 Serial.flush();

You have it indented where it appears that you want both the read() and print() statements to be part of the while loop. That would make sense. In some languages, like Python, doing that indenting is enough to make the indented statements part of the while loop. But C++ (which is what the Arduino is using) totally ignores indenting - doing the indenting is just to make it more readable for you. This is a very common error. As far as the compiler is concerned, what it's really doing is this: (using the Auto Format command from the Tools menu will reformat it to look like this, making the problem more obvious)

 while (p.available()>0)
   char c = p.read();
 Serial.print(c);
 Serial.flush();

Here, it's clear that only the read() statement is in the loop. It will read all characters, and essentially throw them away. You reach the print() statement only when the loop finishes, and at that point the variable c (as well as all of the characters that have been read) are gone and no longer accessible. The fix is to add the curly braces:

 while (p.available()>0)
 {
   char c = p.read();
   Serial.print(c);
 }
 Serial.flush();

This code will work as you expect. The variable declaration, and the read() and print() calls are all inside of the while loop, and it will repeatedly read and print character as long as they are available.

Another common error is to add a semicolon when one isn't needed. Many people automatically add a semicolon at the end of each line, thinking it is a line terminator. In reality, the semicolon is a statement separator. Consider this code, which is the same as the code above with the addition of a semicolon after the while statement:

 while (p.available()>0);
 {
   char c = p.read();
   Serial.print(c);
 }
 Serial.flush();

In this case, that added semicolon causes lots of problems. It is actually putting an empty NULL statement after the while statement, separating that NULL statement from the block of statements in the curly braces. What this is doing is telling the while statement to do nothing as long as characters are available. Once characters are no longer available, it will enter the block of statements denoted by the curly braces. It will create a variable c, read a single character into it, print the character, and then end the block. That will destroy the variable c, making it no longer accessible. That block will only be executed once, because it is no longer associated with the while statement - that semicolon has told the while statement to do nothing. In this case, the problems isn't really that the block statement will only be executed once. In reality, it will never be executed: since nothing is done inside the while statement to consume characters from p, the loop will never end. That infinite loop will run forever, and the sketch will never get past that line.

So that gives an example of type of things you need to look for when trying to get a sketch to compile. It's the details that count - every little character could be important. When you see an error message, you've got to look at the smallest of details to see what might be wrong. In the discussion above, I show three errors: a missing backslash which needs to be added, an error on the next line that isn't really an error and which will be fixed by fixing the first error, and some missing curly braces to make the loop do what you want it to do. Fix those errors, and then try to verify the sketch again. You could very well end up with a new set of errors. This can be an iterative process where you have to go through several cycles of fixing errors and verifying again.

Once you have the sketch successfully verified, then the hard work begins: debugging the code and getting it to do what you want it to do!

Thanks to both of you - ShapeShifter and DarkSabre- very informative and educational.

For starters, I'm curious if this language (C++ ?) cares about blank lines and/or indents- sounds like it doesn't, but it does seem to care about capitalization, right? Odd because there are some strange ways of capitalizing certain words and not others...

Secondly, more related to what I'm trying to do here- I'm not seeing that it is going to runCurl nor runCpuInfo unless and until I tell it to from within the void loop() section, is that right?

Basically I'm trying to merge two fairly simple tasks, and I know that the serial monitoring bit isn't really appropriate for the finished product, but would love to sort of monitor what the MCU is doing while I tweak this code...maybe that's sort of foolish, not sure.

Anyway- I'm trying to merge the standard 'button' sketch on an if/then loop to where it can monitor a button (my doorbell) and then, if it is pressed, shoot pushingbox my device id # which will notify my cell phone. I've perfected the button side of things, so now I'm trying to figure out how to get this Dragino Yun in combo with a Leonardo Arduino board to send the curl call (?) to pushingbox's api. I've (obviously) not quite got the curl section figured out yet....but it's been an interesting journey getting there...

BTW- in case it matters to anyone else reading this now or in the future...the device id listed herein is not accurate on purpose. The id has been changed to protect the innocent! Thx

stgeorge:
For starters, I'm curious if this language (C++ ?) cares about blank lines and/or indents- sounds like it doesn't, but it does seem to care about capitalization, right? Odd because there are some strange ways of capitalizing certain words and not others...

Whitespace is generically defined as characters that don't make a printed mark on the page: this includes spaces, tabs, carriage return, new line, etc. C++ ignores all whitespace (or more properly, takes all sequential whitepsace and considers it a single separator. Some places you need a separator (like between a type name and variable name in a variable declaration) and some times it's optional (like between a number and an operator.) Anywhere whitespace is required or optional, you can use any combination of whitespace" a single space works the same as 10 spaces, which works the same as a combination of spaces and tabs, as well as any combination of spaces, tabs, carriage returns, etc. All of the following are identical as far as the compiler is concerned:

char c;

     char c;

char      c;

char c     ;

char
            c
    ;

char
c
;

char





c





                           ;

Names are case sensitive - this goes for function names, class names, type names, variable names, etc. The following code defines three different variables, all of which are valid and unique variables, even if some languages that are not case sensitive (like BASIC or Python) would treat them as all the same variable (and complain about duplicate definitions:

byte variable;
byte Variable;
byte vAriAblE;

Arduino sketches are based on C++. There's a little pre-processing performed by the IDE to make it a little simpler, but the language that you are writing is regular C++. It sounds like you should read up on some C++ programming tutorials - while there are some slight differences in the way you set up a C++ program vs a sketch (like the sketch sets up the main() entry point for you) most of what you read about C++ will turn out to be very valuable.

If you want the definitive word on C++, that would be the book [u]The C++ Programming Language[/u], by Bjarne Stroustrup. He's the creator of the language, and that book is his official description of the language. It's not necessarily beginner material, however, so you are probably better off looking for an online introductory tutorial. But if you are serious about programming, you may eventually want it.

Secondly, more related to what I'm trying to do here- I'm not seeing that it is going to runCurl nor runCpuInfo unless and until I tell it to from within the void loop() section, is that right?

It's valid to put them in setup(), and they will get called. But they will only be called once. So that's valid for a one-time setup type of operation, but not particularly useful for what you are planning on doing.

Instead, you will want the code to be in your loop() function, which gets called over and over again, forever. That code will look for a button press, and if it finds one, it will call runCurl(). You say you have the button press code already working - are you debouncing the button press? When you press the button, it can actually make several make/break actions for a few milliseconds, both when you press the button and when you release it. The Arduino is fast enough to be able to detect these multiple activations. If you are just using it to light an LED, it doesn't matter, because while it will cause the LED to flicker when the button is being pressed or released, your eye won't see it. But your code will probably see it, and may call runCurl() multiple times for a single button press, causing multiple notifications to be sent. If you haven't already, it's worth doing some research on button debouncing.

To really perfect the button code, you want it to the point where you can print out a message on the serial port saying that the button is pressed, and that message is only ever printed once per press, regardless of how hard or soft you mash the button, and how long you hold it. When you have it to the point where it only prints once per press, then you want to add the call to runCurl() where you are printing out that message.

Basically I'm trying to merge two fairly simple tasks, and I know that the serial monitoring bit isn't really appropriate for the finished product, but would love to sort of monitor what the MCU is doing while I tweak this code...maybe that's sort of foolish, not sure.

No, not at all foolish! That serial output will be invaluable while debugging the code. It's very common to add a lot of Serial print statements when developing code, so that you can see what's going on, and hopefully figure out how to fix it when it doesn't do what you want.

The part that will be particularly helpful is your while available() loop where you echo any output from the Process object to the serial port. If the curl command generates any kind of error message, that will let you see what it is. If it doesn't work, it will be VERY hard to figure out why if you can't see the error messages.

Well...for some reason, it's not sending the device id to the website. I don't know curl well at all, so I'm curious if you think the http (i.e. the website) call should be prior to calling out the "-d" and the device id # ?

Oddly, I'm not seeing anything in the monitor either, except that it has 'connected' !?

I've sent the runCurl() code to pushingbox to see if they have any thoughts as to why it's not working.

I'm not an expert on curl.

When I'm experimenting with something like that, I will first SSH into the Yun, and try the commands out on the command line. That often allows more visibility to any error messages and status. It also allows tring a variety of options much faster than it could be done by updating/loading/running a sketch each time. If it doesn't work by typing the command directly on the Linux command line, there is virtually no chance of getting it to work with a Process object in a sketch.

Two options to consider using while testing, which may give you more information about why it's not working:

• ```*
• -v*
• ```*
• this turns on verbose mode which tells you lots of details about what it's doing (or not doing)
• ```*
• -- trace*
• ```*
• this causes even more detailed information to be printed