Arduino-Yun Wifi - Internet Commands?

Very educational and helpful- thanks! I'll try to improve my posts going forward :grin: .

One thought I had overnight was that, the only time I've actually seen the serial monitor work properly has been when I have run the ConsoleRead example sketch.

Again, since I'm going over wifi, I wonder if it wouldn't make sense to replace all the serial monitor stuff with console read stuff and give that a try. If it works, I'd be able to actually see what the mcu is doing and/or if there are any errors when it attempts to run this curl command.

I can go back and look at that ConsoleRead sketch and see if I can figure out how to replace the serial monitor coding with console coding, but if you have any thoughts on this either way and/or if you have any advice as to console coding requirements, please let me know. Thanks.

stgeorge:
Again, since I'm going over wifi, I wonder if it wouldn't make sense to replace all the serial monitor stuff with console read stuff and give that a try.

I don't think you mentioned that you were trying to use the Serial Monitor over WiFi, or if you did, I missed it. Yes, if you are using a strictly WiFi connection, you MUST use the Console class. The Serial class works ONLY over the USB serial connection. The Console class works ONLY over a network connection (WiFi or Ethernet.) The fact that we were talking about the Serial class made me assume we were talking about USB.

...see if I can figure out how to replace the serial monitor coding with console coding,

Serial and Console both derive from the same Stream class, so they have the same interface and work much the same way. Switching your sketch over is easy: first, you need to add #include <Console.h> at the beginning of your sketch. Then, change your Serial.begin() statement to Console.begin() with no arguments, and make sure it is s called after Bridge.begin() is called. Finally, change every occurrence of Serial in your sketch to Console. All of the print(), println() and other functions are the same and will not need any changes.

I figured! I had this initial hunch that I needed to be working over Console due to wifi, but what had been throwing me off is that, on occasion, I'd see 'connected' in the serial monitor- but then it wouldn't actually communicate, so I knew something was wrong.

Anyway- I'll be working on a conversion to console for a bit and report back what I'm seeing/hearing from the mcu. I'm really interested to learn why this runCurl loop isn't working.

I assume you don't need to call out any baud rate on either the bridge or the console, right?

Does it matter the order in which you list the 'include' libraries (?) - I'm guessing not.

Finally...since I've run across 'boolean' I'm curious if you can shed light on what that does and/or what the proper use is for it? I've certainly heard of Boolean search nomenclature et al but haven't run across it in programming code until recently.

stgeorge:
I assume you don't need to call out any baud rate on either the bridge or the console, right?

Correct.

Bridge.begin() can accept an optional baud rate, because it is actually a serial port connection to the Linux processor. They give you the option of changing that baud rate if you have a special need.

Console.begin() expects no parameters. There is no concept of a baud rate for a network connection. While a network connection does have a physical data signalling speed, that is a function of the physical hardware interface and not something that can be changed in software. (Or at least not by the Console class.)

Does it matter the order in which you list the 'include' libraries (?) - I'm guessing not.

Sometimes it matters, usually it doesn't. There may be a case where an include file needs to use information from another include file, and therefore must be included after the other one. But usually, that include file will just include the specific file it needs, eliminating the need to include them in a specific order. (Wow, talk about some convoluted logic, any chance you can follow that?)

In the case of these include files, it doesn't really matter. I like to include Bridge.h first, as it is the main include file of the Bridge library, and everything else depends on it. However, because everything else depends on it, it is automatically included by the other include files. So, if you happen to include Console.h first, it will include Bridge.h internally to it. Then, when you get to the point where you are including it in your sketch, the compiler will realize that it's already been included and not include it a second time.

But the short answer is no, it usually doesn't matter. In general, I tend to include files in alphabetical order: sometimes there is a long list of includes in a source file, and having them in order makes it easier to find a file in the list when reading the code.

Finally...since I've run across 'boolean' I'm curious if you can shed light on what that does and/or what the proper use is for it?

A boolean is usually another name for an unsigned char (byte.)

It represents a logical value: either true or false. The results of the comparison operators (==, >, <, <=, >=, etc) is a logical value. There are logical operators that take logical values and return logical results like and (&) or (|) exclusive-or (^) and not (!). There are statements that expect logical expressions, like if and while.

C++ uses the numeric value 0 to represent false, and any non-zero numeric value is considered true. The result of a comparison or logical operator is usually 1 when it wants to signal true.

A logical value can be stored in just about any integral numeric variable type, although a single byte value is usually used for efficiency. "boolean" is just another form of unsigned character value (just like "byte") that can be used to store any 8-bit value, but by using the type "boolean" you are giving the reader a hint that you intend to use it for true/false values. (Although the compiler really doesn't care, it treats "byte", "boolean", and "unsigned char" as the same thing: an unsigned 8-bit value.)

Thanks for that.

OK- so I've converted my little sketch to console and the first time around, it showed 'connected' in the serial monitor, but now I'm not often even seeing that.

I'm now wondering if I have my network setup correctly for this console communicating. Because it worked this way for the consoleread example sketch, I'm again thinking that it is fine, but now maybe not.

I read in the consoleread sketch intro that you either telnet to the board or port forward the board and open a serial monitor to connect and see print and other feedback. I port forwarded the board's ip on my lan to 6571 and again, since it worked, I have left it that way, but what is odd to me is that port forwarding is really for outside the lan access to a device on the lan, so this doesn't really make a lot of sense to me because I'm trying to monitor this board's mcu from within my lan. Is there a better way to set this up and/or to open or connect to the console?

Here's my code currently:

// set pin number:
const int buttonPin = 3;     // the number of the doorbell input
const int ledPin =  13;      // the number of the LED pin

// variables will change:
int buttonState = 0;         // variable for reading the pushbutton status

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

void setup() {
   // initialize the LED pin as an output:
  pinMode(ledPin, OUTPUT);
  // initialize the pushbutton pin as an input:
  pinMode(buttonPin, INPUT);
  Bridge.begin();
  Console.begin();
}

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);
    runCurl();
    delay(750);
 
  } else {
    // turn LED off:
    digitalWrite(ledPin, LOW);
  }
}

void runCurl() {
 Process p;            
 p.begin("/usr/bin/curl");
 p.addParameter("-d");
 p.addParameter("\"devid=vBECBF1F4A7D765\"");
 p.addParameter("http://api.pushingbox.com/pushingbox");
 p.run();
 while (p.available()>0)
 {
   char c = p.read();
   Console.print(c);
 }
}

The led light and button pressing etc all works fine, including the delay, but no serial monitor communication and definitely no success with the runCurl loop.

I've not used the Console much, I usually use the USB port for debug messages during development, and then I don't use any type of serial stream communications once the project is finished.

The few times I used the Console class, I did nothing special with a network configuration: I just selected the Yun's network address in the Port menu, and opened the Serial Monitor. I've read where you have to do some extra effort to use a standard Telnet client to connect with the Console class, but that shouldn't be necessary when using the Arduino IDE's Serial Monitor window. Of course, my experience is with an official Arduino Yun board - there are some subtle and no so subtle differences introduced by Dragino in their Yun Shield, and this may be different for you.

I agree, port forwarding should only be necessary for connections coming in from the WAN (Internet) to your LAN (local network), it should not be necessary for a LAN to LAN connection. Assuming your Yun Shield and your computer are connected to the same logical network, your router should not be involved in any communications between your Yun Shield and computer, it's only involvement is to assign IP addresses to them.

Now, if your Yun Shield is connected by WiFi, and your computer is on wired Ethernet, and those are two logically distinct networks that must pass through your router, then you may have to set up some special routing rules. But that would be an unusual setup, and is not the way that most home networks are configured.

So finally got it working properly- interestingly, here is where I found the problem- this line:

p.addParameter(""devid=vBECBF1F4A7D765"");

The curl command I have been trying to execute is:

curl -d "devid=vBECBF1F4A7D765" http://api.pushingbox.com/pushingbox/

and my runCurl(); loop had previously been:

void runCurl() {

 Process p;            
 p.begin("curl");
 p.addParameter("-d");
 p.addParameter("\"devid=vBECBF1F4A7D765\"");
 p.addParameter("http://api.pushingbox.com/pushingbox/");
 p.run();
 while (p.available()>0)
 {
   char c = p.read();
   Console.print(c);
 }
}

...which wasn't working. After many, many experiments, I finally figured out that all I needed to do was literally have the devid in quotes.

Now it works beautifully...

Here is the final version which works...

void runCurl() {

 Process p;            
 p.begin("curl");
 p.addParameter("-d");
 p.addParameter("devid=vBECBF1F4A7D765");
 p.addParameter("http://api.pushingbox.com/pushingbox/");
 p.run();
 while (p.available()>0)
 {
   char c = p.read();
   Console.print(c);
 }
}
1 Like

stgeorge:
Now it works beautifully...

CONGRATULATIONS! It's been a long hard battle...

Interesting that it doesn't actually need the double quote character in the parameter string. I guess it had problems passing it through properly? So, I suppose the curl command would also work from the SSH command line without the quotes around the devid string? I wonder why they suggested using them in the first place?

Thanks. I'm guessing that the pushingbox website may be a bit overrated, but I'm grateful for the service they provide because it is a very inexpensive way to push notification out to me through this Arduino.

Anyone have experience working with Console ascii table?

It's so strange- my little runCurl(); loop is working well, but as soon as I add the console to it to try to see the output from the MCU, I can't get any activity to show up in the monitor.

I can see that it's communicating with my Arduino because firstly, I see that the read/transmit lights are lit up and secondly, the base program doesn't start up until I open the Console (aka Serial Monitor), and then it works correctly, but nothing pops up in the console monitor.

Here is the current language for my loop:

void runCurl() {

 Process p;            
 p.begin("curl");
 p.addParameter("-d");
 p.addParameter("devid=vBECBF1F4A7D765");
 p.addParameter("http://api.pushingbox.com/pushingbox/");
 p.run();
 while (p.available()>0)
 {
   char c = p.read();
   Console.print(c);
 }
}

And yes, I've properly included the console, and started the bridge and console ahead of my while statement- all just like I do in either the Cosole Read example sketch or the Console ASCII Table print, both of which work and show up in the console correctly, but this process doesn't show anything. Is it possible that there's nothing showing up that it can print out?

stgeorge:
Is it possible that there's nothing showing up that it can print out?

I suppose it's possible. It's also possible p.run() isn't returning?

Easy way to tell is the add some additional messages, just for testing:

void runCurl() {

 Process p;           

 Console.println("Calling curl");

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

 Console.println("Start of output:");

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

 Console.println("End of output");
}

This way, you should at least see something...