In the previous tutorial, FTP protocol and file transfer over it between a Client and Server was discussed. The FTP protocol can really useful in many IoT applications. Many IOT devices are installed in places like nuclear plant, electrical grids and other industrial setups where these types of devices can get some bugs and need application software updates to fix them. On standard IoT protocols like MQTT, CoAP, etc, it is hard to update and reinstall application software because most of the IoT protocols are designed for IoT communication between devices and network but not for tasks like application updates.

File Transfer Protocol (FTP) is a standard protocol for transferring files between a client and server over an internet network. The FTP protocol was written by Abhay Bhushan (IIT Kanpur) in 1971. In 1980, a TCP/IP version of the protocol as RFC 765 was introduced which became the de facto standard worldwide. in 1998, the protocol stack was updated for IPv6 support. Within this protocol, the security features were enabled by a  TLS/SSL layers called FTP Secure (FTPS). A new secured version of FTP is also widely used called SSH File transfer protocol (SFTP). The SFTP is quite different protocol than the traditional FTPS. 

In the previous tutorial, it was seen how FTP protocol can be used to update application software on an IoT device. However, FTP protocol has some security concerns as it is vulnerable to several kind of attacks like Brute force attack, FTP bounce attack, Packet capture, Port stealing (guessing the next open port and usurping a legitimate connection), Spoofing attack, Username enumeration etc. Therefore, secure variants of FTP protocols were developed. SSH File Transfer Protocol is one of the secure variants of the FTP protocol.   

Nowadays, most of the hotels and restaurants take online orders of food. Many hotels and restaurants either facilitate pre-ordering or even render delivery services in the local areas. In this project, an Hotel Order Management System is designed where a customer can pre-order food items using a mobile app and a Raspberry Pi based Server manages to cater menu items and book orders.

Emails are the most commonly used communication in the today’s digital era. The emails can also be way of communication with IoT devices. The emails can be used to pass commands to IoT devices. The devices can then be programmed and configured to read emails received and act accordingly. There can be interesting applications built this way. For receiving emails, the IoT devices need to configure as an Email Client. They can retrieve emails only over a standard email protocol. Internet Message Access Protocol (IMAP) is one of the standard email message protocols.  

In the previous tutorial, it was mentioned that IMAP protocol is a standard email protocol which is used to store email messages and retrieve them. It was also mentioned that IMAP protocol can be used in IoT applications where commands can be passed to IoT devices by emails. This can be really helpful in certain situations like when security might be the main concern. Also, emails can be sent on any network without any special application or permissions. The IoT devices can receive emails as email clients where they can read emails and process information contained in them.

Application layer refers to OSI Level 5, 6 and 7. It is application layer in the TCP-IP model. In IOT architecture, this layer lies above the service discovery layer. It is highest layer in the architecture extending from the client ends. It is the interface between the end devices and the network. This layer is implemented through a dedicated application at the device end. Like for a computer, application layer is implemented by the browser. It is the browser which implements application layer protocols like HTTP, HTTPS, SMTP and FTP. Same way, there are application layer protocols specified in context to IOT as well.

In the previous tutorial, installation and configuration of RSMB Broker for MQTT-SN protocol implementation was discussed. In this tutorial, two devices will be setup to communicate over MQTT-SN protocol using RSMB Broker. One of these devices will be configured as MQTT-SN Client and other as the MQTT-SN Server.  The MQTT-SN needs a gateway when WSN (Wireless Sensor Network) devices want to send data to MQTT server which run on TCP/IP protocol or want to communicate with MQTT clients.

Transport Layer Security (TLS) is a security protocol which uses symmetric cryptography to secure data. In this tutorial, Client-Server communication will be setup using TLS Protocol so that data can be securely exchanged between them. The Mosquitto broker is used to provide TLS security. The Mosquitto broker uses 8883 port as an encrypted transmission port to securely exchange the data between clients. 

In the previous tutorial, the basics of Wireless Sensor Networks were discussed. It was mentioned that WSN can utilize many wireless standards and protocols to enable sensor communication with a cloud or server. It was also mentioned that wireless sensors communicate to a cloud or server with the help of a Gateway which performs protocol conversion for the wireless network. Zigbee is one of the standard and protocol which is generally used for WSN deployed in industrial applications.  

In the previous tutorial, Zigbee technology and its application in building Wireless Sensor Networks was discussed. In this tutorial, learn to perform simple Client to Client Communication over Zigbee Protocol. There will be two Xbee modules taken and will be configured to communicate data with each other over the air. The Xbee devices communicate with each other wirelessly over the air. They do not have any microcontroller or processor in themselves, so they cannot manage the received or sent data.

In the previous tutorial, communication between two PCs was setup over Zigbee Protocol using Xbee modules and XCTU software. In this tutorial, two Xbee module based IoT devices will be designed and configured to communicate with each other over Zigbee protocol. One of these devices in the Zigbee network will be a Coordinator device and the other will be a Router device. The coordinator device will control LED interfaced at the Router device. 

In the previous tutorial, IoT communication between two devices over Zigbee protocol was demonstrated using two Xbee modules. The two modules were communicating with each other automatically without any human intervention. The two modules were also operating in transparent mode in the previous project.  In this project, an LED light controller is designed where one device controls the LED interfaced at other by communicating data in API mode. In this tutorial, two Xbee module based IoT devices will be designed and configured to communicate with each other over Zigbee protocol

The Internet of Things have specific network requirements. The traditional TCP/IP protocols usually do not fit to these requirements. That is why there are many protocols designed especially to cater the requirements of IoT applications. Within the IoT domain, sensor networks are one of the applications which are designed using constraint devices and are characterized by limited network bandwidth. A variant of MQTT protocol has been designed for these networks which is called MQTT-SN (MQTT for Sensor Networks).  

In the previous tutorial, basics of MQTT-SN protocol were discussed. It was mentioned that an MQTT-SN Gateway needs to communicate with an MQTT-SN Broker. The MQTT-SN brokers are little different from MQTT Brokers. Really Small Message Broker is one of the popular MQTT-SN brokers. Really small message broker (aka RSMB) is a light-weight, low-overhead messaging MQ telemetry transport broker (version 3 or 3.1) or MQTT-SN broker. It is a pub/sub based broker. It allows messaging to and from tiny devices such as sensors and actuators over networks that are constrained in terms of low bandwidth, limited processing capabilities and varying reliability. 

In the previous tutorial, features, advantages and limitations of TCP/IP Protocol were discussed. Though, TCP/IP is not best suited for IoT applications due to packet overheads, still being the most common protocol stack on internet, it offer ubiquitous connectivity. An IoT device can be made to communicate with a cloud or server using TCP/IP protocol without any hassle of network programming and network administration. In this project, an IoT device will be designed that could transmit sensor data to ThingSpeak Platform using the TCP/IP protocol.  

The TCP/IP protocol despite being most common protocol stack on internet is not much suitable for IoT applications due to large overhead. It is more suitable for applications where reliable delivery of data with high bandwidth in hand is required. The IoT applications generally have limited bandwidth and need swift transfer of small data packets. In such case, the UDP/IP stack is far better than TCP/IP.The User Datagram Protocol (UDP) is the simplest transportation layer protocol used primarily for establishing low-latency and loss tolerating connections between applications on the communication network.

In the previous tutorial, advantages of UDP protocol over TCP/IP in IoT applications were discussed. The UDP protocol has a small overhead of 8 bytes which makes it more suitable for use in the Internet of Things. In this project, the application of UDP protocol in IoT will be demonstrated. In this project, an ESP8266 Wi-Fi modem will be configured as UDP server and a laptop will be used as UDP Client.  

The IoT devices have very limited resources like they have embedded processors or controllers, limited RAM and ROM and they need to operate on battery without replacement for weeks, months or even years. Even they have to communicate data swiftly though small in amount but on limited network bandwidth.  

In the previous tutorial, advantages of CoAP protocol over TCP/IP and UDP protocols in IoT applications were discussed. The CoAP protocol is specially designed for constraint devices and networks. In this project, the application of CoAP protocol in IoT will be demonstrated. In this project, an ESP8266 Wi-Fi modem will be configured as CoAP server and a laptop will be used as CoAP Client. Both Client and server will be co-located communicating through same Wi-Fi router so, the ESP board will act as a local server. The CoAP Client could send data to the server on a particular port with the help of browser add-on – Copper (Cu) CoAP user-agent. In fact, the Copper (Cu) itself will act as CoAP Client.