Greetings YouTubers!
Here is the guy with a Swiss accent again.
The ESP8266 Is a great product.
It adds internet connectivity to a quite fast processor,
and with the newer boards like the ESP 12 we also have plenty of memory and pins available.
And with the Arduino IDE we have a well known programming environment and lots of libraries.
But what is lacking for a true internet of things platform?
We need a software framework with the following characteristics:
Simple connections to Web services;
IOT devices have to be connected to the world;
Simple interface to smartphone;
IOT devices have to be simple and often without keyboard or display.
This is why they have to be able to get the information
for Wi-Fi credentials and other parameters directly from the smartphone.
They need a sleep mode to extend battery life.
We all know that, ESP8266 need lots of Energy and cannot work long time with batteries.
New software has to be loaded remotely over-the-air.
If such devices are deployed
they physically cannot be reached anymore because they are built in or have no programming connectors.
Future users would never want to deal with FTDI or other programming devices.
I start now the building of such a software platform and will show you my progress
Today I start with the first point
And I hope I will be able to reach the last point in the next weeks
To prove the concept I decided to build a device which connects to an official web service in Switzerland,
which announced is all departures of public transportation.
It then compares the actual time with the departure time and
acoustically warns the traveler if the vehicle arrives.
This is very useful because it works completely
automatic and also takes into account the time the traveler needs to walk or run to the next station.
And it takes also into account if the vehicle is delayed, if the web service provides real-time information.
Of course you could get this information using an app on your smartphone
But this is very inconvenient
because it needs many steps till you get the result,
and you have to repeat it several times to get the newest information.
My device will stand in our kitchen and will be started if I decide to take the next bus.
To build the device I started with understanding web services.
in contrary to Normal HTML pages,
Web services provide information in machine readable form. Popular formats used by these services are
XML and JSON.
With IOT devices we have to preserve memory space.
This is why I prefer JSON over XML interfaces.
Therefore in this video, I will concentrate on this technology.
JSON or Javascript Object Notation is an open standard format
that uses human readable text to transmit data objects in a standardized format.
JSON messages are provided by so-called
RESTful Services which communicate over
HTTP and use verbs like
get, post, put, delete, etc.
Because my IOT device only wants to read information,
we will concentrate on the GET work.
As a first step we have to find the web service which provides us with the needed information.
This is typically done by a Google search or by going to the site
https://www.programmableweb.com/
Let's assume you found an API which delivers the information you need.
Then it is good to read its description to understand the syntax of the call and
If you know the syntax the best next step is to try it out manually.
To do this I installed an app from the Google Chrome web store.
You find the link below in the comments.
The syntax of the Swiss Transportation Api is on this slide.
It consists of three parts:
an address,
the two cities where the journey starts and ends,
and optional a statement to restrict the number of fields which are returned from the web service.
This part is very important because it reduces the effort to find the right information
on our small IOT device.
Let's test this service.
As already said, I need the GET message.
I write the call in the respective line and hit send.
I get now three parts of information.
First I get a status message
and second I get the header information.
The third part is the information I am interested in.
It displays the next departure from Basel to Zurich.
This message has only 67 bytes.
if I switch to raw I see the string which I have to decode later in my program
on my ESP8266.
But let's play a little with the api. If I remove the optional field restriction,
the message is much bigger.
It has now
1764 bytes, and it would be nearly impossible to handle it on a small IOT device.
Here we learn an important lesson.
Keep the big work in the internet and not on your small device
The return message is exactly as you see it here.
The first line will be the date line and the last line will be the connections line.
Our program just has to check if the status of the message is okay.
It is status 200; and
then read through all lines to find the sub-string "departure".
The numbers of desire are then in a constant distance from this keyword.
Hours minutes and seconds of the next departure.
Let's now look into the code.
We have [to] read and decode the response.
Bigger computers usually read the whole message in one block and decode or parse it afterwards.
For small devices we read line after line and search for the keyword "departure",
here passed to the subroutine as the variable lookupString.
If we found it in a particular line we extract the three variables:
hours, minutes, and seconds, using string arithmetic.
At the end we can return the next departure time to the calling code
But how is the request message looking?
It consists of three lines.
The first is similar to the one we used in the manual scenario, but without the host name.
The second line adds the host information, and the third
instructs the server if we want to keep the connection alive or close it after the request.
The respective program code is straightforward.
Do not forget the carriage return and line feed characters.
Here I want to call your attention to a particularity of the ESP8266.
The WiFi traffic is handled in parallel to your normal program execution and you do not feel it
because the ESP firmware handles it without
intervention by stealing some time of your program.
if you do loops this stealing can be prohibited and the ESP crashes.
If this happens you have to enhance waiting loops with a short delay.
Never wait in a while (1 == 1) loop. The ESP will crash immediately and produce a dump.
Only if you enhance your loop with a small delay(1), your ESP will run without any problems.
In this video we were able to discover a web service providing a RESTful API.
Check it out manually.
Program a call from the ESP8266.
and decode the JSON formatted messages.
Now we are ready to move on with our IOT framework.
In the next video I will show you how to connect your ESP to your smartphone or PC to enter the needed
credentials for the Wi-Fi Network and other data.
Here you see the current status.
Every seconds the ESP8266
queries the web service and starts to peep if the time to leave for the bus arrives.
I hope this video was useful or at least interesting for you.
Bye!