Department of Computer Engineering

Faculty of Science and Technology

A
Preliminary Project Report on

Lead-Nexus: AI-Driven B2B Lead Management Portal

Submitted to Vishwakarma University, Pune
In the partial fulfilment for the award of the degree of
BACHELOR OF TECHNOLOGY
IN
COMPUTER ENGINEERING

By
Atharva Meherkar (202201684)
Vedant Telgar (202201670)
Yash Joshi (202201675)
Usman Khan (202201416)
Akash Mirande (202201419)

UNDER THE GUIDANCE OF

Prof. Aarti Bhargav Patel

Academic Year
2024-2025
 CERTIFICATE
This is to certify that the project report entitled

Lead-Nexus: AI-Driven B2B Lead Management Portal

Atharva Meherkar (202201684)
Vedant Telgar (202201670)
Yash Joshi (202201675)
Usman Khan (202201416)
Akash Mirande (202201419)

is a Bonafide work carried out by them under the supervision of Prof. Aarti Bhargav Patel and it
is approved for the partial fulfilment of the requirement of Vishwakarma University for the award
of the Degree of Bachelor of Technology in Computer Engineering.

This project report has not been earlier submitted to any other Institute or University for the award
of any degree or diploma.

Prof. Aarti Bhargav Patel Reshma Pise

Internal Guide Head of Department

Department of Computer Engineering Department of Computer Engineering

Dr. Kailash Patil

Dean

External Examiner:
Place:

Date: 22/05/2025

DECLARATION

We here by declare that this submission is our own work and that, to the best of our knowledge and
belief, it contains no material previously published or written by another person nor material which
has been accepted for the award of any other degree or diploma of the university or other institute
of higher learning, except where due acknowledgement has been made in the text.

Place: Date: 22/05/2025

Signature:

Atharva (58)

Vedant Telgar (56)

Yash Joshi (57)

Usman Khan (02)

Akash Mirande (04) Signature

 ACKNOWLEDGEMENT

We, the project team members, wish to express our sincere gratitude to all those who have
supported and guided us throughout Stage 1 of our project, "iNexus: [Your App's Tagline,
e.g., Secure IoT Device Management Portal]". This endeavour would not have been
possible without their invaluable contributions and encouragement.

First and foremost, we extend our deepest appreciation to our esteemed Internal Guide,
[Your Guide's Name/Title, e.g., Prof. [Name], Department of Computer Engineering].
[His/Her/Their] insightful guidance, continuous support, and expert mentorship have been
instrumental in shaping the direction of this project. [His/Her/Their] willingness to dedicate
[his/her/their] time and share [his/her/their] profound knowledge has not only helped us
navigate complex technical challenges but has also inspired us to strive for excellence.

We are thankful to the Department of Computer Engineering and the Faculty of Science
and Technology, Vishwakarma University, Pune, for providing us with the necessary
academic environment, resources, and infrastructure to undertake this project. The
curriculum and learning opportunities have equipped us with the foundational skills crucial
for this work.

We would also like to acknowledge our fellow team members for the collaborative spirit,
dedication, and hard work that each individual has contributed. The synergy within our
group, comprising Atharva Shevate, Ayush Herkal, Pranav Karanjkar, Atharva Lohote,
and Adiraj Chinchpure, has been a key factor in successfully completing this initial stage.
Each member's unique skills and commitment have been invaluable

Name of Students:

Atharva Meherkar (202201684)

Vedant Telgar (202201670)

Yash Joshi (202201675)

Usman Khan (202201416)

Akash Mirande (202201419)

 ABSTRACT
This report details the successful completion of Stage 1 for the "iNexus: Secure IoT Device
Management Portal" project, a mobile- rst application designed to address critical challenges in
current local IoT device management and rmware update practices. Businesses and individuals
frequently encounter inef ciencies stemming from manual device status checks, insecure and
fragmented update procedures, and a lack of intelligent, centralized local control, which collectively
hinder operational effectiveness and device security.

Stage 1 of the iNexus project was strategically focused on establishing a robust foundation through
comprehensive planning, in-depth research, meticulous technology stack selection, rigorous system
architecture design, and the development of a core Minimum Viable Product (MVP). The primary
objectives for Stage 1 encompassed the de nition of the project's scope and requirements, a
thorough investigation into existing local IoT communication patterns, and the architectural
blueprinting of a scalable and secure platform.

Key deliverables included a functional Flutter-based MVP demonstrating core functionalities such
as:

• User-initiated direct device connection via IP address and port.

• Real-time display of device status (Online/Of ine).
• Retrieval and display of device information (IP address, rmware version, OTA capability,
security features).
• A framework for secure rmware upload, including client-side le selection and AES-256
encryption.
• Con rmation of successful real-time communication between the Flutter application and the
physical ESP8266/ESP32 IoT device over Wi-Fi.
The technology stack chosen to realize this MVP and to support future enhancements includes
Flutter and Dart for the mobile- rst responsive frontend, NodeMCU/ESP32 rmware (C++/
Arduino) for the IoT device's server-side logic, the http package for real network
communication, and the encrypt package for client-side AES encryption. Local storage for
recent device IPs is handled by shared_preferences.

The outcomes of Stage 1 are a validated MVP that proves the viability of core local IoT connection
concepts, a comprehensive system design that accommodates future integration of advanced secure
OTA update features, and a clear, strategic roadmap for subsequent development phases. This initial
stage has successfully laid the groundwork for iNexus to evolve into a transformative platform that
enhances local IoT device management, ensures secure updates, and fosters a transparent,
centralized control ecosystem.

Keywords:
IoT Device Management, Over-The-Air (OTA) Firmware Update, Embedded Systems,
Flutter, Dart, ESP32, ESP8266, Network Communication, AES Encryption, Mobile-First Web
App, Responsive UI, Local Wi-Fi, Real-time Status, System Architecture, Minimum Viable
Product (MVP), Secure Communication.

TABLE OF CONTENTS
fi
fi
fi
fi
fi
fi
fi
fl
fi
fi
fi
 CERTIFICATE I

DECLARATION II
ACKNOWLEDGEMENT III

ABSTRACT IV

TABLE OF CONTENTS V

LIST OF FIGURES VII

LIST OF TABLES VIII

CHAPTERS TITLE Page No.

1. INTRODUCTION 1-2
1.1 Motivation 2
1.2 Need 2
2. LITERATURE SURVEY 3
2.1 Literature survey 3
3. PROBLEM STATEMENT 8-9
3.1 Objectives 8
3.2 Feasibility Study 8
4. Project Requirements 10
4.1 Software Requirements. 10
4.2 Hardware Requirements 11
5. SYSTEM ANALYSIS OF PROPOSED ARCHITECTURE 11-23
5.1 System Architecture Diagram 11
5.2 Data Flow Diagrams 13
5.3 UML Diagrams
5.3.1 Use case Diagram 16
5.3.2 Activity Diagram 17
 5.3.3 Sequence Diagram 19
5.3.4 State Diagram 20
5.3.5 Deployment Diagram 21
5.3.6 Component Diagram 22
5.3.7 Class Diagram 23
6. IMPLEMENTATION
6.1 Methodology 24
6.2 System Overview 25
7. PROJECT PLAN 27

8. CONCLUSION 28

9 REFERENCES 29

LIST OF FIGURES

Figure
Name of Figure Approx. Page No. (within 30-page report)
No.

Lead-Nexus High-Level System

3.1 11 (within System Analysis)
Architecture

DFD - Vendor Lead Upload

3.2 13 (within System Analysis)
Process

DFD - Client Lead Search &

3.3 14 (within System Analysis)
Mock Purchase Process

Lead-Nexus MVP Use Case

3.4 16 (within System Analysis)
Diagram

Activity Diagram: Vendor Lead

3.5 17 (within System Analysis)
Upload Process
 Sequence Diagram - MVP Lead
3.6 19 (within System Analysis)
Purchase (Mock Payment)

3.7 State Diagram: Lead Lifecycle 20 (within System Analysis)

Deployment Diagram: MVP on

3.8 21 (within System Analysis)
AWS

Component Diagram: MVP

3.9 22 (within System Analysis)
Components

Class Diagram: MVP Core

3.10 23 (within System Analysis)
Entities

(Often part of Database Architecture, can be same as

(ERD) Lead-Nexus Core Entities ERD
Class Diagram or separate, approx. Page 19-20)

LIST OF TABLES

Table Approx. Page No. (within 30-page

Name of Table
No. report)

1.1 Stakeholder Analysis 2 (within Introduction)

Competitor Feature Matrix and Lead-Nexus

2.1 3 (within Literature Survey)
Positioning

3.1 Technology Stack Justification 9 (within System Analysis)

18 (within System Analysis -

3.2 PostgreSQL companies Table Schema
Database)
 18 (within System Analysis -
3.3 PostgreSQL leads Table Schema
Database)

MVP Feature Implementation Status and Key

4.1 22 (within Implementation)
Details (Stage 1)

Stage 1 Weekly Task Breakdown and Deliverables

6.1 24 (within Project Plan)
(Planned)

6.2 Stage 1 Risk Register and Mitigation Strategies 25 (within Project Plan)

Chapter 1
INTRODUCTION
The pervasive growth of Internet of Things (IoT) devices, particularly within local and private
network environments, presents a substantial opportunity for enhanced automation and data
collection. However, the effective management and secure maintenance of these devices
consistently encounter signi cant operational friction and inef ciencies. A predominant set of
challenges includes the often laborious, time-consuming, and insecure nature of manual device
status checks and rmware update processes. This manual intervention consumes valuable
human resources and introduces delays, potential vulnerabilities, and operational downtime.

Furthermore, a pervasive lack of real-time visibility and transparency regarding device status,
rmware versions, and security con gurations on the local network often leads to uncertainty about
data integrity, device authenticity, and overall operational health. Many organizations and
individuals also grapple with the use of disparate and non-integrated software tools for various
aspects of local IoT device interaction. This fragmentation results in complex work ows, hindering
effective and secure management, especially when scaling beyond a few devices.

While basic network protocols provide connectivity, they often fall short of addressing the nuanced
requirements of a specialized IoT device environment, such as secure, client-side encrypted
rmware delivery or transparent mechanisms for verifying device provenance. The iNexus project
addresses these widely acknowledged inef ciencies in local IoT device management.

Motivation
The motivation for iNexus stems from the transformative potential of cutting-edge technologies to
address these enduring challenges in local IoT device management. The rapid advancements in
fi
fi
fi
fi
fi
fi
fi
fl
 cross-platform mobile development (Flutter), compact embedded systems (ESP32/
NodeMCU), secure local communication protocols, and client-side data processing present
unprecedented opportunities to fundamentally re-engineer traditional device interaction and
maintenance processes.

There is a compelling opportunity to move away from laborious manual interventions, insecure
update methods, and fragmented local management tools towards more intelligent, automated,
proactive, and trustworthy systems for IoT devices. The vision is to create a uni ed,
comprehensive platform that not only centralizes local device management but also intelligently
enhances device security, simpli es Over-The-Air (OTA) rmware updates, and cultivates a
transparent, collaborative ecosystem for all local IoT device interactions.

Need
The critical and increasingly urgent need for such a platform is evident. Businesses and users
require a solution that can:

• Automate Tedious Processes: Reduce the burden of manual device status checks, basic
con guration, and rmware update initiation.
• Enhance Device Security & Reliability: Provide a secure and reliable mechanism for
maintaining device software, mitigating vulnerabilities introduced by insecure update
methods.
• Provide Real-time Device Visibility: Offer clear, immediate insights into device online/
of ine status, rmware versions, and key security features without physical inspection.
• Simplify Local Device Management: Break down complexities of interacting with IoT
devices locally and enable seamless management from a uni ed application.
• Ensure Device Integrity & Secure Practices: Adhere to secure communication principles,
minimizing the risk of data interception or unauthorized rmware tampering during updates.
• Offer Immediate Operational Insights: Leverage real-time device status to inform
proactive maintenance and troubleshooting decisions.

LITERATURE SURVEY
The design and development strategy for iNexus, particularly in its foundational Stage 1, were
signi cantly informed by a comprehensive review of existing academic research and prevailing
industry trends across IoT device management, embedded systems communication, cross-platform
application development, and cybersecurity best practices for connected devices. This review was
instrumental in validating the project's core assumptions, guiding technology choices, and
identifying opportunities for innovation in the local IoT domain.

Key research areas that shaped the project include:

• Cross-Platform Application Development for IoT: Studies demonstrating the ef ciency

and performance of frameworks like Flutter in developing user interfaces for IoT control
have been crucial. Research such as Choi, G. H., Kim, S. H., & Park, J. H. (2023).
"Implementation of Smart Home Control System Using Flutter and ESP32." (e.g., in a
conference like the IEEE International Conference on Information and Communication
Technology Convergence) highlights the bene ts of a single codebase for mobile and web
deployment, informing iNexus's choice of Flutter for rapid development and broad
accessibility for local device interaction.

• Secure Over-The-Air (OTA) Firmware Update Mechanisms: Investigations into robust

and secure OTA update methodologies speci cally for resource-constrained embedded
fl
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
 devices like ESP32 have guided our architectural planning for the rmware update
component. Papers such as Perera, A. G., & Perera, A. R. S. (2023). "A Secure Firmware
Over-The-Air (FOTA) Update Mechanism for ESP32-based IoT Devices." (e.g.,
published in an IEEE journal or conference proceedings) inform the need for secure
protocols beyond basic HTTP.

• Ef cient AES Encryption on Microcontrollers: Understanding the feasibility and

performance of cryptographic implementations on limited hardware resources is vital for
client-side encryption and device-side decryption. Research like Al-Zoubi, M. K. K., & Al-
Ajlouni, A. A. (2022). "Ef cient AES Implementation on Resource-Constrained IoT
Devices." (e.g., in a journal like International Journal of Computer Applications) provides
insights into optimizing AES algorithms for ESP32/ESP8266 platforms.

• Local Wireless Communication Protocols for IoT: Analysis of various local network
communication patterns and protocols has helped validate the choice of direct HTTP over
Wi-Fi for device status and control. Studies like Lee, J. S., & Kim, H. J. (2022).
"Performance Analysis of Local Wireless Communication Protocols for IoT
Applications." (e.g., in a journal focused on wireless communication) inform the design for
ef cient and reliable peer-to-peer device interaction within a local Wi-Fi network.

This evidence-based approach ensures iNexus is built upon a solid theoretical and empirical
foundation, addressing common challenges in the local IoT ecosystem.

PROBLEM STATEMENT
The central problem that the iNexus project aims to address is formally articulated as: "Businesses
and users face critical inef ciencies in local IoT device management due to laborious manual
interactions, insecure update processes, and fragmented local management tools. Existing
approaches often lack real-time visibility and robust secure communication, resulting in operational
delays, device vulnerabilities, and limited control. Our platform will address these gaps by
automating device status retrieval, enabling secure and streamlined rmware updates, and ensuring
veri able device integrity locally."

This overarching problem encompasses several critical, interconnected challenges:

• Lack of Real-time Device Insight & Automated Status: Many existing local IoT setups
require manual checks or complex con gurations to ascertain device online/of ine status,
current rmware version, or operational health.
• Time-Consuming and Insecure Manual Device Updates: Manual ashing of rmware is
inef cient and prone to error, while unencrypted OTA updates expose devices to signi cant
security risks like eavesdropping or tampering on the local network.
• Fragmented Tools and Lack of Integrated Work ows: Users often resort to a patchwork
of disparate tools and manual steps for different aspects of local device management,
hindering a uni ed and ef cient control experience.
• Absence of Comprehensive Automation for Local Device Maintenance: Beyond simple
control, there is a lack of integrated solutions for automating routine maintenance tasks,
such as periodic status checks or scheduled updates.
The core research question iNexus seeks to answer is: "How can a local IoT device management
application be designed and developed to effectively integrate secure communication for automated
status retrieval and encrypted Over-The-Air (OTA) updates, ensure veri able device integrity, and
foster a seamless, ef cient environment to signi cantly improve the manageability and
effectiveness of the local IoT device lifecycle?”
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fl
fi
fi
fl
fi
fl
fi
fi
 Stage 1 justi es its approach by laying a robust foundational groundwork through meticulous
planning, research, architectural design, and the development of an MVP to validate key concepts.

Objectives
The objectives for Stage 1 of iNexus were de ned to deliver a functional core and a robust design
capable of supporting future advanced features in local IoT device management.

Functional Objectives (Stage 1 MVP):

•
Develop a secure connection mechanism to IoT devices via IP address and port,
demonstrating successful network handshake.
• Implement real-time device status retrieval, displaying online/of ine status and IP
address from the connected device.
• Enable basic device information display, including current rmware version, OTA
capability status, and reported security features.
• Implement client-side AES-256 encryption for rmware les, showcasing the preparation
for secure data transmission.
• Design the core data model (DeviceInfo) for consistent representation of IoT device
information within the application.
• De ne a scalable and secure system architecture for local app-device communication.
Non-Functional Objectives (Stage 1 Design Principles & MVP Attributes):

• Ensure a mobile- rst, responsive, and usable UI for the MVP across various screen sizes
and web browsers (via Flutter).
• Design for future sub-second (<1s) device status retrieval times for a uid user
experience.
• Architect for robust local device connectivity and app stability, minimizing connection
failures and crashes.
• Establish secure client-side data handling practices and lay the groundwork for device-
side security features in future stages.
o

Feasibility Study
A feasibility assessment conducted for Stage 1 con rmed the project's viability within available
resources and constraints.

• Technical Feasibility: The chosen technology stack (Flutter with Dart for the
application, and ESP32/NodeMCU (C++/Arduino) for the embedded device rmware)
is mature, well-documented, and boasts strong community support. The team possessed
foundational skills in app development, embedded programming, and network
communication, making the technical challenges surmountable. Access to necessary
hardware (ESP32/NodeMCU boards, USB cables, Wi-Fi network) was readily available.
The local network communication paradigm minimized external API dependencies for core
functionality.

• Financial Feasibility (Stage 1): Costs were minimized by leveraging primarily open-source
development tools (Flutter SDK, Arduino IDE, Visual Studio Code) and inexpensive
microcontroller hardware. Since the core functionality revolves around local Wi-Fi
communication without a dedicated cloud backend for direct device interaction, there were
no recurring hosting or signi cant external API costs for the MVP. Development was
estimated at $0-$5k (primarily representing team effort and minor hardware purchases).
Funding relied on university resources or bootstrapping.
fi
fi
fi
fi
fi
fi
fi
fi
fi
fl
fl
fi
 • Time Feasibility (Stage 1): The 6-8 week timeframe allocated for foundational research,
architectural design, and core MVP development (including establishing real app-device
communication and basic secure framework) was deemed realistic and was largely met
within the academic calendar.

• Security & Integrity Feasibility: Early awareness of the critical importance of device
integrity and secure communication practices in IoT was demonstrated. The MVP design
incorporated foundational elements to support client-side AES encryption for rmware les
and laid the groundwork for device-side decryption and validation, acknowledging the need
to mitigate risks like unauthorized rmware tampering within the local network.

PROJECT REQUIREMENTS
The successful execution of iNexus hinges on ful lling a comprehensive set of technical and non-
technical requirements. The "Checklist of Requirements.docx" (or equivalent) provides a detailed
breakdown. For Stage 1, the focus was on the software and hardware necessary for MVP
development and establishing the foundational architecture for local IoT device management.

Software Requirements The software requirements span development tools, programming

languages, frameworks, libraries, device-side components, and development practices.

Operating Systems:

• Development: Windows, macOS, or Linux (for Flutter development environment).

• IoT Device Firmware: Real-time operating system (RTOS) capabilities often integrated
within the ESP-IDF/Arduino framework, or bare-metal execution.
Programming Languages & Frameworks/Libraries:

• Application Frontend (Cross-Platform):

◦ Framework: Flutter (Google's UI toolkit for building natively compiled applications
from a single codebase).
◦ Language: Dart (v3.x - Google's programming language optimized for UI).
◦ State Management: Provider (for managing application state across widgets).
◦ Routing: go_router (for declarative and type-safe routing).
◦ HTTP Communication: http package (for making actual network requests to IoT
devices).
◦ File Selection: file_picker (for allowing users to select rmware .bin les).
◦ Encryption: encrypt package (for client-side AES-256 encryption).
◦ UI Feedback: fluttertoast (for displaying transient success/error messages).
◦ UI Elements/Animations: flutter_spinkit (for loading indicators),
Material Design widgets.
◦ Local Storage: shared_preferences (for storing recent device IPs).
• IoT Device Firmware (Embedded Server):
◦ Language: C++ (with Arduino Framework for ESP32/ESP8266).
◦ Web Server: ESP8266WebServer (for ESP8266) or WebServer (for
ESP32) (for HTTP communication).
◦ Wi-Fi Connectivity: ESP8266WiFi (for ESP8266) or WiFi (for ESP32).
◦ OTA Updates: ArduinoOTA, Update (for Over-The-Air rmware update
functionality).
◦ mDNS Discovery: ESPmDNS (for ESP32) or ESP8266mDNS (for ESP8266) (for
local network device discovery).
fi
fi
fi
fi
fi
fi
fi
 ◦
Encryption (Future/Full Scope): Crypto library (for device-side AES
decryption).
Data Storage & Models:

• Client-Side Local Storage: shared_preferences (for recent IP addresses and app

settings).
• IoT Device Data Model: Custom Dart classes (e.g., DeviceInfo in lib/models)
for structured representation of device data exchanged via JSON.
• Device-Side Persistence: Microcontroller's Flash Memory (for storing rmware, and
potentially small con guration data using SPIFFS/LittleFS).
Embedded Web Server:

• Implemented directly on the IoT device using C++/Arduino libraries

(ESP8266WebServer / WebServer).
Version Control:

• Git (distributed version control system).

• GitHub (for remote repository hosting and team collaboration).
Containerization & CI/CD (Future Consideration/Advanced Setup):

• Docker (for containerizing Flutter development environments or build agents).

• GitHub Actions (for continuous integration and continuous delivery pipelines, e.g.,
automated builds/tests).
Development Tools & IDEs:

• VS Code (primary IDE for Flutter/Dart application development).

• Arduino IDE or PlatformIO (for embedded C++/Arduino rmware development).
• Flutter SDK CLI (for building, running, and managing Flutter projects).
• Dart SDK (included with Flutter SDK).
• Postman (for testing IoT device API endpoints directly).
• Fritzing (for circuit diagrams and hardware prototyping visualization).
Third-Party Service APIs (Not applicable for core local MVP):

• The core functionality of iNexus (local device management and OTA) does not rely on
external cloud APIs or third-party web services. All communication is direct over the local
network.
o

Hardware Requirements
For Stage 1 (MVP development and initial testing), the hardware requirements were primarily
standard development equipment for the team members and the necessary IoT devices.

• Development Machines:

◦
Standard modern laptops or desktop computers (e.g., Intel Core i5/i7 or AMD Ryzen
equivalent, Apple M-series chips) with at least 8GB RAM (16GB recommended)
and SSD storage.
◦ Reliable internet connection.
• IoT Device Hardware:

◦ESP32 or NodeMCU (ESP8266) Board: Wi-Fi enabled microcontroller board.

◦USB-to-Serial Connectivity: Integrated on board or via external converter, with a
compatible USB cable for ashing rmware.
• Target Mobile Devices/Emulators:
fi
fl
fi
fi
fi
 ◦ Access to various Android smartphones/emulators or iOS devices/simulators for
testing the Flutter application's functionality and responsiveness.

This section details the architectural design of the iNexus platform as conceptualized and partially
implemented in Stage 1. It covers the high-level system overview, app-device communication ow,
and key UML diagrams illustrating structure and behavior.

3.1 System Architecture Diagram

The system architecture for iNexus is designed as a modular, scalable, and resilient platform,
focusing on direct local communication between the mobile application and IoT devices.

Figure3.1:iNexusHigh−LevelSystemArchitecture

High-Level System Architecture: Users interact with the Flutter Application (iNexus) via its UI.
The Flutter app communicates directly with the IoT Device (ESP32/NodeMCU rmware) over the
Local Wi-Fi Network using standard HTTP. The IoT device acts as a small web server, responding
to status queries and accepting rmware updates.

• Client (Flutter App): Provides UI, manages state, handles client-side encryption, and
initiates HTTP requests.
• IoT Device (ESP32/NodeMCU): Runs custom rmware (C++/Arduino), hosts a web
server, and processes requests/responses.
• Local Wi-Fi Network: The common medium for communication between the app and the
device.
This layered architecture ensures modularity and maintainability for future enhancements.

4. IMPLEMENTATION

This section outlines the methodology adopted for the Stage 1 MVP development and provides a
high-level overview of the system's core functionalities and architecture.

4.1 Methodology

The iNexus project, during Stage 1, adopted an Agile/Scrum methodology. This iterative approach
accommodated MVP development, allowing for exibility, continuous feedback, and adaptation.
Key aspects included:

• Iterative Development: Core features were developed in short sprints.

• Requirement Prioritization: Focus on delivering critical MVP functionalities rst.
• Regular Reviews & Collaboration: Weekly meetings for progress review and planning.
• Documentation: Key decisions and progress were documented.
The Constructive Research paradigm also guided Stage 1, building a novel artifact (iNexus) to
solve identi ed problems in local IoT device management.

4.2 System Overview

The iNexus platform, as envisioned and with its core established in the Stage 1 MVP, is a secure
local IoT device management application. Its primary purpose is to provide a uni ed, ef cient, and
transparent way for users to manage and interact with their IoT devices over Wi-Fi.

Core Functionalities (MVP Stage 1):

• Device Management: Secure connection and real-time status display for IoT devices.
fi
fi
fi
fl
fi
fi
fi
fi
fl
 • Device Information: Retrieval and display of rmware version, OTA capability, and
security features.
• Secure Update Framework: Client-side AES-256 encryption for rmware les, ready for
device-side decryption.
• Real Communication: Proven app-to-device communication over local Wi-Fi for status
retrieval.
Technical Architecture Overview: The system employs a modern, multi-tiered architecture:

• Frontend: Flutter (Dart) provides a responsive cross-platform UI.

• Device Backend: NodeMCU/ESP32 rmware (C++/Arduino) acts as the embedded web
server, handling device logic and communication.
• Data Storage: Client-side local storage (shared_preferences) for recent IPs;
device Flash Memory for rmware/settings.
Key Differentiators (Long-Term Vision): While Stage 1 focused on core functionalities, the long-
term vision includes:

• Full OTA integration with device-side decryption and validation.

• Advanced device discovery (e.g., mDNS).
• Expanded device control and automation.
• Robust device integrity checks.
The project plan is agile, adapting to learnings and feedback. Stage 1's success provides con dence
in executing this plan.

5. PROJECT PLAN

The project plan for iNexus is structured in phases, with Stage 1 (MVP development) being the
foundational step. The overall project timeline outlines a multi-phase development cycle.

5.1 Stage 1 Completion (Recap):

Stage 1, focused on research, design, and MVP development, was executed over approximately 6-8
weeks, following a detailed 6-week task breakdown:

• Weeks 1-2: Problem de nition, competitor research, technology stack selection.

• Week 3: UML diagrams, core data model design.
• Weeks 4-5: Flutter app MVP development (UI, state, basic connectivity, encryption
framework).
• Week 6: Integration, initial testing, nal Stage 1 report preparation.
5.2 Subsequent Project Phases (High-Level Plan):

• Phase 2: Core Enhancements & Initial Advanced Feature Integration (Approx. Months
3-4 overall)

◦ Tasks: Implement full OTA update functionality (device-side decryption), re ne

device-side communication robustness, begin advanced device discovery integration.
◦ Focus: Stabilizing core secure update capabilities and introducing initial smart
interaction features.
• Phase 3: Advanced Feature Development & Beta Testing (Approx. Month 5 overall)

◦ Tasks: Implement advanced device control and automation, integrate expanded

sensor/actuator interactions, conduct structured beta testing with pilot users to gather
feedback.
fi
fi
fi
fi
fi
fi
fi
fi
fi
 ◦ Focus: Validating advanced automation and gathering real-world user feedback on a
more feature-rich platform.
• Phase 4: Launch & Iterative Improvement (Approx. Month 6 and beyond)

◦ Tasks: Based on beta feedback, make nal re nements and of cially launch iNexus.
Establish processes for ongoing development, feature rollout, maintenance, and user
support.
◦ Focus: Bringing the product to market and establishing a cycle of continuous
improvement based on live user data and feedback.
5.3 Long-Term Development Roadmap:

The project envisions continued development post-launch to incorporate the full suite of advanced
features, including:

• AI-Powered insights for device health/predictive maintenance.

• Advanced device security (e.g., secure boot integration).
• Expanded third-party IoT platform integrations (if applicable).
• Cloud-backed features for remote management (optional, beyond local scope).
This section details the architectural design of the iNexus platform as conceptualized and partially
implemented in Stage 1. It covers the high-level system overview, app-device communication ow,
and key UML diagrams illustrating structure and behavior.

3.1 System Architecture Diagram

The system architecture for iNexus is designed as a modular, scalable, and resilient platform,
focusing on direct local communication between the mobile application and IoT devices.

Figure3.1:iNexusHigh−LevelSystemArchitecture

High-Level System Architecture: Users interact with the Flutter Application (iNexus) via its UI.
The Flutter app communicates directly with the IoT Device (ESP32/NodeMCU rmware) over the
Local Wi-Fi Network using standard HTTP. The IoT device acts as a small web server, responding
to status queries and accepting rmware updates.

• Client (Flutter App): Provides UI, manages state, handles client-side encryption, and
initiates HTTP requests.
• IoT Device (ESP32/NodeMCU): Runs custom rmware (C++/Arduino), hosts a web
server, and processes requests/responses.
• Local Wi-Fi Network: The common medium for communication between the app and the
device.
This layered architecture ensures modularity and maintainability for future enhancements.

3.2 Data Flow Diagrams

Data Flow Diagrams (DFDs) developed during Stage 1 illustrate how information moves through
the system for core MVP functionalities, showing processes and interactions between the app and
the device.

Figure3.2:DFD−App−DeviceCommunicationFlowDiagram

DFD - App-Device Communication Flow: This diagram clari es how users interact with the app
to initiate device connections and how data ows to retrieve real-time status from the IoT device. It
covers user input, app processing, network request/response, and UI display.
fi
fi
fl
fi
fi
fi
fi
fi
fl
 4. IMPLEMENTATION

This section outlines the methodology adopted for the Stage 1 MVP development and provides a
high-level overview of the system's core functionalities and architecture.

4.1 Methodology

The iNexus project, during Stage 1, adopted an Agile/Scrum methodology. This iterative approach
accommodated MVP development, allowing for exibility, continuous feedback, and adaptation.
Key aspects included:

• Iterative Development: Core features were developed in short sprints.

• Requirement Prioritization: Focus on delivering critical MVP functionalities rst.
• Regular Reviews & Collaboration: Weekly meetings for progress review and planning.
• Documentation: Key decisions and progress were documented.
The Constructive Research paradigm also guided Stage 1, building a novel artifact (iNexus) to
solve identi ed problems in local IoT device management.

4.2 System Overview

The iNexus platform, as envisioned and with its core established in the Stage 1 MVP, is a secure
local IoT device management application. Its primary purpose is to provide a uni ed, ef cient, and
transparent way for users to manage and interact with their IoT devices over Wi-Fi.

Core Functionalities (MVP Stage 1):

• Device Management: Secure connection and real-time status display for IoT devices.
• Device Information: Retrieval and display of rmware version, OTA capability, and
security features.
• Secure Update Framework: Client-side AES-256 encryption for rmware les, ready for
device-side decryption.
• Real Communication: Proven app-to-device communication over local Wi-Fi for status
retrieval.
Technical Architecture Overview: The system employs a modern, multi-tiered architecture:

• Frontend: Flutter (Dart) provides a responsive cross-platform UI.

• Device Backend: NodeMCU/ESP32 rmware (C++/Arduino) acts as the embedded web
server, handling device logic and communication.
• Data Storage: Client-side local storage (shared_preferences) for recent IPs;
device Flash Memory for rmware/settings.
Key Differentiators (Long-Term Vision): While Stage 1 focused on core functionalities, the long-
term vision includes:

• Full OTA integration with device-side decryption and validation.

• Advanced device discovery (e.g., mDNS).
• Expanded device control and automation.
• Robust device integrity checks.
The project plan is agile, adapting to learnings and feedback. Stage 1's success provides con dence
in executing this plan.

5. PROJECT PLAN
fi
fi
fi
fi
fl
fi
fi
fi
fi
fi
fi
The project plan for iNexus is structured in phases, with Stage 1 (MVP development) being the
foundational step. The overall project timeline outlines a multi-phase development cycle.

5.1 Stage 1 Completion (Recap):

Stage 1, focused on research, design, and MVP development, was executed over approximately 6-8
weeks, following a detailed 6-week task breakdown:

• Weeks 1-2: Problem de nition, competitor research, technology stack selection.

• Week 3: UML diagrams, core data model design.
• Weeks 4-5: Flutter app MVP development (UI, state, basic connectivity, encryption
framework).
• Week 6: Integration, initial testing, nal Stage 1 report preparation.
5.2 Subsequent Project Phases (High-Level Plan):

• Phase 2: Core Enhancements & Initial Advanced Feature Integration (Approx. Months
3-4 overall)

◦ Tasks: Implement full OTA update functionality (device-side decryption), re ne

device-side communication robustness, begin advanced device discovery integration.
◦ Focus: Stabilizing core secure update capabilities and introducing initial smart
interaction features.
• Phase 3: Advanced Feature Development & Beta Testing (Approx. Month 5 overall)

◦ Tasks: Implement advanced device control and automation, integrate expanded

sensor/actuator interactions, conduct structured beta testing with pilot users to gather
feedback.
◦ Focus: Validating advanced automation and gathering real-world user feedback on a
more feature-rich platform.
• Phase 4: Launch & Iterative Improvement (Approx. Month 6 and beyond)

◦ Tasks: Based on beta feedback, make nal re nements and of cially launch iNexus.
Establish processes for ongoing development, feature rollout, maintenance, and user
support.
◦ Focus: Bringing the product to market and establishing a cycle of continuous
improvement based on live user data and feedback.
5.3 Long-Term Development Roadmap:

The project envisions continued development post-launch to incorporate the full suite of advanced
features, including:

• AI-Powered insights for device health/predictive maintenance.

• Advanced device security (e.g., secure boot integration).
• Expanded third-party IoT platform integrations (if applicable).
• Cloud-backed features for remote management (optional, beyond local scope).

CONCLUSION
Stage 1 of iNexus successfully concluded, establishing a robust foundation for secure local IoT
device management. This phase validated core concepts through a functional Minimum Viable
Product (MVP).

Key achievements include:

fi
fi
fi
fi
fi
fi
 • Real-time device connection and status display.
• Comprehensive device information retrieval.
• Client-side AES-256 encryption framework for rmware updates.
• Proven real-time communication between the Flutter app and ESP32/NodeMCU over Wi-Fi.
Leveraging Flutter (Dart) for the app and ESP32/NodeMCU (C++) for embedded rmware,
iNexus is now poised to integrate full OTA updates and advanced security features. This initial
stage con rms the project's potential to streamline local IoT device management.

REFERENCES
• Optional Working Ideas for Permanent Valid Data Source.docx
• Detailed Explanation and Workflow.docx
• Checklist of Requirements.docx
• Phase 1 Deliverable E12.docx
• Project Synopsis E12.docx
• Research Paper.docx
• Summarization of Research Papers.docx

Industry Research (from provided documents):

Aditya & Das (2023): Customer segmentation via RFM/K-Means.
Anusha & M (2023): Big Data Analytics in B2B marketing.
IEEE (2022): Machine Learning for lead scoring.
Kumar & Singh (2023): Emerging tech impact on CRM.
Singh et al. (2023): B2B OMS-CRM app case study.

Appendix A: Full UML Diagrams

fi
fi
fi
Appendix B: Working prototype
Appendix C: Glossary of Key Technical Terms
AES (Advanced Encryp on Standard): A symmetric-key encryp on standard adopted worldwide for
securing electronic data.
API (Application Programming Interface): A set of de ned rules that enable different software
components to communicate with each other.
Arduino (Platform): An open-source electronics platform based on easy-to-use hardware and
software, widely used for microcontroller programming.
Baud Rate: The rate at which information is transferred in a communication channel, commonly
used for serial communication (e.g., 115200 for ESP boards).
Checksum: A small-sized datum derived from a block of digital data for the purpose of detecting
errors that may have been introduced during its transmission or storage.
Client (Software): A piece of computer hardware or software that accesses a service made
available by a server.
Dart: An object-oriented, class-based, garbage-collected programming language developed by
Google, primarily used for Flutter development.
DFD (Data Flow Diagram): A graphical representation of the " ow" of data through a system,
showing how data is processed by the system's components.
Embedded System: A computer system with a dedicated function within a larger mechanical or
electrical system, often with real-time computing constraints.
ESP32: A series of low-cost, low-power system on a chip microcontrollers with integrated Wi-Fi
and dual-mode Bluetooth, often used in IoT projects.
ESP8266: A low-cost Wi-Fi microchip with full TCP/IP stack and microcontroller capabilities,
widely used for basic IoT connectivity.
Firmware: Permanent software programmed into read-only memory, typically found in embedded
systems to control hardware functions.
Flash Memory: A type of non-volatile computer memory that can be electrically erased and
reprogrammed, used to store rmware on microcontrollers.
Flutter: Google's open-source UI software development kit used for building natively compiled
applications for mobile, web, and desktop from a single codebase.
GPIO (General Purpose Input/Output): Generic pins on a microcontroller whose behavior (input
or output) can be controlled by the user at runtime.
HTTP (Hypertext Transfer Protocol): An application protocol for distributed, collaborative, and
hypermedia information systems, foundational for data communication on the World Wide Web.
HTTPS (Hypertext Transfer Protocol Secure): An extension of HTTP that encrypts
communication for secure data transfer over a computer network.
IDE (Integrated Development Environment): A software application that provides
comprehensive facilities to computer programmers for software development.
IoT (Internet of Things): A network of physical objects embedded with sensors, software, and
other technologies for the purpose of connecting and exchanging data over the internet.
IP Address (Internet Protocol Address): A numerical label assigned to each device connected to a
computer network that uses the Internet Protocol for communication.
JSON (JavaScript Object Notation): A lightweight data-interchange format that is easy for
humans to read and write and easy for machines to parse and generate.
Local Network: A computer network that interconnects computers within a limited area, such as a
home, school, computer laboratory, or of ce building.
Microcontroller: A small computer on a single integrated circuit containing a processor core,
memory, and programmable input/output peripherals.
Mobile-First Web App: A web application designed with the mobile experience as the primary
consideration, then scaled up for larger screens.
MVP (Minimum Viable Product): A version of a new product with just enough features to satisfy
early adopters and provide feedback for future product development.
ti
fi
fi
fi
ti
fl
 Network Communication: The exchange of information between two or more connected devices
over a computer network.
NodeMCU: An open-source IoT platform based on the ESP8266 (or ESP32) Wi-Fi module, often
used as a development board for IoT projects.
OTA (Over-The-Air) Firmware Update: The wireless method of updating the software/ rmware
on an embedded device without needing a physical connection.
SDK (Software Development Kit): A collection of software development tools in one installable
package.
Secure Communication: The process of exchanging information such that its con dentiality,
integrity, and authenticity are protected from unauthorized access or modi cation.
Serial Monitor: A tool in the Arduino IDE (or similar environments) that allows two-way text
communication with a connected board over the USB serial port.
Server (Software): A computer program or device that provides a service to another computer
program and its user, known as the client.
SSID (Service Set Identi er): The publicly broadcast name of a wireless local area network
(WLAN) or Wi-Fi network.
**TLS (Transport Layer Security): A cryptographic protocol designed to provide communications
security over a computer network, widely used for secure web Browse (HTTPS).
UI (User Interface): The means by which the user and a computer system interact.
UML (Uni ed Modeling Language): A standardized general-purpose modeling language in the
eld of object-oriented software engineering.
UX (User Experience): Encompasses all aspects of the end-user's interaction with the company, its
services, and its products.
fi
fi
fi
fi
fi
fi