KURTOGLU
SINAN

Project Overview

ASUNODE began in February 2026 with a practical objective: build a home system that combines security, electrical control, and monitoring in a way that responds to real user needs.

The project evolved through six stages, from commercial smart-home products to a custom ESP32 network, MQTT-based data exchange, and experiments with local language models. Initial product testing began in July 2026. Dashboard development and the local assistant interface remain ongoing.

Each stage changed my understanding of the problem. Connecting devices was the starting point; dependable operation, useful information, and coordinated behavior became the central engineering goals.

My Role & Contribution

I defined the requirements, selected and evaluated devices, configured the software platforms, and carried out hardware and communication experiments.

As the project progressed, I assigned roles to embedded devices, tested information exchange between hubs, introduced centralized messaging, and evaluated local language models for data analysis.

The work brings together my experience in electrical systems, electronics, communications, computing, and software integration. It also exposes gaps in my previous approaches and gives me a practical reason to revisit them.

Development Journey

Stage 1 — Commercial Smart-Home Integration

I initially built around Apple HomeKit-compatible products, using an iPad, HomePod, and Apple TV alongside devices from Philips Hue, Yale, Aqara, and Meross.

Lighting, switches, cameras, sensors, and hubs provided working initial functions. However, increasing costs and connection problems in my installation limited further progress. Integrating the intended Wago-based electrical power control and monitoring added complexity between separate management environments.

This stage gave me practical experience in device configuration and communication. It also showed that the available functions did not yet meet my expectations for an intelligent home.

Stage 2 — Comparing Product Ecosystems

I then tested products from Sonoff, Tapo, Xiaomi Mi, and Interra against the functions required by the project.

Differences in software behavior proved significant. Camera recording and hub capabilities varied, and the combinations I tested did not provide a unified solution for all requirements.

The experience shifted my evaluation toward how devices behave together, how information is retained, and how software choices affect security and everyday use.

Stage 3 — Central Coordination with Home Assistant

Home Assistant offered a route toward coordinating different products through a shared software platform. I began configuring integrations and obtained better results than in the earlier stages, although continuous operation and stability remained concerns in my installation.

A small-scale installation in a residential setting for older people made the importance of reliability more concrete. People could benefit from automation, but their needs demanded more than convenient remote controls.

This experience strengthened the project’s focus on useful behavior, continuity, and the relationship between the system and its users.

Stage 4 — Embedded Hardware Exploration

I explored the development boards and repairable equipment already available to me. Arduino provided an accessible starting point, NodeMCU introduced practical Wi-Fi capabilities, and an MSP development board appealed to my engineering approach.

Module availability in Türkiye influenced the choices. I increasingly focused on Espressif devices, researching their hardware, SDKs, and development options, including Arduino and Zephyr.

Small program uploads to an ESP32-C6 provided an initial basis for hands-on evaluation.

Stage 5 — Distributed ESP32 Network and MQTT

I grouped ESP32 devices by function. Some acted as hubs, another served as a bridge to extend coverage, and others handled timekeeping and independent event logging.

I also worked on information exchange between two hubs, including identifying which sensor information was more recent. Communication experiments and “Dead Man’s Switch” mechanisms supported efforts to detect interruptions and reduce their impact.

Introducing MQTT on Ubuntu allowed devices to concentrate on their assigned tasks while passing data into a central software environment.

The devices were communicating and sending sensor information, although sensor behavior and continuity still required refinement. I remained responsible for interpreting the information and managing the system, which led to the next stage.

Stage 6 — Local AI Assistant Research

I installed local language models, learned how to operate them, and assigned experimental data inspection and analysis tasks. Models from the Qwen, Gemma, CodeGemma, and Llama families were evaluated within the available hardware resources.

I then began preparing a retrieval-based approach using RAG, PostgreSQL, and Obsidian. The aim is to supply a local assistant with relevant project information and system context.

These experiments established a direction for assistance and analysis. A completed assistant interface and coordinated integration with the automation system remain under development.

This need also gave rise to my separate work on human-guided, semi-autonomous AI workflows and reusable development templates.

System Structure

The developing architecture separates device responsibilities from data coordination and user interaction.

ESP32 devices perform assigned sensing, communication, hub, bridge, and logging tasks. MQTT provides the messaging layer for transferring device data into the Ubuntu-based environment.

The dashboard is intended to make system information accessible to the user. Local AI research explores an additional assistance layer for interpreting information and supporting system supervision.

This separation allows each part to be developed and evaluated while integration continues.

Current Status & Next Steps

The project has progressed from commercial device trials to a communicating ESP32 network, centralized data exchange, and local model experiments.

Dashboard work has been carried out in Flutter. A Python rewrite is planned, with completion targeted for the end of 2026. The local LLM interface remains in R&D.

Further work focuses on the user interface, coordination software, sensor reliability, and continued evaluation of operational continuity. These are development goals rather than completed capabilities.

Personal Significance

ASUNODE is where I bring together the experience accumulated throughout my working life. Electrical engineering, communications, infrastructure, software, and practical troubleshooting all contribute to the same system.

The project also encourages me to reconsider familiar problems through tools and methods I had previously overlooked. Discovering approaches such as Node-RED has expanded how I think about coordination and automation.

For me, ASUNODE means “my legacy for tomorrow”: a continuing effort to turn accumulated knowledge into systems that serve people’s actual needs.