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

ﬁ ﬁ

antonio.sousa}@tridonic.com

Keywords:

IoT Provisioning, Smart Lighting, BLE Mesh.

Abstract:

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 beneﬁt 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.

1 INTRODUCTION

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-conﬁgured soft-

ware, and updating and conﬁguring 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

https://orcid.org/0009-0007-5443-4073

https://orcid.org/0000-0002-1834-0420

https://orcid.org/0000-0002-8278-9062

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 beneﬁts 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.

252

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

Additionally, the majority of the smart lighting so-

lutions support a speciﬁc 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.

2 STATE OF ART

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

protocols.

(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-deﬁned 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 trafﬁc and weather conditions.

Despite the system’s ﬁeld 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-

Bee.

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

beneﬁts 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-

ﬁed 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 trafﬁc ﬂow 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) identiﬁes 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

253

Table 1: Overview on Academic and Industrial Smart Lighting Solutions.

Platform

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 identiﬁed. 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 ﬁeld 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 speciﬁc subset of devices

and/or protocols, limiting the possibility of extending

the solution to other communication protocols and de-

vices.

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 efﬁcient autonomous

commissioning procedure and an extensible architec-

ture that can be adapted to different communication

protocols as well as other installation requirements.

3 PROPOSED SOLUTION

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 conﬁguration. The IoT De-

vice Layer comprises the physical lighting infrastruc-

IoTBDS 2024 - 9th International Conference on Internet of Things, Big Data and Security

254

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, conﬁgure 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 conﬁgurations 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 identiﬁed 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 identiﬁed 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 notiﬁcations and sends an event to the

web interface (cf. 4, Fig. 1) stating that the action was

successful. These notiﬁcations 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

255

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 classiﬁed 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 conﬁgu-

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

Devices.

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

ﬂow of information is similar in all the requests. The

IoTBDS 2024 - 9th International Conference on Internet of Things, Big Data and Security

256

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

request.

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 ﬁltered 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 conﬁg-

ured.

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-

tiﬁed 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

identiﬁes the lighting infrastructure on the blueprint

and estimates the distance between identiﬁed objects

(step 6). In the end, the technicians use the web inter-

face to verify the algorithm’s output and ﬁx identiﬁ-

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

identiﬁed 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 conﬁdence level of the localisation,

the technician is asked via the web interface to vali-

date the luminaires with low conﬁdence 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 conﬁdence level. These are speciﬁc 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

257

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 identiﬁed in the state of the

art.

After commissioning, the technician is invited to

create groups of luminaires and scenes (sets of pre-

deﬁned 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 deﬁnition of the an-

chor points and validation of localisations with low

conﬁdence 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 efﬁcient 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-

efﬁcient/slow execution of code.

Regarding BLE, we started setting up a testbed in

an ofﬁce 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 inﬂuence,

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 deﬁne an adequate network conﬁguration

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.

4 CONCLUSION

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 ﬁrst 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

efﬁcient 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 ofﬁce environment to un-

derstand clearly how the BLE mesh network will in-

ﬂuence it. In the second stage of the evaluation, we

will evaluate the system in other environments (ofﬁce,

warehouse, etc.) to fully characterize how BLE inﬂu-

ences the provisioning in different installation topolo-

gies and, with this, prepare a set of pre-conﬁgurations

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-

localization.

ACKNOWLEDGEMENTS

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

258

REFERENCES

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. https://dapr.io/. [Online; accessed 4-December-

2023].

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–

3839.

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. https://lightwaverf.com/.

[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 ﬁrst time. IoT Analytics.

Available: https://iot-analytics.com/state-of-the-iot-

2020-12-billion-iot-connections-surpassing-non-iot-

for-the-ﬁrst-time/.

Microsoft (2024). Azure. limitless innovation. https://azure.

microsoft.com/en-us. [Online; accessed 4-December-

2023].

Nagy, Z., Yong, F. Y., Frei, M., and Schlueter, A. (2015).

Occupant centered lighting control for comfort and

energy efﬁcient 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,

30(2):111–125.

Nordic Semiconductors (2019). nRF52840 Product Speci-

ﬁcation. Nordic Semiconductors. Rev. 1.1.

OSRAM GmbH (2023). Osram lightify. https://www.os

ram.pt/cb/lightify. [Online; accessed 4-December-

2023].

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://

www.gelighting.com. [Online; accessed 4-December-

2023].

Signify Holding (2023). Philips hue. https://www.philips-

hue.com/. [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,

6(4):7266–7281.

Lite4More: A Hardware and Software Solution to Improve the Commissioning of Lighting Infrastructures

259