An Easy and Customizable Arduino powered Weather Station connected with Xively

By on July 3, 2014
Pin It

esploso

Use Arduino as a Xively HTTP client and interact with the new shield for power management.

We already talked about WiFi connectivity for Arduino in other posts, presenting the design of a high performance WiFi shield and explaining how to use it both as a web server, or a web client. The two modes of operation enable to a wide range of applications supported by network connectivity. Unlike other shield, ours incorporates a module that is able to take over those tasks which, if left to the Arduino, prevent it from carrying out its work with reasonable responsiveness, precluding thus the possibility to implement many of the applications envisioned. In other words, our WiFi shield handles all the HTTP protocol, meaning that it allows the Arduino to focus on the role of client/server, forgetting managing web connections.

Today, based on the Arduino and the WiFi shield, we will propose an application that takes the form of a Arduino-based weather station, by adding a Weather Shield presented in this post and a very simple cyclic timer, which is also implemented as a shield: our stack will therefore be composed of an Arduino , the WiFi shield, the weather shield and the timer shield.

We already know the first two elements, then we will explain the others. But before that, it’s important to anticipate what is the purpose of our project: this is a web application that can detect climatic data and publish them on the website www.xively.com.

 

The Xively website

Xively website was born to serve “the Internet of things” and is a virtual cloud space, dedicated to the collection and sharing of data collected from disparate sensors. It allows free use, in the form of “development accounts”, to allow potential users to test the functionality provided. If you want to use this site for amateurial purposes and realize the application described here, you must register a “Free Developer Account” by entering a few essential information.

Schermata

At this point it comes to defining the source of your data; or what is called generically “device”. This data source is also called feed and it has an identification number (Feed Id), a reference URL and a URL to use with the connection APIs. It also has a long KEYWORD to be used to enter and manage data. Everything is automatically defined when you create a device. A device can have several channels (datastreams), each of which corresponds to a type of measurement (temperature, pressure, etc..). So, after you have defined your devices, you have to create at least one channel, which will be identified by its name (eg temperature).







Once defined the destination of your data, it comes to deciding which mode to use for connections. In fact, you can use the http protocol but also the connection using sockets. For the sake of simplicity we will use the Web access.

To send the data you must make a “request” with “PUT” method. The call should be forwarded to “api.xively.com”, and more specifically to the resource “/v2/feeds/yourfeedid” But we must also define, in the http package, the following header:

  • Host: api.xively.com
  • X-apikey: 39KvFo30fuhM … (abbreviated here)

You can also route the call to the site “api.xively.com” using the corresponding numerical address “173.203.98.29”, rather than the url, in case of DNS issues. The data can be provided in different formats: XML, JSON, CSV. We have chosen, for simplicity, the CSV format (Comma Separated Values). Then, having to publish meteorological data you can to provide three lines such as:

temperature, 19

Pressure, 1022

Humidity,  62

 

You can display the collected data in the form of a graph directly on the site. But there are several possible other display modes.

Fig1

The site also provides libraries for the most popular systems and therefore also for Arduino; but of course the library provided refers to basic Arduino WiFi and therefore is not usable in our case.

By the way, thanks to the simplicity of our library in dealing with the HTTP protocol, the code needed is just made of a few lines.

 

Arduino as an HTTP client

To use our WiFi shield, we proposed a special library. The author of the library keeps updating it from time to time and is now available, improved and updated, in 2.4 version. Lately the Client mode (sendRequest) was enhanced with the possibility to define the HTTP header, so as to allow the connection with servers that require the presence of particular headers. Also PUT and DELETE methods were added, provided by the REST (Representational State Transfer) approach. In server mode (getRequest), on the other hand, authentication has been added.

In the examples we provided with our library you already have an Arduino sketch to create an HTTP client that communicates with a custom server. Now, with the aim of illustrating the ability to connect to a public server, we explore better use the library as a client, referring to the next article deepening of the server mode. Here are the steps to be taken.

 

  1. Connect to the WiFi router.
  2. Connect to the IP address of the server (with a certain port).
  3. Make the string with the data to send.
  4. Define the resource address on the server.
  5. Define the method to use (GET, POST, PUT, DELETE).
  6. Define headers.
  7. Send (sendRequest) providing method, resource, header and data (if using POST or PUT).

8 .Await response (getResponse) and we use (if we used GET).

  1. Close the socket with the server.

 

Applying this in with Xively, we have, in this case, the following series of statement.

  1. WIFI.ConnectWPAwithKey(ACCESSPOINT,key);
  2. csocket=WIFI.openSockTCP(REMOTEIP,PORT);
  3. snprintf_P(recValues,64,FVal,stemp,sumid,spress) ;
  4. #define RESOURCE     “/v2/feeds/1070345129.csv”
  5. the method used is PUT
  6. #define HOST         “Host: api.xively.com”

#define KEY          “X-ApiKey: 39KvFo30fu…”







  1. WIFI.sendRequestPUT(csocket,headers,2,RESOURCE,recValues);
  2. WIFI.getResponse(csocket,1000); (1s timeout)
  3. WIFI.closeSock(csocket);

 

The connection to Xively is made ​​in one step and exploits the key that has been drafted for the one-time WiFi router used. The key is drawn as a function of the password and once calculated, can be used for almost immediate access. Instead password access may take up to a minute due to the calculation of the key. Obviously the key was previously stored. In this application, which provides for periodic Arduino shutdowns (see below), the key is stored in the EEPROM.

Regarding the connection to the server there’s not much to add compared to what is said in the post that introduced the library. The socket number (CSocket) must be less than 255 because to mean a connected socket.

The construction of the data-string was done using an AVR C function which allows the use of format in the program memory, so as to economize on the RAM. fact, that of RAM scarcity ( 2k on Arduino Uno), is one of the major problems that needs to be addressed when making complex programs on these versions of Arduino. For this reason the library itself makes extensive use of program memory for string literals and text messages.

On the definition of the resource to be addressed on the method and on the necessary header, there is not much to say besides the fact that they are those indicated by Xively.

As mentioned above, the modes sendRequestPUT sendRequestDELETE were added to the library possible to cope with the requirements of public servers.

A timeout was added to the getResponse, so to be sure of the arrival of the response.

 

Consumption management

FT1100_45

The application proposed here provides for the periodic delivery of meteorological data collected by the Weather shield; it comes to temperature, barometric pressure and humidity. Furthermore than the sensors, the shield also sports a RTC (Real Time Clock) made ​​with the Maxim DS1307 IC.

With the Weather Shield, we implement a real weather station even better than the commercial ones, because our platform is expandable and configurable by changing the code and adding additional devices and shields (as in our case where we add internet connectivity through a WiFi shield). The sensors mounted in the Weather shield are:

– MCP9700A for measuring temperature

-HIH-5030-001 of Honeywell, to determine the relative humidity

-MPXH6115A6U from Freescale to provide data regarding the absolute atmospheric pressure.

Weather data taken from the system, typically are acquired at intervals of several minutes or even hours. For this reason, it makes no sense to keep system on, let alone the Weather shield, all the time. Leave all continuously fed means consuming more than one hundred milliamps / hour (between WiFi and Arduino shield) to use it for about 4 seconds (this is the time it takes to upload the data on Xively) every 10 minutes – or even hourly – a waste of power. Saving power becomes vital if the system is battery powered and connected only to WiFi. That’s the reason why we decided to design a shield with very elementary power management, whose task is to turn the system on only when used, and turn it off when not. This shield has a variable power input adjusted to from 7 to 15 Vt and a direct input at 5 V. The power supply takes place via this Arduino shield that provides the voltage on its pin 5 V.

1100_Schema

The shield is essentially a cyclic timer based on the classic 555 monostable configuration, which controls a MOSFET as electronic switch used to turn on and turn off Arduino at intervals dictated by the time of charging and discharging of  a timing capacitor; the circuit feeds the 5V contact of Arduino while charging the capacitor, which occurs in a very short time, when compared to that of discharge (when the MOSFET is interdit).

Once on the system is on, the Arduino performs the operations and then goes to sleep, placing high logic level on contact 8: this interrupts the power supply to the timer for a period established by the RC group of 555.

FT1100 1100_TopSilk

As the Weather shield also contains an RTC (DS1307) (with battery backup) we decided to wake the Arduino every minute for it to quickly check if it is time has passed (every 10 minutes). In case not, the system goes back to sleep. In this way you keep a resolution to the minute without having to rely on long and imprecise charging time of the capacitor. The time required for the control is very low and in any case does not turn on the WiFi, so consumption is negligible.

When the wait time established, Arduino connects and transmits data. All this happens in about 4 seconds. The consumption so low that allows us to feed the system even with a small solar panel with a battery.

 

As you can see from the diagram, the shield has a feed section and another for the management of the 5 V pin of the Arduino. The power supply section allows to supply a voltage ranging from 4.5 V up to 15 V. In fact, if we wanted to feed Arduino with three AA batteries for a total of 4.5 V or finally, four AA batteries (NiCd or NiMH) for a total of 4.8 V, this can be done through the direct 5V connector that is connected to the 5V Arduino contact (Arduino can also be operated at voltages below 5 volts). The same is true if we wanted food source Arduino with a standard USB 5V.

If we wanted to feed the Arduino with a 6V battery (and up 15V) we could do this by using the power connector connected to U2 (LF50AB) which is a low droput regulator (450mV) and low load current (<1mA) and with a maximum load of 1A.

 

D1 input diode is only for protection and it’s better to short-circuit it in the case of 6 volts supply. So, with this board we “bypass” the standard Arduino power to gain a a greater freedom of sources.

 

The power management section, however, takes care of close it on command. The command is provided from one of the digital I/O pins D4, D8, D12 of Arduino brought to a high level; the pin is chosen by the JA jumper on the basis of what line is available and implemented in the sketch. In practice, if one of the D4, D8, D12 is busy, set JA to use a free line and modify the sketch accordingly.

In the instant the classic 555 (U3) circuit receives this pulse via T1, which operates as a separating (and inverting) interface, its pin 3 (out) goes high and doesn’t provide anymore the most negative value to the gate of P-channel Q1 MOSFET. MOSFET IRLIB9343, which has a low response threshold (about-3V), interrupts then the power to the 5V pin of the Arduino.

Circuit 555 operates in monostable mode and puts up its output as soon as it receives the trigger pulse: it charges the capacitor through R1 and R2 trimmer. Once the threshold value is reached, the 555 discharges the capacitor and returns to the initial state with low output, for which Q1 returns to conduct.

The time during which the power of Arduino is interrupted is defined by the formula:

 

Where T is expressed in seconds. Since R is a total of about 5.4 Mohm (halfway trimmer), we have prepared three different capacitance values ​​can be managed via the jumper, allowing as many intervals:

  • 10 uF for a time T of 60 seconds
  • for a 100 uF T time of 10 minutes,
  • 600 uF for a time T of 3.600 s (1 h.)

 

The Arduino sketch

 

In the sketch you’ll only find the setup() method while the method loop() is left blank; it does not have to perform any action repeatedly, but rather act and turn off. So the shield performs these tasks in the following order:

  • Reads the WiFi key if present in the EEPROM,
  • connects to RTC of the Weather shield using the supplied library and reads the time,
  • checks that more than 10 minutes have passed (define TIMEINT) and otherwise launches the shutdown routine,
  • if 10 minutes have passed, it makes all the steps to connect and dispatch data;
  • it turns off as a result commanding contact 8.

 

The turn off routine works this way: activates pin 8 which causes the power supply to stop for about a minute. Upon awakening, of course, it starts as after a reset. If the power management board is not present, however, a reduction in the absorption was provided by placing Arduino in SLEEP_MODE_PWR_DOWN mode, from which it is awakened, after about a minute, by a reset caused by the “watchdog counter.” In fact, you make a series of repeated watchdog interrupts with the longest time of 8s allowed for the watchdog timer, up to reaching one minute.

About Boris Landoni

Boris Landoni is the technical manager of Open-Electronics.org. Skilled in the GSM field, embraces the Open Source philosophy and its projects are available to the community.

One Comment

  1. Jim Myers

    July 21, 2014 at 8:44 PM

    Why are all of the WiFi shields so over priced? For $69.95 you can buy the DigiX )(http://digistump.com/products/50) which is a Due compatible board that includes an on board 802.11b/g/n WiFi Module, 99 I/O pins, MicroSD slot, RTC, mesh networking support (nRF24L01+ wireless module socket), 4KB EEPROM, and is 100% compatible with anything that works with the Arduino Due – no adapters, code changes, or special software needed.

    I found out about the DigiX when I was searching for a WiFi shield. I’ll never purchase a WiFi shield now.

Leave a Reply