Lite4More: A Hardware and Software Solution to Improve the
Commissioning of Lighting Infrastructures
Diogo Correia
1 a
, Jo
ao Gomes
, Carlos Resende
1 b
, Filipe Sousa
1 c
, Jorge Filipe
Carlos Silva
and Antonio Sousa
Fraunhofer Portugal AICOS (FhP-AICOS), Rua Alfredo Allen 455, Porto, Portugal
Tridonic Portugal, Rotunda Eng. Edgar Cardoso 23, Vila Nova de Gaia, Portugal
IoT Provisioning, Smart Lighting, BLE Mesh.
The Internet of Things is being integrated into many aspects of our daily lives to optimise it. Smart building, in
particular, smart lighting, is one of the aspects that can benefit power consumption and user well-being. How-
ever, such systems’ installation and maintenance costs are hampering their dissemination. The commissioning
of lighting infrastructures is a human and time-consuming task whose complexity increases with the size of the
building under installation. The manual discovery of the luminaires in the building and their association with
their digital counterparts is one of the main reasons for this, and the current state-of-the-art solutions do not
properly address it. In this paper, we propose Lite4More, a modular hardware and software solution that can
be easily adapted to different installation requirements and address the lighting infrastructure commissioning
issue by automating it. Lite4More takes advantage of the Cloud, Edge and IoT device layers to, through the
use of AI algorithms, guide the technician along the commissioning procedure, reducing on-site work and
aiming to reduce the total time for commissioning.
Internet of Things (IoT) solutions are disseminat-
ing and optimizing several aspects of our daily lives.
In 2020, 11.7 billion IoT device connections were
registered, and it is estimated a 13.5% growth un-
til 2025 (Lueth, line). Such dissemination brings a
lot of challenges, namely in the commissioning of
such devices. Currently, these devices are delivered to
customers with pre-installed and pre-configured soft-
ware, and updating and configuring them is usually a
manual and local procedure. The overhead of such a
procedure increases with the (high) number of nodes
present in IoT networks, so it is mandatory to auto-
mate it (Dautov and Song, 2020).
Focusing on the application of IoT on smart build-
ings, Xu et al. (Xu et al., 2019) identify the high in-
stallation and maintenance costs as one of the main
blockers to the dissemination of smart building de-
ployments. In the case of smart lighting, the main
hurdle in installing and maintaining a large lighting
infrastructure is the time and repetitive strain required
to commission. This procedure can take up to several
weeks and, in some cases, months, depending on the
size of the installation.
The typical commissioning process consists of
checking each digital address space one by one and
activating the corresponding luminaire. Then, for
each iteration, search the activated luminaires on the
physical infrastructure and attribute an easy-to-read
name to its address and location on the computing
system. The commissioning time increases in a non-
linear way with the size of the infrastructure because
two consecutive luminaires in the commissioning pro-
cedure may be located too far apart.
The industry and academic community are in-
vesting in smart lighting solutions, taking into con-
sideration its benefits in terms of energy consump-
tion (Hughes and Dhannu, 2008; Neida et al., 2001)
and users’ well-being (So and Leung, 1998; Nagy
et al., 2015). However, the proposed solutions do
not address the commissioning issues because they
assume that the lighting infrastructure already exists
and is fully commissioned.
Correia, D., Gomes, J., Resende, C., Sousa, F., Filipe, J., Silva, C. and Sousa, A.
Lite4More: A Hardware and Software Solution to Improve the Commissioning of Lighting Infrastructures.
DOI: 10.5220/0012691000003705
Paper published under CC license (CC BY-NC-ND 4.0)
In Proceedings of the 9th International Conference on Internet of Things, Big Data and Security (IoTBDS 2024), pages 252-259
ISBN: 978-989-758-699-6; ISSN: 2184-4976
Proceedings Copyright © 2024 by SCITEPRESS Science and Technology Publications, Lda.
Additionally, the majority of the smart lighting so-
lutions support a specific set of communication pro-
tocols or devices, so they do not address the ven-
dor lock-in issue and the high heterogeneity in terms
of communication protocols available in smart light-
ing (Chinchero et al., 2020).
With this in mind, we propose Lite4More, a hard-
ware and software solution that addresses these is-
sues. Lite4More spans from the IoT device, i.e., the
luminaires, to the Cloud, where a set of algorithms
automate the localization and commissioning of the
lighting infrastructures, minimizing human interven-
tion on-site. As this is a work in progress, Lite4More
currently supports Bluetooth Low Energy (BLE) and
Digital Illumination Interface Alliance (DALI). Nev-
ertheless, its implementation is based on microser-
vices, which can easily be extended to other commu-
nication protocols (e.g., Zigbee, Thread, Matter) and
installation requirements (e.g., the integration with
other smart building infrastructures, such as heating,
security, and access control systems).
The remainder of this paper is organized as fol-
lows. Section 2 reviews the literature about smart
lighting and its commissioning procedures. Section 3
presents the proposed solution and the lessons learned
so far. Section 4 concludes the paper and outlines fu-
ture steps.
The academic and industrial communities are propos-
ing smart lighting solutions targeting improvements
in energy usage and users’ well-being. However, only
a few identify the commissioning problem of such
systems, and almost none address it. This section
overviews such efforts.
(Xu et al., 2019) provide a framework for design-
ing solutions for smart buildings and applying it to
a smart emergency lighting system. Despite identi-
fying the high overhead in installing and maintaining
IoT solutions in smart buildings, the authors do not
try to automate and minimize such overhead. Instead,
they state that the business models enabled by the pro-
posed framework will deal with such a process. The
authors also state that multiple communication proto-
cols might be part of the installation, but the proposed
solution for emergency lighting only uses LoRa, and
it is unclear if it is extensible to other communication
(Pandharipande and Thijssen, 2019) propose a
lighting data model for street light infrastructure in
smart city applications, which aims to ease the inte-
gration with other city infrastructures and the devel-
opment of smart applications. The authors are aware
of the need for a commissioning process to set up
the luminaires and the multitude of communication
protocols needed to build such a system. However,
they only tackle the support for multiple communica-
tion protocols via a pre-defined API, which does not
clearly indicate how new protocols can be added to
the system.
(Gagliardi et al., 2020) propose and prototype
an IoT infrastructure for smart city lighting that can
adapt autonomously to traffic and weather conditions.
Despite the system’s field validation, the authors do
not address the issue of autonomous commissioning.
Additionally, the authors do not consider heterogene-
ity in terms of communication protocols for the de-
vices in smart lighting and tie their solution to Zig-
uchtenhans et al., 2021) review the state-of-art
on technologies and applications for smart lighting
systems and, based on such review, elaborate on the
benefits that can be obtained by applying smart light-
ing to warehouse order picking. The authors, how-
ever, fail to address the challenge of deploying such
systems, namely the high overhead on the commis-
sioning of lighting infrastructures. (Chinchero et al.,
2020) also review the state-of-the-art on technologies
and methods for lighting control systems for smart
buildings. They propose an architecture that fails to
address such a system’s commissioning and installa-
tion overhead but, despite not providing the details,
considers the multiple communication protocols that
might be involved in such installation.
In (Cheng et al., 2020), the authors identify a set
of challenges that need to be addressed by smart light-
ing systems and propose a solution to reduce lighting
energy consumption based on sensors, a rule-based
mechanism for lighting control and Zigbee. The over-
head of the commissioning procedure is not identi-
fied as a challenge, so it is not addressed, nor is the
heterogeneity in terms of communication protocols.
(Lin et al., 2020) also propose a solution to address
the energy consumption of lighting systems, but they
focus only on the indoor personnel positioning chal-
lenge. (Chen et al., 2022) developed a solution to re-
duce the energy consumption of street road lighting.
They use renewable energy sources and employ intel-
ligent mechanisms that control the light intensity level
based on traffic flow and the presence and absence of
people. Still, again, they do not focus on the commis-
sioning of such a system, and they tie their solution to
ZigBee, disregarding the heterogeneity of communi-
cation protocols for smart lighting solutions.
(Ristimella, 2020) identifies in his master thesis,
with the help of representatives of Helvar Oy Ab, the
Lite4More: A Hardware and Software Solution to Improve the Commissioning of Lighting Infrastructures
Table 1: Overview on Academic and Industrial Smart Lighting Solutions.
Automated Smart and remote Extensible to multiple
Commissioning Lighting Control communication protocols
(Xu et al., 2019) No Yes Not clear
(Pandharipande and Thijssen, 2019) No Yes Yes
(Gagliardi et al., 2020) No Yes No
(Chinchero et al., 2020) No Yes Yes
(Cheng et al., 2020) No Yes No
(Chen et al., 2022) No Yes No
(Signify Holding, 2023) No Yes No
(SavantT Technologies LLC, 2022) No Yes No
(OSRAM GmbH, 2023) No Yes No
(Lightwave, 2023) No Yes No
(Ristimella, 2020) Partially Yes No
Lite4More Yes Yes Yes
challenge of lighting localization and its importance
in the commissioning of lighting systems. Ristimella
proposes a localization mechanism for lighting sys-
tems, which complements a personal lighting control
mechanism for public spaces. However, the local-
ization mechanism relies on a technician carrying a
Received Signal Strength Indicator (RSSI) and Pas-
sive Infra Red (PIR) scanning device along the space
where the luminaires need to be identified. This pro-
cedure is impractical for big public spaces such as
hospitals, airports or stadiums. Additionally, the solu-
tion does not address the heterogeneity of communi-
cation protocols for smart lighting solutions because
it is tied to BLE and the ActiveAhead luminaries from
Helvar Oy Ab.
Nevertheless, Ristimella’s master’s thesis is the
only publicly known industrial effort to ease the com-
missioning of lighting solutions. Other companies in
this field only advertise their efforts on smart light-
ing. (Signify Holding, 2023), (SavantT Technologies
LLC, 2022), (OSRAM GmbH, 2023), and (Light-
wave, 2023) are examples of such efforts in which
the luminaire is complemented with a wireless com-
munication protocol, which allows its integration with
a web and/or mobile interface to control it. Another
common characteristic of the existing industrial so-
lutions is the support of a specific subset of devices
and/or protocols, limiting the possibility of extending
the solution to other communication protocols and de-
Table 1 summarizes the studied smart lighting so-
lutions in terms of the commissioning procedure, sup-
port for smart/remote lighting control, and the possi-
bility of being extended to support other communi-
cation protocols, addressing heterogeneity and ven-
dor lock-in. One can conclude that all the solutions
provide support for smart/remote lighting control, but
only the solutions proposed by (Pandharipande and
Thijssen, 2019) and (Chinchero et al., 2020) sup-
port the extensibility to other communication proto-
cols (the solution proposed by (Xu et al., 2019) is
not clear regarding the supported of this feature). Re-
garding the capability to automate the commissioning
procedure, only (Ristimella, 2020) proposes a solu-
tion that partially addresses this issue. Ristimella’s
solution still requires the technician to scan the build-
ing fully to identify the luminaires, which is not ideal.
Lite4More not only addresses smart/remote lighting
control but also proposes a more efficient autonomous
commissioning procedure and an extensible architec-
ture that can be adapted to different communication
protocols as well as other installation requirements.
Lite4More addresses the lighting infrastructure com-
missioning problem by employing a system architec-
ture that spans from the IoT device (the luminaires) to
the Cloud, which houses a set of algorithms and a user
interface that automates and guides the technician
through the commissioning procedure. Section 3.1
and section 3.2 overview such architecture and com-
missioning procedure, respectively. Section 3.3 con-
cludes with the lessons learned so far.
3.1 System Architecture
Figure 1 presents Lite4More’s architecture, which
spans the Cloud, Edge and IoT Device Layers. The
Cloud Layer is responsible for automating and con-
trolling the luminaires, user interaction, and storage
of the lighting network configuration. The IoT De-
vice Layer comprises the physical lighting infrastruc-
IoTBDS 2024 - 9th International Conference on Internet of Things, Big Data and Security
Figure 1: System architecture.
ture: luminaires, sensors, and actuators (e.g., light
and dimmer switches). The Edge Layer serves as the
interface between the lighting infrastructure and the
components at the Cloud level.
The Cloud Layer builds on top of the Microsoft
Azure Cloud platform (Microsoft, 2024). It com-
prises a set of services that control and manage the
physical infrastructure and a web interface provid-
ing an interface between the user and the services.
Using Azure API manager (cf. 1, Fig. 1), a REST
API is provided as an interface for the web inter-
face. For each action invoked with this API (e.g.
scan for devices, add devices, light commissioning,
etc.), an Azure function (cf. 2, Fig. 1) is triggered.
These functions are a type of Function as a Service
that executes Lite4More code in a server-less man-
ner. They handle any events triggered by the Edge
Devices, users or other services and run the logic re-
quired to commission, configure and plan the infras-
tructure. Another adopted service is the Azure Event
Hubs, which provides queues to inject and consume
messages that our system needs to forward between
the different services and devices. A database ser-
vice (cf. 1, Fig. 1) stores structured data, such as
the system configurations and the information about
the lighting infrastructure. The blob storage (cf. 1,
Fig. 1) stores unstructured data, such as architectural
blueprints. The Azure IoT Hub service (cf. 3, Fig. 1)
provides the message broker that interfaces the Cloud
services with the Edge Devices in the layer below.
This service is crucial for synchronising the device
data stored in the Cloud with its physical counter-
part. When, for example, a user requests the sys-
tem to provision a new luminaire (see section 3.2),
the Azure function sends an identified action message
to the closest Edge Device requesting the provision
of such luminaire. Then, when the luminaire is pro-
visioned, the Edge Device sends an identified action
response, which is consumed by another Azure func-
tion that updates the network in the database. At the
same time, another Cloud function is responsible for
asynchronous notifications and sends an event to the
web interface (cf. 4, Fig. 1) stating that the action was
successful. These notifications are published by the
Azure Web PubSub (cf. 1, Fig. 1), a WebSocket ser-
vice allowing asynchronous messages to be published
to our web interface.
The Edge Layer comprises multiple Edge Devices
that connect the distinct lighting infrastructure with
the Cloud. The architecture of the Edge Device (cf.
Lite4More: A Hardware and Software Solution to Improve the Commissioning of Lighting Infrastructures
Figure 2: Sequence diagram for scan operation.
5, Fig. 1) is based on microservices that communicate
with each other through an event bus (cf. 6, Fig. 1).
Those microservices can be classified into translation
(cf. 7, Fig. 1) and functional (cf. 8, Fig. 1). Trans-
lation microservices are responsible for translating
Cloud events into events understandable by the func-
tional microservices and vice-versa, decoupling the
latter’s interface from the interface on the Cloud. The
functional microservices are typically used to perform
some type of functional computation (cf. 8, Fig. 1),
namely: the Redis Database stores a local configu-
ration of the nearby IoT Device layer; the Teleme-
try module bypasses the Edge message broker to send
large amounts of data (e.g. sensor data) back to the
Cloud; and the protocol drivers, currently BLE Mesh
or DALI, communicate directly with the target de-
vices in the IoT Device Layer. The different microser-
vices in an Edge Device communicate using a single
event bus based on the Dapr (Dapr, 2023). This bus
can also be shared with other devices, called Edge De-
vice bridges, a type of Edge Device without a connec-
tion to the Cloud (cf. 9, Fig. 1). The Dapr event bus
allows Edge Device bridges to use full-featured Edge
Devices as a relay to the Cloud. To achieve this, each
full-featured Edge Device has an Edge message bro-
ker (cf. 10, Fig. 1) to receive and send messages from
and to the Cloud. Based on microservices, this archi-
tecture allows us to easily extend Lite4More to other
lighting infrastructure protocols beyond BLE Mesh
and DALI.
The lighting infrastructure lies at the IoT Device
Layer. This lighting infrastructure consists of lu-
minaires, sensors, actuators (such as light switches
and dimming switches) and sometimes a combina-
tion of these. These devices can be divided into two
categories: Lite4More devices, which are based on
Nordic nRF52840 microcontroller (Nordic Semicon-
ductors, 2019), use BLE as communication technol-
ogy and have a set of sensors that provide relevant
data for the commissioning procedure; and the clas-
sic devices, which use well-established communica-
tion technologies that do not account for IoT scope
and are the standard in the lighting industry, such as
DALI devices. The DALI devices are integrated into
the Lite4More scope through the DALI microservices
running on the Edge Device. Currently, the light-
ing infrastructure only supports BLE and DALI de-
vices, but other communication protocols can be eas-
ily added by including new functional microservices
responsible for communicating with them in the Edge
The sequence diagram in Figure 2 resumes the
interactions with the different elements of the ar-
chitecture described above. Figure 2 showcases the
scan request, which prompts the Edge Devices within
the installation to search for BLE Mesh and DALI-
compatible devices. We use this example, but the
flow of information is similar in all the requests. The
IoTBDS 2024 - 9th International Conference on Internet of Things, Big Data and Security
Figure 3: Overview of commissioning stages.
main difference resides in the ”Azure Function” used,
the services of the set ”Other Services” provided by
the Cloud, and the ”Translation micro-services” used.
These macro elements provide a set of different ser-
vices and functions that respond to each performed
In Figure 2, the web interface will perform a scan
request to the Cloud through the exposed ”REST
API” (cf. 1, Figure 2). This triggers an ”Azure Func-
tion” that will get the list of available Edge devices
from the ”SQL Database” (one of the services avail-
able in the set of ”Other Services” in the Cloud) and
identify which Edge device it needs to forward the
request to (cf 2, Figure 2). An ”Azure IoT Hub Mes-
sage” is sent to that Edge device (cf 3, Figure 2). The
Edge device receives such a message in the ”Edge
Message Broker”, which will convert it into the scan
API call (cf. 4, Figure 2). This call is consumed by
all ”Translation micro-services”, which will call the
respective driver modules to perform the scan (cf. 5,
Figure 2). From here, the scan results are propagated
backwards until the ”Edge Message Broker”. They
are then filtered in the ”Azure IoT Hub”, triggering an
”Azure Function” that will save the scanned devices
(cf. 7, Figure 2) and publish the information to the
”Web Interface” (cf. 8, Figure 2) through the ”Web
PubSub” socket (service available in the set of ”Other
Services” in the Cloud).
3.2 Commissioning Procedure
Figure 3 provides an overview of the three stages of
the Lite4More commissioning procedure. ”Stage 1 -
provisioning” and ”Stage 2 - blueprint submission”
do not depend on each other’s outputs, so they can be
run concurrently. ”Stage 3 - node’s auto-localisation”
can only be run after the conclusion of the other two.
In the commissioning procedure, we assume that the
lighting infrastructure and the remaining Lite4More
system are already installed and ready to be config-
In Stage 1, technicians incorporate lighting de-
vices into the Lite4More network. Utilising a web
interface, they initiate a scanning process for both
BLE Mesh and DALI devices (Step 1). This directive
prompts the Edge Devices to scan for BLE Mesh and
DALI-compatible devices during installation. After
scanning, Lite4More automatically registers the iden-
tified devices to its network (Step 2) and stores them
in a Cloud-based database (Step 3).
In Stage 2, technicians upload the building’s
blueprint to Lite4More using its web interface (step
4). After the upload, they provide additional con-
textual information, such as the blueprint’s scale and
lighting legend (step 5). When all the contextual in-
formation is provided, a computer vision algorithm
identifies the lighting infrastructure on the blueprint
and estimates the distance between identified objects
(step 6). In the end, the technicians use the web inter-
face to verify the algorithm’s output and fix identifi-
cation errors (step 7).
In Stage 3, the technicians use the web interface
to run a localisation algorithm based on RSSI and lu-
minance values that match provisioned devices to the
identified objects in the blueprint (step 8). The algo-
rithm requires the technician to set at least one an-
chor point (match one provisioned luminaire with a
point in the blueprint) from which all the other lumi-
naires are matched in the blueprint (step 9). The pro-
cedures use a human-in-the-loop approach in which,
depending on the confidence level of the localisation,
the technician is asked via the web interface to vali-
date the luminaires with low confidence levels or se-
lect another anchor to continue the localisation proce-
dures (step 10). A more detailed explanation of such
algorithm is found on (Barandas et al., 2024).
Even though the provisioning still requires the
presence of a technician onsite, it is important to note
that such presence is only required to identify the an-
chor points and validate luminary localisation with a
low confidence level. These are specific and well-
known locations, so there is no need for the technician
Lite4More: A Hardware and Software Solution to Improve the Commissioning of Lighting Infrastructures
to scan all the physical infrastructure. The procedure
can be completed with a quick visit to the installation
site rather than weeks or even months, as is the case
of the current procedure identified in the state of the
After commissioning, the technician is invited to
create groups of luminaires and scenes (sets of pre-
defined settings). The system can also suggest groups
and scenes based on the location of the luminaires and
existing groups and scenes.
In conclusion, except for the definition of the an-
chor points and validation of localisations with low
confidence levels, all the steps of the commissioning
procedure can be performed remotely with the sup-
port of the web interface.
3.3 Lessons Learned
The current version of Lite4More allowed us to draw
some conclusions about the technological decisions
that were made for the solutions. The most relevant is
using Microsoft Azure for the Cloud and BLE for the
luminaire communication.
Microsoft Azure is a powerful tool for develop-
ing IoT solutions for the Cloud with seamless inte-
gration with the Edge, but the efficient selection and
combination of some of their products is not straight-
forward. When using Microsoft Azure for complex
solutions composed of several of their products, it is
crucial to have good knowledge about Azure and al-
ways contact technical support in case of doubt or in-
efficient/slow execution of code.
Regarding BLE, we started setting up a testbed in
an office to evaluate Lite4More developments. This
setup is currently composed of a Raspberry Pi 4
that plays the role of an Edge Device and 86 lu-
minaires distributed through open spaces and small
rooms spanning 705 square meters. Initial tests indi-
cate that BLE mesh network parameters such as the
number of relays, the transmission power, the time
to live, and the number of Edge Devices influence,
as expected, the message delivery success rate and
response time. Such success rate and response time
are intrinsically connected to the provisioning success
rate and duration. This indicates that we will need
to tune the BLE parameters to the installation under-
provisioning. We need to perform a structured eval-
uation and characterisation of the provisioning pro-
cedures to define an adequate network configuration
according to a set of installation topologies. Addition-
ally, to deal with possible network failures in the pro-
visioning, we need to implement a scheme that mon-
itors node provisioning success and enables retries in
case of failure.
In this paper, we presented Lite4More architecture,
a hardware and software solution that targets the au-
tonomous commissioning of lighting systems, which,
to the best of our knowledge, is the first proposal in
that direction. Lite4More reduces the commission-
ing time by guiding the technician along the com-
missioning procedure and reducing on-site work. To
achieve this, it comprises a set of serverless func-
tions running in the Cloud, which integrate multiple
lighting infrastructures connected via Edge devices
running local storage, communication and translation
services. For the lighting system, we propose using a
BLE-based device with backward compatibility with
DALI, composed of sensors that provide relevant data
for the commissioning procedure. The proposed so-
lution aims to be highly scalable and easily adapted
to new lighting system communication protocols and
installation requirements.
The current status of the solution allowed us to
validate some of our technological decisions, namely
the use of Microsoft Azure for the Cloud and BLE
mesh for the lighting system communication. How-
ever, this is not without some challenges, namely the
efficient selection, integration and setup of all the ser-
vices provided by Microsoft Azure and the tuning of
the BLE mesh network parameters to guarantee low
response time and high success rate on message trans-
mission, which relate with the successful provision of
the lighting system.
The next steps for Lite4More are to perform a
structured evaluation and characterization of the pro-
visioning procedures in an office environment to un-
derstand clearly how the BLE mesh network will in-
fluence it. In the second stage of the evaluation, we
will evaluate the system in other environments (office,
warehouse, etc.) to fully characterize how BLE influ-
ences the provisioning in different installation topolo-
gies and, with this, prepare a set of pre-configurations
for the BLE network according to different installa-
tion topologies. The roadmap also includes the eval-
uation of the other stages of our commissioning pro-
cedure, namely blueprint submission and node auto-
This work has been realised in the frame of the
Lite4More Project (nº 46142), under SI I&DT RCI
(AAC 25/SI/2016) funded program.
IoTBDS 2024 - 9th International Conference on Internet of Things, Big Data and Security
Barandas, M., Santos, R., Filipe, J., and Silva, C. (2024).
Iterative wireless node localization based on blue-
tooth and visible light for smart lighting systems.
In 2024 Wireless Telecommunications Symposium
(WTS). CalPoly Pomona. (To Appear).
Chen, Z., Sivaparthipan, C., and Muthu, B. (2022). Iot
based smart and intelligent smart city energy opti-
mization. Sustainable Energy Technologies and As-
sessments, 49:101724.
Cheng, Y., Fang, C., Yuan, J., and Zhu, L. (2020). De-
sign and application of a smart lighting system based
on distributed wireless sensor networks. Applied Sci-
ences, 10(23).
Chinchero, H. F., Alonso, J. M., and Ortiz T, H. (2020). Led
lighting systems for smart buildings: a review. IET
Smart Cities, 2(3):126–134.
Dapr (2023). Apis for building secure and reliable microser-
vices. [Online; accessed 4-December-
Dautov, R. and Song, H. (2020). Towards agile manage-
ment of containerised software at the edge. In 2020
IEEE Conference on Industrial Cyberphysical Sys-
tems (ICPS), volume 1, pages 263–268. IEEE.
uchtenhans, M., Grosse, E. H., and Glock, C. H. (2021).
Smart lighting systems: state-of-the-art and poten-
tial applications in warehouse order picking. Interna-
tional Journal of Production Research, 59(12):3817–
Gagliardi, G., Lupia, M., Cario, G., Tedesco, F., Cic-
chello Gaccio, F., Lo Scudo, F., and Casavola, A.
(2020). Advanced adaptive street lighting systems for
smart cities. Smart Cities, 3(4):1495–1512.
Hughes, R. F. and Dhannu, S. S. (2008). Substantial en-
ergy savings through adaptive lighting. In 2008 IEEE
Canada Electric Power Conference, pages 1–4. IEEE.
Lightwave (2023). Lightwave.
[Online; accessed 4-December-2023].
Lin, X., Duan, P., Zheng, Y., Cai, W., and Zhang, X. (2020).
Posting techniques in indoor environments based on
deep learning for intelligent building lighting system.
IEEE Access, 8:13674–13682.
Lueth, K. L. (2020. Accessed on: September, 2021. [On-
line]). State of the iot 2020: 12 billion iot connections,
surpassing non-iot for the first time. IoT Analytics.
Microsoft (2024). Azure. limitless innovation. https://azure. [Online; accessed 4-December-
Nagy, Z., Yong, F. Y., Frei, M., and Schlueter, A. (2015).
Occupant centered lighting control for comfort and
energy efficient building operation. Energy and Build-
ings, 94:100–108.
Neida, B. V., Maniccia, D., and Tweed, A. (2001). An
analysis of the energy and cost savings potential
of occupancy sensors for commercial lighting sys-
tems. Journal of the Illuminating Engineering Society,
Nordic Semiconductors (2019). nRF52840 Product Speci-
fication. Nordic Semiconductors. Rev. 1.1.
OSRAM GmbH (2023). Osram lightify. https://www.os [Online; accessed 4-December-
Pandharipande, A. and Thijssen, P. (2019). Connected
street lighting infrastructure for smart city applica-
tions. IEEE Internet of Things Magazine, 2(2):32–36.
Ristimella, E. (2020). Smart luminaire positioning and
lighting control in collaborative spaces. Master’s the-
sis, University of Oulu - Faculty of Information Tech-
nology and Electrical Engineering.
SavantT Technologies LLC (2022). Ge lighting. https:// [Online; accessed 4-December-
Signify Holding (2023). Philips hue. [Online; accessed 4-December-2023].
So, A. T. and Leung, L. M. (1998). Indoor lighting design
incorporating human psychology. Architectural Sci-
ence Review, 41(3):113–124.
Xu, W., Zhang, J., Kim, J. Y., Huang, W., Kanhere, S. S.,
Jha, S. K., and Hu, W. (2019). The design, imple-
mentation, and deployment of a smart lighting system
for smart buildings. IEEE Internet of Things Journal,
Lite4More: A Hardware and Software Solution to Improve the Commissioning of Lighting Infrastructures