IEEE Consumer Electronics Magazine - November/December 2021 - 71

external service within the smart home system,
we introduce the concept of the virtual device.
The virtual device is registered with the smart
home hub, just like physical devices typically
are. It maps the functionality of the external platform
to the services and properties, which are
exposed to the user of the smart home system.
By representing the service as the device within
the system, the control layer can data provided
by the service can easily be used in home automation
rules created by the user.
When integrating with the external IoT soluFigure
2. Smart home system and external
extensions.
together, due to the unified internal representation
of their capabilities.
Remote control of the smart home system is
enabled by the smart home cloud, which serves
as a proxy for the messages exchanged by the
user applications and the smart home hubs. The
hubs, cloud, and user applications communicate
with each other using Message Queuing Telemetry
Transport (MQTT) protocol over TLS.
The integration with the external services and
device platforms will be performed on the cloud
level, by creating the adapters, i.e., translators
between the internal smart home system MQTT
API and the APIs exposed by the partner services.
Depending on the partner API, various authorization
mechanisms may apply, and the service
adapter should handle them appropriately.
To enable the full integration with external
services, their functionalities have to be mapped
to the internal system representation of a
device. For example, some of the services resemble
the physical sensors, as they cannot be controlled
by the user. Such are the services
providing information about the local traffic or
weather conditions, or utility services informing
the user about the electricity, gas or water consumption.
On the other side, there are services
that require the bidirectional exchange of information,
and allow users to order something (be
it food delivery, house cleaning, or the desired
video stream). These services resemble the
physical actuators. Therefore, to represent the
November/December 2021
tions, such as multimedia, lighting, or sensory
device platforms, the goal is to allow as much control
over the device as possible using the local network
connection. This will enable normal system
operation even in the cases of Internet connectivity
loss. However, there may be device functionalities
that are not suitable for low bandwidth IoT
network traffic, or which are not exposed by the
devicemanufacturer. For example, camera streaming
cannot be performed using wireless IoT protocols
such as Zigbee or Bluetooth LowEnergy. Also,
some of the device features may be implemented
in a custom, proprietary way, and only be accessible
through the cloud API exposed by the device
manufacturer. In this case, the physical device
twin is created within the smart home cloud, to
serve as a bridge between the smart home representation
of the device, and the external device
platform. All devices of the same type (e.g., cameras,
sensors, lights) will be represented within
the system in the same way, regardless of their
manufacturer and the API used to control them.
During the process of device discovery and
inclusion into the smart home system, the platform
adapter in the smart home cloud creates a
device twin for every physical device that is
added. The device twin contains all the information
necessary to control and monitor the device
through the external API, such as the identification
of the device in the external system, the list
of its functionalities and relevant settings, as
well as authorization tokens if required.
WEATHER SERVICE INTEGRATION
To demonstrate the proposed concept of virtual
device, we integrate the weather forecast
service into to the system.14 Due to the nature of
71
IEEE Consumer Electronics Magazine - November/December 2021

Table of Contents for the Digital Edition of IEEE Consumer Electronics Magazine - November/December 2021
