YoderB:
First of all, I am sincerely thank you for your comment. My first"Unable to connect: retrying (0)...
Unable to connect: retrying (2)...
Unable to connect: retrying (3)...
What connection are you using for the Serial Monitor? In the IDE Tools menu, do you have the USB serial port selected, or the Yun's IP address?
- If you want to connect over the USB port, you must select the Yun's USB serial port on the IDE Tools menu, and your sketch must use the Serial object (or SerialUSB) for communications.
- If you want to connect over a network connection (WiFi or Ethernet) you must select the Yun's IP address on the IDE Tools menu, and your sketch must use the Console object for communications.
The unable to connect messages you show are usually caused by selecting the Yun's IP address on the IDE Tools menu, but using the Serial object in the sketch for your communications output.
However, your given output includes a connected message - I've not seen that before. Perhaps you are indeed using the Console object for output, but you are trying to connect immediately on power on? While the Serial or SerialUSB connection will be active as soon as the board powers on, the Console object must go through the Bridge and the Linux side of the Yun, and the Linux side takes some time to boot up (usually about a minute.) Maybe you are getting the unable to connect messages while Linux is booting up?
Having some more details about how you have things connected and configured would be helpful. Also, posting your complete sketch would be helpful (but if there are any account tokens/keys for IFTTT or any other personal information, it would be best to change that before posting.)
Needless to say that when I checked the HTTP client with the built-in example, it worked just fine.
The first thing I would do is take the example, which you say it works, and change only the URL with a hard-coded URL for IFTTT. Then, if it doesn't work, you know the problem is in the way you formed the URL. The URLs for many web services are complicated, and even a slight error in spelling or punctuation can cause it to fail.
I find it helpful to try manually typing the URLs into a web browser first. That way, you can test out whether you are sending the right commands, and you often get some more meaningful error messages. If you can't get it to work by typing it into a web browser, then the odds are good that it won't work when you code it into a sketch. My usual development flow when working with a new web service is:
- First, get the URL working manually with a web browser. In the past I've used browser plug-ins that make it easy to enter GETs and POSTs with various data. Until you can reliably get the service to respond with a manual entry, there is no point in trying to get it to work programmatically.
- Then, after you have a URL request that works by manually typing it into a browser, then try to do the same thing in the sketch, using the exact same fixed URL string you got working with the browser. If you use the exact same URL, and it doesn't work, then you know the problem is in your sketch, and not the URL
- Finally, when you have the sketch able to trigger the web service using the hard-coded fixed URL, then update the sketch to programmatically generate the URL using variable data. If that fails, you know the problem is in the way your code built the URL string.
Many people jump in and code up the last step first. Then, when it doesn't work, you don't know if it's because your code didn't generate the URL the way you intended, or the sketch didn't send the URL properly, or perhaps you misunderstood the URL format and while the code generated the URL you wanted, it isn't in the format that the web service could understand. It's a complex process, so take it one step at a time - get it working in its most simple form first, and then add to it, changing only one thing at a time and re-testing it after each step. If you try to do too much at once, and it doens't work, it's hard to tell which part is causing the problem.
although I am planning to send a maximum of 5 requests per hour, I prefer to learn more in the process of making it then make it in the most simple way.
That is a good attitude. If you learn how to get it to work using the HttpClient, you will know how to make the request on an Arduino Yun running the Bridge library. If you learn how to do it with a Linux script and the curl command, you will know how to make the request on a very wide range of computers and development boards, and not just a single development board. It's more work to learn how to do it with curl and script, but I think the effort is worth it. The combination of running an Arduino sketch on a board with a Linux system on it is very powerful, and if you try to do everything just in the sketch, you are losing out on most of that power. It's worth the effort to learn how to make full use of the combination.[/quote]
