Object Description

[Required] Your API access key, which can be found in yo

access_key
dashboard.

[Required] Use this parameter to pass a single location o

query semicolon-separated location identifiers to the API. Learn
the Query Parameter.

[Optional] Use this parameter to pass one of the unit iden

API:
 m for Metric
units
 s for Scientific
 f for Fahrenheit
Learn more about the Units Parameter.

[Optional] Use this parameter to specify your preferred AP

language language using its ISO-code. (Default: unset, English) Lea
the Language Parameter.

[Optional] Use this parameter to specify a JSONP callback

callback
to wrap your API response in. Learn more about JSONP Ca

Example API Response:

The successful API request from the example above now returns real-time weather
data for the city of New York, including detailed information about temperature,
humidity, wind, clouds, pressure, the current time, a series of location identifiers,
and more.
{
"request": {
"type": "City",
"query": "New York, United States of America",
"language": "en",
 "unit": "m"
},
"location": {
"name": "New York",
"country": "United States of America",
"region": "New York",
"lat": "40.714",
"lon": "-74.006",
"timezone_id": "America/New_York",
"localtime": "2019-09-07 08:14",
"localtime_epoch": 1567844040,
"utc_offset": "-4.0"
},
"current": {
"observation_time": "12:14 PM",
"temperature": 13,
"weather_code": 113,
"weather_icons": [

"https://assets.weatherstack.com/images/wsymbols01_png_64/wsymbol_0001_sunn
y.png"
],
"weather_descriptions": [
"Sunny"
],
"wind_speed": 0,
"wind_degree": 349,
"wind_dir": "N",
"pressure": 1010,
"precip": 0,
 "humidity": 90,
"cloudcover": 0,
"feelslike": 13,
"uv_index": 4,
"visibility": 16
}
}

API Response Objects:

Response Object Description

Returns the type of location lookup used for this request.

 City
request > type  LatLon
 IP
 Zipcode

request > query Returns the exact location identifier query used for this re

request > language Returns the ISO-Code of the language used for this reque

Returns the unit identifier used for this request:

 m for Metric
request > unit
 s for Scientific
 f for Fahrenheit

location > name Returns the name of the location used for this request.

Returns the country name associated with the location us

location > country
request.
Response Object Description

Returns the region name associated with the location use

location > region
request.

Returns the latitude coordinate associated with the locatio

location > lat
request.

Returns the longitude coordinate associated with the loca

location > lon
this request.

Returns the timezone ID associated with the location used

location > timezone_id
request. (Example: America/New_York)

Returns the local time of the location used for this reques
location > localtime
(Example: 2019-09-07 08:14)

Returns the local time (as UNIX timestamp) of the location

location > localtime_epoch
request. (Example: 1567844040)

Returns the UTC offset (in hours) of the timezone associat

location > utc_offset
location used for this request. (Example: -4.0)

current > observation_time Returns the UTC time for when the returned whether data

current > temperature Returns the temperature in the selected unit. (Default: Ce

Returns the universal weather condition code associated

current > weather_code weather condition. You can download all available weathe
this link: Download Weather Codes (ZIP file)

Returns one or more PNG weather icons associated with t

current > weather_icons
weather condition.

Returns one or more weather description texts associated

current > weather_descriptions
current weather condition.
 Response Object Description

current > wind_speed Returns the wind speed in the selected unit. (Default: kilo

current > wind_degree Returns the wind degree.

current > wind_dir Returns the wind direction.

current > pressure Returns the air pressure in the selected unit. (Default: MB

Returns the precipitation level in the selected unit. (Defau

current > precip
millimeters)

current > humidity Returns the air humidity level in percentage.

current > cloudcover Returns the cloud cover level in percentage.

Returns the "Feels Like" temperature in the selected unit.

current > feelslike
Celsius)

current > uv_index Returns the UV index associated with the current weather

current > visibility Returns the visibility level in the selected unit. (Default: k

Current Location:
JavaScript FetchJavaScript AxiosPython RequestsPython Http.client

const url = 'https://api.weatherstack.com/current?

access_key={PASTE_YOUR_API_KEY_HERE}&query=New Delhi';
const options = {
 method: 'GET'
};

try {
const response = await fetch(url, options);
const result = await response.text();
console.log(result);
} catch (error) {
console.error(error);
}

Location Identifier:
Aside from simply passing the name of a city, there are multiple other ways of
passing a location to the API.
JavaScript FetchJavaScript AxiosPython RequestsPython Http.client

const url = "https://api.weatherstack.com/current?

access_key={PASTE_YOUR_API_KEY_HERE}&query=40.7831,-73.9712";
const options = {
method: "GET",
};

try {
const response = await fetch(url, options);
const result = await response.text();
 console.log(result);
} catch (error) {
console.error(error);
}

Query ParameterAvailable on: All plans

The API's query parameter can be used in various ways to pass a single location or
multiple locations to the API when making requests to one of the API's weather data
endpoints. Using the example of the API's current endpoint, all available options will
be outlined below:
Single Location:
The most common use case for the query parameter is to pass a single location to
the API when making a weather data request. Find an example below:
Run API Requesthttp://api.weatherstack.com/current
? access_key = 326434219471cbee84aa40cb52b52ad1
& query = London, United Kingdom

Multiple Locations: (Professional Plan and higher)

To make use of the API's bulk query capability, you can also pass multiple
semicolon-separated locations to the API:
Run API Requesthttp://api.weatherstack.com/current
? access_key = 326434219471cbee84aa40cb52b52ad1
& query = London;Singapur;Shanghai

Supported Location Identifiers:

Aside from simply passing the name of a city, there are multiple other ways of
passing a location to the API:
 Definition Example Description

Location Name query = New York The standard way of passing a location nam

Pass a UK/Canada/US ZIP code to the API an

UK/Canada/US ZIP Code query = 99501
the associated location.

query = 40.7831,- Pass latitude and longitude coordinates to th

Coordinates (Lat/Lon)
73.9712 detect the associated location.

query = Pass an IP address to the API and auto-detec

IP Address
153.65.8.20 location.

Pass fetch:ip to the API in order to auto-dete

IP Address (Auto-Fetch) query = fetch:ip
IP address and location.

Multiple Location:
Use query parameter to pass a single location or multiple semicolon-separated
location identifiers to the API.
JavaScript FetchJavaScript AxiosPython RequestsPython Http.client

const url = "https://api.weatherstack.com/current?

access_key={PASTE_YOUR_API_KEY_HERE}&query=London;Singapur;Shanghai";
const options = {
method: "GET",
};

try {
const response = await fetch(url, options);
const result = await response.text();
console.log(result);
} catch (error) {
console.error(error);
}

Note: Each location passed to this parameter as part of a bulk query will count
towards your monthly request volume.
Historical WeatherAvailable on: Standard Plan and higher
To look up historical weather data all the way back to 2008, simply pass one date of
your choice (later than July 2008) or multiple semicolon-separated dates to the
weatherstack API's historical endpoint using the historical_date parameter.
Example API Request:
Run API Requesthttp://api.weatherstack.com/historical
? access_key = 326434219471cbee84aa40cb52b52ad1
& query = New York
& historical_date = 2015-01-21
& hourly = 1

HTTP GET Request Parameters:

Object Description

[Required] Your API access key, which can be found in yo

access_key
dashboard.

[Required] Use this parameter to pass a single location o

query semicolon-separated location identifiers to the API. Learn
the Query Parameter.
 Object Description

[Required] Use this parameter to pass one historical dat

historical_date semicolon-separated dates to the API. (Example: 2015-01
date or 2015-01-21;2015-01-22 for multiple dates)

[Optional] Set this parameter to 1 (on) or 0 (off) dependin

hourly
not you want the API to return weather data split hourly. (

[Optional] If hourly data is enabled, use this parameter to

interval:
 1 hour

interval  3 hourly (default)

 6 hourly
 12 hourly (day/night)
 24 hourly (day average)

[Optional] Use this parameter to pass one of the unit iden

API:
 m for Metric
units
 s for Scientific
 f for Fahrenheit
Learn more about the Units Parameter.

[Optional] Use this parameter to specify your preferred AP

language language using its ISO-code. (Default: unset, English) Lea
the Language Parameter.

[Optional] Use this parameter to specify a JSONP callback

callback
to wrap your API response in. Learn more about JSONP Ca

Example API Response:

In addition to the requested historical weather data, a successful historical weather
API call will also return the current weather in the location used for the request, as
well as information about the API request and location.
{
"request": {
"type": "City",
"query": "New York, United States of America",
"language": "en",
"unit": "m"
},
"location": {
"name": "New York",
"country": "United States of America",
"region": "New York",
"lat": "40.714",
"lon": "-74.006",
"timezone_id": "America/New_York",
"localtime": "2019-09-07 10:05",
"localtime_epoch": 1567850700,
"utc_offset": "-4.0"
},
"current": {
"observation_time": "02:05 PM",
"temperature": 15,
"weather_code": 113,
"weather_icons": [

"https://assets.weatherstack.com/images/wsymbols01_png_64/wsymbol_0001_sunn
y.png"
],
"weather_descriptions": [
 "Sunny"
],
"wind_speed": 0,
"wind_degree": 0,
"wind_dir": "N",
"pressure": 1011,
"precip": 0,
"humidity": 78,
"cloudcover": 0,
"feelslike": 15,
"uv_index": 5,
"visibility": 16
},
"historical": {
"2008-07-01": {
"date": "2008-07-01",
"date_epoch": 1214870400,
"astro": {
"sunrise": "05:29 AM",
"sunset": "08:31 PM",
"moonrise": "03:24 AM",
"moonset": "07:37 PM",
"moon_phase": "Waning Crescent",
"moon_illumination": 4
},
"mintemp": 0,
"maxtemp": 0,
"avgtemp": 19,
"totalsnow": 0,
"sunhour": 14.5,
 "uv_index": 4,
"hourly": [
{
"time": "0",
"temperature": 27,
"wind_speed": 7,
"wind_degree": 201,
"wind_dir": "SSW",
"weather_code": 113,
"weather_icons": [

"https://assets.weatherstack.com/images/wsymbols01_png_64/wsymbol_0001_sunn
y.png"
],
"weather_descriptions": [
"Sunny"
],
"precip": 1.8,
"humidity": 80,
"visibility": 9,
"pressure": 1011,
"cloudcover": 15,
"heatindex": 25,
"dewpoint": 20,
"windchill": 24,
"windgust": 11,
"feelslike": 25,
"chanceofrain": 0,
"chanceofremdry": 0,
"chanceofwindy": 0,
 "chanceofovercast": 0,
"chanceofsunshine": 0,
"chanceoffrost": 0,
"chanceofhightemp": 0,
"chanceoffog": 0,
"chanceofsnow": 0,
"chanceofthunder": 0,
"uv_index": 6
},
{ "time": "300", ... },
{ "time": "600", ... },
// 6 more items
]
}
}
}

Please note: The response objects request, location and current will not be
explained below as they are already mentioned in the Current Weather
Endpoint section above.
API Response Objects:

Response Object Description

historical > ... > date Returns the requested historical date.

historical > ... > date_epoch Returns the requested historical date as UNIX timestamp.

Returns a total of 6 sub response objects containing astro

historical > ... > astro
details, listed and explained in detail below.
Response Object Description

astro > sunrise Returns the local sunrise time in the format hh:mm am/pm

astro > sunset Returns the local sunset time in the format hh:mm am/pm

astro > moonrise Returns the local moonrise time in the format hh:mm am/

astro > moonset Returns the local moonset time in the format hh:mm am/p

Returns the local moon phase. Possible values:

 New Moon
 Waxing Crescent
 First Quarter
astro > moon_phase  Waxing Gibbous
 Full Moon
 Waning Gibbous
 Last Quarter
 Waning Crescent

astro > moon_illumination Returns the moon illumination level as percentage.

Returns the minimum temperature of the day in the selec

historical > ... > mintemp
(Default: Celsius)

Returns the maximum temperature of the day in the selec

historical > ... > maxtemp
(Default: Celsius)

Returns the average temperature of the day in the selecte

historical > ... > avgtemp
Celsius)

Returns the snow fall amount in the selected unit. (Defaul

historical > ... > totalsnow
cm)
Response Object Description

historical > ... > sunhour Returns the number of sun hours.

historical > ... > uv_index Returns the UV index associated with the current weather

Returns a series of sub response objects containing hourly

historical > ... > hourly
listed and explained in detail below.

Returns the time as a number in 24h format:

 0 = 12:00 AM
 100 = 1:00 AM
 200 = 2:00 AM
hourly > time
 ...
 1200 = 12:00 PM
 1300 = 1:00 PM
 etc.

hourly > temperature Returns the temperature in the selected unit. (Default: Ce

hourly > wind_speed Returns the wind speed in the selected unit. (Default: kilo

hourly > wind_degree Returns the wind degree.

hourly > wind_dir Returns the wind direction.

Returns the universal weather condition code associated

hourly > weather_code weather condition. You can download all available weathe
this link: Download Weather Codes (ZIP file)

Returns one or more PNG weather icons associated with t

hourly > weather_icons
weather condition.
Response Object Description

Returns one or more weather description texts associated

hourly > weather_descriptions
current weather condition.

Returns the precipitation level in the selected unit. (Defau

hourly > precip
millimeters)

hourly > humidity Returns the air humidity level in percentage.

hourly > visibility Returns the visibility level in the selected unit. (Default: k

hourly > pressure Returns the air pressure in the selected unit. (Default: MB

hourly > cloudcover Returns the cloud cover level in percentage.

Returns the heat index temperature in the selected unit. (

hourly > heatindex
Celsius)

hourly > dewpoint Returns the dew point temperature in the selected unit. (D

hourly > windchill Returns the wind chill temperature in the selected unit. (D

Returns the wind gust speed in the selected unit. (Default

hourly > windgust
kilometers/hour)

Returns the "Feels Like" temperature in the selected unit.

hourly > feelslike
Celsius)

hourly > chanceofrain Retuns the chance of rain (precipitation) in percentage.

hourly > chanceofremdry Retuns the chance of remaining dry in percentage.

hourly > chanceofwindy Retuns the chance of being windy in percentage.

 Response Object Description

hourly > chanceofovercast Retuns the chance of being overcast in percentage.

hourly > chanceofsunshine Retuns the chance of sunshine in percentage.

hourly > chanceoffrost Retuns the chance of frost in percentage.

hourly > chanceofhightemp Retuns the chance of high temperatures in percentage.

hourly > chanceoffog Retuns the chance of fog in percentage.

hourly > chanceofsnow Retuns the chance of snow in percentage.

hourly > chanceofthunder Retuns the chance of thunder in percentage.

hourly > uv_index Returns the UV index associated with the current weather

Historical:
JavaScript FetchJavaScript AxiosPython RequestsPython Http.client

const url = 'https://api.weatherstack.com/historical?

access_key={PASTE_YOUR_API_KEY_HERE}&query=New
York&historical_date=2015-01-21&hourly=1';
const options = {
method: 'GET'
};

try {
const response = await fetch(url, options);
 const result = await response.text();
console.log(result);
} catch (error) {
console.error(error);
}

Historical Time-SeriesAvailable on: Standard Plan and higher

In addition to looking up historical weather data for specific dates, the API is also
capable of processing historical time-series results if the
parameters historical_date_start and historical_date_end are set to valid dates.
Example API Request:
Run API Requesthttp://api.weatherstack.com/historical
? access_key = 326434219471cbee84aa40cb52b52ad1
& query = New York
& historical_date_start = 2015-01-21
& historical_date_end = 2015-01-25

HTTP GET Request Parameters:

Object Description

[Required] Your API access key, which can be found in yo

access_key
dashboard.

[Required] Use this parameter to pass a single location o

query semicolon-separated location identifiers to the API. Learn
the Query Parameter.
Object Description

[Required] Use this parameter to pass a start date for th

historical_date_start
historical time-series request.

[Required] Use this parameter to pass an end date for th

historical_date_end
historical time-series request.

[Optional] Set this parameter to 1 (on) or 0 (off) dependin

hourly
not you want the API to return weather data split hourly. (

[Optional] If hourly data is enabled, use this parameter to

interval:
 1 hour

interval  3 hourly (default)

 6 hourly
 12 hourly (day/night)
 24 hourly (day average)

[Optional] Use this parameter to pass one of the unit iden

API:
 m for Metric
units
 s for Scientific
 f for Fahrenheit
Learn more about the Units Parameter.

[Optional] Use this parameter to specify your preferred AP

language language using its ISO-code. (Default: unset, English) Lea
the Language Parameter.

[Optional] Use this parameter to specify a JSONP callback

callback
to wrap your API response in. Learn more about JSONP Ca
API Response:
For more information about the API response, please refer to the API response in
the Historical Weather section above.
Please note: The historical time-series can accept a maximum timeframe of 60
days.
Note: Each day and location included in your request will count towards your
monthly allowed API request volume.

Historical Time-Series:
JavaScript FetchJavaScript AxiosPython RequestsPython Http.client

const url =
"https://api.weatherstack.com/historical?
access_key={PASTE_YOUR_API_KEY_HERE}&query=New
York&historical_date_start=2015-01-21&historical_date_end=2015-01-25";
const options = {
method: "GET",
};

try {
const response = await fetch(url, options);
const result = await response.text();
console.log(result);
} catch (error) {
console.error(error);
}
Weather ForecastAvailable on: Professional Plan and higher
The weatherstack is capable of returning weather forecast data for up to 14 days
into the future. To get weather forecasts, simply use the API's forecast and define
your preferred number of forecast days using the forecast_days parameter.
Example API Request:
Run API Requesthttp://api.weatherstack.com/forecast
? access_key = 326434219471cbee84aa40cb52b52ad1
& query = New York
& forecast_days = 1
& hourly = 1

HTTP GET Request Parameters:

Object Description

[Required] Your API access key, which can be found in yo

access_key
dashboard.

[Required] Use this parameter to pass a single location o

query semicolon-separated location identifiers to the API. Learn
the Query Parameter.

[Optional] Use this parameter to specify the number of da

forecast_days API returns forecast data. (Default: 7 or 14 days, dependin
subscription)

[Optional] Set this parameter to 1 (on) or 0 (off) dependin

hourly
not you want the API to return weather data split hourly. (

interval [Optional] If hourly data is enabled, use this parameter to

interval:
 1 hour
 Object Description

 3 hourly (default)
 6 hourly
 12 hourly (day/night)
 24 hourly (day average)

[Optional] Use this parameter to pass one of the unit iden

API:
 m for Metric
units
 s for Scientific
 f for Fahrenheit
Learn more about the Units Parameter.

[Optional] Use this parameter to specify your preferred AP

language language using its ISO-code. (Default: unset, English) Lea
the Language Parameter.

[Optional] Use this parameter to specify a JSONP callback

callback
to wrap your API response in. Learn more about JSONP Ca

Note: Each day and location included in your request will count towards your
monthly allowed API request volume.
API Response:
{
"request": {
"type": "City",
"query": "New York, United States of America",
"language": "en",
"unit": "m"
},
 "location": {
"name": "New York",
"country": "United States of America",
"region": "New York",
"lat": "40.714",
"lon": "-74.006",
"timezone_id": "America/New_York",
"localtime": "2019-09-07 11:38",
"localtime_epoch": 1567856280,
"utc_offset": "-4.0"
},
"current": {
"observation_time": "03:38 PM",
"temperature": 18,
"weather_code": 113,
"weather_icons": [

"https://assets.weatherstack.com/images/wsymbols01_png_64/wsymbol_0001_sunn
y.png"
],
"weather_descriptions": [
"Sunny"
],
"wind_speed": 0,
"wind_degree": 345,
"wind_dir": "NNW",
"pressure": 1011,
"precip": 0,
"humidity": 58,
"cloudcover": 0,
 "feelslike": 18,
"uv_index": 5,
"visibility": 16
},
"forecast": {
"2019-09-07": {
"date": "2019-09-07",
"date_epoch": 1567814400,
"astro": {
"sunrise": "06:28 AM",
"sunset": "07:19 PM",
"moonrise": "03:33 PM",
"moonset": "12:17 AM",
"moon_phase": "First Quarter",
"moon_illumination": 54
},
"mintemp": 17,
"maxtemp": 25,
"avgtemp": 21,
"totalsnow": 0,
"sunhour": 10.3,
"uv_index": 5,
"hourly": [
{
"time": "0",
"temperature": 18,
"wind_speed": 28,
"wind_degree": 15,
"wind_dir": "NNE",
"weather_code": 122,
 "weather_icons": [

"https://assets.weatherstack.com/images/wsymbols01_png_64/wsymbol_0004_black
_low_cloud.png"
],
"weather_descriptions": [
"Overcast"
],
"precip": 0,
"humidity": 68,
"visibility": 10,
"pressure": 1008,
"cloudcover": 75,
"heatindex": 18,
"dewpoint": 12,
"windchill": 18,
"windgust": 35,
"feelslike": 18,
"chanceofrain": 0,
"chanceofremdry": 87,
"chanceofwindy": 0,
"chanceofovercast": 90,
"chanceofsunshine": 15,
"chanceoffrost": 0,
"chanceofhightemp": 0,
"chanceoffog": 0,
"chanceofsnow": 0,
"chanceofthunder": 0,
"uv_index": 0
},
 { "time": "300", ... },
{ "time": "600", ... },
// 6 more items
]
}
}
}

Please note: The response objects request, location and current will not be
explained below as they are already mentioned in the Current Weather
Endpoint section.
API Response Objects:

Response Object Description

forecast > ... > date Returns the requested forecast date.

forecast > ... > date_epoch Returns the requested forecast date as UNIX timestamp.

Returns a total of 6 sub response objects containing astro

forecast > ... > astro
details, listed and explained in detail below.

astro > sunrise Returns the local sunrise time in the format hh:mm am/pm

astro > sunset Returns the local sunset time in the format hh:mm am/pm

astro > moonrise Returns the local moonrise time in the format hh:mm am/

astro > moonset Returns the local moonset time in the format hh:mm am/p

astro > moon_phase Returns the local moon phase. Possible values:
 New Moon
Response Object Description

 Waxing Crescent
 First Quarter
 Waxing Gibbous
 Full Moon
 Waning Gibbous
 Last Quarter
 Waning Crescent

astro > moon_illumination Returns the moon illumination level as percentage.

Returns the minimum temperature of the day in the selec

forecast > ... > mintemp
(Default: Celsius)

Returns the maximum temperature of the day in the selec

forecast > ... > maxtemp
(Default: Celsius)

Returns the average temperature of the day in the selecte

forecast > ... > avgtemp
Celsius)

Returns the snow fall amount in the selected unit. (Defaul

forecast > ... > totalsnow
cm)

forecast > ... > sunhour Returns the number of sun hours.

forecast > ... > uv_index Returns the UV index associated with the current weather

Returns a series of sub response objects containing hourly

forecast > ... > hourly
listed and explained in detail below.

hourly > time Returns the time as a number in 24h format:

 0 = 12:00 AM
Response Object Description

 100 = 1:00 AM
 200 = 2:00 AM
 ...
 1200 = 12:00 PM
 1300 = 1:00 PM
 etc.

hourly > temperature Returns the temperature in the selected unit. (Default: Ce

hourly > wind_speed Returns the wind speed in the selected unit. (Default: kilo

hourly > wind_degree Returns the wind degree.

hourly > wind_dir Returns the wind direction.

Returns the universal weather condition code associated

hourly > weather_code weather condition. You can download all available weathe
this link: Download Weather Codes (ZIP file)

Returns one or more PNG weather icons associated with t

hourly > weather_icons
weather condition.

Returns one or more weather description texts associated

hourly > weather_descriptions
current weather condition.

Returns the precipitation level in the selected unit. (Defau

hourly > precip
millimeters)

hourly > humidity Returns the air humidity level in percentage.

hourly > visibility Returns the visibility level in the selected unit. (Default: k
Response Object Description

hourly > pressure Returns the air pressure in the selected unit. (Default: MB

hourly > cloudcover Returns the cloud cover level in percentage.

Returns the heat index temperature in the selected unit. (

hourly > heatindex
Celsius)

hourly > dewpoint Returns the dew point temperature in the selected unit. (D

hourly > windchill Returns the wind chill temperature in the selected unit. (D

Returns the wind gust speed in the selected unit. (Default

hourly > windgust
kilometers/hour)

Returns the "Feels Like" temperature in the selected unit.

hourly > feelslike
Celsius)

hourly > chanceofrain Retuns the chance of rain (precipitation) in percentage.

hourly > chanceofremdry Retuns the chance of remaining dry in percentage.

hourly > chanceofwindy Retuns the chance of being windy in percentage.

hourly > chanceofovercast Retuns the chance of being overcast in percentage.

hourly > chanceofsunshine Retuns the chance of sunshine in percentage.

hourly > chanceoffrost Retuns the chance of frost in percentage.

hourly > chanceofhightemp Retuns the chance of high temperatures in percentage.

hourly > chanceoffog Retuns the chance of fog in percentage.

 Response Object Description

hourly > chanceofsnow Retuns the chance of snow in percentage.

hourly > chanceofthunder Retuns the chance of thunder in percentage.

hourly > uv_index Returns the UV index associated with the current weather

Weather Forecast:
JavaScript FetchJavaScript AxiosPython RequestsPython Http.client

const url = 'https://api.weatherstack.com/forecast?

access_key={PASTE_YOUR_API_KEY_HERE}&query=New York&forecast_days=7';
const options = {
method: 'GET'
};

try {
const response = await fetch(url, options);
const result = await response.text();
console.log(result);
} catch (error) {
console.error(error);
}
Location Lookup/AutocompleteAvailable on: Standard Plan and higher
The weatherstack API's location autocomplete endpoint can be used to pinpoint one
or more specific locations and their identifying response objects with the aim of
later passing them to a weather data endpoint. In our example below, we are
looking for London, United Kingdom.
Example API Request:
Run API Requesthttp://api.weatherstack.com/autocomplete
? access_key = 326434219471cbee84aa40cb52b52ad1
& query = london

HTTP GET Request Parameters:

Object Description

[Required] Your API access key, which can be found in yo

access_key
dashboard.

[Required] Use this parameter to pass your location

query
search/autocomplete query to the API in free-text.

[Optional] Use this parameter to specify a JSONP callback

callback
to wrap your API response in. Learn more about JSONP Ca

API Response:
A successful API request will return one or multiple results that match your search
query. In our example, the first array object (London, United Kingdom) contains the
correct result. Now that we have our identifying response objects of the target
location we were looking for, we can make sure that the correct location is used by
other API endpoints by using one of the available location identifiers
(ideally: lat and lon) for upcoming queries.
{
"request": {
"query": "london",
 "results": 2
},
"results": [
{
"name": "London",
"country": "United Kingdom",
"region": "City of London, Greater London",
"lon": "-0.106",
"lat": "51.517",
"timezone_id": "Europe/London",
"utc_offset": "1.0"
},
{
"name": "London",
"country": "Canada",
"region": "Ontario",
"lon": "-81.250",
"lat": "42.983",
"timezone_id": "America/Toronto",
"utc_offset": "-4.0"
}
]
}

API Response Objects:

Response Object Description

request > query Returns the exact query sent to the API.
 Response Object Description

request > results Returns the number of results found as an integer.

results > name Returns the name of the resulting city.

results > country Returns the associated country.

results > region Returns the name of the resulting region/state/district.

results > lon Returns the longitude coordinates of the resulting location

results > lat Returns the latitude coordinates of the resulting location.

Returns the timezone ID associated with the resulting loca

results > timezone_id
(Example: America/New_York)

Returns the UTC offset (in hours) of the timezone associat

results > utc_offset
resulting location. (Example: -4.0)

Autocomplete:
JavaScript FetchJavaScript AxiosPython RequestsPython Http.client

const url = 'https://api.weatherstack.com/autocomplete?

access_key={PASTE_YOUR_API_KEY_HERE}&query=New Delhi';
const options = {
method: 'GET'
};

try {
 const response = await fetch(url, options);
const result = await response.text();
console.log(result);
} catch (error) {
console.error(error);
}

General Options
Units ParameterAvailable on: All plans
By default, the API will return all results in metric units. Aside from metric units,
other common unit formats are supported as well. You can use the units parameter
to switch between the different unit formats Metric, Scientific and Fahrenheit.
m for Metric:

Parameter Units

units = m temperature: Celsius

units = m Wind Speed/Visibility: Kilometers/Hour

units = m Pressure: MB - Millibar

units = m Precip: MM - Millimeters

units = m Total Snow: CM - Centimeters

s for Scientific:
 Parameter Units

units = s temperature: Kelvin

units = s Wind Speed/Visibility: Kilometers/Hour

units = s Pressure: MB - Millibar

units = s Precip: MM - Millimeters

units = s Total Snow: CM - Centimeters

f for Fahrenheit:

Parameter Units

units = f temperature: Fahrenheit

units = f Wind Speed/Visibility: Miles/Hour

units = f Pressure: MB - Millibar

units = f Precip: IN - Inches

units = f Total Snow: IN - Inches

Language ParameterAvailable on: Professional Plan and higher

The API is capable of delivering results in a total of 40 world languages. To change
the default value (English) to another language, simply attach
the language parameter to your API URL and set it to the 2-letter ISO Code of your
preferred language.
Supported Languages:
Parameter (ISO Code) Language

language = ar Arabic

language = bn Bengali

language = bg Bulgarian

language = zh Chinese Simplified

language = zh_tw Chinese Traditional

language = cs Czech

language = da Danish

language = nl Dutch

language = fi Finnish

language = fr French

language = de German

language = el Greek

language = hi Hindi

language = hu Hungarian

language = it Italian

language = ja Japanese
Parameter (ISO Code) Language

language = jv Javanese

language = ko Korean

language = zh_cmn Mandarin

language = mr Marathi

language = pl Polish

language = pt Portuguese

language = pa Punjabi

language = ro Romanian

language = ru Russian

language = sr Serbian

language = si Sinhalese

language = sk Slovak

language = es Spanish

language = sv Swedish

language = ta Tamil

language = te Telugu
 Parameter (ISO Code) Language

language = tr Turkish

language = uk Ukrainian

language = ur Urdu

language = vi Vietnamese

language = zh_wuu Wu (Shanghainese)

language = zh_hsn Xiang

language = zh_yue Yue (Cantonese)

language = zu Zulu

JSONP CallbacksAvailable on: All plans

The API supports JSONP Callbacks. To make use of this feature, simply append the
API's callback parameter to your API request URL and set it to your preferred
function name. The API will then return your API results set wrapped inside the tags
of the function you specified.
Example API Request:
Run API Requesthttp://api.weatherstack.com/current
? access_key = 326434219471cbee84aa40cb52b52ad1
& query = New York
& callback = FUNCTION_NAME

Example API Response:

CALLBACK_FUNCTION ({
{
 "request": {
"type": "City",
"query": "New York, United States of America",
"language": "en",
[...]
}
})

Please note: The API also supports Access-Control (CORS) headers.

Business Continuity - API Overages
Ensuring our customers achieve success is paramount to what we do at APILayer.
For this reason, we will be rolling out our Business Continuity plan guaranteeing
your end users will never see a drop in coverage. Every plan has a certain amount
of API calls that you can make in the given month. However, we would never want
to cut your traffic or impact user experience negatively for your website or
application in case you get more traffic.
What is an overage?
An overage occurs when you go over a quota for your API plan. When you reach
your API calls limit, we will charge you a small amount for each new API call so we
can make sure there will be no disruption in the service we provide to you and your
website or application can continue running smoothly.
Prices for additional API calls will vary based on your plan. See table below for prices
per call and example of an overage billing.

Monthly Number of Overage Price Ove

Plan Name
Price Calls per call ge

Standard $9.99 50,000 0.0002997 10,0

Professional $49.99 300,000 0.00024995 60,0

200
Business $99.99 1,000,000 0.000149985
0

Why does APILayer have overage fees?

Overage fees allow developers to continue using an API once a quota limit is
reached and give them time to upgrade their plan based on projected future use
while ensuring API providers get paid for higher usage.
How do I know if I will be charged for overages?
When you are close to reaching your API calls limit for the month, you will receive
an automatic notification (at 75%, 90% and 100% of your monthly quota). However,
it is your responsibility to review and monitor for the plan’s usage limitations. You
are required to keep track of your quota usage to prevent overages. You can do this
by tracking the number of API calls you make and checking the dashboard for up-to-
date usage statistics.
How will I be charged for my API subscription?
You will be charged for your monthly subscription plan, plus any overage fees
applied. Your credit card will be billed after the billing period has ended.
What happens if I don’t have any overage fees?
In this case, there will be no change to your monthly invoice. Only billing cycles that
incur overages will see any difference in monthly charges. The Business Continuity
plan is an insurance plan to be used only if needed and guarantees your end users
never see a drop in coverage from you.
What if I consistently have more API calls than my plan allows?
If your site consistently surpasses the set limits each month, you may face
additional charges for the excess usage. Nevertheless, as your monthly usage
reaches a certain threshold, it becomes more practical to consider upgrading to the
next plan. By doing so, you ensure a smoother and more accommodating
experience for your growing customer base.
I would like to upgrade my plan. How can I do that?
You can easily upgrade your plan by going to your Dashboard and selecting the new
plan that would be more suitable for your business needs. Additionally, you may
contact your Account Manager to discuss a custom plan if you expect a continuous
increase in usage.
Introducing Platinum Support - Enterprise-grade support for APILayer
Upgrade your APIlayer subscription with our exclusive Platinum Support, an
exceptional offering designed to enhance your business’ API management journey.
With Platinum Support, you gain access to a host of premium features that take
your support experience to a whole new level.
What does Platinum Support include?

Standard Support Platinum Suppor

 General review on the issue

Access to knowledge base articles

Email support communication

Regular products updates and

fixes

Dedicated account team

Priority Email Support with

unlimited communication

Priority bug and review updates

Option for quarterly briefing call

with product Management

Features requests as priority

roadmap input into product

Priority Email Support: Experience unrivaled responsiveness with our priority

email support. Rest assured that your inquiries receive top-priority attention,
ensuring swift resolutions to any issues.
Unlimited Communication: Communication is key, and with Platinum Support,
you enjoy unlimited access to our support team. No matter how complex your
challenges are, our experts are here to assist you every step of the way.
Priority Bug Review and Fixes: Bugs can be a headache, but not with Platinum
Support. Benefit from accelerated bug review and fixes, minimizing disruptions and
maximizing your API performance.
Dedicated Account Team: We understand the value of personalized attention.
That's why Platinum Support grants you a dedicated account team, ready to cater
to your specific needs and provide tailored solutions.
Quarterly Briefing Call with Product Team: Stay in the loop with the latest
updates and insights from our Product team. Engage in a quarterly briefing call to
discuss new features, enhancements, and upcoming developments.
Priority Roadmap Input: Your input matters! As a Platinum Support subscriber,
your feature requests receive top priority, shaping our product roadmap to align
with your evolving requirements.
Don't settle for the standard when you can experience the exceptional. Upgrade to
Platinum Support today and supercharge your APIlayer experience!
Upgrade now
Choose the subscription plan "One Call by Call" and get access to the various data
for any coordinates with One Call API 3.0.
1,000 API calls per day for free! Pay as you call.

Included data Time

Current weather Now

Minute forecast Next hour

Hourly forecast Next 48 hours

Daily forecast Next 8 days

Weather data by any 45+ years back - 4 days ahead

timestamp forecast

National weather alerts All available data

45+ years back - 1,5 years ahead

Daily aggregation
forecast

human-readable weather
Weather overview
summary

1.
On/off button for the display.
Figure 13. Display.
Two microprocessors and a wireless board were installed to handle all the sensors
and the HMI. This solution prevents overheating a single MCU and provides an
easier way to modularize the sub-systems. Following this design, two PCBs were
designed: main PCB (Figure 14) and second PCB (Figure 15).
Figure 14. Main PCB.

Figure 15. Second PCB.

The main PCB includes:
 1. The main MCU that manages the sensors stores the data in the SD card,
controls the timestamp obtained from the RTC, and sends the data shown
through the display.
2. SD module controlled with SPI protocol.
3. Button for removing or inserting the SD safely.
4. 3V Coin battery to power the RTC even when the primary power source is
disconnected.
5. Voltage regulators.
6. JST connectors for a secure component connection.
On the other hand, the second PCB includes:
1. MCU that manages the 2.4″ display and controls the WiFi board.
2. JST connector for communication with the main PCB.
3. WiFi board (ESP8266) that sends the data via the internet to ThingSpeak.
4. Headers to attach the display.
4.2. Ergonomics Assessment
Once the prototype was functional, it was evaluated in terms of ergonomics. It is a
science focused on equipment design with a human-centered approach to reduce
operator fatigue or discomfort considering physical, cognitive, social, organizational,
and environmental factors [38,39]. Since this science focuses on improving design
performance, the degree of usability must be quantified to accurately assess the
ease of use of the designed prototype; therefore, several helpful methods exist for
this purpose. For instance, keystroke-level model, link analysis, questionaries,
checklist, hierarchical task analysis, layout analysis, and interview, among others
[39]; the selection of the methods for the assessment depends on the project´s
design stage in this case. the project has a functional and physical prototype.
Therefore, the methods selected were observation for the usability link analysis and
layout analysis for the ergonomics test [39].
The observation method was performed by giving the users the device and asking
them to perform planned activities; in this case, six users were selected, and six
different activities were established:
1. Move the station to a specific point.
2. Turn on the device.
3. Set the measurement interval time to 24 h.
4. Turn off the display.
5. Open the case to get access to the internal components.
6. Remove the SD card.
Only six users were selected since, when evaluating the usability of a product, it is
enough for only five users to use the product because they will find more than 75%
of the product issues. Using fewer users will lead to not covering most of these
problems; meanwhile, using more than six users, repeated issues will be found,
making the results meaningless [40].
Each user had ten points at the beginning of the test, and then each wrong action or
asking of a question was penalized by subtracting one point each time; in addition,
the time that the user took to complete all the activities was measured. Table
5 shows the average score of each activity performed by the six users and the
average time. In general, the overall score was 8.7 regarding usability.
Table 5. Observation method results for the usability test.

Regarding ergonomics, the layout and link analyses were performed simultaneously
on the human–machine interface presented in Figure 12. The first method states
that the components from the same category must be as close as possible. There
were only two categories found: device control and power. On the other hand, the
second method consists of establishing a sequence of actions that would be one of
the most common sequences while using the device in a normal operational mode
and tracing lines between the components following that order [39]. In this case,
the sequence was:
1. Turn on the device.
2. Check the indicator LEDs.
3. Turn on the display.
4. Watch the display and the measurements.
5. Change the measuring interval time to a different value.
Figure 16 depicts the two groups (red for device control and blue for power) and
the lines (green) that follow the order established. The device control group includes
the components labeled B, C, D, and E; the power group includes only component A.
Figure 16. Layout analysis and link analysis.
Once the lines are traced, the method establishes that no line should cross with
another to enhance operability and ergonomics. In this case, line A-E crosses line C-
D, indicating that one or more components should be relocated.
Figure 17 shows the rearrangement of the components that satisfy the link
analysis requirements. Furthermore, it can be observed that the four elements (B, C,
D, and E) are now grouped and satisfy the layout analysis requirements.
Figure 17. Components relocated.
4.3. Data Comparison
The first comparison was between the designed weather station and the Schneider
Electric thermostat. As stated, the two devices were placed together, as shown
in Figure 7. The data from the reference instrument were provided directly by
Schneider´s personnel. Figure 18 shows the two signals; the blue line represents
the measurements performed by the current proposal, and the orange one is the
reference value. At first glance, the two signals seem to have the same direction,
and a monotonic relationship can be inferred.

Figure 18. OSWS and reference device plot in an indoor scenario for temperature.
Statistical parameters were obtained to compare the two signals and determine
their relationship. The first non-parametric value is the Spearman correlation, which
indicates the strength of the association, a number between −1 and 1, and the
direction of the association, which can be positive or negative [40]. Additionally, the
root mean square error (RMSE) and mean absolute percentage error MAPE were
calculated to determine the performance of the measurement process; these
parameters are mainly focused on rating a forecast model’s accuracy, but they can
be applied to quantify the total error of two signals.
Moreover, a Bland–Altman plot was generated to assess the agreement between
these two signals. On the y-axis, the differences between the measurements are
displayed; on the x-axis, the averages of the measurements are plotted. Each plot
on this graph is a pair of measurements taken by the two instruments. Finally, this
Bland–Altman method has two limits of agreement at ±1.96 times the standard
deviation. Ideally, all the points should lie between these two limits, representing an
agreement between them [41]. Figure 19 shows the Bland–Altman plot generated
by comparing the time series.

Figure 19. Bland–Altman plot for temperatures measured indoors.

This figure indicates a good agreement between these signals since most points are
between the interval limits [41]. The differences between the paired values increase
when the temperature is between 23.6 °C and 23.8 °C. Table 6 shows the values
obtained for the other statistical parameters. The correlation parameter is a high
value indicating a strong relationship between the two measurements [42]. In
addition, RMSE and MAPE are low values, demonstrating that the OSWS has similar
measurement values to Schneider´s thermostat.
Table 6. Statistical parameters for temperature measurements.
In assessing humidity measurements, Figure 20 illustrates a comparative analysis
between the proposed OSWS and the Schneider’s thermostat over a specified time
frame. Concurrently, Figure 21 presents the Bland–Altman plot, highlighting that
most values reside within the stipulated boundaries. This pattern suggests a
favorable level of agreement between the two measurements (air temperature and
relative humidity) since most points are between the two red lines representing the
limits of agreement in which 95% of the differences between the two measurements
are expected to fall.

Figure 20. OSWS and reference device in an indoor scenario for relative humidity.
Figure 21. Bland–Altman plot for relative humidity measured indoors.
The OSWS was juxtaposed with a Purple Air sensor located approximately 2.118 km
away in the outdoor environment. The methodologies employed were consistent
with those used in the indoor experiments. Comprehensive quantitative findings are
enumerated in Table 7. Moreover, Figure 22 depicts the atmospheric pressure
graphs where the upper blue line represents the signal from the proposed station. In
contrast, the red line at the bottom corresponds to the reference sensor. Notably,
the difference in readings between the two signals in Figure 22 could be attributed
to the variance in altitude where each sensor was positioned. Figure 23 highlights
the measurement discrepancy, revealing an average difference of 1.07 hPa. Figure
24 shows a Bland–Altman plot that affirms a notable alignment between the two
signals, with most of the points nestled within the limits of agreement. Additionally,
it is paramount to consider the inherent biases of the sensors, which can introduce
measurement discrepancies. External noise, including environmental factors or
electronic interference, can also influence the readings, affecting the system’s
accuracy.
Figure 22. OSWS and reference device plot in an outdoor scenario for atmospheric
pressure.
Figure 23. Differences between the two pressure time series.
Figure 24. Bland–Altman plot for pressure measured outdoors.
Table 7. Statistical parameters for measurements in an indoor scenario.

Furthermore, concerning PM 2.5 measurements, Figure 25 captures the

simultaneous readings from the OSWS and the reference device in an outdoor
scenario. Figure 26 details the disparities between the two PM 2.5 time series,
shedding light on periods of convergence and divergence. Finally, Figure
27 employs a Bland–Altman plot to visualize the agreement of PM 2.5 values
measured outdoors between the OSWS and the reference device, reinforcing the
consistency and reliability of the OSWS measurements.
Figure 25. OSWS and reference device plot in an outdoor scenario for PM 2.5.
Figure 26. Differences between the two PM 2.5 time series.
Figure 27. Bland–Altman plot for PM 2.5 measured outdoors.
These numbers provide essential information and insights about the data gathered.
Regarding the Spearman correlation, all the data collected from the sensors are
considered to have a robust positive correlation since all the Spearman correlation
values are above 0.8 [40,42]. In the case of the RMSE parameter, all the
measurements were below five units, and the MAPE was below 10%. It is essential
to mention that the air temperature and relative humidity may be affected by the
buildings near the OSWS and the house where the device was placed [14].
5. Discussion
5.1. Comparison with the Existing Literature
The introduction of the OSWS in the realm of weather monitoring marks a significant
stride. To contextualize its place amidst the extensive literature on the subject, it is
vital to delineate how the OSWS aligns with, deviates from, and potentially
surpasses contemporary solutions. The core strength of OSWS lies in its
commitment in democratizing weather data access using cost-effective sensors.
Many monitoring systems in the current literature either prioritize accuracy over
affordability or vice versa. However, the OSWS strikes a balance, ensuring that
smaller communities and users are not left behind in the age of data-driven
decision-making. This holistic approach offers a twofold advantage: it ensures
affordability without compromising the essential quality of weather data.
Furthermore, real-time data sharing and monitoring capabilities distinguish the
OSWS from many conventional systems. In sectors where swift responses to
changing weather conditions are paramount, the immediacy of data becomes
indispensable. The potential of OSWS to create a connected network of weather
stations exponentially amplifies this benefit, enhancing data accessibility and utility
across regions.
To encapsulate the distinctions and similarities between the OSWS and other
research endeavors, the comparative Table 8 offers a concise quantitative
perspective, aiding in discerning the unique propositions the OSWS offers. This table
shows the root mean square error that each station has against a professional
measuring tool in an indoor scenario and whose values are considered as the
reference.
Table 8. Comparative table between this OSWS and other projects in RMSE.

5.2. Impact
The revolutionary aspect of the OSWS is its democratization of weather data
through low-cost sensors, facilitating accessible and affordable weather monitoring.
By enabling real-time data sharing, the OSWS fosters timely decisions, which is
crucial for sectors sensitive to weather fluctuations. Apart from real-time weather
monitoring, the broader vision behind the OSWS extends to its application across
diverse sectors like agriculture and urban development. Its educational utility,
offering a tangible tool for learners, further underscores its multifaceted
applicability.
The OSWS, with its potential for regional weather analysis and integration from
multiple units, lays the groundwork for enhanced predictive capabilities, with
notable relevance in sectors relying heavily on accurate weather forecasts.
5.3. Limitations and Future Directions
While the OSWS heralds a transformative shift in weather monitoring, certain
limitations prevail. These encompass the system’s precision, which, while
consistent, might be inherently limited due to its cost-effective approach. Another
pivotal concern is data transmission and security, especially in regions with
unreliable internet connectivity.
Future endeavors related to the OSWS ought to emphasize:
1. Secure and dependable data transmission, particularly in remote settings.
 2. ExplorING alternative data transmission channels and offline data
logging/retrieval solutions.
3. Strengthening data security measures to preserve data integrity during
transmission and storage.
4. Investigating durable sensors and materials to withstand environmental
challenges, reinforcing the OSWS’s reliability.
6. Conclusions
The OSWS offers a groundbreaking approach to weather monitoring, harnessing
low-cost sensors to overcome challenges posed by high costs and the need for
expert personnel inherent in existing technologies. Its capacity for real-time
monitoring and forecasting of pivotal environmental variables using the ARIMA
model stands utmost for agriculture, transportation, and air quality monitoring. Its
open-source nature further amplifies data accessibility, fostering informed decisions
essential in our current climate-changing era.
The design and implementation of the OSWS laid the groundwork for the future
evolution of cost-effective and efficient monitoring systems. As we move ahead,
focusing on enhancing data transmission security, diversifying communication
interfaces, and enduring diverse environmental conditions will be pivotal in refining
the OSWS, aiming to bolster environmental sustainability and foster informed
decision-making amidst escalating ecological challenges.
Author Contributions
Conceptualization, A.R., P.P., A.M. (Arturo Molina) and A.M. (Alan Meier);
Methodology, A.R., P.P. and O.M.; Software, A.R., P.P. and A.M. (Arturo Molina);
Validation, A.R., P.P. and O.M.; Formal analysis, A.R., P.P., O.M., A.M. (Arturo Molina)
and A.M. (Alan Meier); Investigation, A.R., P.P., O.M. and A.M. (Alan Meier);
Resources, P.P.; Data curation, A.R., P.P. and A.M. (Arturo Molina); Writing—original
draft, P.P. and A.M. (Alan Meier); Writing—review & editing, A.R. and A.M. (Arturo
Molina); Visualization, A.R.; Supervision, P.P., A.M. (Arturo Molina) and A.M. (Alan
Meier); Project administration, P.P.; Funding acquisition, A.M. (Arturo Molina). All
authors have read and agreed to the published version of the manuscript.
Funding
Institute of Advanced Materials for Sustainable Manufacturing, Tecnológico de
Monterrey.
Institutional Review Board Statement
Not applicable.
Informed Consent Statement
Not applicable.
Data Availability Statement
Data are contained within the article.
Conflicts of Interest
The authors declare no conflict of interest.
References
1. Effects|Facts—Climate Change: Vital Signs of the Planet. Available
online: https://climate.nasa.gov/effects/ (accessed on 2 October 2023).
2. United Nations. What Is Climate Change? Available
online: https://www.un.org/en/climatechange/what-is-climate-change (
accessed on 2 October 2023).
3. Lai, C. How Does Deforestation Affect the Carbon Cycle? Earth.Org. Available
online: https://earth.org/how-does-deforestation-affect-the-carbon-
cycle/ (accessed on 2 October 2023).
4. US EPA. Causes of Climate Change. Available
online: https://www.epa.gov/climatechange-science/causes-climate-
change (accessed on 2 October 2023).
5. US EPA. Introduction to Indoor Air Quality. Available
online: https://www.epa.gov/indoor-air-quality-iaq/introduction-
indoor-air-quality (accessed on 2 October 2023).
6. How Climate Change Affects Vector-Borne Diseases|News|Wellcome. Available
online: https://wellcome.org/news/how-climate-change-affects-vector-
borne-diseases (accessed on 2 October 2023).
7. Kulkarni, M.A.; Duguay, C.; Ost, K. Charting the Evidence for Climate Change
Impacts on the Global Spread of Malaria and Dengue and Adaptive
Responses: A Scoping Review of Reviews. Glob. Health 2022, 18, 1. [Google
Scholar] [CrossRef] [PubMed]
8. Weather Forecast with Meteodrones Weather Drones|Meteomatics. Available
online: https://www.meteomatics.com/en/meteodrones-weather-
drones/ (accessed on 2 October 2023).
9. Surface Mooring Network in the Kuroshio Extension. Available
online: https://ieeexplore.ieee.org/document/4579297 (accessed on 2
October 2023).
10.Demetillo, A.T.; Japitana, M.V.; Taboada, E.B. A System for Monitoring Water
Quality in a Large Aquatic Area Using Wireless Sensor Network
Technology. Sustain. Environ. Res. 2019, 29, 12. [Google Scholar]
[CrossRef]
11.AE521/AE521: What Is a Wireless Sensor Network? Available
online: https://edis.ifas.ufl.edu/publication/AE521 (accessed on 2
October 2023).
 12.Pule, M.; Yahya, A.; Chuma, J. Wireless Sensor Networks: A Survey on
Monitoring Water Quality. J. Appl. Res. Technol. 2017, 15, 562–570. [Google
Scholar] [CrossRef]
13.Newlands, N.K. Model-Based Forecasting of Agricultural Crop Disease Risk at
the Regional Scale, Integrating Airborne Inoculum, Environmental, and
Satellite-Based Monitoring Data. Front. Environ. Sci. 2018, 6, 63. [Google
Scholar] [CrossRef]
14.World Meteorological Organization. Guide to Instruments and Methods of
Observation (WMO-No. 8). Available
online: https://community.wmo.int/en/activity-areas/imop/wmo-no_8 (
accessed on 2 October 2023).

15. MQTT (Message Queuing Telemetry Transport) is a messaging

protocol under the ISO standard, designed for communication with a large
number of remote sensors and control devices that have limited
computing power and work in low-bandwidth, unreliable networks. It
works on the TCP/IP protocol family and uses a publish/subscribe model
for messaging. the MQTT protocol has the following key features:
16. 1. Lightweight: the MQTT protocol is designed to be very simple and
lightweight, which makes it very suitable for resource-constrained devices
such as sensors, smart appliances, etc.
17. 2. Open and easy to implement: The MQTT protocol is open and any
organisation or individual can use it for free, and its implementation is
relatively simple and easy to integrate into various systems.
18. 3. Support multiple message quality of service: MQTT protocol
provides three different message quality of service (QoS) to meet the
needs of different application scenarios. QoS 0 means at most one
delivery, QoS 1 means at least one delivery, QoS 2 means only one
delivery.
19. 4. Based on publish/subscribe model: MQTT protocol uses
publish/subscribe model for messaging. This model achieves decoupling
of messages, so that message publishers and subscribers do not need to
communicate directly, but through the MQTT proxy server for message
relay and distribution.
20. 5. Low overhead and low bandwidth usage: The MQTT protocol has
very low transmission overhead and bandwidth usage, which makes it
ideal for use in environments with limited bandwidth or poor network
conditions.
21. MQTT protocol has a wide range of applications in the field of IoT,
such as smart home, smart agriculture, industrial automation and so on.
Through the MQTT protocol, various IoT devices can be interconnected
and work together to build an efficient and intelligent IoT ecosystem.

For grammatical articles in English, see English articles.

In grammar, an article is any member of a class of dedicated words that are used
with noun phrases to mark the identifiability of the referents of the noun phrases.
The category of articles constitutes a part of speech.
In English, both "the" and "a(n)" are articles, which combine with nouns to form
noun phrases. Articles typically specify the grammatical definiteness of the noun
phrase, but in many languages, they carry additional grammatical information such
as gender, number, and case. Articles are part of a broader category
called determiners, which also include demonstratives, possessive determiners,
and quantifiers. In linguistic interlinear glossing, articles are abbreviated as ART.
Types of article
[edit]
Definite article
[edit]
"Definite article" redirects here. For the comedy album, see Definite Article.
A definite article is an article that marks a definite noun phrase. Definite articles,
such as the English the, are used to refer to a particular member of a group. It may
be something that the speaker has already mentioned, or it may be otherwise
something uniquely specified.
For example, Sentence 1 uses the definite article and thus, expresses a request for
a particular book. In contrast, Sentence 2 uses an indefinite article and thus,
conveys that the speaker would be satisfied with any book.
1. Give me the book.
2. Give me a book.
The definite article can also be used in English to indicate a specific class among
other classes:
The cabbage white butterfly lays its eggs on members of the Brassica genus.
However, recent developments show that definite articles are morphological
elements linked to certain noun types due to lexicalization. Under this point of view,
definiteness does not play a role in the selection of a definite article more than the
lexical entry attached to the article.[clarification needed][1][2]
Some languages (such as the continental North Germanic
languages, Bulgarian or Romanian) have definite articles only as suffixes.
Indefinite article
[edit]
An indefinite article is an article that marks an indefinite noun phrase. Indefinite
articles are those such as English "a" or "an", which do not refer to a specific
identifiable entity. Indefinites are commonly used to introduce a new discourse
referent which can be referred back to in subsequent discussion:
1. A monster ate a cookie. His name is Cookie Monster.
Indefinites can also be used to generalize over entities who have some property in
common:
1. A cookie is a wonderful thing to eat.
Indefinites can also be used to refer to specific entities whose precise identity is
unknown or unimportant.
1. A monster must have broken into my house last night and eaten all my
cookies.
2. A friend of mine told me that happens frequently to people who live on
Sesame Street.
Indefinites also have predicative uses:
1. Leaving my door unlocked was a bad decision.
Indefinite noun phrases are widely studied within linguistics, in particular because of
their ability to take exceptional scope.
Proper article
[edit]
A proper article indicates that its noun is proper, and refers to a unique entity. It
may be the name of a person, the name of a place, the name of a planet, etc.
The Māori language has the proper article a, which is used for personal nouns; so,
"a Pita" means "Peter". In Māori, when the personal nouns have the definite or
indefinite article as an important part of it, both articles are present; for example,
the phrase "a Te Rauparaha", which contains both the proper article a and the
definite article Te refers to the person name Te Rauparaha.
The definite article is sometimes also used with proper names, which are already
specified by definition (there is just one of them). For example: the Amazon, the
Hebrides. In these cases, the definite article may be considered superfluous. Its
presence can be accounted for by the assumption that they are shorthand for a
longer phrase in which the name is a specifier, i.e. the Amazon River, the Hebridean
Islands.[citation needed] Where the nouns in such longer phrases cannot be omitted, the
definite article is universally kept: the United States, the People's Republic of China.
This distinction can sometimes become a political matter: the former usage the
Ukraine stressed the word's Russian meaning of "borderlands"; as Ukraine became a
fully independent state following the collapse of the Soviet Union, it requested that
formal mentions of its name omit the article. Similar shifts in usage have occurred in
the names of Sudan and both Congo (Brazzaville) and Congo (Kinshasa); a move in
the other direction occurred with The Gambia. In certain languages, such as French
and Italian, definite articles are used with all or most names of countries: la
France, le Canada, l'Allemagne; l'Italia, la Spagna, il Brasile.
If a name [has] a definite article, e.g. the Kremlin, it cannot idiomatically be used
without it: we cannot say Boris Yeltsin is in Kremlin.
— R. W. Burchfield[3]
Some languages use definite articles with personal names, as in Portuguese (a
Maria, literally: "the Maria"), Greek (η Μαρία, ο Γιώργος, ο Δούναβης, η Παρασκευή),
and Catalan (la Núria, el/en Oriol). Such usage also occurs colloquially or dialectally
in Spanish, German, French, Italian and other languages. In Hungarian, the
colloquial use of definite articles with personal names, though widespread, is
considered to be a Germanism.
The definite article sometimes appears in American English nicknames such as "the
Donald", referring to former president Donald Trump, and "the Gipper", referring to
former president Ronald Reagan.[4]
Partitive article
[edit]
A partitive article is a type of article, sometimes viewed as a type of indefinite
article, used with a mass noun such as water, to indicate a non-s