Web API and MQTT
Web API and MQTT
• Requires a 24/7 dedicated operator on site for continuously monitoring the system
NEW REQUIREMENTS
• The clients/users need to monitor the real time and historical values provided by the field
devices not just from the centralised system but also from the other devices irrespective
of their location.
• The client can perform:
1. Building analytics
2. Automate the set point adjustments
3. Energy forecasting etc.
Proposed Solutions
• Solution1: Restful Web Services
• The user can access the real time data on
the Desigo CC via Restful web service
interface
Solution 2:
MQTT
The data can be transferred to the
cloud by the ConnectX300 and
other 3rd party connectors (AWS
web) and from cloud to users on
their smart phones via App which
is connected to the MQTT broker
(hosted by the cloud) via internet.
RESTFUL WEB SERVICE
• REST is used to build Web services that are lightweight, maintainable, and scalable in
nature.
• The underlying protocol for REST is HTTP
• REST is a way to access resources which lie in a particular environment
RESTFUL WEB SERVICE
• REST ARCHITECTURE:
REST ARCHITECTURE
• The architecture is :
a. client/server
b. Stateless
c. supports caching
HTTP VERBS
WORKING OF REST API
• I created a Restful web service for the Student Registration for an Institution consisting of
the details of the Students.
• After hosting the web server and running the web service application, the data is
available on the server which can be accessed locally from the web server.
TESTING USING POSTMAN
• Postman is an interactive and automatic tool for verifying the APIs of your
project. Postman is a Google Chrome app for interacting with HTTP APIs. It
presents you with a friendly GUI for constructing requests and reading
response.
HTTP- GET
• End point: https://localhost:44395
• Resource path: /api/StudentRetrive
HTTP- GET
• End point: https://localhost:44395
• Resource path:
/api/StudentRetrive
HTTP- POST
• Endpoint: https://localhost:44395
• Resource path:
/api/StudentRegistration
HTTP- PUT
• Endpoint: https://localhost:44395
• Resource path:
/api/StudentUpdate
HTTP- DELETE
• Endpoint: https://localhost:44395
• Resource path:
/api/StudentDelete/student/remov
e/registrationNumber
MQTT (Message queuing telemetry
transport protocol)
• It’s a lightweight protocol. So, it’s easy to implement in software and fast in
data transmission.
• It’s based on a messaging technique .
• It’s real time! That’s is specifically what makes it perfect for IoT
applications
ARCHITECURE
• MQTT server is called a broker and
the clients are simply the connected
devices. So:
• • When a device (a client) wants to
send data to the broker, we call this
operation a “publish”.
• • When a device (a client) wants to
receive data from the broker, we call
this operation a “subscribe”.
MQTT Client and MQTT Broker
MQTT PUBLISH
• Each publish and subscribe message contains the topic which is used by
broker for filtering of messages. The PUBLISH message contains the
payload along with the topic
MQTT SUBSCRIBE
• The SUBSCRIBE message contains the list of topic names in which the
subscriber is interested in. Hence, the subscriber can subscribe to one or
more topics of interest
WORKING
Conclusion
• I successfully learnt and implemented the REST API web service and the MQTT protocol
as a solution to new requirements in the market for accessing the data of the BMS or any
system from any remote location irrespective of the centralised workstation.
• The clients thereby can access the data locally with help of the software like Desigo CC
from the servers and can also access the data from the cloud via MQTT apps connected
with the broker hosted by the cloud where the data is sent to the cloud with the help of a
hardware connector.