Slides of the presentation at IEEE WiMob/SEUNet 2017, in Rome. We exploit an overlooked feature of the ESP8266 WiFi chip, i.e. the AT commands interpreter, to implement a sensor/actuator that meets the above specifications. To test our design, we implement a library that provides a transparent wrapper for AT commands. Hardware and software are available on bitbucket.

1. SEUNet 2017 - Rome
Design and implementation of a low-cost modular sensor
Augusto Ciuffoletti - Univ. of Pisa (Italy)
October 9th 2017

2. Sensors in urban environments
• In order to control an urban environment we need to
interconnect many different sensors
• Many: an overwhelming number of aspects needs to be
monitored, measuring parameters of detecting events
• Different: each aspect is characterized by a different
monitoring technology and devices
• Interconnected: they exchange data and control with other
data aggregators and processors
• Sensors need to be cheap, simple and reusable:
• A high cost excludes a significant scale
• The design should be affordable for the technical staff of
the urban district
• Reusability allows a flexible design in a fast evolving
environment

3. Sensors in urban environments
• In order to control an urban environment we need to
interconnect many different sensors
• Many: an overwhelming number of aspects needs to be
monitored, measuring parameters of detecting events
• Different: each aspect is characterized by a different
monitoring technology and devices
• Interconnected: they exchange data and control with other
data aggregators and processors
• Sensors need to be cheap, simple and reusable:
• A high cost excludes a significant scale
• The design should be affordable for the technical staff of
the urban district
• Reusability allows a flexible design in a fast evolving
environment

4. Sensors in urban environments
• In order to control an urban environment we need to
interconnect many different sensors
• Many: an overwhelming number of aspects needs to be
monitored, measuring parameters of detecting events
• Different: each aspect is characterized by a different
monitoring technology and devices
• Interconnected: they exchange data and control with other
data aggregators and processors
• Sensors need to be cheap, simple and reusable:
• A high cost excludes a significant scale
• The design should be affordable for the technical staff of
the urban district
• Reusability allows a flexible design in a fast evolving
environment

5. Sensors in urban environments
• In order to control an urban environment we need to
interconnect many different sensors
• Many: an overwhelming number of aspects needs to be
monitored, measuring parameters of detecting events
• Different: each aspect is characterized by a different
monitoring technology and devices
• Interconnected: they exchange data and control with other
data aggregators and processors
• Sensors need to be cheap, simple and reusable:
• A high cost excludes a significant scale
• The design should be affordable for the technical staff of
the urban district
• Reusability allows a flexible design in a fast evolving
environment

6. Sensors in urban environments
• In order to control an urban environment we need to
interconnect many different sensors
• Many: an overwhelming number of aspects needs to be
monitored, measuring parameters of detecting events
• Different: each aspect is characterized by a different
monitoring technology and devices
• Interconnected: they exchange data and control with other
data aggregators and processors
• Sensors need to be cheap, simple and reusable:
• A high cost excludes a significant scale
• The design should be affordable for the technical staff of
the urban district
• Reusability allows a flexible design in a fast evolving
environment

7. Sensors in urban environments
• In order to control an urban environment we need to
interconnect many different sensors
• Many: an overwhelming number of aspects needs to be
monitored, measuring parameters of detecting events
• Different: each aspect is characterized by a different
monitoring technology and devices
• Interconnected: they exchange data and control with other
data aggregators and processors
• Sensors need to be cheap, simple and reusable:
• A high cost excludes a significant scale
• The design should be affordable for the technical staff of
the urban district
• Reusability allows a flexible design in a fast evolving
environment

8. Sensors in urban environments
• In order to control an urban environment we need to
interconnect many different sensors
• Many: an overwhelming number of aspects needs to be
monitored, measuring parameters of detecting events
• Different: each aspect is characterized by a different
monitoring technology and devices
• Interconnected: they exchange data and control with other
data aggregators and processors
• Sensors need to be cheap, simple and reusable:
• A high cost excludes a significant scale
• The design should be affordable for the technical staff of
the urban district
• Reusability allows a flexible design in a fast evolving
environment

9. Sensors in urban environments
• In order to control an urban environment we need to
interconnect many different sensors
• Many: an overwhelming number of aspects needs to be
monitored, measuring parameters of detecting events
• Different: each aspect is characterized by a different
monitoring technology and devices
• Interconnected: they exchange data and control with other
data aggregators and processors
• Sensors need to be cheap, simple and reusable:
• A high cost excludes a significant scale
• The design should be affordable for the technical staff of
the urban district
• Reusability allows a flexible design in a fast evolving
environment

10. Design principles
• Limit the presence of ad hoc components
• use COTS components as far as possible
• Do not overkill the problem
• tailor the computational capabilities on the real needs
• Modularize the architecture
• the design is more agile
• exploit concurrency
• improve reusability
• Use standard interfaces
• improve reusability
• Use inexpensive and widely diffused components

11. Design principles
• Limit the presence of ad hoc components
• use COTS components as far as possible
• Do not overkill the problem
• tailor the computational capabilities on the real needs
• Modularize the architecture
• the design is more agile
• exploit concurrency
• improve reusability
• Use standard interfaces
• improve reusability
• Use inexpensive and widely diffused components

12. Design principles
• Limit the presence of ad hoc components
• use COTS components as far as possible
• Do not overkill the problem
• tailor the computational capabilities on the real needs
• Modularize the architecture
• the design is more agile
• exploit concurrency
• improve reusability
• Use standard interfaces
• improve reusability
• Use inexpensive and widely diffused components

13. Design principles
• Limit the presence of ad hoc components
• use COTS components as far as possible
• Do not overkill the problem
• tailor the computational capabilities on the real needs
• Modularize the architecture
• the design is more agile
• exploit concurrency
• improve reusability
• Use standard interfaces
• improve reusability
• Use inexpensive and widely diffused components

14. Design principles
• Limit the presence of ad hoc components
• use COTS components as far as possible
• Do not overkill the problem
• tailor the computational capabilities on the real needs
• Modularize the architecture
• the design is more agile
• exploit concurrency
• improve reusability
• Use standard interfaces
• improve reusability
• Use inexpensive and widely diffused components

15. Design principles
• Limit the presence of ad hoc components
• use COTS components as far as possible
• Do not overkill the problem
• tailor the computational capabilities on the real needs
• Modularize the architecture
• the design is more agile
• exploit concurrency
• improve reusability
• Use standard interfaces
• improve reusability
• Use inexpensive and widely diffused components

16. Design principles
• Limit the presence of ad hoc components
• use COTS components as far as possible
• Do not overkill the problem
• tailor the computational capabilities on the real needs
• Modularize the architecture
• the design is more agile
• exploit concurrency
• improve reusability
• Use standard interfaces
• improve reusability
• Use inexpensive and widely diffused components

17. Design principles
• Limit the presence of ad hoc components
• use COTS components as far as possible
• Do not overkill the problem
• tailor the computational capabilities on the real needs
• Modularize the architecture
• the design is more agile
• exploit concurrency
• improve reusability
• Use standard interfaces
• improve reusability
• Use inexpensive and widely diffused components

18. Design principles
• Limit the presence of ad hoc components
• use COTS components as far as possible
• Do not overkill the problem
• tailor the computational capabilities on the real needs
• Modularize the architecture
• the design is more agile
• exploit concurrency
• improve reusability
• Use standard interfaces
• improve reusability
• Use inexpensive and widely diffused components

19. Design principles
• Limit the presence of ad hoc components
• use COTS components as far as possible
• Do not overkill the problem
• tailor the computational capabilities on the real needs
• Modularize the architecture
• the design is more agile
• exploit concurrency
• improve reusability
• Use standard interfaces
• improve reusability
• Use inexpensive and widely diffused components

20. Design principles
• Limit the presence of ad hoc components
• use COTS components as far as possible
• Do not overkill the problem
• tailor the computational capabilities on the real needs
• Modularize the architecture
• the design is more agile
• exploit concurrency
• improve reusability
• Use standard interfaces
• improve reusability
• Use inexpensive and widely diffused components

21. Typical architecture of a (smart) sensor
• Modularize the (smart) sensor
• Dumb device: hardware measurement or enactment
• Dumb device/Processor interface
• Processor: controls dumb devices according to a logic
• Processor/Network Module interface
• Network Module
• We concentrate on Processor and Network Module

22. Typical architecture of a (smart) sensor
• Modularize the (smart) sensor
• Dumb device: hardware measurement or enactment
• Dumb device/Processor interface
• Processor: controls dumb devices according to a logic
• Processor/Network Module interface
• Network Module
• We concentrate on Processor and Network Module

23. Typical architecture of a (smart) sensor
• Modularize the (smart) sensor
• Dumb device: hardware measurement or enactment
• Dumb device/Processor interface
• Processor: controls dumb devices according to a logic
• Processor/Network Module interface
• Network Module
• We concentrate on Processor and Network Module

24. Typical architecture of a (smart) sensor
• Modularize the (smart) sensor
• Dumb device: hardware measurement or enactment
• Dumb device/Processor interface
• Processor: controls dumb devices according to a logic
• Processor/Network Module interface
• Network Module
• We concentrate on Processor and Network Module

25. Typical architecture of a (smart) sensor
• Modularize the (smart) sensor
• Dumb device: hardware measurement or enactment
• Dumb device/Processor interface
• Processor: controls dumb devices according to a logic
• Processor/Network Module interface
• Network Module
• We concentrate on Processor and Network Module

26. Typical architecture of a (smart) sensor
• Modularize the (smart) sensor
• Dumb device: hardware measurement or enactment
• Dumb device/Processor interface
• Processor: controls dumb devices according to a logic
• Processor/Network Module interface
• Network Module
• We concentrate on Processor and Network Module

27. Typical architecture of a (smart) sensor
• Modularize the (smart) sensor
• Dumb device: hardware measurement or enactment
• Dumb device/Processor interface
• Processor: controls dumb devices according to a logic
• Processor/Network Module interface
• Network Module
• We concentrate on Processor and Network Module

28. Meta ex-cursus: about this paper
• Principles are the foundations, but I quickly go to practice
• Maybe too much in an "Instructables" style, but possibly
useful
• one of the reviewers did not appreciate that, sorry
• Scientific approach, though:
• full details of the experiment (reproducible)
• discussion of the results
• not the end of the story
• you can just improve this (I did...)

29. Meta ex-cursus: about this paper
• Principles are the foundations, but I quickly go to practice
• Maybe too much in an "Instructables" style, but possibly
useful
• one of the reviewers did not appreciate that, sorry
• Scientific approach, though:
• full details of the experiment (reproducible)
• discussion of the results
• not the end of the story
• you can just improve this (I did...)

30. Meta ex-cursus: about this paper
• Principles are the foundations, but I quickly go to practice
• Maybe too much in an "Instructables" style, but possibly
useful
• one of the reviewers did not appreciate that, sorry
• Scientific approach, though:
• full details of the experiment (reproducible)
• discussion of the results
• not the end of the story
• you can just improve this (I did...)

31. Meta ex-cursus: about this paper
• Principles are the foundations, but I quickly go to practice
• Maybe too much in an "Instructables" style, but possibly
useful
• one of the reviewers did not appreciate that, sorry
• Scientific approach, though:
• full details of the experiment (reproducible)
• discussion of the results
• not the end of the story
• you can just improve this (I did...)

32. Meta ex-cursus: about this paper
• Principles are the foundations, but I quickly go to practice
• Maybe too much in an "Instructables" style, but possibly
useful
• one of the reviewers did not appreciate that, sorry
• Scientific approach, though:
• full details of the experiment (reproducible)
• discussion of the results
• not the end of the story
• you can just improve this (I did...)

33. Meta ex-cursus: about this paper
• Principles are the foundations, but I quickly go to practice
• Maybe too much in an "Instructables" style, but possibly
useful
• one of the reviewers did not appreciate that, sorry
• Scientific approach, though:
• full details of the experiment (reproducible)
• discussion of the results
• not the end of the story
• you can just improve this (I did...)

34. Meta ex-cursus: about this paper
• Principles are the foundations, but I quickly go to practice
• Maybe too much in an "Instructables" style, but possibly
useful
• one of the reviewers did not appreciate that, sorry
• Scientific approach, though:
• full details of the experiment (reproducible)
• discussion of the results
• not the end of the story
• you can just improve this (I did...)

35. Meta ex-cursus: about this paper
• Principles are the foundations, but I quickly go to practice
• Maybe too much in an "Instructables" style, but possibly
useful
• one of the reviewers did not appreciate that, sorry
• Scientific approach, though:
• full details of the experiment (reproducible)
• discussion of the results
• not the end of the story
• you can just improve this (I did...)

36. The Processor: Arduino Nano
• Similar to the Arduino Uno, but smaller size (18x45 mm)
• Onboard ADC, PWM, Digital I/O, UART
• Easily programmable in C
• Often used in high school teaching
• Open design
• Inexpensive (available for less than 5 euros)

37. The Processor: Arduino Nano
• Similar to the Arduino Uno, but smaller size (18x45 mm)
• Onboard ADC, PWM, Digital I/O, UART
• Easily programmable in C
• Often used in high school teaching
• Open design
• Inexpensive (available for less than 5 euros)

38. The Processor: Arduino Nano
• Similar to the Arduino Uno, but smaller size (18x45 mm)
• Onboard ADC, PWM, Digital I/O, UART
• Easily programmable in C
• Often used in high school teaching
• Open design
• Inexpensive (available for less than 5 euros)

39. The Processor: Arduino Nano
• Similar to the Arduino Uno, but smaller size (18x45 mm)
• Onboard ADC, PWM, Digital I/O, UART
• Easily programmable in C
• Often used in high school teaching
• Open design
• Inexpensive (available for less than 5 euros)

40. The Processor: Arduino Nano
• Similar to the Arduino Uno, but smaller size (18x45 mm)
• Onboard ADC, PWM, Digital I/O, UART
• Easily programmable in C
• Often used in high school teaching
• Open design
• Inexpensive (available for less than 5 euros)

41. The Processor: Arduino Nano
• Similar to the Arduino Uno, but smaller size (18x45 mm)
• Onboard ADC, PWM, Digital I/O, UART
• Easily programmable in C
• Often used in high school teaching
• Open design
• Inexpensive (available for less than 5 euros)

42. The Network Module: Espressif ESP-01
• Tiny 8 pins board (14x25 mm)
• Based on the ESP8266: WiFi client or access point
• Onboard UART
• Not immediate to program, but shipped with a serial API
• Growing popularity among hobbists
• Inexpensive (available for less than 5 euros)

43. The Network Module: Espressif ESP-01
• Tiny 8 pins board (14x25 mm)
• Based on the ESP8266: WiFi client or access point
• Onboard UART
• Not immediate to program, but shipped with a serial API
• Growing popularity among hobbists
• Inexpensive (available for less than 5 euros)

44. The Network Module: Espressif ESP-01
• Tiny 8 pins board (14x25 mm)
• Based on the ESP8266: WiFi client or access point
• Onboard UART
• Not immediate to program, but shipped with a serial API
• Growing popularity among hobbists
• Inexpensive (available for less than 5 euros)

45. The Network Module: Espressif ESP-01
• Tiny 8 pins board (14x25 mm)
• Based on the ESP8266: WiFi client or access point
• Onboard UART
• Not immediate to program, but shipped with a serial API
• Growing popularity among hobbists
• Inexpensive (available for less than 5 euros)

46. The Network Module: Espressif ESP-01
• Tiny 8 pins board (14x25 mm)
• Based on the ESP8266: WiFi client or access point
• Onboard UART
• Not immediate to program, but shipped with a serial API
• Growing popularity among hobbists
• Inexpensive (available for less than 5 euros)

47. The Network Module: Espressif ESP-01
• Tiny 8 pins board (14x25 mm)
• Based on the ESP8266: WiFi client or access point
• Onboard UART
• Not immediate to program, but shipped with a serial API
• Growing popularity among hobbists
• Inexpensive (available for less than 5 euros)

48. The interface: Espressif AT interface
• The ESP-01 board comes pre-flashed with an API
accessible through an onboard UART (aka serial line)
• The API allows all sorts of network related operations:
from IP address configuration to TCP connections
• The API implementation is open source, and extensible
• The commands are sent through the serial line as (quite
verbose) series of characters.
• e.g., to connect to an AP
AT+CWJAP_CUR="room123","the psk"
• The Network Module returns a response
• a plain OK for success, more complex in case of error

49. The interface: Espressif AT interface
• The ESP-01 board comes pre-flashed with an API
accessible through an onboard UART (aka serial line)
• The API allows all sorts of network related operations:
from IP address configuration to TCP connections
• The API implementation is open source, and extensible
• The commands are sent through the serial line as (quite
verbose) series of characters.
• e.g., to connect to an AP
AT+CWJAP_CUR="room123","the psk"
• The Network Module returns a response
• a plain OK for success, more complex in case of error

50. The interface: Espressif AT interface
• The ESP-01 board comes pre-flashed with an API
accessible through an onboard UART (aka serial line)
• The API allows all sorts of network related operations:
from IP address configuration to TCP connections
• The API implementation is open source, and extensible
• The commands are sent through the serial line as (quite
verbose) series of characters.
• e.g., to connect to an AP
AT+CWJAP_CUR="room123","the psk"
• The Network Module returns a response
• a plain OK for success, more complex in case of error

51. The interface: Espressif AT interface
• The ESP-01 board comes pre-flashed with an API
accessible through an onboard UART (aka serial line)
• The API allows all sorts of network related operations:
from IP address configuration to TCP connections
• The API implementation is open source, and extensible
• The commands are sent through the serial line as (quite
verbose) series of characters.
• e.g., to connect to an AP
AT+CWJAP_CUR="room123","the psk"
• The Network Module returns a response
• a plain OK for success, more complex in case of error

52. The interface: Espressif AT interface
• The ESP-01 board comes pre-flashed with an API
accessible through an onboard UART (aka serial line)
• The API allows all sorts of network related operations:
from IP address configuration to TCP connections
• The API implementation is open source, and extensible
• The commands are sent through the serial line as (quite
verbose) series of characters.
• e.g., to connect to an AP
AT+CWJAP_CUR="room123","the psk"
• The Network Module returns a response
• a plain OK for success, more complex in case of error

53. The interface: Espressif AT interface
• The ESP-01 board comes pre-flashed with an API
accessible through an onboard UART (aka serial line)
• The API allows all sorts of network related operations:
from IP address configuration to TCP connections
• The API implementation is open source, and extensible
• The commands are sent through the serial line as (quite
verbose) series of characters.
• e.g., to connect to an AP
AT+CWJAP_CUR="room123","the psk"
• The Network Module returns a response
• a plain OK for success, more complex in case of error

54. The interface: Espressif AT interface
• The ESP-01 board comes pre-flashed with an API
accessible through an onboard UART (aka serial line)
• The API allows all sorts of network related operations:
from IP address configuration to TCP connections
• The API implementation is open source, and extensible
• The commands are sent through the serial line as (quite
verbose) series of characters.
• e.g., to connect to an AP
AT+CWJAP_CUR="room123","the psk"
• The Network Module returns a response
• a plain OK for success, more complex in case of error

55. Limits of the AT library
• Commands are verbose
• negligible impact on serial line traffic,
• heavy footprint on program size (strings need to be
buffered)
• No documented support for TSL
• No support for HTTP(S)
• many REST-ful IoT servers exist
• WebSockets look very promising for IoT applications
• The interface is complex to manage
• Buffer management
• Timeouts
• Variable response formats

56. Limits of the AT library
• Commands are verbose
• negligible impact on serial line traffic,
• heavy footprint on program size (strings need to be
buffered)
• No documented support for TSL
• No support for HTTP(S)
• many REST-ful IoT servers exist
• WebSockets look very promising for IoT applications
• The interface is complex to manage
• Buffer management
• Timeouts
• Variable response formats

57. Limits of the AT library
• Commands are verbose
• negligible impact on serial line traffic,
• heavy footprint on program size (strings need to be
buffered)
• No documented support for TSL
• No support for HTTP(S)
• many REST-ful IoT servers exist
• WebSockets look very promising for IoT applications
• The interface is complex to manage
• Buffer management
• Timeouts
• Variable response formats

58. Limits of the AT library
• Commands are verbose
• negligible impact on serial line traffic,
• heavy footprint on program size (strings need to be
buffered)
• No documented support for TSL
• No support for HTTP(S)
• many REST-ful IoT servers exist
• WebSockets look very promising for IoT applications
• The interface is complex to manage
• Buffer management
• Timeouts
• Variable response formats

59. Limits of the AT library
• Commands are verbose
• negligible impact on serial line traffic,
• heavy footprint on program size (strings need to be
buffered)
• No documented support for TSL
• No support for HTTP(S)
• many REST-ful IoT servers exist
• WebSockets look very promising for IoT applications
• The interface is complex to manage
• Buffer management
• Timeouts
• Variable response formats

60. Limits of the AT library
• Commands are verbose
• negligible impact on serial line traffic,
• heavy footprint on program size (strings need to be
buffered)
• No documented support for TSL
• No support for HTTP(S)
• many REST-ful IoT servers exist
• WebSockets look very promising for IoT applications
• The interface is complex to manage
• Buffer management
• Timeouts
• Variable response formats

61. Limits of the AT library
• Commands are verbose
• negligible impact on serial line traffic,
• heavy footprint on program size (strings need to be
buffered)
• No documented support for TSL
• No support for HTTP(S)
• many REST-ful IoT servers exist
• WebSockets look very promising for IoT applications
• The interface is complex to manage
• Buffer management
• Timeouts
• Variable response formats

62. Limits of the AT library
• Commands are verbose
• negligible impact on serial line traffic,
• heavy footprint on program size (strings need to be
buffered)
• No documented support for TSL
• No support for HTTP(S)
• many REST-ful IoT servers exist
• WebSockets look very promising for IoT applications
• The interface is complex to manage
• Buffer management
• Timeouts
• Variable response formats

63. Limits of the AT library
• Commands are verbose
• negligible impact on serial line traffic,
• heavy footprint on program size (strings need to be
buffered)
• No documented support for TSL
• No support for HTTP(S)
• many REST-ful IoT servers exist
• WebSockets look very promising for IoT applications
• The interface is complex to manage
• Buffer management
• Timeouts
• Variable response formats

64. Limits of the AT library
• Commands are verbose
• negligible impact on serial line traffic,
• heavy footprint on program size (strings need to be
buffered)
• No documented support for TSL
• No support for HTTP(S)
• many REST-ful IoT servers exist
• WebSockets look very promising for IoT applications
• The interface is complex to manage
• Buffer management
• Timeouts
• Variable response formats

65. Limits of the AT library
• Commands are verbose
• negligible impact on serial line traffic,
• heavy footprint on program size (strings need to be
buffered)
• No documented support for TSL
• No support for HTTP(S)
• many REST-ful IoT servers exist
• WebSockets look very promising for IoT applications
• The interface is complex to manage
• Buffer management
• Timeouts
• Variable response formats

66. Our purpose
• Design the simplest hardware for coupling the Nano and
the ESP-01
• Write a wrapper for the serial API interface:
• plain behavior (object oriented with side effects on global
buffers)
• transparent wrap of AT commands (library not dependent
from API details)
• Add HTTP Rest operation
TARGET
A 10 Euro thing that can interact with a
ThingSpeak server with limited programming
effort

67. Our purpose
• Design the simplest hardware for coupling the Nano and
the ESP-01
• Write a wrapper for the serial API interface:
• plain behavior (object oriented with side effects on global
buffers)
• transparent wrap of AT commands (library not dependent
from API details)
• Add HTTP Rest operation
TARGET
A 10 Euro thing that can interact with a
ThingSpeak server with limited programming
effort

68. Our purpose
• Design the simplest hardware for coupling the Nano and
the ESP-01
• Write a wrapper for the serial API interface:
• plain behavior (object oriented with side effects on global
buffers)
• transparent wrap of AT commands (library not dependent
from API details)
• Add HTTP Rest operation
TARGET
A 10 Euro thing that can interact with a
ThingSpeak server with limited programming
effort

69. Our purpose
• Design the simplest hardware for coupling the Nano and
the ESP-01
• Write a wrapper for the serial API interface:
• plain behavior (object oriented with side effects on global
buffers)
• transparent wrap of AT commands (library not dependent
from API details)
• Add HTTP Rest operation
TARGET
A 10 Euro thing that can interact with a
ThingSpeak server with limited programming
effort

70. Our purpose
• Design the simplest hardware for coupling the Nano and
the ESP-01
• Write a wrapper for the serial API interface:
• plain behavior (object oriented with side effects on global
buffers)
• transparent wrap of AT commands (library not dependent
from API details)
• Add HTTP Rest operation
TARGET
A 10 Euro thing that can interact with a
ThingSpeak server with limited programming
effort

71. Our purpose
• Design the simplest hardware for coupling the Nano and
the ESP-01
• Write a wrapper for the serial API interface:
• plain behavior (object oriented with side effects on global
buffers)
• transparent wrap of AT commands (library not dependent
from API details)
• Add HTTP Rest operation
TARGET
A 10 Euro thing that can interact with a
ThingSpeak server with limited programming
effort

72. Hardware design
The electrical layout (complicated by different technologies)

73. The library
• Use the SoftwareSerial library to interact with the ESP-01
• leave Nano UART available for software testing and
debugging
• Headers of the six functions:

74. The library
• Use the SoftwareSerial library to interact with the ESP-01
• leave Nano UART available for software testing and
debugging
• Headers of the six functions:

75. The library
• Use the SoftwareSerial library to interact with the ESP-01
• leave Nano UART available for software testing and
debugging
• Headers of the six functions:

76. The library
• Use the SoftwareSerial library to interact with the ESP-01
• leave Nano UART available for software testing and
debugging
• Headers of the six functions:
ESP(SoftwareSerial *mySerial, int baudrate); // The constructor

77. The library
• Use the SoftwareSerial library to interact with the ESP-01
• leave Nano UART available for software testing and
debugging
• Headers of the six functions:
ESP(SoftwareSerial *mySerial, int baudrate); // The constructor
void reset(); // Cleaning after problems

78. The library
• Use the SoftwareSerial library to interact with the ESP-01
• leave Nano UART available for software testing and
debugging
• Headers of the six functions:
ESP(SoftwareSerial *mySerial, int baudrate); // The constructor
void reset(); // Cleaning after problems
int state(); // Inspect current state

79. The library
• Use the SoftwareSerial library to interact with the ESP-01
• leave Nano UART available for software testing and
debugging
• Headers of the six functions:
ESP(SoftwareSerial *mySerial, int baudrate); // The constructor
void reset(); // Cleaning after problems
int state(); // Inspect current state
int atflush(); // Serial buffer cleanup

80. The library
• Use the SoftwareSerial library to interact with the ESP-01
• leave Nano UART available for software testing and
debugging
• Headers of the six functions:
ESP(SoftwareSerial *mySerial, int baudrate); // The constructor
void reset(); // Cleaning after problems
int state(); // Inspect current state
int atflush(); // Serial buffer cleanup
// atcmd: the cmd buffer contains the AT command to be executed,
// the ESP-01 response is returned in the same buffer
int atcmd(char cmd[], int size, int timeout);

81. The library
• Use the SoftwareSerial library to interact with the ESP-01
• leave Nano UART available for software testing and
debugging
• Headers of the six functions:
ESP(SoftwareSerial *mySerial, int baudrate); // The constructor
void reset(); // Cleaning after problems
int state(); // Inspect current state
int atflush(); // Serial buffer cleanup
// atcmd: the cmd buffer contains the AT command to be executed,
// the ESP-01 response is returned in the same buffer
int atcmd(char cmd[], int size, int timeout);
// session: the header and body buffers contain the request,
// the (truncated) response from the server is returned in the same buffer
int session(char header[], int headersize,
char body[], int bodysize, int timeout);

82. Using the library (setup and declaration)
// constants
#define CMDSIZE 50
#define HEADERSIZE 200
#define BODYSIZE 100
#define HOST "api.thingspeak.com"
#define PORT 80
#define PERIOD 30
// variables definitions
...
// setup
...
All debug printout on hardware serial has been removed

83. Using the library (setup and declaration)
// constants
...
// variables definitions
SoftwareSerial mySerial(2,3);
ESP esp1(&mySerial,19200);
char *cmd;
char *header;
char *body;
int v=0;
// setup
...
All debug printout on hardware serial has been removed

84. Using the library (setup and declaration)
// constants
...
// variables definitions
...
// setup
void setup() {
cmd=(char *) malloc(CMDSIZE);
header=(char *) malloc(HEADERSIZE);
body=(char *) malloc(BODYSIZE);
do {
esp1.reset();
delay(1000);
do { sprintf(cmd,"ATE0"); } while (esp1.atcmd(cmd,CMDSIZE,5) < 0); // no echo
sprintf(cmd,"AT+CWMODE_CUR=1"); esp1.atcmd(cmd,CMDSIZE,5); // station mode
sprintf(cmd,"AT+CIPMUX=0"); esp1.atcmd(cmd,CMDSIZE,5); // single TCP
sprintf(cmd,"AT+CWJAP_CUR="%s","%s"",ESSID,PASSWORD);
esp1.atcmd(cmd,CMDSIZE,20); // join
} while ( esp1.state() != 2); // until connected to the AP
delay(1000);
}
All debug printout on hardware serial has been removed

85. Using the library (the loop)
void loop() {
// prepare HTTP request
sprintf(body,"api_key=%s&field1=%d", CHANNEL_KEY,v++);
sprintf(header,"POST /update HTTP/1.1rn");
sprintf(header+strlen(header),"Host: %srn",HOST);
sprintf(header+strlen(header),"Content-Type: application/x-www-form-urlencodedrn");
sprintf(header+strlen(header),"Content-Length: %drn",strlen(body));
// connect to server
do {
sprintf(cmd,"AT+CIPSTART="TCP","%s",%d",HOST,PORT);
esp1.atcmd(cmd,CMDSIZE,10);
} while ( esp1.state() != 3 );
// prepare send operation
do {
sprintf(cmd,"AT+CIPSENDEX=%d",strlen(header)+2+strlen(body));
} while ( esp1.atcmd(cmd,CMDSIZE,5)<0 );
// send request
esp1.session(header,HEADERSIZE,body,BODYSIZE,10);
// close connection (should be already closed)
if ( esp1.state() == 3 ) {
sprintf(cmd,"AT+CIPCLOSE");
esp1.atcmd(cmd,CMDSIZE,5);
}
esp1.atflush();
}

86. Program footprint
• An MCU has a very limited storage
• libraries, buffers, constants etc.
• The demo program above is only overhead
• all that is done is to increment and send an integer
• So we have an estimate of atlib overhead (w.r.t. Arduino
Nano)
• 7604 bytes (24%) of program memory
• 681 bytes (33%) of global storage
• another 350 bytes of global storage are for buffers
• The remaining space is available for driving sensors and
actuators

87. Program footprint
• An MCU has a very limited storage
• libraries, buffers, constants etc.
• The demo program above is only overhead
• all that is done is to increment and send an integer
• So we have an estimate of atlib overhead (w.r.t. Arduino
Nano)
• 7604 bytes (24%) of program memory
• 681 bytes (33%) of global storage
• another 350 bytes of global storage are for buffers
• The remaining space is available for driving sensors and
actuators

88. Program footprint
• An MCU has a very limited storage
• libraries, buffers, constants etc.
• The demo program above is only overhead
• all that is done is to increment and send an integer
• So we have an estimate of atlib overhead (w.r.t. Arduino
Nano)
• 7604 bytes (24%) of program memory
• 681 bytes (33%) of global storage
• another 350 bytes of global storage are for buffers
• The remaining space is available for driving sensors and
actuators

89. Program footprint
• An MCU has a very limited storage
• libraries, buffers, constants etc.
• The demo program above is only overhead
• all that is done is to increment and send an integer
• So we have an estimate of atlib overhead (w.r.t. Arduino
Nano)
• 7604 bytes (24%) of program memory
• 681 bytes (33%) of global storage
• another 350 bytes of global storage are for buffers
• The remaining space is available for driving sensors and
actuators

90. Program footprint
• An MCU has a very limited storage
• libraries, buffers, constants etc.
• The demo program above is only overhead
• all that is done is to increment and send an integer
• So we have an estimate of atlib overhead (w.r.t. Arduino
Nano)
• 7604 bytes (24%) of program memory
• 681 bytes (33%) of global storage
• another 350 bytes of global storage are for buffers
• The remaining space is available for driving sensors and
actuators

91. Program footprint
• An MCU has a very limited storage
• libraries, buffers, constants etc.
• The demo program above is only overhead
• all that is done is to increment and send an integer
• So we have an estimate of atlib overhead (w.r.t. Arduino
Nano)
• 7604 bytes (24%) of program memory
• 681 bytes (33%) of global storage
• another 350 bytes of global storage are for buffers
• The remaining space is available for driving sensors and
actuators

92. Program footprint
• An MCU has a very limited storage
• libraries, buffers, constants etc.
• The demo program above is only overhead
• all that is done is to increment and send an integer
• So we have an estimate of atlib overhead (w.r.t. Arduino
Nano)
• 7604 bytes (24%) of program memory
• 681 bytes (33%) of global storage
• another 350 bytes of global storage are for buffers
• The remaining space is available for driving sensors and
actuators

93. Program footprint
• An MCU has a very limited storage
• libraries, buffers, constants etc.
• The demo program above is only overhead
• all that is done is to increment and send an integer
• So we have an estimate of atlib overhead (w.r.t. Arduino
Nano)
• 7604 bytes (24%) of program memory
• 681 bytes (33%) of global storage
• another 350 bytes of global storage are for buffers
• The remaining space is available for driving sensors and
actuators

94. Program footprint
• An MCU has a very limited storage
• libraries, buffers, constants etc.
• The demo program above is only overhead
• all that is done is to increment and send an integer
• So we have an estimate of atlib overhead (w.r.t. Arduino
Nano)
• 7604 bytes (24%) of program memory
• 681 bytes (33%) of global storage
• another 350 bytes of global storage are for buffers
• The remaining space is available for driving sensors and
actuators

95. What I did that others do not
• Use the AT library
• mostly used for demo purposes
• with UART pins attached to PC tty
• unconfortable to use as an API
• many prefer to reflash standalone applications
• exciting hack, but limited possibilities (3 GPIO pins)
• Use dynamic memory allocation
• may be dangerous, because of heap fragmentation
• with some care may give extra possibilities
• the usual advice is do not malloc()

96. What I did that others do not
• Use the AT library
• mostly used for demo purposes
• with UART pins attached to PC tty
• unconfortable to use as an API
• many prefer to reflash standalone applications
• exciting hack, but limited possibilities (3 GPIO pins)
• Use dynamic memory allocation
• may be dangerous, because of heap fragmentation
• with some care may give extra possibilities
• the usual advice is do not malloc()

97. What I did that others do not
• Use the AT library
• mostly used for demo purposes
• with UART pins attached to PC tty
• unconfortable to use as an API
• many prefer to reflash standalone applications
• exciting hack, but limited possibilities (3 GPIO pins)
• Use dynamic memory allocation
• may be dangerous, because of heap fragmentation
• with some care may give extra possibilities
• the usual advice is do not malloc()

98. What I did that others do not
• Use the AT library
• mostly used for demo purposes
• with UART pins attached to PC tty
• unconfortable to use as an API
• many prefer to reflash standalone applications
• exciting hack, but limited possibilities (3 GPIO pins)
• Use dynamic memory allocation
• may be dangerous, because of heap fragmentation
• with some care may give extra possibilities
• the usual advice is do not malloc()

99. What I did that others do not
• Use the AT library
• mostly used for demo purposes
• with UART pins attached to PC tty
• unconfortable to use as an API
• many prefer to reflash standalone applications
• exciting hack, but limited possibilities (3 GPIO pins)
• Use dynamic memory allocation
• may be dangerous, because of heap fragmentation
• with some care may give extra possibilities
• the usual advice is do not malloc()

100. What I did that others do not
• Use the AT library
• mostly used for demo purposes
• with UART pins attached to PC tty
• unconfortable to use as an API
• many prefer to reflash standalone applications
• exciting hack, but limited possibilities (3 GPIO pins)
• Use dynamic memory allocation
• may be dangerous, because of heap fragmentation
• with some care may give extra possibilities
• the usual advice is do not malloc()

101. What I did that others do not
• Use the AT library
• mostly used for demo purposes
• with UART pins attached to PC tty
• unconfortable to use as an API
• many prefer to reflash standalone applications
• exciting hack, but limited possibilities (3 GPIO pins)
• Use dynamic memory allocation
• may be dangerous, because of heap fragmentation
• with some care may give extra possibilities
• the usual advice is do not malloc()

102. What I did that others do not
• Use the AT library
• mostly used for demo purposes
• with UART pins attached to PC tty
• unconfortable to use as an API
• many prefer to reflash standalone applications
• exciting hack, but limited possibilities (3 GPIO pins)
• Use dynamic memory allocation
• may be dangerous, because of heap fragmentation
• with some care may give extra possibilities
• the usual advice is do not malloc()

103. Up and running...

104. Experimental results
• The prototype consumes around 150mA at 5V, and can be
powered across the same USB port used for programming
• I ran one 40 hours experiment to check the stability of the
prototype
• I used the demo code shown above to post an incremental
value to the public ThingSpeak server
RESULTS
• The program resiliency to networking problems is poor,
• easy to fix, but requires additional code
• with a stable WiFi the operation is stable
• However I noticed many "Bad Request" responses (with
loss of the sample value)

105. Experimental results
• The prototype consumes around 150mA at 5V, and can be
powered across the same USB port used for programming
• I ran one 40 hours experiment to check the stability of the
prototype
• I used the demo code shown above to post an incremental
value to the public ThingSpeak server
RESULTS
• The program resiliency to networking problems is poor,
• easy to fix, but requires additional code
• with a stable WiFi the operation is stable
• However I noticed many "Bad Request" responses (with
loss of the sample value)

106. Experimental results
• The prototype consumes around 150mA at 5V, and can be
powered across the same USB port used for programming
• I ran one 40 hours experiment to check the stability of the
prototype
• I used the demo code shown above to post an incremental
value to the public ThingSpeak server
RESULTS
• The program resiliency to networking problems is poor,
• easy to fix, but requires additional code
• with a stable WiFi the operation is stable
• However I noticed many "Bad Request" responses (with
loss of the sample value)

107. Experimental results
• The prototype consumes around 150mA at 5V, and can be
powered across the same USB port used for programming
• I ran one 40 hours experiment to check the stability of the
prototype
• I used the demo code shown above to post an incremental
value to the public ThingSpeak server
RESULTS
• The program resiliency to networking problems is poor,
• easy to fix, but requires additional code
• with a stable WiFi the operation is stable
• However I noticed many "Bad Request" responses (with
loss of the sample value)

108. Experimental results
• The prototype consumes around 150mA at 5V, and can be
powered across the same USB port used for programming
• I ran one 40 hours experiment to check the stability of the
prototype
• I used the demo code shown above to post an incremental
value to the public ThingSpeak server
RESULTS
• The program resiliency to networking problems is poor,
• easy to fix, but requires additional code
• with a stable WiFi the operation is stable
• However I noticed many "Bad Request" responses (with
loss of the sample value)

109. Experimental results
• The prototype consumes around 150mA at 5V, and can be
powered across the same USB port used for programming
• I ran one 40 hours experiment to check the stability of the
prototype
• I used the demo code shown above to post an incremental
value to the public ThingSpeak server
RESULTS
• The program resiliency to networking problems is poor,
• easy to fix, but requires additional code
• with a stable WiFi the operation is stable
• However I noticed many "Bad Request" responses (with
loss of the sample value)

110. Experimental results
• The prototype consumes around 150mA at 5V, and can be
powered across the same USB port used for programming
• I ran one 40 hours experiment to check the stability of the
prototype
• I used the demo code shown above to post an incremental
value to the public ThingSpeak server
RESULTS
• The program resiliency to networking problems is poor,
• easy to fix, but requires additional code
• with a stable WiFi the operation is stable
• However I noticed many "Bad Request" responses (with
loss of the sample value)

111. Experimental results
• The prototype consumes around 150mA at 5V, and can be
powered across the same USB port used for programming
• I ran one 40 hours experiment to check the stability of the
prototype
• I used the demo code shown above to post an incremental
value to the public ThingSpeak server
RESULTS
• The program resiliency to networking problems is poor,
• easy to fix, but requires additional code
• with a stable WiFi the operation is stable
• However I noticed many "Bad Request" responses (with
loss of the sample value)

112. Bad Responses
• I counted the number of "Bad Responses" during the
experiment
00:00:00
06:00:00
12:00:00
18:00:00
00:00:00
06:00:00
12:00:00
18:00:00
00:00:00
0
100
200
300
400
• I noticed a regularity in the number of events, since they
are concentrated (synchronized with USA working hours)
• I conclude that the sensor is not responsible

113. Bad Responses
• I counted the number of "Bad Responses" during the
experiment
00:00:00
06:00:00
12:00:00
18:00:00
00:00:00
06:00:00
12:00:00
18:00:00
00:00:00
0
100
200
300
400
• I noticed a regularity in the number of events, since they
are concentrated (synchronized with USA working hours)
• I conclude that the sensor is not responsible

114. Bad Responses
• I counted the number of "Bad Responses" during the
experiment
00:00:00
06:00:00
12:00:00
18:00:00
00:00:00
06:00:00
12:00:00
18:00:00
00:00:00
0
100
200
300
400
• I noticed a regularity in the number of events, since they
are concentrated (synchronized with USA working hours)
• I conclude that the sensor is not responsible

115. Conclusions
• We have shown how to make a small sensor with
• simple, reproducible design
git clone http://bitbucket.org/augusto_ciuffoletti/wifinano
• limited programming effort using atlib
git clone http://bitbucket.org/augusto_ciuffoletti/atlib
• low cost
• Arduino programming environment
• The pros and cons
• stable operation with Bad Requests
• power consumption not compatible with battery operation

116. Conclusions
• We have shown how to make a small sensor with
• simple, reproducible design
git clone http://bitbucket.org/augusto_ciuffoletti/wifinano
• limited programming effort using atlib
git clone http://bitbucket.org/augusto_ciuffoletti/atlib
• low cost
• Arduino programming environment
• The pros and cons
• stable operation with Bad Requests
• power consumption not compatible with battery operation

117. Conclusions
• We have shown how to make a small sensor with
• simple, reproducible design
git clone http://bitbucket.org/augusto_ciuffoletti/wifinano
• limited programming effort using atlib
git clone http://bitbucket.org/augusto_ciuffoletti/atlib
• low cost
• Arduino programming environment
• The pros and cons
• stable operation with Bad Requests
• power consumption not compatible with battery operation

118. Conclusions
• We have shown how to make a small sensor with
• simple, reproducible design
git clone http://bitbucket.org/augusto_ciuffoletti/wifinano
• limited programming effort using atlib
git clone http://bitbucket.org/augusto_ciuffoletti/atlib
• low cost
• Arduino programming environment
• The pros and cons
• stable operation with Bad Requests
• power consumption not compatible with battery operation

119. Conclusions
• We have shown how to make a small sensor with
• simple, reproducible design
git clone http://bitbucket.org/augusto_ciuffoletti/wifinano
• limited programming effort using atlib
git clone http://bitbucket.org/augusto_ciuffoletti/atlib
• low cost
• Arduino programming environment
• The pros and cons
• stable operation with Bad Requests
• power consumption not compatible with battery operation

120. Conclusions
• We have shown how to make a small sensor with
• simple, reproducible design
git clone http://bitbucket.org/augusto_ciuffoletti/wifinano
• limited programming effort using atlib
git clone http://bitbucket.org/augusto_ciuffoletti/atlib
• low cost
• Arduino programming environment
• The pros and cons
• stable operation with Bad Requests
• power consumption not compatible with battery operation

121. Conclusions
• We have shown how to make a small sensor with
• simple, reproducible design
git clone http://bitbucket.org/augusto_ciuffoletti/wifinano
• limited programming effort using atlib
git clone http://bitbucket.org/augusto_ciuffoletti/atlib
• low cost
• Arduino programming environment
• The pros and cons
• stable operation with Bad Requests
• power consumption not compatible with battery operation

122. Conclusions
• We have shown how to make a small sensor with
• simple, reproducible design
git clone http://bitbucket.org/augusto_ciuffoletti/wifinano
• limited programming effort using atlib
git clone http://bitbucket.org/augusto_ciuffoletti/atlib
• low cost
• Arduino programming environment
• The pros and cons
• stable operation with Bad Requests
• power consumption not compatible with battery operation

123. Conclusions
• We have shown how to make a small sensor with
• simple, reproducible design
git clone http://bitbucket.org/augusto_ciuffoletti/wifinano
• limited programming effort using atlib
git clone http://bitbucket.org/augusto_ciuffoletti/atlib
• low cost
• Arduino programming environment
• The pros and cons
• stable operation with Bad Requests
• power consumption not compatible with battery operation
not the end of the story

124. V2.0
• Hardware and library re-designed:
• Mini/3.3V instead of Nano
• Hardware is simpler and more compact
• 50% storage footprint, comparable program footprint
• More robust (no Bad Requests?!)
• HTTP response parsing
• Power saving (48hrs operation with 3 AAA NiMH)
• https://bitbucket.org/augusto_ciuffoletti/wifimini/