A No-Code Educational Platform for Introducing Internet of Things and Its Application to Agricultural Education

Abstract

This study introduces a no-code educational platform created to introduce Internet of Things (IoT) to university students who lack programming experience. The platform allows users to set IoT sensor nodes, and create a wireless sensor network through a simple graphical interface. Sensors’ data can be sent to cloud services but they can also be stored locally, which makes our platform particularly realistic in fieldwork settings where internet access may be limited. The platform was tested in a pilot activity within a university course that previously covered IoT only in theory and was evaluated using the Technology Acceptance Model (TAM). Results showed strong student engagement and high ratings for ease of use, usefulness, and future use intent. These findings suggest that a no-code approach can effectively bridge the gap between IoT technologies and learners in non-engineering fields.

1. Introduction

The ability to perform algorithmic processing without writing code is becoming increasingly popular [1]. Today, specialized tools enable non-technical individuals to visually develop software applications without relying on traditional coding, following Low-Code (LC) and No-Code (NC) frameworks [2]. As a result, LC/NC platforms are being integrated into critical aspects of daily life, such as healthcare and finance, offering several advantages, including reduced dependency on programmers and lower application development costs [3,4]. These platforms use drag-and-drop interfaces and pre-built components, facilitating rapid application development [5]. The differences between low-code and no-code are not entirely clear. It can generally be said that in the low-code framework, most of the code is provided by the platform, although some coding is still expected from the user. In contrast, the no-code framework requires no code to be written by the user.

As this groundbreaking approach transforms software development, its potential in education is particularly intriguing, with objectives that may vary across different academic disciplines. For Computer Science (CS) students, the introduction to programming poses a range of challenges, as beginner programmers often struggle with syntax errors and debugging complexities. This issue can undermine learning objectives such as understanding algorithmic concepts, mastering fundamental programming language skills, and effectively applying algorithms [6]. In this context, a low-code approach can provide a gentler introduction to computational concepts [7,8].

For non-CS studies, teaching programming is even more challenging, as students may struggle to transfer programming knowledge to their field [9]. Again, a low-code approach can be utilized if teaching programming continues to be the learning objective. Hopefully, over time, some students may feel confident enough to make the transition into full coding environments. However, for some science fields, it may be decided that programming is not a needed skill [10]. In this context, a no-code approach can be used, aiming to empower students to create algorithmic functionality and services that previously required technical expertise beyond the scope of their studies.

The present paper introduces a no-code approach in the form of an innovative educational platform that enables students to explore the Internet of Things (IoT). It also evaluates the application of this approach in the field of agricultural sciences. Unlike simulation tools or purely software-based development environments, our platform is a hands-on educational solution that integrates real IoT hardware with a no-code software interface, specifically designed for classroom use. Through this platform, students are empowered to create wireless sensor networks, a key feature of IoT applications. The sensors are located at the end-nodes, where each end-node is based on a microcontroller running a piece of code known as firmware [11]. The end-nodes transmit data to a central station, which receives, stores, and—if determined by the student—may forward it to IoT cloud platforms. Such networks are particularly relevant to precision agriculture [12], a modern farming method based on observing, measuring, and responding to inter- and intra-field variability in crops. The objective is to ensure that crops and soil receive exactly what they need for optimal health and productivity. This approach minimizes the environmental footprint of farming, enhances sustainability, and increases both crop yields and profitability. It must be noted that this is a pilot study aimed at evaluating initial usability and acceptance. Comprehensive learning outcomes will be explored in subsequent research.

2. Approaches for Teaching CS to Non-CS Students

Teaching introductory CS courses to non-CS students presents several challenges. Many students struggle with conceptual learning due to differing levels of prior experience [13]. It is important to note that difficulties with syntax and a lack of problem-solving strategies [6] are frequently associated with weaknesses in both conceptual and strategic knowledge. Additionally, a lack of motivation and an unbalanced emphasis on programming components may further hinder learning [14]. To address these issues, two primary approaches are suggested in the literature.

The first approach focuses on improving teaching strategies. Following this approach, the importance of addressing common misconceptions and strengthening instructors’ pedagogical content knowledge is emphasized in [6]. Problem-solving-based teaching strategies are proposed by Riley [14]. A similar approach is supported in [15], where the authors also emphasize the importance of tailoring teaching methods to the specific needs of non-CS students and incorporating programming as a tool within their respective domains to promote effective learning.

The second approach involves shifting the focus from programming techniques to functionality, allowing students to develop applications within a Low-Code/No-Code (LC/NC) context. This approach is supported by recent studies examining the integration of LC/NC development into university curricula and its impact on student learning outcomes. The results appear to be positive, as the next subsection highlights.

3. Why Use a No-Code Approach to Teach?

We adopted a no-code approach because designing and deploying a sensor network typically requires programming expertise that students only gain after completing a full programming course. However, our focus is on an introductory computer science course, which assumes no prior programming experience. In many university departments, this course is the only exposure students have to computer science, meaning they are not required to acquire programming skills at all [10]. As such, it represents a critical opportunity to equip students with relevant digital competencies without the barrier of coding.

Furthermore, the LC/NC framework offers several advantages from an educational perspective, as recent literature demonstrates promising outcomes. For example, a no-code business app development module that can be integrated into various information systems courses was introduced in [16], showing positive preliminary results in terms of student learning outcomes. Similarly, a modularized Data Science curriculum using no-code tools was presented in [17], which led to increased student motivation and improved conceptual understanding among non-CS majors.

In addition to learning outcomes, LC/NC approaches have been shown to enhance students’ self-confidence. In [18], it was found that incorporating LC/NC tools in a Management Information Systems (MIS) course boosted students’ self-efficacy and interest in further skill development. Likewise, in [8], it was reported that students perceived LC/NC platforms as easier to learn than traditional programming approaches. Similarly, in [19], it was reported that using a no-code platform increased students’ comfort levels. Building self-confidence is particularly important, as studies show a positive correlation between self-confidence and academic performance [20]. For instance, in [21], it was demonstrated that students exposed to confidence-boosting stimuli exhibited higher academic self-confidence and cognitive performance compared to those exposed to negative stimuli. This effect appears to be even stronger among middle- and lower-performing students [21].

4. LC/NC Approaches for Teaching IoT

In this section, we present existing solutions for teaching the Internet of Things (IoT) within the LC/NC context, with a focus on educational use. These approaches are centered around specific hardware that students must use to construct real wireless sensor networks. Unlike purely software-based simulations, these solutions provide hands-on experience with physical devices. This fact makes them particularly relevant for classroom activities that emphasize practical engagement and applied learning.

Notably, some IoT cloud platforms adopt the no-code approach, which enables users to create wireless sensor networks without programming the end-nodes. These platforms also offer free usage up to a certain limit. While they provide a convenient option for teaching IoT, they do have some limitations. A first obvious limitation is that they are not completely free. Furthermore, they typically rely on communication through Wireless Fidelity (WiFi) or Long Range (LoRa) technologies, neither of which is particularly cost-effective. Instead, we have chosen Bluetooth because of its affordability and suitability for scenarios requiring low power consumption and short-range communication [22]. For our purposes, long-range communication is unnecessary, as the course takes place either in a lab or in an outdoor field within the campus. Furthermore, to establish a basic wireless sensor network using Bluetooth, only end-nodes and a laptop or PC with a Bluetooth dongle are needed. This setup, although limited in range and scalability, is inexpensive and contains the essential components to support all the necessary educational scenarios.

MySensors [23] is an open-source hardware and software platform designed to simplify the development of DIY wireless sensor networks. It enables users to create low-power sensor nodes that communicate using various wireless protocols. The platform provides a flexible and modular framework that supports both simple and complex sensor applications, making it suitable for hobbyists, educators, and developers. It is important to note, however, that MySensors does not follow a no-code approach. In particular, it relies on the Arduino IDE for compiling and uploading firmware to the end-nodes. Pre-written example code is available for many common scenarios, allowing users to deploy functional nodes with minimal modifications. However, users are still required to engage with the source code, even if only to adjust parameters or customize behavior. Thus, interaction with the code is expected, and some basic programming familiarity is necessary, placing MySensors closer to a low-code rather than a no-code paradigm.

Another educational approach is IWAST (IoT With A Soft Touch) [24]. It is a plug-and-play educational IoT system designed by KU Leuven’s DRAMCO research group to introduce non-specialists to the Internet of Things in a user-friendly manner. It uses LoRa technology for wireless communication. The system comes with an intuitive configuration tool (Windows-based) for setting thresholds and sampling intervals. A web interface is available for viewing sensor data, generating graphs, and exporting Comma-Separated Values (CSV) files for further analysis.

IoT Data Collection and Analysis [25] is an Internet of Things (IoT) application that connects devices and sensors to the internet, collects data, and performs actions based on the data. The application supports cloud-based management of devices and data analysis. Only a certain type of temperature sensor is supported, but it is enough for some educational settings. However, users have to engage with the source code to adjust parameters or customize behavior. Furthermore, they cannot customize the application by adding more sensor types, as this would require new code.

Among the existing approaches, IWAST is the closest to ours. Both approaches share the same goal: to facilitate the introduction of IoT to students. They also both support a web interface for viewing and plotting sensor data. But they also have differences. The hardware of the end-nodes in IWAST consists of specially designed hexagonal boards, where each board is either a “motherboard” or a “sensor board”. In this sense, it is not as flexible as our solution, which uses Arduino-based end-nodes that can be constructed from materials available at electronics stores.

Table 1. Alternative approaches to hands-on learning in IoT education.

Solution	Off-the-Shelf Hardware	Communication Technology	No-/Low-Code	Usage Cost
Our Platform	Yes	Bluetooth/serial	No-Code	Free
IWAST	No	LoRa	No-Code	Free
MySensors	Yes	2.4 GHz radio/RFM69/LoRa	Low-Code	Free
Byansi’s	Yes	Wi-Fi	Low-Code	Free
IoT Cloud Platforms	Yes	Wi-Fi/Cellular/Ethernet/LoRa	* No-Code	* Limited Free

* Note: this does not hold for all IoT cloud platforms.

summarizes the key characteristics of each approach. Our no-code educational platform stands out as the only free solution that follows a no-code paradigm while relying entirely on off-the-shelf hardware. Furthermore, its use of Bluetooth communication minimizes infrastructure requirements while reducing construction costs.

As an overall comment, we can say that all the alternative approaches do not target education alone, but contain features that can be used in in-field deployment, making them more general-purpose and potentially more complex for educational settings.

5. Materials and Methods

5.1. Educational Platform Design

The proposed no-code educational platform leverages open-source hardware and software to enable students to easily build and interact with a wireless sensor network. The end-node hardware consists of an Arduino Uno board integrated with a set of sensors of agricultural interest, including temperature, humidity, soil moisture, and light sensors.

To simplify the hardware interaction for beginners, the end-node is embedded in a newly developed 3D-printable educational robotics kit called Odysseus. This kit was designed specifically for teaching programming and algorithmic thinking to students with no prior experience, while maintaining a low production cost.

Sensor data is transmitted from each end-node to a central station via either wired (USB) or wireless (Bluetooth) communication. The software component includes a NodeJS-based web server. Students can build the network and visualize the data through a graphical interface that supports “click-on-button” interactions, eliminating the need for writing code. Students can also send the data to IoT cloud platforms.

5.2. Educational Implementation

The platform was introduced as part of an introductory course in informatics offered by the Department of Natural Resources Development and Agricultural Engineering at the Agricultural University of Athens. The primary aim was to assess the usability and educational value of the no-code platform in a real classroom setting.

5.3. Evaluation Methodology

The evaluation followed the Technology Acceptance Model (TAM) [26], a framework widely used for predicting user acceptance of information systems and previously applied to similar engineering education projects [27,28].

A total of 39 undergraduate students participated in the pilot study. The evaluation instrument was a structured questionnaire based on the Technology Acceptance Model (TAM) developed by Davis [29]. It was designed to measure four key constructs: perceived usefulness, perceived ease of use, attitude towards use, and behavioral intention to use. The questionnaire consisted of 14 items in total, with each item rated on a 5-point Likert scale ranging from “Strongly Disagree” (1) to “Strongly Agree” (5). It was adapted from previous validated TAM studies [27,28], and minor wording modifications were made to align the items with the context of the no-code IoT educational platform. The students were asked to complete the questionnaire after completing a hands-on educational scenario using the no-code platform.

Although the sample size was relatively small due to the study’s pilot nature, the responses indicated a high level of acceptance. In particular, students reported strong agreement that the platform was easy to use, believed it would enhance their academic performance, and expressed a strong intention to use it in the future. A detailed breakdown of the evaluation results is provided in Section 9.

6. No-Code Introduction to IoT

6.1. Architecture of the No-Code Educational Platform

Our No-Code educational platform approach utilizes open hardware and software, enabling students to create a wireless sensor network easily. The architecture of this network, shown in Figure 1, follows a typical IoT structure. Specifically, multiple end-nodes, equipped with sensors of agricultural interest, transmit their data to a central station. The hardware part of the central station can be any computer that supports Bluetooth connectivity and has internet access. It must also be capable of running the necessary code to collect, store, and forward data to IoT cloud platforms. For example, the central station’s hardware could be a Raspberry Pi, a laptop, or a desktop computer equipped with a Bluetooth dongle.

6.2. The End-Nodes

The end-node consists of a microcontroller board equipped with sensors relevant to agriculture, such as temperature, humidity, soil moisture, and light sensors. While many microcontrollers are suitable for this purpose, we have chosen the Arduino Uno, primarily due to its strong community support, which enhances its effectiveness in educational settings [30]. To connect to the IoT, the end-node must be able to transmit data, typically through Bluetooth, GSM, WiFi, or LoRa. Figure 2 illustrates the hardware of the end-node and various options for wireless communication. As discussed in Section 4, we have selected Bluetooth for this implementation.

6.3. Decisions on the Level of Abstraction

When introducing software and hardware to non-CS students, it is essential to carefully consider the level of technical detail required for effective use. Our approach was developed based on the following guidelines:

• Software based on “click on button” actions. Any programming concept is hidden from the students, allowing them to focus on concepts of their scientific field instead. This is an obvious decision since we aimed to create a no-code platform.
• Abstract hardware. The students interact with the hardware of the end-node in a controlled manner that hides certain technical details that could consume time and discourage them.

Software abstraction is achieved through the no-code application we developed. Hardware abstraction is achieved by implementing the end-nodes using the programmable component of a newly developed educational robotics kit named Odysseus. Odysseus (or Ody, for short) was created as part of this research. It offers several features that make it particularly suitable for educational scenarios where hardware complexity must be minimized. In particular, students do not deal with individual cables; instead, each sensor has a dedicated plug designed to fit only its corresponding socket, eliminating the possibility of incorrect connections or short circuits.

Figure 3 shows the top view of the programmable component of Odysseus. Slots 1–8 contain the outputs (motors and LEDs), which are not used in the current version of our IoT educational platform (however, they will be used in the future for supporting actuators). Slots 12, 13, 14, and 15 are used for 3-pin sensors; slot 16 is used for the ultrasonic sensor (also not applicable in our case study), while slot 17 is used for any sensor that can be connected to the I²C bus. In the middle of the programmable component, there exists an OLED display (9), a power switch (10), as well as a switch for Bluetooth (11). It follows that Odysseus can handle up to 4 3-pin sensors and many I²C sensors by adding more sockets to the I²C bus. The right part of the figure shows the sensors currently supported in our case study, i.e., the (3-pin) obstacle sensor (18), the (3-pin) DHT11 temperature and humidity sensor (19), the (I²C) SI1151 sunlight sensor that returns visible light and IR light (20), and the (3-pin) soil moisture sensor (21).

The Bluetooth module of Odysseus is set to operate at 57,600 bps; however, this detail is intentionally hidden from the students. This decision aligns with our guideline of minimizing exposure to low-level technical tasks. Tasks such as configuring communication modules could distract students from their primary focus on precision agriculture.

Let us now discuss the abstraction of the code running in the Arduino (i.e., the firmware). Presenting the firmware as plain source code would serve little purpose, as students lack the background to interpret or understand it meaningfully. However, it is common practice in introductory Computer Science courses to use flowcharts as a way to visualize logical structures [31]. Figure 4 presents an abstract flowchart illustrating the logic implemented in the firmware. The core structure is an infinite loop, within which data is transmitted to the central station at predefined time intervals. This is achieved by checking whether the elapsed time since the last transmission exceeds the time interval. Whether this abstract flowchart is shown to students depends on the extent to which basic algorithmic concepts are included in the specific course curriculum.

6.4. The Central Station’s Software

6.4.1. Architecture and Possible Educational Scenarios

The software used by students to create their wireless sensor network (as depicted in Figure 1) is accessible via a web interface, implemented as the client side of a web server built using the Node.js framework. The server component, which runs in the central station, is responsible for collecting and storing the data transmitted by the end-nodes. This server can be executed on any computer running Windows, Linux, macOS, or Raspbian. For data storage, we have employed SQLite, a lightweight Relational Database Management System (RDBMS). Through this web server and its integrated database, students are provided with a dashboard that allows them to visualize sensor data through plots or perform SQL queries. This architecture offers significant flexibility in terms of the educational scenarios that can be supported and the underlying infrastructure required. The possible educational scenarios are outlined as follows:

• Isolated Node Mode (One-to-One): In this setup, the educational activity takes place in the lab, where the web server runs independently on each computer. As a result, each execution of the web server forms its own isolated network. Each student creates and tests a single end-node within a private network, allowing him or her to query and plot data from only that node. This scenario can be implemented even without Bluetooth by connecting the end-node directly to the computer via a USB cable. While this method only simulates wireless communication, it is sufficient for familiarizing students with end-node hardware and cloud IoT platform integration. Additionally, this setup enables students to continue working independently from home, provided they have an end-node and the central station’s software installed on their personal computer.
• Lab Network Mode (Many to One): The educational activity takes place in the lab, and the web server runs on a computer accessible by all the lab’s computers. Each student again handles one end-node and accesses the central station through one of the lab’s computers; thus, each end-node is connected to a different computer. This time, all the end-nodes enter the same network, and all students can plot and query data from all end-nodes. Again, the end-nodes can be wired to the computers (in which case we have a wired simulation of a wireless network) or connected with the computers via Bluetooth (in which case we have a wireless network).
• Field Deployment Mode (Many to One): The educational activity takes place in an outdoor setting, such as a greenhouse within the university campus. The educator brings a laptop to serve as the central station, running the server code. The sensors, positioned at close range, connect to the central station via Bluetooth and transmit their data.

6.4.2. User Interface

Figure 5 shows the buttons available to the students. The leftmost button is used for uploading the firmware to the Arduino wired to the student’s computer, transforming the Arduino into an end-node. Moving to the right, we see the button used to calibrate the end-node. Next to it is the “Start” button, which instructs the end-node to begin sending data to the central station. This function is used in both Isolated Node Mode and Lab Network Mode, where each student is responsible for one sensor. The “Database” button allows for writing SQL queries, and the “Dashboard” allows for plotting the stored data. Finally, the “Start Sensor Network” button initiates Field Deployment Mode. In this mode, the central station sends a command to all end-nodes connected to the computer. Once commanded, each end-node begins sending its data, which the central station then collects. Let us now explain the functionality of each button in more detail.

The leftmost button requires no action from the student other than connecting the Arduino to the computer via a USB cable. A single click uploads the firmware to the Arduino, transforming it into an end-node. To use the calibration button, the student must again connect the end-node to the computer via USB and complete a series of configuration steps. The first step involves selecting the target IoT platform to which the server will forward the data, or choosing the “local storage only” option (see Figure 6). If an IoT platform is selected, the student must then provide the necessary parameters to ensure successful data transmission.

For example, in Figure 6, the student selects the IoT cloud platform Ubidots [32]. After clicking OK, the student is prompted to enter the necessary parameters for sending data to Ubidots. This requires prior setup: the student must create an account on Ubidots and define a virtual device to receive data from the physical end-node. Figure 7 shows the HTML page for a virtual device named “my_end_node”, which includes a variable called “random_number”. This indicates that the device is configured to accept values labeled with that name. Students may define multiple variables per virtual device and create multiple virtual devices as needed.

On the left side of the page, the parameters associated with this virtual device are displayed. To enable our no-code platform to send data from the end-node to this virtual device, the user must copy the token and API label and paste them into the corresponding input fields on the right side of Figure 6. It is worth noting that all supported IoT cloud platforms offer limited free access, which helps to simplify the educational process.

The next step is to define the sensors connected to the Arduino. For each type of physical measure (e.g., temperature, humidity) provided by a sensor, the user must specify the Arduino pin to which the corresponding sensor is connected. The interface for entering this information is shown in Figure 8. To ensure compatibility with the virtual device shown in Figure 7, i.e., to send data labeled as “random_number”, the student must check the “Random number” option in Figure 8. The “Random number” option simulates a sensor by generating test values and can be used for experimentation or in cases where a real sensor is not available.

After configuring the sensors, the user defines the transmission policy, that is, the interval (in minutes) between consecutive data transmissions. The next step is to assign a unique number to the end-node, which it includes with each data packet for identification purposes. Finally, the type of network connection must be selected; currently, the platform supports either a wired or Bluetooth connection (but the code is the same for both cases). Once all parameters are configured, the user is asked to choose the appropriate COM port (corresponding to the connected end-node). Then, all settings are transmitted to the end-node and stored in its non-volatile memory. This calibration procedure is required only once. The end-node is now ready to transmit data, which can be initiated by clicking the “Start End-Node” button (for educational scenarios, “Isolated Node Mode” and “Lab Network Mode”), or the “Start Sensor Network” button (for “Field Deployment Mode”).

As previously mentioned, the data is stored locally on the server side. Through a built-in dashboard (see Figure 9), students can visualize the data from a selected node and specific attribute over a chosen time range (including all data, the last 24 h, or the last hour). This capability ensures that the educational scenarios remain fully functional even without the use of cloud platforms, which is particularly important in field settings where Internet access may not be available. In this context, our platform embraces the principles of edge computing, as data is processed and analyzed locally on the central station without reliance on external servers. This not only improves responsiveness but also introduces students to a computing paradigm that is increasingly important in modern IoT deployments.

The database scheme is simple and shown on the left part of Figure 10. The “Database” button in the main menu allows for writing SQL queries, as shown on the right part of Figure 10.

Finally, the “Start Network” button in the main menu enables students to initiate and monitor the wireless sensor network from a single web interface. As illustrated in Figure 11, this feature provides a real-time overview of the network’s operation. It allows users to observe connected nodes and incoming data streams in a consolidated and user-friendly environment. For this network to start, all end-nodes must be connected to the same computer—a requirement that characterizes the “Field Deployment Mode” educational scenario. The student adds end-nodes to the network one by one by clicking the “Insert End-Node” button. Each end-node appears in a list on the left side of Figure 11, initially labeled as “unknown” since communication has not yet begun and the central station has not received the nodes’ identifying information. Once all end-nodes have been inserted, the student clicks the “Start Network” button to begin data transmission. The central area of the screen displays real-time information for each node that sends data. Specifically, for every active node, students can see its name, the timestamp of the most recent data packet received, and the total number of data packets transmitted. For example, in Figure 11, the network currently consists of two end-nodes, named “Node 1” and “Node 2.”

7. Evaluation Framework

7.1. Overview

The no-code platform approach was incorporated into the informatics introductory course of the Department of Natural Sciences Development and Agricultural Engineering of the Agricultural University of Athens to evaluate its usability. According to the “Isolated Node Mode” educational scenario, the users (i.e., the students) created their end-nodes by plugging the sensors into the programmable component of Odysseus (see Figure 12). Then, they created accounts in cloud platforms, uploaded the firmware into the Arduino, and calibrated their end-node. Finally, they observed the sensor data either by plotting the locally stored data or by plotting the same data in the cloud platform they chose to create accounts. Upon completion of the scenario, they were asked to evaluate their experience with the no-code platform by completing a questionnaire aiming to answer the research questions stated in the following subsection.

7.2. Research Questions

The purpose of the evaluation was to answer the following research questions:

• Research Question 1 (RQ1): Is this platform useful according to the students?
• Research Question 2 (RQ2): Do the students intend to use this platform in the future?

As a tool for answering the above research questions, we chose the Technology Acceptance Model presented in the next subsection. Prior studies have adapted TAM for student populations in educational settings for this reason [33,34,35,36,37,38]. For this purpose, the TAM model was selected as the most appropriate validated tool, which attempts to explain and predict the leading factors to the use of Information Systems.

It is important to note that this study represents a pilot phase with a limited sample size, focusing primarily on assessing student engagement and the perceived usefulness of the platform. No objective measurements of conceptual learning outcomes were conducted in this evaluation. The aim was to gather preliminary insights into user acceptance and usability, with plans for future studies to include larger, more diverse samples and rigorous learning assessments to evaluate the platform’s educational impact more comprehensively.

7.3. The Technology Acceptance Model (TAM)

The platform’s evaluation was based on the Technology Acceptance Model (TAM) developed by Davis in 1989, which attempts to explain and predict the leading factors to the use of Information Systems [26]. It has also been used to evaluate engineering projects [27,28] based on hardware/software. It is based on Ajzen and Fishbein’s Theory of Reasoned Action (TRA), which identifies all those appropriate variables that could be used on the Information Systems’ acceptance [39] as shown in Figure 13.

TAM consists of key factors such as (i) External Variables (EV), (ii) Perceived Ease of Use (PEOU), (iii) Perceived Usefulness (PU), (iv) Attitude Towards Use (ATU), (v) Behavioral Intention to Use (BIU), and (vi) Actual Usage (AU), that try to explain the technology acceptance of a system [28].

According to Davis [29], the user acceptance of an Information System is a prerequisite for its technological effectiveness [40]. User acceptance can be evaluated and assessed by measuring the TAM’s Perceived Ease of Use (PEOU) and Perceived Usefulness (PU) factors.

7.3.1. External Variables

External variables are variables that shape the Perceived Ease of Use (PEOU) and Perceived Usefulness (PU) factors, such as the system’s features and characteristics, overall design, user experience, trust, security, and everything that boosts the user’s productivity, etc. [40,41].

7.3.2. Perceived Ease of Use (PEOU)

The Perceived Ease of Use (PEOU) factor is related to the user’s belief that the ease of using a system does not require too much effort. It is determined by the information system’s external variables.

7.3.3. Perceived Usefulness (PU)

The Perceived Usefulness (PU) factor is related to how the user believes that using the system will improve his/her performance. It has a direct effect from PEOU and external variables.

7.3.4. Attitude Towards Use (ATU)

The Attitude Towards Use (ATU) factor reflects the user’s evaluation of the Information System and their disposition towards its use. According to [26], ATU is jointly influenced by Perceived Usefulness (PU) and Perceived Ease of Use (PEOU). Their relative weights are typically determined through linear regression analysis.

7.3.5. Behavioural Intention to Use (BIU)

The Behavioural Intention to Use (BIU) factor refers to the user’s intention to use the Information System. It is directly affected by ATU and PU [26].

7.3.6. Actual Use

Lastly, Actual Use (AU) refers to the real-world utilization of the Information System, typically measured by metrics such as usage frequency or duration.

7.3.7. TAM’s Research Hypotheses

The present study was a pilot one (the research sample was not significantly large) to obtain initial evaluation data, identify the platform’s strengths and weaknesses, and gather a preliminary indication of students’ intention to use the no-code platform. Based on the TAM model and the prior research questions (RQ1, RQ2), two hypotheses were formulated for this initial measurement, as illustrated in Figure 14. Future research will expand on this foundation by including additional hypotheses related to the Actual Use (AU) factor of the no-code platform.

Hypothesis 1 (H1).

Perceived Ease of Use (PEOU) will have a significant influence on students’ Perceived Usefulness (PU) towards the No-Code platform’s use. It answers RQ1 (see Section 7.2).

Hypothesis 2 (H2).

Perceived Usefulness (PU) will have a significant influence on students’ Behavioral Intention to Use (BIU) towards the No-Code platform’s use. It answers RQ2 (see Section 7.2).

7.4. Research Methodology

7.4.1. Research Context and Participants

The acceptance of the no-code platform was evaluated by 39 undergraduate students from the Department of Natural Sciences Development and Agricultural Engineering of the Agricultural University of Athens. The educational activity described in the Isolated Node Mode scenario (see Section 6.4.1) was conducted in the lab, followed by the distribution of a questionnaire designed to assess the PU, PEOU, ATU, and BIU factors. Students were of the same age, background studies, and levels of graduate studies, so demographic information was not captured via the questionnaire.

Before the research, all ethical issues [42] were taken seriously. The researchers obtained the necessary permission to conduct the study from the university’s ethics department. The students filled out a consent form that informed them of the study’s objectives and outlined the procedure and terms of the research.

7.4.2. Instrument Development

Particular attention was given to keeping the questionnaire concise, which is why it consists of a single section focusing exclusively on the TAM factors. To this end, an online form was developed using Microsoft 365 Forms, incorporating items derived from the TAM model. Empirical data were collected through 14 questionnaire items designed to measure the key TAM constructs.

According to [29], four items are sufficient to construct the PU and PEOU dimensions of the TAM model. Therefore, in this study, each of the PU and PEOU constructs was measured using four items, which were adapted to fit the specific context of the platform, as presented in

Table 2. PEOU and PU items.

PEOU and PU Items:
PU Items
A1. Using the no-code platform helped me to better understand the basic concepts of IoT and wireless sensor networks.
A2. The no-code platform helped me increase my efficiency in managing sensor data and sending it to the cloud.
A3. The use of the no-code platform enhanced my learning experience on practical IoT-related topics.
A4. By using the no-code platform, I can implement IoT-related exercises more quickly and efficiently.
PEOU Items
A5. Learning to use the no-code platform was easy for me.
A6. I can easily use the no-code platform to design sensor networks and send data to the cloud.
A7. The user interface of the no-code platform is understandable and functional.
A8. I can easily acquire skills to use the no-code platform and apply my knowledge in the field of IoT.

.

TAM’s ATU and BIU factors were measured too, as shown below in

Table 3. ATU and BIU items.

ATU and BIU Items:
ATU Items
A9. Using the no-code platform is a positive experience in learning IoT technologies.
A10. I like the idea of using the no-code platform for my IoT training.
A11. Using the no-code platform is enjoyable and motivates me to learn more about the Internet of Things.
BIU Items
A12. I plan to continue to use the no-code platform in the future for the development of IoT applications in Agriculture.
A13. I would recommend the no-code platform to other students who want to learn about wireless sensor networks and IoT.
A14. I plan to use the no-code platform in other educational or research activities related to IoT

, but Actual Use was not measured as the no-code platform was not available for mass production and distribution.

The above TAM items were based on the original Davis’ TAM items [29], but were adapted to the research’s needs, translated into Greek, and then translated back to English to ensure translation equivalence [43]. For all of these items, a 5-point Likert scale from 1 to 5 was used to measure the TAM’s factors (

Table 4. The 5-point Likert scale used to measure the TAM’s items.

5-Point Likert Scale
1—Strongly disagree 2—Somewhat disagree 3—Neither agree nor disagree 4—Somewhat agree 5—Strongly agree

).

TAM’s independent variables were perceived ease of use (PEOU) and perceived usefulness (PU), while the dependent variables were attitude toward usage (ATU) and behavioral intention to use (BIU). (

Table 5. Dependent and Independent Variables of the TAM’s research model.

Variable Type	Variable Codes
Independent Variables	Perceived Ease of Use (PEOU) Perceived Usefulness (PU)
Dependent Variables	Attitude Towards Use (ATU) Behavioural Intention to Use (BIU)

).

8. Results

8.1. Validity and Reliability Analysis

At the beginning, the reliability and validity of the TAM variables (PU and PEOU) were checked. Reliability refers to the precision and consistency of a measurement, indicating its repeatability over time [27]. Validity, on the other hand, concerns the accuracy and correctness of the measurement [44]. To evaluate reliability, we employed both Cronbach’s Alpha (α) and McDonald’s Omega (ω) coefficients, which are widely accepted metrics for internal consistency [44,45].

To assess validity, Exploratory Factor Analysis (EFA) was conducted, following the guidelines of [46]. Additionally, the Average Variance Extracted (AVE) was calculated for each construct to evaluate convergent validity, which examines the degree to which multiple indicators of a given construct are correlated [43]. All statistical analyses were performed using the last version of Jamovi (version 1.6) [47], an open-source statistical software built on the R programming language.

8.2. Reliability Analysis

The Perceived Ease of Use (PEOU) construct yielded an average score of 4.17 (SD = 0.654; see

Table 6. Reliability analysis for PEOU.

Scale Reliability Statistics
	Mean	SD	Cronbach’s α	McDonald’s ω
Scale	4.17	0.654	0.785	0.794
Item Reliability Statistics
	If Item Dropped
	Cronbach’s α		McDonald’s ω
PEOU1	0.694		0.701
PEOU2	0.744		0.772
PEOU3	0.727		0.728
PEOU4	0.767		0.782

), indicating a generally high level of perceived ease of use among students. The internal consistency of the PEOU scale was acceptable, with a Cronbach’s alpha of 0.785, exceeding the commonly accepted threshold of 0.70 [48], and a McDonald’s Omega (ω) coefficient of 0.794. Furthermore, no improvement in reliability was observed when individual survey items were removed.

The Perceived Usefulness (PU) construct yielded an average score of 4.31 (SD = 0.671; see

Table 7. Reliability analysis for PU.

Scale Reliability Statistics
	Mean	SD	Cronbach’s α	McDonald’s ω
Scale	4.31	0.671	0.825	0.827
Item Reliability Statistics
	If Item Dropped
	Cronbach’s α		McDonald’s ω
PEOU1	0.805		0.805
PEOU2	0.768		0.773
PEOU3	0.756		0.760
PEOU4	0.785		0.788

), indicating a high level of perceived usefulness among students. The scale demonstrated strong internal consistency, with a Cronbach’s alpha of 0.825, exceeding the accepted threshold of 0.70, and a McDonald’s Omega (ω) coefficient of 0.827. Additionally, the reliability of the scale would not be improved by removing any individual items.

ATU and BIU displayed an average score of 4.33 (SD = 0.749) and 4.00 (SD = 0.841), respectively (see

Table 8. Descriptives for ATU, BIU.

	Attitude Towards Use (ATU)	Behavioural Intention to Use (BIU)
N	39	39
Missing	0	0
Mean	4.33	4.00
Standard deviation	0.749	0.841
Minimum	2.00	1.33
Maximum	5.00	5.00

), indicating that students showed a strong attitude towards and intention to use the no-code platform.

8.3. Validity Analysis

To perform Exploratory Factor Analysis (EFA), two key assumptions must be verified: sphericity and sampling adequacy. We assessed sphericity using Bartlett’s test of sphericity and sampling adequacy using the Kaiser–Meyer–Olkin (KMO) Measure of Sampling Adequacy (MSA).

Table 9. EFA’s assumption checks.

Bartlett’s Test of Sphericity
χ2	df	p
133	28	<0.001
KMO Measure of Sampling Adequacy
		MSA
Overall		0.826
PEOU1		0.840
PEOU2		0.867
PEOU3		0.730
PEOU4		0.866
PU1		0.696
PU2		0.862
PU3		0.830
PU4		0.885

shows the results.

Bartlett’s test yielded a p-value < 0.001, indicating statistical significance (as p < 0.05 is required), and thus confirming that the correlation matrix is not an identity matrix. The overall KMO index was 0.826, suggesting a high level of sampling adequacy (with values closer to 1 indicating greater suitability for factor analysis). Therefore, both assumptions were satisfied, supporting the appropriateness of EFA for the dataset [44].

We then examined the Eigenvalues (with values greater than 1 indicating a significant factor) and analyzed the Scree plot (see Figure 15) to identify the underlying data factors relevant to this research [44].

The factor loadings and statistics resulting from the Exploratory Factor Analysis (EFA) are presented in

Table 10. EFA’s factor loadings.

	Factor
	1	2	Uniqueness
PEOU1	0.776		0.406
PEOU2	0.617		0.605
PEOU3	0.868		0.328
PEOU4	0.493	0.342	0.518
PU1		0.905	0.237
PU2	0.546	0.454	0.314
PU3	0.355	0.517	0.472
PU4	0.514	0.387	0.442

Note. “Minimum residual” extraction method was used in combination with an “oblimin” rotation.

and

Table 11. EFA’s factor statistics.

Factor	SS Loadings	% of Variance	Cumulative %
1	2.88	36.0	36.0
2	1.80	22.5	58.5

, respectively. Both the extracted factors and their loadings align well with the theoretical constructs specified in the research model. The uniqueness values of the variables (indicating the variance not explained by the extracted factors) ranged between 0.237 and 0.605. According to [44], these values are considered good to excellent, signifying that the variables contribute meaningfully to the factor model.

8.4. No-Code Platform’s Level of Acceptance

Spearman’s rank-order correlation was employed to evaluate the research hypotheses by measuring the strength and direction of the associations between the relevant variables [27]. Prior to conducting the test, we verified that all three underlying assumptions were satisfied: (i) both variables are ordinal, (ii) the variables represent paired observations, and (iii) there exists a monotonic relationship between them. The results indicated a statistically significant and positive correlation between Perceived Ease of Use (PEOU) and Perceived Usefulness (PU), with Spearman’s rho = 0.609 and p < 0.001 (

Table 12. Spearman’s correlation matrix PEOU-PU.

		Perceived Ease of Use (PEOU)	Perceived Usefulness (PU)
Perceived Ease of Use (PEOU)	Spearman’s rho	—
	df	—
	p-value	—
	N	—
Perceived Usefulness (PU)	Spearman’s rho	0.609 ***	—
	df	37	—
	p-value	<0.001	—
	N	39	—

Note. * p < 0.05, ** p < 0.01, *** p < 0.001.

).

Hypothesis 1 (H1). 

Perceived Ease of Use (PEOU) will have a significant influence on students’ Perceived Usefulness (PU) towards the No-Code platform’s use.

To evaluate TAM’s Hypothesis 1 (H1), we conducted a linear regression analysis to examine whether Perceived Ease of Use (PEOU) significantly predicts Perceived Usefulness (PU). Prior to the analysis, we ensured that all seven assumptions of linear regression were met: (i) the dependent variable (PU) is measured at the continuous level, (ii) the independent variable (PEOU) is also measured at the continuous level, (iii) a linear relationship exists between PU and PEOU, (iv) the observations are independent, (v) there are no significant outliers, (vi) homoscedasticity is satisfied, and (vii) the residuals of the regression are normally distributed. The results showed that PEOU was a significant predictor of PU, R = 0.645, F(1, 37) = 26.4, p < 0.001 (

Table 13. H1—linear regression PU-PEOU.

Model Fit Measures
			Overall Model Test
Model	R	R2	F	df1	df2	p
1	0.645	0.416	26.4	1	37	<0.001
Model Coefficients—Perceived Usefulness (PU)
Predictor			Estimate	SE	t	p
Intercept			1.555	0.544	2.86	0.007
Perceived Ease of Use (PEOU)			0.661	0.129	5.13	<0.001

Note. Models estimated using sample size of N = 39.

).

Hypothesis 2 (H2). 

Perceived Usefulness (PU) will have a significant influence on students’ Behavioral Intention to Use (BIU) the No-Code educational platform.

To evaluate Hypothesis 2 (H2), we performed a linear regression analysis to examine whether Perceived Usefulness (PU) significantly predicts students’ Behavioral Intention to Use (BIU) the no-code platform. As with H1, we first confirmed that all seven assumptions of linear regression were satisfied: (i) the dependent variable (BIU) is continuous, (ii) the independent variable (PU) is continuous, (iii) there is a linear relationship between PU and BIU, (iv) observations are independent, (v) no significant outliers exist, (vi) homoscedasticity is present, and (vii) the residuals are normally distributed. The results indicated that PU was a significant predictor of BIU, R = 0.696, F(1, 37) = 34.7, p < 0.001 (

Table 14. H2—linear regression BIU-PU.

Model Fit Measures
			Overall Model Test
Model	R	R2	F	df1	df2	p
1	0.696	0.484	34.7	1	37	<0.001
Model Coefficients—Behavioural Intention to Use (BIU)
Predictor			Estimate	SE	t	p
Intercept			0.234	0.646	0.363	0.719
Perceived Usefulness (PU)			0.873	0.148	5.894	<0.001

Note. Models estimated using sample size of N = 39.

).

9. Discussion

This study was a pilot effort, and while the research sample was not particularly large, the results indicate a promising level of use and acceptance of the no-code platform by students. This is demonstrated in

Table 15. Descriptives PEOU-PU-ATU-BIU.

	Perceived Ease of Use (PEOU)	Perceived Usefulness (PU)	Attitude Towards Use (ATU)	Behavioural Intention to Use (BIU)
N	39	39	39	39
Missing	0	0	0	0
Mean	4.17	4.31	4.33	4.00
Standard deviation	0.654	0.671	0.749	0.841
Minimum	2.75	1.50	2.00	1.33
Maximum	5.00	5.00	5.00	5.00

.

Furthermore, the TAM model’s hypothesis (H1, H2) was confirmed, and showed a significant correlation between (i) PU and PEOU, (ii) PU and BIU (Figure 16). As a result, research questions RQ1 and RQ2 (introduced in Section 7.2) are also confirmed.

The findings offer valuable insights into the strengths and limitations of the proposed no-code IoT educational platform.

Let us start with the strengths. A key strength lies in the platform’s ability to allow students (particularly those without prior coding experience) to create fully functioning wireless sensor networks. Students engaged directly with IoT hardware while remaining focused on application logic rather than syntax or debugging. The platform’s ease of use (Mean PEOU = 4.17) and perceived usefulness (Mean PU = 4.31) suggest that it effectively lowers entry barriers and encourages learner autonomy. Importantly, students reported a strong positive attitude toward the platform and indicated a willingness to continue using it, pointing to its potential sustainability in curricula. It seems that the platform enabled learners to engage with core IoT concepts and workflows, from sensor configuration to data visualization. This supports the view that no-code platforms can lower barriers to entry and promote meaningful learning in interdisciplinary education.

Another strength of this work is that it addresses a relatively unexplored area in IoT education by delivering a solution specifically tailored for non-CS educational settings. Although some efforts in this direction exist (e.g., [23,24,25]), to our knowledge, this is the first platform that integrates real IoT hardware, a fully no-code interface, and classroom-ready deployment for non-technical learners, combined with off-the-shelf hardware and minimal construction cost.

In short, the platform’s strengths are its low cost, scalability, open philosophy (in terms of hardware and software), focus on agricultural students, and programming without the use of code.

Let us now report the weaknesses. While the findings are promising, the small sample size and short evaluation period naturally limit the generalizability of the results. Additionally, as the TAM model centers on students’ perceptions and intended use rather than measurable learning outcomes, it does not provide direct insight into long-term knowledge acquisition or retention. To address these limitations, future research will involve a larger and more diverse participant pool and will incorporate complementary evaluation methods aimed at assessing actual learning gains and sustained engagement with the platform.

10. Conclusions and Future Work

The main contribution of this research is the design, implementation, and preliminary evaluation of a no-code educational platform that enables students with no prior programming experience to build and deploy real IoT sensor networks. Unlike most existing tools, which require technical programming knowledge, this platform uniquely combines a no-code interface with hands-on hardware deployment, using off-the-shelf components and minimal infrastructure (e.g., Bluetooth). Students were able to configure sensor nodes, define transmission parameters, and visualize collected data through an intuitive graphical interface, all without writing code.

The platform was evaluated through a pilot study involving 39 undergraduate students in the Department of Natural Sciences Development and Agricultural Engineering of the Agricultural University of Athens. Based on the Technology Acceptance Model (TAM), students reported strong levels of perceived ease of use and usefulness, and expressed positive attitudes and behavioral intentions towards future use. These results support the platform’s potential as a viable learning tool for IoT concepts in non-technical academic contexts. Further studies will also explore long-term usage and potentially integrate lightweight assessments of conceptual understanding and skill transfer in real-world problem-solving scenarios.

Although the evaluation was limited to a single course with a relatively small sample size, the platform’s design responds directly to the realities of the curriculum: students had no prior programming knowledge and no prior exposure to practical IoT activities. Keeping in mind that a programming course may not exist at all in the curriculum, it follows that the no-code approach is not just beneficial, it is essential.

Our work regarding this platform is not over. Future work includes deploying the platform across different departments and institutions and increasing its openness for wider use. Extending the range of supported hardware and communication technologies is also an interesting research direction, as it will allow deployment into real-world environments. In agricultural settings, supporting Long Range communications (LoRaWAN) is the crucial step towards this target. Allowing two-way communications with the end-nodes is also a logical next step because it will allow for incorporating actuators into the end-nodes. After performing these enhancements, we plan to focus on comparing our platform with existing no-code IoT educational platforms.