Vegetable tracing using IOT

Abstract:
Wireless sensor networks have a strong impact all over the world
over the wired networks due to the development of new standards
and technologies from the last decades. Wireless sensor networks
are used in a wide range of applications including remote
Monitoring, health care, industrial automation or environmental
monitoring. Each WSN may have specific objectives and application
goals. Here our objective is to assure maximum quality and minimum
spoilage of the stored food in food industry, by maintaining and
monitoring of the temperature sensor, moisture sensor, gas sensor,
level sensor and colour sensor of the environment. Sensory data
comes from temperature, moisture, gas and colour sensors of
different locations, where food is stored and received at the receiver.
WSN is formulated by a group of sensor nodes equipped with short-
range communication capability. Every sensor node consists of at
least a transceiver, a processing unit, a transducer and a power unit.
New standards and technologies like internet of things, having a
specific parameter of low power consumption, are used for short
range wireless communications. This paper provides the
implementation of monitoring and controlling of sensors using high
end board Nodemcu.
Introduction:
• A food contamination can occur in the production process, but
also a large part caused by the inefficient food handling because
of inappropriate ambient conditions when the food is being
transported and stored.
• There are many factors leading to food poisoning, typically
changes in temperature and humidity are important factors. So
the monitoring system capable of measuring temperature and
humidity variability during transport and storage is of prime
 importance. Today almost everybody is getting effected by the
food they consume, it's not only about the junk food, but all the
packed foods, vegetables, products consumed and used in daily
life, as all of them do not offer quality since their temperature,
moisture, oxygen content vary from time to time.
• Majority of consumers only pay attention to the information
provided on the packaging, i.e. the amount of ingredients used
and their nutritional value but they forget that they are blindly
risking their health by ignoring the environmental conditions to
which these packets are subjected.
• Every product making firm just want to attract more and more
costumers towards them their main motive is to sell the product
anyhow like by adding more flavours, colouring chemicals and
preservatives to increase the taste and appearance but they
forget that these money making tactics are actually affecting the
consumers health.
Literature survey:
1 Application of internet of things in food packaging and
transportation
Mirjana maksimovic, Vuka karadzica, Enisa Omanovic
Food safety is a scientific field which includes a number of
routines and inspections at every stage of the food chain that should
be adopted to avoid potentially dangerous health risks. Novel and
efficient solutions across the supply chain are the consequence of
constant upgrades of information and communication technologies.
With the help of internet of things (IoT) connected testing
equipment, food quality can be monitored at any point from farm to
table, connecting at the same time food producers, transportation
and hospitality/retail companies. Relying on the fact that food
transporting and packaging units are the most critical points in food
production, the survey of IoT applications in food packaging and
transportation is given in this paper. To demonstrate the significance
of IoT appliance and defined concepts, a proposal of low cost
solution based on IoT for real-time food traceability and monitoring
in food transportation process is presented.
2. Comprehensive Monitoring System of Fresh Food Cold Chain
Logistics
 Yong Jun Zhang  , En Xiu Chen
The paper discusses how to use the advanced technology of the
Internet of things to realize the real-time monitoring of the library
and the preservation of goods in transit third party cold chain
logistics, mainly discusses how to network technology with Internet
3G network of RFID and WSN integrated network and intelligent
nodes, realize the visualization of fresh goods real-time monitoring,
convenient management personnel of customer inquiries and
feedback information, to ensure the preservation of food quality and
safety.
3. The Design of the Internet of Things Solution for Food Supply
Chain
Zhao Xiaorong, Fan Honghui, b, Zhu Hongji, Fu Zhongjun, Fu Hanyu
Many problems of foods safety had occurred in recent years,
which resulted in public panic. As a result, the government has made
food safety a top priority. In the last few years, the rapid
development of the Internet of Things (IoT). How to make sure the
security of food supply chain with the help of emerging technology—
IoT, has the important practical significance. Iot is an inevitable
choice to improve food logistics, and compare the content
networking technology application before and after the food logistics
management titer, thus must content networking technology
application in food logistics, to food logistics management titer have
larger stimulative effect. In this paper, we introduce a novel IoT
architecture able to track and trace agriculture from the field
through the supply chain and in food processing environments,
realizing the food supply chain’s effective information identification
and traceability.
4. Construction of Optimal Allocation System on the Edible
Agricultural Products Components of the Nutrition and Health Care
Based on Internet of Things

Ming Hua Wei, Liu Qing Yang, Qiao Ling Zhou, Jin GUI Zheng

In daily life, the nutrients taken from the food of the human
body are often insufficient or surplus, which has a negative impact on
human health and waste of agricultural nutrients as well. There is
some catering software that can guide people about the intake of the
nutrients at home and abroad, but they can only realize the analysis
function, that is, tell the user that the nutrients intake is inadequate
or exceed the standard. This paper constructs an optimal allocation
system of the agricultural products components of the nutrition and
health care based on internet of things, allowing people to use it at
home or in the hotel. Based on the users free ordering meal, analyze
and optimize the users meal according to different types of users
with different matching allocation model, guide the user to adjust
the meal to meet their nutrient needs, finally reach the purpose of
users adjustment of the dietary structure.
5. A Low Cost Internet of Things Solution for Traceability and
Monitoring Food Safety during Transportation
Mirjana Maksimovic, Vladimir Vujović, Enisa Omanović-Mikličanin
We are faced with a dozen food crisis, which have impact on
human health. EU as response to food contamination applies a set
of laws and standards for food traceability through all stages of
production, processing and distribution, forcing that all food and
feed operators implement special traceability systems. One of the
main and a crucial element of this system is food transport from
manufacturer to consumer, and possibility for monitoring food
quality through the transportation process. Applying new
 technologies, like Internet of Things (IoT), nowadays it is possible
to connect food producers, transportation and hospitality/retail
companies. A low cost solution based on IoT for real-time food
traceability and monitoring in food transportation process is
presented in this paper. 

Existing system:
The existing system consists of two wireless sensor networks based
on Zigbee and Bluetooth. The heart of the system is the
microcontroller, which controls both of the networks by relay
switching. A relay is connected with the microcontroller, when the
relay is on, wireless sensor network based on Bluetooth works and
when it is off, then the network based on Zigbee works. Different
sensors like temperature and humidity sensors are used to measure
the temperature and humidity of the environment. After measuring
the temperature and humidity, the data is sent to the monitoring
unit, where the data is recorded. If the temperature or the humidity
of the environment increases from a particular point, then we can
control the temperature or humidity wirelessly.
Proposed system:
• The water level sensor is used to identify the level of a liquid
content in the vegetables, and Moisture level is also identify
the environment moisture content
• DHT11 sensor is used to identify the food and external
environment level
• Gas sensor used to identify the rotten smell in vegetables
• This sensor data is getting analysed through single board
computer called Nodemcu and it send data to cloud if any of
the sensor value is critical it send the Gmail alert using Ubidots
cloud.
Block diagram:
Hardware required:
Nodemcu
DHT11 sensor
Gas sensor
Ubidots

NODE MCU

NodeMCU is an open source IoT platform.[4][5] It includes firmware which runs on

the ESP8266 Wi-Fi SoC from Espressif Systems, and hardware which is based on the ESP-12
module.[6][7] The term "NodeMCU" by default refers to the firmware rather than the
development kits. The firmware uses the Lua scripting language. It is based on the eLua
project, and built on the Espressif Non-OS SDK for ESP8266. It uses many open source
projects, such as lua-cjson[8] and SPIFFS

NodeMCU was created shortly after the ESP8266 came out. On December 30,

2013, Espressif Systems[6] began production of the ESP8266.[10] The ESP8266 is a Wi-Fi SoC
integrated with a Tensilica Xtensa LX106 core,[citation needed]
 widely used in IoT applications
(see related projects). NodeMCU started on 13 Oct 2014, when Hong committed the first file
of nodemcu-firmware to GitHub.[11] Two months later, the project expanded to include an
open-hardware platform when developer Huang R committed the gerber file of an ESP8266
board, named devkit v0.9.[12]Later that month, Tuan PM ported MQTT client library
from Contiki to the ESP8266 SoC platform,[13] and committed to NodeMCU project, then
NodeMCU was able to support the MQTT IoT protocol, using Lua to access the MQTT
broker. Another important update was made on 30 Jan 2015, when Devsaurus ported the
u8glib[14] to NodeMCU project,[15] enabling NodeMCU to easily drive LCD, Screen, OLED,
even VGA displays.

In summer 2015 the creators abandoned the firmware project and a group of independent
contributors took over. By summer 2016 the NodeMCU included more than 40 different
modules. Due to resource constraints users need to select the modules relevant for their
project and build a firmware tailored to their needs.

ESP8266 Arduino Core[edit]

As Arduino.cc began developing new MCU boards based on non-AVR processors like the

ARM/SAM MCU and used in the Arduino Due, they needed to modify the Arduino IDE so
that it would be relatively easy to change the IDE to support alternate toolchains to allow
Arduino C/C++ to be compiled for these new processors. They did this with the introduction
of the Board Manager and the SAM Core. A "core" is the collection of software components
required by the Board Manager and the Arduino IDE to compile an Arduino C/C++ source
file for the target MCU's machine language. Some ESP8266 enthusiasts developed an
Arduino core for the ESP8266 WiFi SoC, popularly called the "ESP8266 Core for the
Arduino IDE".[16] This has become a leading software development platform for the various
ESP8266-based modules and development boards, including NodeMCUs.

ntroduction

NodeMCU is an open source LUA based firmware developed for ESP8266 wifi chip. By

exploring functionality with ESP8266 chip, NodeMCU firmware comes with ESP8266
Development board/kit i.e. NodeMCU Development board.
NodeMCU Development Board/kit v0.9 (Version1)

Since NodeMCU is open source platform, their hardware design is open for
edit/modify/build.

NodeMCU Dev Kit/board consist of ESP8266 wifi enabled chip. The ESP8266 is a low-
cost Wi-Fi chip developed by Espressif Systems with TCP/IP protocol. For more information
about ESP8266, you can refer ESP8266 WiFi Module.

There is Version2 (V2) available for NodeMCU Dev Kit i.e. NodeMCU Development
Board v1.0 (Version2), which usually comes in black colored PCB.
NodeMCU Development Board/kit v1.0 (Version2)

For more information about NodeMCU Boards available in market refer NodeMCU

Development Boards

NodeMCU Dev Kit has Arduino like Analog (i.e. A0) and Digital (D0-D8) pins on its board.

It supports serial communication protocols i.e. UART, SPI, I2C etc. 

Using such serial protocols we can connect it with serial devices like I2C enabled LCD
display, Magnetometer HMC5883, MPU-6050 Gyro meter + Accelerometer, RTC chips,
GPS modules, touch screen displays, SD cards etc.

How to start with NodeMCU?

NodeMCU Development board is featured with wifi capability, analog pin, digital pins and
serial communication protocols.

To get start with using NodeMCU for IoT applications first we need to know about how to
write/download NodeMCU firmware in NodeMCU Development Boards. And before that
where this NodeMCU firmware will get as per our requirement.

There is online NodeMCU custom builds available using which we can easily get our custom
NodeMCU firmware as per our requirement.
To know more about how to build custom NodeMCU firmware online and download it
refer Getting started with NodeMCU

How to write codes for NodeMCU?

After setting up ESP8266 with Node-MCU firmware, let’s see the IDE (Integrated
Development Environment) required for development of NodeMCU.

NodeMCU with ESPlorer IDE

Lua scripts are generally used to code the NodeMCU. Lua is an open source,
lightweight, embeddable scripting language built on top of C programming language.

For more information about how to write Lua script for NodeMCU refer Getting
started with NodeMCU using ESPlorerIDE

NodeMCU with Arduino IDE

Here is another way of developing NodeMCU with a well-known IDE i.e. Arduino
IDE. We can also develop applications on NodeMCU using Arduino development
environment. This makes easy for Arduino developers than learning new language and
IDE for NodeMCU.

For more information about how to write Arduino sketch for NodeMCU refer Getting
started with NodeMCU using ArduinoIDE

Difference in using ESPlorer and Arduino IDE

Well, there is a programming language difference we can say while developing application
for NodeMCU using ESPlorer IDE and Arduino IDE.

We need to code in C\C++ programming language if we are using Arduino IDE for
developing NodeMCU applications and Lua language if we are using ESPlorer IDE.

Basically, NodeMCU is Lua Interpreter, so it can understand Lua script easily. When we
write Lua scripts for NodeMCU and send/upload it to NodeMCU, then they will get executes
sequentially. It will not build binary firmware file of code for NodeMCU to write. It will send
Lua script as it is to NodeMCU to get execute.

In Arduino IDE when we write and compile code, ESP8266 toolchain in background creates
binary firmware file of code we wrote. And when we upload it to NodeMCU then it will flash
all NodeMCU firmware with newly generated binary firmware code. In fact, it writes the
complete firmware.

That’s the reason why NodeMCU not accept further Lua scripts/code after it is getting
flashed by Arduino IDE. After getting flashed by Arduino sketch/code it will be no more Lua
interpreter and we got error if we try to upload Lua scripts. To again start with Lua script, we
need to flash it with NodeMCU firmware.

Since Arduino IDE compile and upload/writes complete firmware, it takes more time than
ESPlorer IDE.

Gas sensor module 

In current technology scenario, monitoring of gases produced is very important. From

home appliances such as air conditioners to electric chimneys and safety systems at industries
monitoring of gases is very crucial. Gas sensors are very important part of such systems.
Small like a nose, gas sensors spontaneously react to the gas present, thus keeping the system
updated about any alterations that occur in the concentration of molecules at gaseous state.   

  Gas sensors are available in wide specifications depending on the sensitivity levels,

type of gas to be sensed, physical dimensions and numerous other factors. This Insight covers
a methane gas sensor that can sense gases such as ammonia which might get produced from
methane. When a gas interacts with this sensor, it is first ionized into its constituents and is
then adsorbed by the sensing element. This adsorption creates a potential difference on the
element which is conveyed to the processor unit through output pins in form of current. What
is this sensing element? Is it kept in some chamber or is kept exposed? How does it get
current and how it is taken out? Let’s find out in this Insight!!!
 The gas sensor module consists of a steel exoskeleton under which a sensing element
is housed. This sensing element is subjected to current through connecting leads. This current
is known as heating current through it, the gases coming close to the sensing element get
ionized and are absorbed by the sensing element. This changes the resistance of the sensing
element which alters the value of the current going out of it.

Image shows externals of a standard gas sensor module: a steel mesh, copper clamping ring
and connecting leads. The top part is a stainless steel mesh which takes care of the following:
Filtering out the suspended particles so that only gaseous elements are able to pass to insides
of the sensor.  

 Protecting the insides of the sensor.

 Exhibits an anti-explosion network that keeps the sensor module intact at high
temperatures and gas pressures.
In order to manage above listed functions efficiently, the steel mesh is made into two layers.
The mesh is bound to rest of the body via a copper plated clamping ring.

The connecting leads of the sensor are thick so that sensor can be connected firmly to
the circuit and sufficient amount of heat gets conducted to the inside part. They are casted
from copper and have tin plating over them. Four of the six leads (A, B, C, D) are for signal
fetching while two (1, 2) are used to provide sufficient heat to the sensing element.
The pins are placed on a Bakelite base which is a good insulator and provides firm gripping
to the connecting leads of the sensor.
The top of the gas sensor is removed off to see the internals parts of the sensor:
sensing element and connection wiring. The hexapod structure is constituted by the sensing
element and six connecting legs that extend beyond the Bakelite base.
Using a ceramic substrate increases the heating efficiency and tin oxide, being
sensitive towards adsorbing desired gas’ components (in this case methane and its products)
suffices as sensing coating.
The leads responsible for heating the sensing element are connected through Nickel-
Chromium, well known conductive alloy. Leads responsible for output signals are connected
using platinum wires which convey small changes in the current that passes through the
sensing element.  The platinum wires are connected to the body of the sensing element while
Nickel-Chromium wires pass through its hollow structure.

While other wires are attached to the outer body of the element, Nickel-Chromium wires are
placed inside the element in a spring shaped. Image shows coiled part of the wire which is
placed on the inside of the hollow ceramic

Image shows the ceramic with tin dioxide on the top coating that has good adsorbing
property. Any gas to be monitored has specific temperature at which it ionizes. The task of
the sensor is to work at the desired temperature so that gas molecules get ionized. Through
Nickel-chromium wire, the ceramic region of the sensing element is subjected to heating
current. The heat is radiated by the element in the nearby region where gases interact with it
and get ionized. Once, ionized, they are absorbed by the tin dioxide. Adsorbed molecules
change the resistance of the tin dioxide layer. This changes the current flowing through the
sensing element and is conveyed through the output leads to the unit that controls
the working of the gas sensor.

Humidity sensor

Measurement and control of temperature and relative humidity finds applications in

numerous areas. These days devices are available which have both temperature and humidity
sensors with signal conditioning, ADC, calibration and communication interface all built
inside them. The use of such smart sensors greatly simplify the design and reduces the overall
cost. We discussed in past about Humidity and temperature measurements with Sensirion’s
SHT1x/SHT7x sensors. These sensors are capable of measuring both temperature and relative
humidity and provide fully calibrated digital outputs. While SHT1x/SHT7x are very accurate
sensors, they are still expensive for hobbyists use. This articles discusses the DHT11 sensor
which also provides calibrated digital outputs for temperature and humidity but is relatively
lot cheaper than the Sensirion sensors. The DHT11 sensor uses a proprietary 1-wire protocol
which we will be exploring here and implementing with the PIC16F628A microcontroller
that will receive the temperature and humidity values from the sensor and display them on a
16×2 character LCD.

About DHT11 sensor

The DHT11 sensor comes in a single row 4-pin package and operates from 3.5 to
5.5V power supply. It can measure temperature from 0-50 °C with an accuracy of ±2°C and
relative humidity ranging from 20-95% with an accuracy of  ±5%. The sensor provides fully
calibrated digital outputs for the two measurements. It has got its own proprietary 1-wire
protocol, and therefore, the communication between the sensor and a microcontroller is not
possible through a direct interface with any of its peripherals. The protocol must be
implemented in the firmware of the MCU with precise timing required by the sensor. The
following timing diagrams describe the data transfer protocol between a MCU and the
DHT11 sensor. The MCU initiates data transmission by issuing a “Start” signal. The MCU
pin must be configured as output for this purpose. The MCU first pulls the data line low for at
least 18 ms and then pulls it high for next 20-40 ?s before it releases it.

DHT11 sensor comes in a single row 4-pin package

 Next, the sensor responds to the MCU “Start“  signal by pulling the line low for 80 ?s
followed by a logic high signal that also lasts for 80 ?s. Remember that the MCU pin must be
configured to input after finishing the “Start“ signal. Once detecting the response signal from
the sensor, the MCU should be ready to receive data from the sensor. The sensor then sends
40 bits (5 bytes) of data continuously in the data line. Note that while transmitting bytes, the
sensor sends the most significant bit first.

"Start" and "Response" signals

The 40-bit data from the sensor has the following structure.

Data (40-bit) = Integer Byte of RH + Decimal Byte of RH + Integer Byte of Temp. +

Decimal Byte of Temp. + Checksum Byte

For DHT11 sensor, the decimal bytes of temperature and humidity measurements are always
zero. Therefore, the first and third bytes of received data actually give the numeric values of
the measured relative humidity (%) and temperature (°C). The last byte is the checksum byte
which is used to make sure that the data transfer has happened without any error. If all the
five bytes are transferred successfully then the checksum byte must be equal to the last 8 bits
of the sum of the first four bytes, i.e.,

Checksum = Last 8 bits of (Integer Byte of RH + Decimal Byte of RH + Integer Byte of

Temp. + Decimal Byte of Temp.) 

Now lets talk about the most important thing, which is signalling for transmitting “0″ and
“1″. In order to send a bit of data, the sensor first pulls the line low for 50 ?s. Then it raises
the line to high for 26-28 ?s if it has to send “0″, or for 70 ?s if the bit to be transmitted is
“1″. So it is the width of the positive pulse that carries information about 1 and 0.
 Timing difference for transmitting "1s" and "0s"

Start, Response and Data signals in sequence

At the end of the last transmitted bit, the sensor pulls the data line low for 50 ?s and then
releases it. The DHT11 sensor requires an external pull-up resistor to be connected between
its Vcc and the data line so that under idle condition, the data line is always pulled high. After
finishing the data transmission and releasing the data line, the DHT11 sensor goes to the low-
power consumption mode until a new “Start” signal arrives from the MCU.

Software required:
Arduino ide
Embedded C
ARDUINO IDE AND ITS PROGRAMMING

Arduino is a tool for making computers that can sense and control more of the
physical world than your desktop computer. It's an open-source physical
computing platform based on a simple microcontroller board, and a
development environment for writing software for the board.
Arduino can be used to develop interactive objects, taking inputs from a
variety of switches or sensors, and controlling a variety of lights, motors, and
other physical outputs. Arduino projects can be stand-alone, or they can be
communicate with software running on your computer. The boards can be
assembled by hand or purchased preassembled; the open-source IDE can be
downloaded for free.

The Arduino programming language is an implementation of Wiring, a similar

physical computing platform, which is based on the Processing multimedia
programming environment.

2.1 Overview
The Arduino microcontroller is an easy to use yet powerful single board
computer that has gained considerable traction in the hobby and professional
market. The Arduino is open-source, which means hardware is reasonably
priced and development software is free. This guide is for students in ME 2011,
or students anywhere who are confronting the Arduino for the first time. For
advanced Arduino users, prowl the web; there are lots of resources.

This guide covers the Arduino Uno board (Spark fun DEV-09950, $29.95), a
good choice for students and educators. With the Arduino board, you can write
programs and create interface circuits to read switches and other sensors, and
to control motors and lights with very little effort. Many of the pictures and
drawings in this guide were taken from the documentation on the

This is what the Arduino ide looks like.

The Arduino Integrated Development Environment (IDE) is a cross-
platform application (for Windows, macOS, Linux) that is written in functions
from C and C++.[2] It is used to write and upload programs
to Arduino compatible boards, but also, with the help of third-party cores,
other vendor development boards.[3]
The source code for the IDE is released under the GNU General Public License,
version 2.[4] The Arduino IDE supports the languages C and C++ using special
rules of code structuring.[5] The Arduino IDE supplies a software library from
the Wiring project, which provides many common input and output
procedures. User-written code only requires two basic functions, for starting
the sketch and the main program loop, that are compiled and linked with a
program stub main() into an executable cyclic executive program with the GNU
toolchain, also included with the IDE distribution. [6] The Arduino IDE employs
the program avrdude to convert the executable code into a text file in
hexadecimal encoding that is loaded into the Arduino board by a loader
program in the board's firmware. [7] By default, avrdude is used as the
uploading tool to flash the user code onto official Arduino boards.[8]

Arduino Pro IDE

Developer(s) Arduino Software

Preview release v0.1.2 / 14 September 2020;

4 months ago[9]

Repository github.com/arduino/
Arduino

Written in C, C++

Operating Windows, macOS, Linux
system

Platform IA-32, x86-64, ARM

Type Integrated development

environment

License LGPL or GPL license

Website blog.arduino.cc/2020/08/24
 /cli-and-ide-get-better-
together/

With the rising popularity of Arduino as a software platform, other vendors

started to implement custom open source compilers and tools (cores) that can
build and upload sketches to other microcontrollers that are not supported by
Arduino's official line of microcontrollers.
In October 2019 the Arduino organization began providing early access to a
new Arduino Pro IDE with debugging[10] and other advanced features.[11]

The Duemilanove board features an Atmel ATmega328 microcontroller

operating at 5 V with 2 Kb of RAM, 32 Kb of flash memory for storing programs
and 1 Kb of EEPROM for storing parameters. The clock speed is 16 MHz, which
translates to about executing about 300,000 lines of C source code per second.
The board has 14 digital I/O pins and 6 analog input pins. There is a USB
connector for talking to the host computer and a DC power jack for connecting
an external 6-20 V power source, for example a 9 V battery, when running a
program while not connected to the host computer. Headers are provided for
interfacing to the I/O pins using 22 g solid wire or header connectors.

The Arduino programming language is a simplified version of C/C++. If you

know C, programming the Arduino will be familiar. If you do not know C, no
need to worry as only a few commands are needed to perform useful
functions.

An important feature of the Arduino is that you can create a control program
on the host PC, download it to the Arduino and it will run automatically.
Remove the USB cable connection to the PC, and the program will still run
from the top each time you push the reset button. Remove the battery and put
the Arduino board in a closet for six months. When you reconnect the battery,
the last program you stored will run. This means that you connect the board to
the host PC to develop and debug your program, but once that is done, you no
longer need the PC to run the program.

The Arduino Uno is a microcontroller board based on the ATmega328.It has 14

digital input/output pins (of which 6 can be used as PWM outputs), 6 analog
inputs, a 16 MHz ceramic resonator, a USB connection, a power jack, an ICSP
header, and a reset button. It contains everything needed to support the
microcontroller; simply connect it to a computer with a USB cable or power it
with a AC-to-DC adapter or battery to get started.
The Uno differs from all preceding boards in that it does not use the FTDI USB-
to-serial driver chip. Instead, it features the Atmega16U2 (Atmega8U2 up to
version R2) programmed as a USB-to-serial converter.
2.3 Pin Configuration

The NodeMCU can be powered via the USB connection or with an external
power supply. The power source is selected automatically.

External (non-USB) power can come either from an AC-to-DC adapter (wall-
wart) or battery. The adapter can be connected by plugging a 2.1mm center-
positive plug into the board's power jack. Leads from a battery can be inserted
in the Gnd and Vin pin headers of the POWER connector.

The board can operate on an external supply of 6 to 20 volts. If supplied with

less than 7V, however, the 5V pin may supply less than five volts and the board
may be unstable. If using more than 12V, the voltage regulator may overheat
and damage the board. The recommended range is 7 to 12 volts.

The power pins are as follows:

VIN. The input voltage to the Arduino board when it's using an external
power source (as opposed to 5 volts from the USB connection or other
regulated power source). You can supply voltage through this pin, or, if
supplying voltage via the power jack, access it through this pin.

 5V. this pin outputs a regulated 5V from the regulator on the board. The
board can be supplied with power either from the DC power jack (7 - 12V), the
USB connector (5V), or the VIN pin of the board (7-12V). Supplying voltage via
the 5V or 3.3V pins bypasses the regulator, and can damage your board.

3V3. A 3.3 volt supply generated by the on-board regulator. Maximum

current draw is 50 mA.

GND. Ground pins.

 IOREF. This pin on the Arduino board provides the voltage reference with
which the microcontroller operates. A properly configured shield can read the
IOREF pin voltage and select the appropriate power source or enable voltage
translators on the outputs for working with the 5V or 3.3V.

Memory
The ATmega328 has 32 KB (with 0.5 KB used for the bootloader). It also has 2
KB of SRAM and 1 KB of EEPROM.

Input and Output

Each of the 14 digital pins on the Uno can be used as an input or output, using
pinMode(), digital Write( ), and digital Read( ) functions. They operate at 5
volts. Each pin can provide or receive a maximum of 40 mA and has an internal
pull- up resistor (disconnected by default) of 20-50 kohms. In addition, some
pins have specialized functions:

• Serial: 0 (RX) and 1 (TX). Used to receive (RX) and Trans mit (TX) TTL serial
data.

These pins are connected to the corresponding pins of the ATmega8U2 USB-to-
TTL Serial chip.

•External Interrupts: 2 and 3. These pins can be configured to trigger an

interrupt on a low value, a rising or falling edge, or a change in value. See the
attach Interrupt () function for details.

•PWM: 3, 5, 6, 9, 10, and 11. Provide 8-bit PWM output with the analog Write
() function.

•SPI: 10 (SS), 11 (MOSI), 12 (MISO), 13 (SCK). These pins support SPI

communication using the SPI library.

•LED: 13. There is a built- in LED connected to digital pin 13. When the pin is
HIGH value, the LED is on, when the pin is LOW, it's off.

The Uno has 6 analog inputs, labeled A0 through A5, each of which provide 10
bits of resolution (i.e. 1024 different values). By default they measure from
ground to 5 volts, though is it possible to change the upper end of their range
using the AREF pin and the analog Reference () function. Additionally, some
pins have specialized functionality:

• TWI: A4 or SDA pin and A5 or SCL pin. Support TWI communication using
the Wire library.

There are a couple of other pins on the board:

• AREF. Reference voltage for the analog inputs. Used with analog Reference
().

Reset. Bring this line LOW to reset the microcontroller. Typically used to add a
reset button to shields which block the one on the board.

2.4 Communication

Microcontrollers depend on a host computer for developing and compiling

programs. The software used on the host computer is known as an integrated
development environment, or IDE. For the Arduino, the development
environment is based on the open source Processing platform
(www.processing.org) which is described by its creators as a “programming
language and environment for people who want to program images,
animation, and interactions.“ The Arduino programming language leverages an
open source project known as Wiring (wiring.org.co). The Arduino language is
based on good old- fashioned C. If you are unfamiliar with this language, don’t
worry; it’s not hard to learn, and the Arduino IDE provides some feedback
when you make mistakes in your programs.

The Arduino Uno has a number of facilities for communicating with a

computer, another Arduino, or other microcontrollers. The ATmega328
provides UART TTL (5V) serial communication, which is available on digital pins
0 (RX) and 1 (TX). An ATmega16U2 on the board channels this serial
communication over USB and appears as a virtual com port to software on the
computer. The '16U2 firmware uses the standard USB COM drivers, and no
external driver is needed. However, on Windows, a inf file is required. The
Arduino software includes a serial monitor which allows simple textual data to
be sent to and from the Arduino board. The RX and TX LEDs on the board will
flash when data is being transmitted via the USB-to-serial chip and USB
connection to the computer (but not for serial communication on pins 0 and
1).
A Software Serial library allows for serial communication on any of the Uno's
digital pins. The ATmega328 also supports I2C (TWI) and SPI communication.
The Arduino software includes a Wire library to simplify use of the I2C bus; see
the documentation for details. For SPI communication, use the SPI library.

As you go through the list of programming statements available in the Arduino

IDE (choose Help->Reference), you might think there isn’t much power for
doing t hings like running servos, operating stepper motors, reading
potentiometers, or displaying text on an LCD. Like most any language based on
C, the Arduino supports the notion of “libraries” code
Repositories that extend core programming functionality. Libraries let you re-
use code without having to physically copy and paste it into all your programs.
The standard Arduino software installation comes with several libraries you
may use, and you can download others from the Arduino support pages and
from third-party websites that publish Arduino library code. A good example of
a library you’ll use with the Robot and likely many other robot projects is

Servo. This library allows you to connect one or more hobby R/C servos to the
Arduino’s digital I/O pins. The Servo library comes with the standard Arduino
installation package Library->Servo. This adds the line

#include <Servo.h>

Which tells the Arduino IDE that you wish to include the Servo library in your
sketch. With the functionality of the library now available to you, you can use
its various functions to control one or more servos. For example, you can use
the write function to rotate a servo to a specific position, from 0 to 180
degrees. The following code

myServo.write(90);

Moves a servo to its midpoint, or 90 degree position. Structurally, Arduino

sketches are very straightforward and are pretty easy to read and understand.
The Arduino program contains two main parts: setup () and loop (). These are
programming functions that do what their names suggest: setup () sets up the
Arduino hardware, such as specifying which I/O lines you plan to use, and
whether

They are inputs or outputs. The loop () function is repeated endlessly when the
Arduino is operating.

Arduino IDE (Integrated development environment) is used to write the

program and dump into the Arduino board
2.5 ARDUINO SOFTWARE:

1. Open Arduino IDE as shown below

Open Arduino IDE

2. Select the COM Port from tool Select the COM

Port
3. Select the required Arduino board from Tools as shown below
Select the required Arduino board

4. Write the sketch in Arduino IDE

Sketch in Arduino IDE
5. Compile and upload the Sketch to Arduino board upload the Sketch to Arduino
board

UBIDOTS EXPLORER:
Introduction
Welcome to the Ubidots REST API hardware docs. Here you would reference how
to send or retrieve data from your hardware devices using our supported
communication protocols: HTTP, MQTT and TCP/UDP.
The purpose of this section is to help you understand what happens in the
backstage when communicating with Ubidots, so you can replicate this in your
firmware. For this reason, we avoid the use of examples using libraries. However,
if you’d like to use one of our libraries (Python, C, and more), check out
our compatible devices and API clients sections.
How Ubidots Works?

Every time a device updates a sensor value in a variable, a data-point or "dot" is

created. Ubidots stores dots that come from your devices inside variables, and
these stored dots have corresponding timestamps:

Each dot contains these items:

Item Description Mandatory

value A numerical value. Ubidots accepts up to 16 YES

floating-point length numbers.

timestamp Unix Epoch time, in milliseconds. If not NO

specified, then our servers will assign one
Item Description Mandatory

upon reception.

context An arbitrary collection of key-value pairs. NO

Mostly used to store the latitude and
longitude coordinates of GPS devices.

Values

A numerical value. Ubidots accepts up to 16 floating-point length numbers.

{"value" : 34.87654974}
Timestamps

A timestamp, as best described here, is a way to track time as a running total of

seconds. This count starts at the Unix Epoch on January 1st, 1970 at UTC.
Therefore, the unix time stamp is merely the number of seconds between a
particular date and the Unix Epoch. Please keep in mind that when you send data
to Ubidots, you must set the timestamp in milliseconds; also, if you retrieve a
dot's timestamp, it will be in milliseconds.
"timestamp" : 1537453824000
The above timestamp corresponds to Thursday, September 20, 2018 2:30:24 PM.

PRO-TIP: A useful tool to convert between Unix timestamps and human-readable

dates is Epoch Converter.
Context

Numerical values are not the only data type supported; you can also
store string or char data types inside what we call context. The context is a key-
value object that allows you to store not only numerical but also string values. An
example use of the context could be:
"context" : {"status" : "on", "weather" : "sunny"}
A context is commonly used to store the latitude and longitude coordinates of
your device for GPS/tracking application use cases. All Ubidots maps uses
the lat and lng keys from a dot's context to extract the coordinates of your
device, in that way you just need to send a single dot with the coordinates values
in the variable context to plot a map instead of sending separately both latitude
and longitude in two different variables. Below you can find a typical context with
coordinates values:
"context" : {"lat":-6.2, "lng":75.4, "weather" : "sunny"}
Please note that you can mix both string and numerical values in the context. If
your application is for geo-localization purposes, make sure that the coordinates
are set in decimal degrees.
Time Series

Based on the above, we can illustrate an Ubidots time series like this:

Ubidots is an agnostic platform, this means that it does not really care what
hardware device you are using, as long as you're able to interact with us through
at least one of these protocols:

 HTTP
 MQTT
 TCP/UDP
HTTP

HTTP is the main internet protocol for information exchange in the Internet. It
also supports data encryption, which is usually called secure HTTP or HTTPs. When
you use a web browser (MS Edge, Firefox, Google Chrome, etc) you are sending
and receiving packages using HTTP or HTTPs. Because of this, it was not surprising
to see HTTPs become a popular option for data exchange within IoT.
When a developer is to implement HTTP communication, then he should look for
a RESTful Application Programming Interface, or REST API, which exposes all the
endpoints required to interact with a third party application (like Ubidots). In this
section, you can reference our REST API to understand how to send and retrieve
data from our servers.
Note: Our goal with this section is to help you understand what’s happening
behind when communicating with Ubidots, enabling you to replicate it within
your own firmware. Because of this, we avoid using our custom libraries in all the
examples.
HTTP requests
The following methods are specified within the HTTP standard:
HTTP Method Description

GET Used to retrieve information

POST Used to create a new element

PATCH Used to update existing elements

DELETE Used to delete existing elements

HTTP is a request/response protocol, this means that every request that you

make is answered by the server. This response includes a number (response code)
and a body. For example, when you make a request to retrieve a file on a
webpage "(e.g. "Get me the file 'webside.html'" )", you build a GET request. If the
request is correct, the server will typically return a 200 response code, along with
the file requested (body).
Under the same logic, when a device sends a GET request to the Ubidots' server
(i.e. requesting the last value of a variable), then the server sends back a response
with the status of the request (response code), and a body, which would be the a
value with its context and timestamp.

An HTTP request also needs the parameters below:

 Host: Specifies the server you will be making HTTP requests to.
 Path: This is typically the remaining portion of the URL that specifies the
resource you want to consume, be it a variable or a device. For example, if
an API endpoint is: industrial.api.ubidots.com/api/v1.6/devices/my-
device then the path would be /api/v1.6/devices/my-device
 Headers: Define the operating parameters of the HTTP request such as
authentication, Content-Type, Content-Length, etc.
 Body/payload: In the case of POST and PATCH requests, this is the data
sent by your device to the server. GET requests typically do not have a body
because they are meant to request data, not to send data.
Ubidots accepts data as JavaScript Object Notation or JSON. JSON is a
typical HTTP data type, it is a collection of name/value pairs. In various
programming languages, this is treated as an object, record, struct, dictionary,
hash table, keyed list, or associative array. It is also human readable and language
independent. An example of a JSON data type that Ubidots accepts can be
referenced below:
{"temperature": {"value":10, "timestamp": 1534881387000, "context":
{"machine": "1st floor"}}}
A typical HTTP request to Ubidots should be set as below:
POST {PATH} HTTP/1.1<CR><LN>
Host: {HOST}<CR><LN>
User-Agent: {USER_AGENT}<CR><LN>
X-Auth-Token: {TOKEN}<CR><LN>
Content-Type: application/json<CR><LN>
Content-Length: {PAYLOAD_LENGTH}<CR><LN><CR><LN>
{PAYLOAD}
<CR><LN>
Where:
  {PATH}: Path to the resource to consume
Example: /api/v1.6/variables/ to get user's variables information.
 {HOST}: Host URL.
Example: industrial.api.ubidots.com
 {USER_AGENT}: An optional string used to identify the type of client, be it
by application type, operating system, software vendor or software version
of the requesting user agent.
Examples: ESP8266/1.0, Particle/1.2
 {TOKEN}: Unique key that authorizes your device to ingest data inside your
Ubidots account.
 {PAYLOAD_LENGTH}: The number of characters of your payload.
Example: The payload {"temperature": 20} will have a content-length of 19.
 {PAYLOAD}: Data to send.
Example: {"temperature": 20}
PRO TIP: The easy way of handle HTTP and HTTPs requests is by using cURL, a
command line tool. To learn how to install cURL on Windows, MacOSX or Linux
please refer to this guide.
API URLs

API access can be over HTTP or secure HTTP, HTTPs, using the following endpoints
based on your Ubidots Account type.
Security Note: We strongly advise to use HTTPs to make sure your data travels
encrypted, avoiding the exposure of your API token and/or sensor data.
HTTP

Ubidots Account Endpoint Port

Educational http://things.ubidots.com 80

Industrial http://industrial.api.ubidots.com 80
HTTPs

Ubidots Account Endpoint Port

Educational https://things.ubidots.com 443

Industrial https://industrial.api.ubidots.com 443

Ubidots supports SSL v1.1, TLS v1.2 and v1.3. You can download our root
certificates in different formats:

 PEM file: A certificate chain with two root certificates from our certificate
authorities (CAs).
 DER file: Same as the PEM file, with an alternative encoding.
 CRT file: Same as the PEM file, with a different extension. Often referred to
as .crt, .cert or .cer.
NOTE: To avoid future inconveniences, we advise to use both certificates in your
device's auth routines. While the second is the current valid certificate, we will
use the first after 2021.
Fixed IPs

Ubidots also supports fixed IPs address for data ingestion, but we highly advise to
our users to implement their firmware routines using the dns endpoints instead
of fixed IPs, as these last ones may change in the future.

Ubidots Account ipv4 ipv6 Port

Educational 50.23.124.68 2607:f0d0:2101:39::2 80/443

Industrial 169.55.61.243 2607:f0d0:3:b::2 80/443

HTTP Authentication

Every request requires a token. A token is an unique key that authorizes your
device to ingest data inside your Ubidots account.
The easiest way to get yours is clicking on "API Credentials" under your profile
tab:

Also, 6 hour valid tokens can be generated using your account API-KEY. If you

desire to learn how to do it, please refer the Ubidots REST Software API reference.
There are two ways to send a token in a request:
1. Send the token as parameter in the endpoint, setting it with the ?
token= expression. This is the easiest one to implement but the most
unsecure method to send your authentication credentials.
2. Send the token as a request header. For this, use the X-Auth-Token header.
Security Note: While sending your token as a URL parameter can be quite
comfortable in some devices, we only advise to do this for prototyping stages. For
production stages, we strongly advise sending the token using the X-Auth-
Token header.
GET
https://industrial.api.ubidots.com/api/

Send data

Our REST API allows you send data to the platform in two different ways:

 Send data to a device

 Send data to a variable
If you're looking for more advanced API capabilities, such as editing a device
name, or listing all of your devices, please refer to our Ubidots Software REST API
Reference.
Send data to a device

Request structure:
POST /api/v1.6/devices/{DEVICE_LABEL} HTTP/1.1<CR><LN>
Host: {Host}<CR><LN>
User-Agent: {USER_AGENT}<CR><LN>
X-Auth-Token: {TOKEN}<CR><LN>
Content-Type: application/json<CR><LN>
Content-Length: {PAYLOAD_LENGTH}<CR><LN><CR><LN>
{PAYLOAD}
<CR><LN>
Expected Response:
HTTP/1.1 200 OK<CR><LN>
Server: nginx<CR><LN>
Date: Tue, 04 Sep 2018 22:35:06 GMT<CR><LN>
Content-Type: application/json<CR><LN>
Transfer-Encoding: chunked<CR><LN>
Vary: Cookie<CR><LN>
Allow: GET, POST, HEAD, OPTIONS<CR><LN><CR><LN>
{PAYLOAD_LENGTH_IN_HEXADECIMAL}<CR><LN>
{"{VARIABLE_LABEL}": [{"status_code": 201}]}<CR><LN>
0<CR><LN>
The easiest way to send values to Ubidots is by specifying your Device label in the
request path and making a POST request to it.
Replace the {DEVICE_LABEL} with the unique label of the desired device to send
data to. If the device does not exist in your Ubidots account, it will be
automatically created. Device labels can contain any alphanumerical character,
without blank spaces, i.e weather-station, my-home, esp8266.
To set the variables values, just create a JSON data payload as below
Nº
Variables JSON structure

One {"variable-label": VALUE}

Multiple {"variable-label-1": {"value": VALUE, "timestamp":

TIMESTAMP, "context": {"key": VALUE}}, ... , "variable-
Nº
Variables JSON structure

label-n": {"value": VALUE, "timestamp": TIMESTAMP,

"context": {"key": VALUE}}}

timestamp and context parameters are optional.

NOTE 1:: By default, the Ubidots backend will take the latitude and longitude
values inside any variable labeled
as "gps", "location", position or "coordinates" automatically to get your device
coordinates in all of the map widgets. Alternatively, you change the default
location variable.
NOTE 2: All timestamps must be in milliseconds. If you set a timestamp for a
variable value, it will be stored with the date represented by it. You can easily
convert dates to timestamps values here.
Examples
 Single dot: {"temperature": 27}
 Multiple dots: {"temperature": 27, "humidity": 55, ... ,"pressure": 78}
Including additional keys like context and timestamp
 Single dot: {"position": {"value" : 1, "timestamp": 1514808000000,
"context":{"lat":-6.2, "lng":75.4, "name" : "John"}}}
 Multiple dots: {"temperature": {"value": 27, "timestamp": 1514808000000},
"humidity": 55, "pressure": {"value": 78, "context":{"name" : "John"}}}
POST
https://industrial.api.ubidots.com/api/v1.6/devices/{DEVICE_LABEL}
POST
https://things.ubidots.com/api/v1.6/devices/{DEVICE_LABEL}
Send a single dot (Educational users)

curl -X POST -H "X-Auth-Token: BBFF-Rfcgaxns6HlVb155WA0RhSY85xNDmB" -H

"Content-Type: application/json" -d '{"temperature": 27}'
https://things.ubidots.com/api/v1.6/devices/my-new-device

Send a single dot (Industrial users)

curl -X POST -H "X-Auth-Token: BBFF-Rfcgaxns6HlVb155WA0RhSY85xNDmB" -H

"Content-Type: application/json" -d '{"temperature": 27}'
https://industrial.api.ubidots.com/api/v1.6/devices/my-new-device

Send a dot with coordinates

curl -X POST -H "X-Auth-Token: BBFF-Rfcgaxns6HlVb155WA0RhSY85xNDmB" -H

"Content-Type: application/json" -d '{"position": {"value" : 1, "timestamp":
1514808000000, "context":{"lat":-6.2, "lng":75.4}}}'
https://industrial.api.ubidots.com/api/v1.6/devices/my-new-device

Send multiple dots

curl -X POST -H "X-Auth-Token: BBFF-Rfcgaxns6HlVb155WA0RhSY85xNDmB" -H

"Content-Type: application/json" -d '{"temperature": {"value": 27, "timestamp":
1514808000000}, "humidity": 55, "pressure": {"value": 78, "context":{"name" :
"John"}}}' https://industrial.api.ubidots.com/api/v1.6/devices/my-new-device

Send data to a variable

You can also send one or multiple dots to a single variable.

Request structure:
POST /api/v1.6/devices/{DEVICE_LABEL}/{VARIABLE_LABEL}/values
HTTP/1.1<CR><LN>
Host: {Host}<CR><LN>
User-Agent: {USER_AGENT}<CR><LN>
X-Auth-Token: {TOKEN}<CR><LN>
Content-Type: application/json<CR><LN>
Content-Length: {PAYLOAD_LENGTH}<CR><LN><CR><LN>
{PAYLOAD}
<CR><LN>
Expected Response:
HTTP/1.1 201 Created<CR><LN>
Server: nginx<CR><LN>
Date: Tue, 04 Sep 2018 22:50:55 GMT<CR><LN>
Content-Type: application/json<CR><LN>
Transfer-Encoding: chunked<CR><LN>
Vary: Accept, Cookie<CR><LN>
Location:
http://industrial.api.ubidots.com/api/v1.6/values/{VARIABLE_ID}<CR><LN>
Allow: GET, POST, HEAD, OPTIONS<CR><LN><CR><LN>
{PAYLOAD_LENGTH_IN_HEXADECIMAL}<CR><LN>
{"url": "http://things.ubidots.com/api/v1.6/values/{VARIABLE_ID}", "value": 27.0,
"timestamp": 1536101455822, "context": {}, "created_at": "2018-09-
04T22:50:55.822035Z"}<CR><LN>
0<CR><LN>
In the path specified above, replace the {DEVICE_LABEL} and {VARIABLE_LABEL}
keys with the unique labels of the Ubidots device and variable you wish to send
data to. If the specified device and/or variable do not exist, they will be
automatically created.
Examples
 Single dot: {"value":27}
 Single dot with context and timestamp: {"value":27, "timestamp":
1514808000000, "context":{"lat":37.773, "lng":-122.431}}
 Multiple dots (must include the timestamp of each value): [{"value": 27,
"timestamp":1514808000000}, {"value": 12, "timestamp":1514808900000}]
Send a single dot (Educational users)

POST
https://industrial.api.ubidots.com/api/v1.6/devices/{DEVICE_LABEL}/
{VARIABLE_LABEL}/values
POST
https://things.ubidots.com/api/v1.6/devices/{DEVICE_LABEL}/
{VARIABLE_LABEL}/values
Send a single dot (Industrial users)

curl -X POST -H "X-Auth-Token: BBFF-Rfcgaxns6HlVb155WA0RhSY85xNDmB" -H

"Content-Type: application/json" -d '{"value": 27}'
https://industrial.api.ubidots.com/api/v1.6/devices/my-new-device/my-

variable/values
Send a single dot (Educational users)

curl -X POST -H "X-Auth-Token: BBFF-Rfcgaxns6HlVb155WA0RhSY85xNDmB" -H

"Content-Type: application/json" -d '{"value": 27}'
https://things.ubidots.com/api/v1.6/devices/my-new-device/my-variable/values

Send multiple dots

curl -X POST -H "X-Auth-Token: BBFF-Rfcgaxns6HlVb155WA0RhSY85xNDmB" -H

"Content-Type: application/json" -d '[{"value": 27, "timestamp":1514808000000},
{"value": 12, "timestamp":1514808900000}]'
https://industrial.api.ubidots.com/api/v1.6/devices/my-new-device/my-

variable/values
Retrieve data

The Ubidots REST API allows you to retrieve data from the platform data base. A
typical application for data retrieval is actuators like motors or lights control.
Retrieve mutiple values from a variable

Request structure:
GET /api/v1.6/devices/{DEVICE_LABEL}/{VARIABLE_LABEL}/values
HTTP/1.1<CR><LN>
Host: {Host}<CR><LN>
User-Agent: {USER_AGENT}<CR><LN>
X-Auth-Token: {TOKEN}<CR><LN>
Content-Type: application/json<CR><LN><CR><LN>
Expected Response:
HTTP/1.1 200 OK<CR><LN>
Server: nginx<CR><LN>
Date: Tue, 04 Sep 2018 22:35:06 GMT<CR><LN>
Content-Type: application/json<CR><LN>
Transfer-Encoding: chunked<CR><LN>
Vary: Cookie<CR><LN>
Allow: GET, POST, HEAD, OPTIONS<CR><LN><CR><LN>
{PAYLOAD_LENGTH_IN_HEXADECIMAL}<CR><LN>
{"count": true, "previous": null, "results": [{PAYLOAD_WITH_VALUES}], "next":
{URL_WITH_ADDITIONAL_VALUES}}<CR><LN>
0<CR><LN>
In the path specified above, replace the {DEVICELABEL} and {VARIABLE_LABEL}
keys with the unique labels of the Ubidots device and variable you desired to
retrieve data from. This _path returns by default the last 50 values stored of your
variable. You can manage the number of dots to retrieve using
the page_size parameter in your path:
/api/v1.6/devices/{DEVICE_LABEL}/{VARIABLE_LABEL}/values/?page_size=2
The path above retrieves the last 2 dots of your variable.

Ubidots API also allows you to filter the values to be retrieved by date range,
number of dots, and more. If you desire to go deep into this kind of requests,
please check the Ubidots Software REST API Reference.
GET
https://industrial.api.ubidots.com/api/v1.6/devices/{DEVICE_LABEL}/
{VARIABLE_LABEL}/values
GET
https://things.ubidots.com/api/v1.6/devices/{DEVICE_LABEL}/
{VARIABLE_LABEL}/values
Get the last two values from a variable (Educational users)

curl -X GET -H "X-Auth-Token: BBFF-Rfcgaxns6HlVb155WA0RhSY85xNDmB" -H

"Content-Type: application/json"
https://things.ubidots.com/api/v1.6/devices/my-device/my-variable/values/?

page_size=2
Get the last two values from a variable (Industrial users)

curl -X GET -H "X-Auth-Token: BBFF-Rfcgaxns6HlVb155WA0RhSY85xNDmB" -H

"Content-Type: application/json"
https://industrial.api.ubidots.com/api/v1.6/devices/my-device/my-

variable/values/?page_size=2
Retrieve the last value from a variable

A typical control application in general only needs to ask for the last value of a
variable, i.e, if you push a virtual switch at Ubidots, you just need to know what is
the last value of the variable related with that switch to take actions on any
actuators at your side.

Request structure:
GET /api/v1.6/devices/{DEVICE_LABEL}/{VARIABLE_LABEL}/lv HTTP/1.1<CR><LN>
Host: {Host}<CR><LN>
User-Agent: {USER_AGENT}<CR><LN>
X-Auth-Token: {TOKEN}<CR><LN>
Content-Type: application/json<CR><LN><CR><LN>
Expected Response:
HTTP/1.1 200 OK<CR><LN>
Server: nginx<CR><LN>
Date: Tue, 04 Sep 2018 22:35:06 GMT<CR><LN>
Content-Type: application/json<CR><LN>
Transfer-Encoding: chunked<CR><LN>
Vary: Cookie<CR><LN>
Allow: GET, POST, HEAD, OPTIONS<CR><LN><CR><LN>
{PAYLOAD_LENGTH_IN_HEXADECIMAL}<CR><LN>
{LAST_VALUE}<CR><LN>
0<CR><LN>
In the path specified above, replace the {DEVICE_LABEL} and {VARIABLE_LABEL}
keys with the unique labels of the Ubidots device and variable you desired to
retrieve data from.
GET
https://industrial.api.ubidots.com/api/v1.6/devices/{DEVICE_LABEL}/
{VARIABLE_LABEL}/lv
GET
https://things.ubidots.com/api/v1.6/devices/{DEVICE_LABEL}/
{VARIABLE_LABEL}/lv
Get the last value from a variable (Educational users)

curl -X GET -H "X-Auth-Token: BBFF-Rfcgaxns6HlVb155WA0RhSY85xNDmB" -H

"Content-Type: application/json"
https://things.ubidots.com/api/v1.6/devices/my-device/my-variable/lv

Get the last value from a variable (Industrial users)

curl -X GET -H "X-Auth-Token: BBFF-Rfcgaxns6HlVb155WA0RhSY85xNDmB" -H

"Content-Type: application/json"
https://industrial.api.ubidots.com/api/v1.6/devices/my-device/my-variable/lv

HTTP Examples

In this section, you will find different examples that show you how to handle data
with Ubidots to start monitoring and controlling your IoT Devices.

At the right side, you can find each example provided in different programming
languages. Please, refer to your preferred programming language by clicking the
tabs located on the right upper side of the page.
Sending a geopoint

Ubidots provides multiples ways to start tracking your IoT devices, so here we are
going to show you how to send coordinates to Ubidots in order to start with a
GPS IoT Solution.

To learn more about the Ubidots Maps Features, please check this guide.
curl -X POST -H "X-Auth-Token: BBFF-Rfcgaxns6HlVb155WA0RhSY85xNDmB" -H
"Content-Type: application/json" -d '{"location":{"value": 1, "context":
{"lat":37.773, "lng":-122.431}}}'
https://industrial.api.ubidots.com/api/v1.6/devices/my-new-device

Sending a string value

The String values provide additional information to the dot which is being sent. As
a basic example here, let's suppose that you are deploying a Weather Station
which provides you the Weather Status as a String value. At this point, the
Weather Status ought to be sent in the context of the dot.

To learn more of how to display the context of a dot in the Ubidots Dashboard,
please check this guide.
curl -X POST -H "X-Auth-Token: BBFF-Rfcgaxns6HlVb155WA0RhSY85xNDmB" -H
"Content-Type: application/json" -d '{"weather":{"value": 1, "context":{"weather-
status": "sunny"}}}' https://industrial.api.ubidots.com/api/v1.6/devices/my-new-

device
Sending values in bulk from a datalogger

In case you desire to send information to Ubidots from a data logger which is in
charge of taking samples for long periods of time, you can simply do it by
managing the values registered plus the time when the value was registered.
curl -X POST -H "X-Auth-Token: BBFF-Rfcgaxns6HlVb155WA0RhSY85xNDmB" -H
"Content-Type: application/json" -d '{"my-sensor":[{"value": 27,
"timestamp":1514808000000}, {"value": 30, "timestamp":1514808900000},
{"value": 31, "timestamp":1514809800000}, {"value": 29,
"timestamp":1514810700000}, {"value": 27, "timestamp":1514768400000}]}'
https://industrial.api.ubidots.com/api/v1.6/devices/my-new-device

Retrieve the last value for control

This is typically used for remote control applications. Your devices would retrieve
the last value of a variable, and then act based on that value. It is also used to
remotely manage your devices, like for example changing a sampling rate or
performing a remote reboot.

To learn more about the control features that Ubidots offer, please check this
guide.
Example Request

curl -X GET -H "X-Auth-Token: BBFF-Rfcgaxns6HlVb155WA0RhSY85xNDmB"

"https://industrial.api.ubidots.com/api/v1.6/devices/my-new-device/control/lv"

Response codes

The Ubidots REST API uses the following response codes when you make
an HTTP request, with them you can know your request status and errors if there
are any:
Cod
e Meaning

200 Ok -- Successful request.

201 Created -- Successful request + an item (device or variable)

was created.

202 Accepted -- The request has been accepted for processing, but
the processing has not been completed.

204 One of the fields is incorrect and the request is not saved --
Please verify it's a valid JSON string and that the fields are the
ones expected by the endpoint (string, object or float).

400 Bad Request -- Error due to an invalid body in your request.

Please verify it's a valid JSON string and that the fields are the
ones expected by the endpoint (string, object or float).

401 Invalid API key -- Please verify your API Key.

402 Payment required -- Please verify your balance.

403 Forbidden -- This token is not valid. Please verify your token.
Cod
e Meaning

404 Not Found -- We couldn’t find the URL you're trying to access.
This might be due to a wrong device label or ID, a wrong
variable label or ID, or simply a typo in the URL of the request.

405 Method Not Allowed -- This API endpoint does not accept the
method used. Check our API docs to see the allowed methods.

415 Unsupported media type -- The payload is in a format not

supported by this method on the target resource.

420 You have exceeded your API limits -- To upgrade your API
limits contacts the Ubidots team

423 Device does not receive data because it is disabled

429 Too many requests -- Many requests sent in a given amount of

time ("rate limiting")

50* Internal Error -- We're having issues with our servers. Please
check our status page.

MQTT

MQTT  is an "Internet of Things" connectivity protocol. It was designed as an

extremely lightweight publish/subscribe  messaging transport. It is useful for
connections with remote locations where a small code footprint is required and/or
network bandwidth is at a premium"
(Source: MQTT.org).
MQTT is specially useful to push data from the cloud to your devices. Imagine a
cloud-controlled device to open/close a door remotely. In the case of HTTP, the
device would have to continuously make GET requests to the Ubidots server to
see if there’s a change in a variable, say "Door Control Variable", and then take an
action depending on the last reading. This takes a lot of requests and it’s not
entirely a real-time interaction since it depends of the polling frequency. With
MQTT, the device can "listen" to the cloud and only get notified when there’s a
change in the variable. This way, the connection between the device and the
cloud is left open but data only travels when is necessary, saving battery, network
bandwidth and improving the real-time experience.
In this section you will find the documentation needed to handle your devices
with Ubidots over MQTT.

For a detailed explation of the Ubidots MQTT API Reference click here

Quality of Service
In MQTT, the quality of service, QoS for short, guarantees the delivery of a
specific message. There are three leves of QoS:

 0, At most once: This level does not guarantee the message delivery, it
would be labeled as best-effort server QoS.
 1, At least once: This level guarantees that the message is delivered at least
one time to the receiver. The receiver answer with a puback packet, if this
puback packet is not received the sender sends again the message.
 2, Exactly once: Guarantees that the message is received only once by the
receptor. It is the slowest packet interchange QoS as it requires two
request/response flows.
Ubidots supports QoS up to 1 (at most once).
Broker URLs

API access can be over plain MQTT or secure MQTT with TLS, using the following
endpoints based on your Ubidots Account type:
Non-TLS

Ubidots Account Endpoint Port

Educational things.ubidots.com 1883

Ubidots Account Endpoint Port

Industrial industrial.api.ubidots.com 1883

TLS

Ubidots Account Endpoint Port

Educational things.ubidots.com 8883

Industrial industrial.api.ubidots.com 8883

You can download the Ubidots PEM certificate for TLS here

Security Note: We strongly advise to use MQTT with TLS to make sure your data
travels encrypted, avoiding the exposure of your API token and/or sensor data to
third parties.
NOTE: To avoid future inconveniences, we advise to use both certificates in your
device's auth routines. While the first one is the current valid certificate, we may
change this after 2021.
Fixed IPs

Ubidots also supports fixed IPs address for data ingestion, but we highly advise to
our users to implement their firmware routines using the dns endpoints instead
of fixed IPs, as these last ones may change in the future.

Ubidots Account ipv4 ipv6 Port

Educational 50.23.124.68 2607:f0d0:2101:39::2 1883/8883

Industrial 169.55.61.243 2607:f0d0:3:b::2 1883/8883

MQTT Authentication

To interact with the Ubidots MQTT broker you'll need a token. A token is an
unique key that authorizes your device to interact with Ubidots API.
To establish the connection with the MQTT broker you need to assign
the username and password following the table below:
MQTT Credentials Parameter

Username Ubidots token

Password any character - not required -

Send data (Publish)

To send data, set the unique Device label in the topic path.

Ubidots accepts MQTT data JavaScript Object Notation or JSON. JSON is a
collection of name/value pairs in various programming languages, this is treated
as an object, record, struct, dictionary, hash table, keyed list, or associative array.
It is also human readable and language independent. An example of a JSON data
type that Ubidots accepts can be referenced below:
{"temperature": {"value":10, "timestamp": 1534881387000, "context":
{"machine": "1st floor"}}}
The keys context and timestamp are optional.
NOTE 1:: The Ubidots backend will take the latitude and longitude values inside
any variable labeled as "gps", "location", position or "coordinates" automatically
to get your device coordinates in all of the map widgets. You may change the
default location variable from Ubidots web user interface.
NOTE 2: All timestamps must be in milliseconds. If you set a timestamp for a
variable value, it will be stored with the date represented by it. You can easily
convert dates to timestamps values here.
If you wish to send more than one value, then you need to separate them using
commas. Below you can reference a typical structure for MQTT payloads:
Variable
s JSON structure

One {"VARIABLE-LABEL": {"value":VALUE, "timestamp":

TIMESTAMP, "context":{"KEY":VALUE}}}

Multiple {"VARIABLE-LABEL_1": {"value":VALUE, "context":

{"KEY":VALUE}}, ... , "VARIABLE-LABEL_n":
{"value":VALUE, "context":{"KEY": VALUE}}}

keys context and timestamp are optional.
Examples
Note: All the bash examples from this section makes use of the Eclipse Mosquitto
library, if you wish to test them please install it using the official instructions
 Single dot: {"temperature": 27}
 Multiple dots: {"temperature": 27, "humidity": 55, ... ,"pressure": 78}
Including additional keys like context and timestamp
 Single dot: {"position": {"value" : 1, "timestamp": 1514808000000,
"context":{"lat":-6.2, "lng":75.4, "name" : "John"}}}
 Multiple dots:{"temperature": {"value": 27, "timestamp": 1514808000000},
"humidity": 55, "pressure": {"value": 78, "context":{"name" : "John"}}}
PUB
/v1.6/devices/{DEVICE_LABEL}/
Send a single dot (Educational users)

mosquitto_pub -h "things.api.ubidots.com" -t "/v1.6/devices/weather-station" -u

"p4uuT2O25AJwv7ncADLoVhQfImwRQW" -p 1883 -q 1 -m '{"temperature": 27}'

Send a single dot (Industrial users)

mosquitto_pub -h "industrial.api.ubidots.com" -t "/v1.6/devices/weather-station"

-u "BBFF-Rfcgaxns6HlVb155WA0RhSY85xNDmB" -p 1883 -q 1 -m '{"temperature":

27}'
Send a dot with coordinates

mosquitto_pub -h "industrial.api.ubidots.com" -t "/v1.6/devices/weather-station"

-u "BBFF-Rfcgaxns6HlVb155WA0RhSY85xNDmB" -p 1883 -q 1 -m '{"position":
{"value" : 1, "timestamp": 1514808000000, "context":{"lat":-6.2, "lng":75.4}}}'

Send multiple dots

mosquitto_pub -h "industrial.api.ubidots.com" -t "/v1.6/devices/weather-station"

-u "BBFF-Rfcgaxns6HlVb155WA0RhSY85xNDmB" -p 1883 -q 1 -m '{"temperature":
{"value": 27, "timestamp": 1514808000000}, "humidity": 55, "pressure": {"value":

78, "context":{"name" : "John"}}}'

Retrieve data (Subscribe)

Similar to the GET function in HTTP, subscribe is the method to obtain values with
a huge difference: you do not have to be continuously ask the server for each
value in your custom script. For example, if a variable's value changes, Ubidots
will automatically update you (the user) of any changes. Thus saving data requests
and processing time for your device and overall project functionality and
expenses. Because of this, MQTT is a communication protocol adviced to
implement firmware routines to control actuators.
Retrieve the last value of a variable

Replace the {DEVICE_LABEL} and {VARIABLE_LABEL} with the unique label of the

device and the variable to subscribe for retrieving values update. If the specified
Device or Variable do not exist, you will not able to establish the subscription with
it.
SUB
/v1.6/devices/{DEVICE_LABEL}/{LABEL_VARIABLE}/lv
Subscribe to a variable (Educational users)

mosquitto_sub -h "things.ubidots.com" -t "/v1.6/devices/weather-

station/temperature/lv" -u "p4uuT2O25AJwv7ncADLoVhQfImwRQW" -p 1883 -q 1

Subscribe to a variable (Industrial users)

mosquitto_sub -h "industrial.api.ubidots.com" -t "/v1.6/devices/weather-

station/temperature/lv" -u "BBFF-Rfcgaxns6HlVb155WA0RhSY85xNDmB" -p 1883

-q 1
MQTT Examples

In this section, you will find different examples that show you how use MQTT to
implement several IoT applications.

At the right side, you can find each example provided in different programming
languages. Please, refer to your preferred programming language by clicking the
tabs located on the right upper side of the page.
GPS Tracker

Ubidots provides multiples ways to start tracking your IoT devices, so here we are
going to show you how to send coordinates to Ubidots in order to start with a
GPS IoT Solution.

To learn more about the Ubidots Maps Features, please check this guide.
mosquitto_pub -p 1883 -h industrial.api.ubidots.com -t "/v1.6/devices/my-new-
device" -u 'BBFF-Rfcgaxns6HlVb155WA0RhSY85xNDmB' -m '{"location":{"value":

1, "context":{"lat":37.773, "lng":-122.431}}}' -d -q 1
Weather description

The String values provide additional information to the dot which is being sent. As
a basic example here, let's suppose that you are deploying a Weather Station
which provides you the Weather Status as a String value. At this point, the
Weather Status ought to be sent in the context of the dot.

To learn more of how to display the context of a dot in the Ubidots Dashboard,
please check this guide.
mosquitto_pub -p 1883 -h industrial.api.ubidots.com -t "/v1.6/devices/my-new-
device" -u 'BBFF-Rfcgaxns6HlVb155WA0RhSY85xNDmB' -m '{"weather":{"value":

1, "context":{"weather-status": "sunny"}}}' -d -q 1
Retrieve the last value for control

This is the perfect solution for you in case your desire to control remotely the
garage doors, home lights, alarm system, or any asset you desire.

To learn more about the control features that Ubidots offer, please check this
guide.
Example Request

mosquitto_sub -p 1883 -h industrial.api.ubidots.com -t "/v1.6/devices/my-new-

device/control/lv" -u 'BBFF-Rfcgaxns6HlVb155WA0RhSY85xNDmB' -d -q 1

TCP / UDP

The Transmision Control Protocol, TCP, is one of the most popular data transport
protocols, so much it is supported by default in most hardware devices. Its main
advantage comes in the packet size, usually lower than packets sent using HTTP
(which in fact, uses TCP as transport layer). TCP is "connection oriented", which
means it implements confirmation methods to guarantee that data is received by
the destinatary.

The User Datagram Protocol, UDP, is also a very popular protocol that, unlike TCP,
it is "connectionless". This means it does not implements any confirmation
method to guarantee that data is received by the destinatary. This can be an
advantage in applications where simplicity and speed are more important than
reliability.

TCP and UDP are similar in the sense that they share the structure
of endpoint + port.
TCP Authentication

To send data to Ubidots using TCP or UDP broker you need your Ubidots TOKEN.
The easiest way to get it is by clicking on "API Credentials" under your profile tab:
TCP URLs

API access can be over plain TCP or secure TCP with TLS, using the following
endpoints based on your Ubidots Account type:
Non-TLS

Ubidots Account Endpoint Port

Educational things.ubidots.com 9012

Industrial industrial.api.ubidots.com 9012

TLS

Ubidots Account Endpoint Port

Educational things.ubidots.com Not Available

Industrial industrial.api.ubidots.com 9812

You can download the Ubidots PEM certificate for TLS here

Security Note: We strongly advise to use TCP with TLS to make sure your data
travels encrypted, avoiding the exposure of your API token and/or sensor data to
third parties.
NOTE: To avoid future inconveniences, we advise to use both certificates in your
device's auth routines. While the first one is the current valid certificate, we may
change this after 2021.
Send Data

Structure
Ubidots created a pre-defined structure to understand the content of your
TCP/UDP packets. If you wish to implement a custom structure, please get in
touch with our support channel.

Single device:

{USER_AGENT}|POST|{TOKEN}|DEV_LABEL(:DEV_NAME)
(@GLOBAL_TIMESTAMP)=>[VAR_LABEL:VALUE([$CONTEXT_KEY=CONTEXT_VAL]..
.)](@VARIABLE_TIMESTAMP)|end
Multiple devices:

{USER_AGENT}|POST|{TOKEN}|DEV_LABEL(:DEV_NAME)
(@GLOBAL_TIMESTAMP)=>[VAR_LABEL:VALUE([$CONTEXT_KEY=CONTEXT_VAL]..
.)](@VARIABLE_TIMESTAMP); ... ;DEV_LABEL(:DEV_NAME)
(@GLOBAL_TIMESTAMP)=>[VAR_LABEL:VALUE([$CONTEXT_KEY=CONTEXT_VAL]..
.)](@VARIABLE_TIMESTAMP)|end
Where:

 {USER_AGENT}: Mandatory. Contains a characteristic string that allows to

identify the application type, operating system, software vendor or software
version of the requesting software user agent. Examples: ESP8266/1.0,
Particle/1.2
 {DEVICE_LABEL}: Mandatory. The device label to publish values. If it does
not exist, Ubidots will create it. Blank spaces are not allowed.
Examples: Weather-station, living-room
 {DEVICE_Name}: Optional. The device name to publish values. If not set, the
device name will be set using the device label. This parameter is useful when
you have as device label your device MAC and you wish to show to final
users a friendly name. Blank spaces are not allowed.
Examples: Street-42-weather-station, living-room-floor-1
 {GLOBAL_TIMESTAMP}: Optional. Unix time stamp. If set, any variable value
without timestamp will use this one to store values. Must be in
milliseconds.If not set, Ubidots will add it automatically with the actual
 timestamp in UTC.
Examples: 1534282544356
 {VARIABLE_LABEL}: Mandatory. The variable label that will store the dot. If
it does not exist, Ubidots will create it.You may send multiple variables
splitting them by commas.
Examples: temperature, wind-speed
 {VALUE}: Mandatory. Dot value. You can use a dot to set float numbers.
Examples: 1.0005, 2
 {CONTEXT_KEY}: Optional. If set, you must specify a context value. You can
add as many context key as you wish splitting them with a '$' char.
Examples: lat, lng, name, surname.
 {CONTEXT_VALUE}: Optional. The context key value.
Examples (based on keys above): -6.2, 75.4, "John", "Smith"
 {VARIABLE_TIMESTAMP}: Optional. Unix time stamp. If set, the variable will
use this one to store dots. This parameter has precedence among the global
timestamp. Must be in milliseconds.If not set, Ubidots will add it
automatically with the actual timestamp in UTC.
Examples: 1534282544356
Server Response
[OK|...]
ERROR|400
 Valid messages: Ubidots will answer Ok if the request is correct. If multiple
values are sent, Ok|OK... strings (one per variable in the request) splitted by
pipelines '|' will be returned.
 Non valid messages: Ubidots will answer ERROR|400 if the message is not
valid.
Stream Examples
 Variable with multiple context values:
ubidots/1.0|POST|{TOKEN}|weather-station=>temperature:20$day-
hour=11$day-minute=23|end
 Variable with same value to multiple devices:
ubidots/1.0|POST|{TOKEN}|weather-station-denver=>temperature:20;weather-
station-london=>temperature:20|end
Examples

Send a single dot to a device with name green-truck and device

label 5b7356ccbbddbd594df54555 stored inside the variable speed:
ESP8266/1.0|POST|p4uuT2O25AJwv7ncADLoVhQfImwRQW|
5b7356ccbbddbd594df54555:green-truck=>speed:2|end

Send a single dot to a device named as green-truck with device

label 5b7356ccbbddbd594df54555 stored inside the variable speed at 2017/12/31
8:00 UTC:
ESP8266/1.0|POST|p4uuT2O25AJwv7ncADLoVhQfImwRQW|
5b7356ccbbddbd594df54555:green-truck=>speed:2@1514707200000|end

Send a single dot to a device labeled as green-truck with api

label 5b7356ccbbddbd594df54555 stored inside the variable speed at 2017/12/31
8:00 UTC with latitude, longitude and other keys inside its context:
ESP8266/1.0|POST|p4uuT2O25AJwv7ncADLoVhQfImwRQW|
5b7356ccbbddbd594df54555:green-truck=>speed:2$lat=-
6.2$lng=75.4$name=John$surname=Smith@1514707200000|end

Send multiple values

ESP8266/1.0|POST|p4uuT2O25AJwv7ncADLoVhQfImwRQW|weather-
station=>temperature:20,humidity:35|end
Send values to multiple devices

ESP8266/1.0|POST|p4uuT2O25AJwv7ncADLoVhQfImwRQW|weather-station-
toronto=>temperature:20,humidity:35;weather-station-
washington=>temperature:20,humidity:35|end
Send a single dot (Educational users)

echo -n "ESP8266/1.0|POST|p4uuT2O25AJwv7ncADLoVhQfImwRQW|
5b7356ccbbddbd594df54555:green-truck=>speed:2|end" | telnet

things.ubidots.com 9012
Send a single dot (Industrial users)

echo -n "ESP8266/1.0|POST|BBFF-
kiFdJvtV3OWTY56M0rKluUGm71lzzn6kboWpbWpfhJFah7fL6p1kcks|green-
truck:5b7356ccbbddbd594df54555=>speed:2|end" | telnet

industrial.api.ubidots.com 9012
Send multiple dots (Educational users)

echo -n "ESP8266/1.0|POST|p4uuT2O25AJwv7ncADLoVhQfImwRQW|weather-
station=>temperature:20,humidity:35|end" | telnet things.ubidots.com 9012

Send multiple dots (Industrial users)

echo -n "ESP8266/1.0|POST|BBFF-
kiFdJvtV3OWTY56M0rKluUGm71lzzn6kboWpbWpfhJFah7fL6p1kcks|weather-
station=>temperature:20,humidity:35|end" | telnet industrial.api.ubidots.com

9012
Retrieve Data

Structure
Ubidots TCP/UDP supports the payload request structure below for retrieving
dots values
{USER_AGENT}|LV|{TOKEN}|{DEVICE_LABEL}:{VARIABLE_LABEL}|end
{USER_AGENT}|GET|{TOKEN}|{VARIABLE_ID}|end
where:

 {USER_AGENT}: Mandatory. Contains a characteristic string that allows to

identify the application type, operating system, software vendor or software
version of the requesting software user agent. Examples: ESP8266/1.0,
Particle/1.2
 {DEVICE_LABEL}: Mandatory. The device label to publish values. If it does
not exist, Ubidots will create it. Blank spaces are not allowed.
Examples: Weather-station, living-room
 {VARIABLE_LABEL}: Mandatory. The variable label that stores the dot.
Examples: temperature, wind-speed

 {VARIABLE_LABEL}: Mandatory. The variable unique identifier that
stores the dot.
Examples: 573dc1ee76254241c57a4616
Server Response
OK|Number
ERROR|400 , ERROR|404
 Valid message: Ubidots will answer Ok| followed by the dot value if the
request is correct.
 Non valid message: Ubidots will answer ERROR|400 if the message is not
valid or ERROR|400 if the message contains a variable or device that does
not exist.
Examples

Get the last value from the variable speed inside a device labeled with api
label green-truck:
ESP8266/1.0|LV|p4uuT2O25AJwv7ncADLoVhQfImwRQW|green-truck:speed|end
Get the last value from the variable speed inside a device labeled with api
label green-truck using the speed variable unique id:
ESP8266/1.0|GET|p4uuT2O25AJwv7ncADLoVhQfImwRQW|
573dc1ee76254241c57a4616|end
Get last variable value (Educational users)

echo -n "ESP8266/1.0|LV|p4uuT2O25AJwv7ncADLoVhQfImwRQW|green-

truck:speed|end" | telnet things.ubidots.com 9012

Get last variable value (Industrial users)

echo -n "ESP8266/1.0|LV|BBFF-
kiFdJvtV3OWTY56M0rKluUGm71lzzn6kboWpbWpfhJFah7fL6p1kcks|green-

truck:speed|end" | telnet industrial.api.ubidots.com 9012

Utils

Ubidots also supports to retrieve the actual UTC timestamp from our servers.

Structure
Ubidots TCP/UDP supports the payload request structure below for retrieving
dots values

{USER_AGENT}|UTCNOW|||end
where:

 {USER_AGENT}: Mandatory. Contains a characteristic string that allows to

identify the application type, operating system, software vendor or software
version of the requesting software user agent. Examples: ESP8266/1.0,
Particle/1.2
Server Response
OK|TIMESTAMP
ERROR|400
 Valid message: Ubidots will answer Ok| followed by the actual UTC
timestamp in milliseconds.
 Not valid message: Ubidots will answer ERROR|400 if the message is not
valid.
References:
[1] Ki-hwanEom, Chang Won Lee, Nghia Truong Van, Kyung Kwon Jung,
JooWoong Kim And Woo Seung Choi “Food Poisoning Prevention
Monitoring System Based On The Smart RFID Tag System”
InInternational Journal Of Multimedia And Ubiquitous Engineering
Vol.8, No.5 (2013), Pp.213-222
[2] Kong Xiangsheng Xinxiang University, Xinxiang, China “Design And
Implementation Of Food Monitoring System Based On Wsn”
[3] Karleigh Huff “Active And Intelligent Packaging: Innovations For The
Future” Graduate Student Department Of Food Science And
Technology Virginia Polytechnic Institute And State University (Virginia
Tech) Blacksburg
[4] “Food Borne Patogen Detection” In Adv. J. Food Sci. Technol., 6(11):
1241-1248, 2014
[5] Evangelyn C. Alocilja, Member, IEEE, Nichole L. Ritchie, And Daniel L.
Grooms “ Protocol Development Using An Electronic Nose For
Differentiating E. Coli Strains” IEEE SENSORS JOURNAL, VOL. 3, No. 6,
December 2003
[6] Kang Along, Zhang Chenrui, ZongweiLuo, Lai Xiaozheng, Han Tao “
SAWRFID Enabled Multi-functional Sensors For Food Safety
Applications” Program For The IEEE International Conference On Rfid-
technology And Applications, 17 - 19 June 2010 Guangzhou, China
[7] P.-Y. Cresson , C. Ricardi , L. Dubois , S. Vaucher , T. Lasri , J. Pribetich
«Temperature Measurement By Microwave Radiometry” I2MTC 2008 -
IEEE International Instrumentation And Measurement Technology
Conference Victoria, Vancouver Island, Canada, May 12-15, 2008
[8] Ove Schimmer1, Frank Daschner2 And Reinhard Knöchel „Uwb-
sensors In Food Quality Management – The Way From The Concept To
Market” PROCEEDINGS OF THE 2008 IEEE INTERNATIONAL
CONFERENCE ON ULTRAWIDEBAND (ICUWB2008), VOL. 2
[9] Zhibo Pang, Jun Chen, Zhi Zhang, Qiang Chen, LirongZheng “ Global
Fresh Food Tracking Service Enabled By Wide Area Wireless Sensor
Network “
[10] Fojan P, Jensen KR And Gurevich“ Label-free Detection Of
Biomolecular Interaction – DNA - Antimicrobial Peptide Binding “ 978-1-
4577-0787-2/11/$26.00 ©2011 IEEE
[11] Dr. Jiten Ch. Dutta “Ion Sensitive Field Effect Transistor For
Applications In Bioelectronic Sensors: A Research Review” Cisp2012|
proceedings|185
[12] Lei Wan1, Yajie Qin1, Patrick Chiang1, 2, Guoping Chen1, Ran Liu1,
ZhiliangHong1 “High-Sensitivity Photodetection Sensor Front-End,
Detecting Organophosphourous Compounds for Food Safety”