KURTOGLU
SINAN

Projektüberblick

ASUNODE begann im Februar 2026 mit einem praktischen Ziel: ein Haussystem zu bauen, das Sicherheit, elektrische Steuerung und Überwachung so verbindet, dass es auf reale Nutzerbedürfnisse eingeht.

Das Projekt entwickelte sich über sechs Phasen, von kommerziellen Smart-Home-Produkten über ein eigenes ESP32-Netzwerk und MQTT-basierten Datenaustausch bis zu Experimenten mit lokalen Sprachmodellen. Die ersten Produkttests begannen im Juli 2026. Die Dashboard-Entwicklung und die Schnittstelle für den lokalen Assistenten laufen weiter.

Jede Phase veränderte mein Verständnis des Problems. Die Verbindung von Geräten war der Ausgangspunkt; zuverlässiger Betrieb, nützliche Informationen und abgestimmtes Verhalten wurden zu den zentralen technischen Zielen.

Meine Rolle & mein Beitrag

Ich habe die Anforderungen definiert, Geräte ausgewählt und bewertet, die Softwareplattformen konfiguriert sowie Hardware- und Kommunikationsexperimente durchgeführt.

Im Verlauf des Projekts habe ich Embedded-Geräten Rollen zugewiesen, den Informationsaustausch zwischen Hubs getestet, zentrales Messaging eingeführt und lokale Sprachmodelle für die Datenanalyse bewertet.

Die Arbeit führt meine Erfahrung in Elektrotechnik, Elektronik, Kommunikation, Datenverarbeitung und Softwareintegration zusammen. Sie zeigt auch Lücken in meinen früheren Ansätzen auf und gibt mir einen praktischen Grund, sie erneut zu betrachten.

Entwicklungsweg

Phase 1 — Integration kommerzieller Smart-Home-Produkte

Zunächst baute ich auf Apple-HomeKit-kompatiblen Produkten auf und nutzte ein iPad, einen HomePod und ein Apple TV zusammen mit Geräten von Philips Hue, Yale, Aqara und Meross.

Beleuchtung, Schalter, Kameras, Sensoren und Hubs lieferten zunächst funktionierende Grundfunktionen. Steigende Kosten und Verbindungsprobleme in meiner Installation begrenzten jedoch den weiteren Fortschritt. Die Einbindung der geplanten Wago-basierten elektrischen Leistungssteuerung und -überwachung brachte zusätzliche Komplexität zwischen getrennten Verwaltungsumgebungen.

Diese Phase gab mir praktische Erfahrung in Gerätekonfiguration und Kommunikation. Sie zeigte auch, dass die verfügbaren Funktionen meine Erwartungen an ein intelligentes Zuhause noch nicht erfüllten.

Phase 2 — Vergleich von Produkt-Ökosystemen

Danach testete ich Produkte von Sonoff, Tapo, Xiaomi Mi und Interra anhand der Funktionen, die das Projekt erforderte.

Unterschiede im Softwareverhalten erwiesen sich als erheblich. Kameraaufzeichnung und Hub-Fähigkeiten unterschieden sich, und die von mir getesteten Kombinationen boten keine einheitliche Lösung für alle Anforderungen.

Die Erfahrung verlagerte meine Bewertung darauf, wie sich Geräte gemeinsam verhalten, wie Informationen gespeichert werden und wie sich Softwareentscheidungen auf Sicherheit und Alltagsnutzung auswirken.

Phase 3 — Zentrale Koordination mit Home Assistant

Home Assistant bot einen Weg, verschiedene Produkte über eine gemeinsame Softwareplattform zu koordinieren. Ich begann, Integrationen zu konfigurieren, und erzielte bessere Ergebnisse als in den früheren Phasen, obwohl Dauerbetrieb und Stabilität in meiner Installation weiterhin Sorgen bereiteten.

Eine kleine Installation in einer Wohneinrichtung für ältere Menschen machte die Bedeutung von Zuverlässigkeit greifbarer. Die Menschen konnten von Automation profitieren, doch ihre Bedürfnisse verlangten mehr als bequeme Fernbedienungen.

Diese Erfahrung stärkte den Fokus des Projekts auf nützliches Verhalten, Kontinuität und die Beziehung zwischen dem System und seinen Nutzern.

Phase 4 — Erkundung von Embedded-Hardware

Ich erkundete die Entwicklungsboards und reparierbaren Geräte, die mir bereits zur Verfügung standen. Arduino bot einen leicht zugänglichen Einstieg, NodeMCU brachte praktische WLAN-Fähigkeiten, und ein MSP-Entwicklungsboard sprach meine technische Herangehensweise an.

Die Verfügbarkeit von Modulen in der Türkei beeinflusste die Auswahl. Ich konzentrierte mich zunehmend auf Espressif-Geräte und recherchierte deren Hardware, SDKs und Entwicklungsoptionen, darunter Arduino und Zephyr.

Kleine Programm-Uploads auf einen ESP32-C6 boten eine erste Grundlage für die praktische Bewertung.

Phase 5 — Verteiltes ESP32-Netzwerk und MQTT

Ich habe ESP32-Geräte nach Funktion gruppiert. Einige fungierten als Hubs, ein weiteres diente als Bridge zur Erweiterung der Reichweite, und andere übernahmen Zeithaltung und unabhängige Ereignisprotokollierung.

Außerdem habe ich am Informationsaustausch zwischen zwei Hubs gearbeitet, einschließlich der Feststellung, welche Sensorinformation aktueller war. Kommunikationsexperimente und „Dead Man’s Switch“-Mechanismen unterstützten die Bemühungen, Unterbrechungen zu erkennen und ihre Auswirkungen zu verringern.

Durch die Einführung von MQTT unter Ubuntu konnten sich die Geräte auf ihre zugewiesenen Aufgaben konzentrieren und Daten zugleich in eine zentrale Softwareumgebung weiterreichen.

Die Geräte kommunizierten und sendeten Sensorinformationen, doch Sensorverhalten und Kontinuität mussten noch verfeinert werden. Ich blieb dafür verantwortlich, die Informationen zu interpretieren und das System zu verwalten, was zur nächsten Phase führte.

Phase 6 — Forschung zu einem lokalen KI-Assistenten

Ich installierte lokale Sprachmodelle, lernte ihren Betrieb und übertrug ihnen experimentelle Aufgaben zur Dateninspektion und -analyse. Modelle der Familien Qwen, Gemma, CodeGemma und Llama wurden im Rahmen der verfügbaren Hardwareressourcen bewertet.

Anschließend begann ich, einen Retrieval-basierten Ansatz mit RAG, PostgreSQL und Obsidian vorzubereiten. Das Ziel ist, einem lokalen Assistenten relevante Projektinformationen und Systemkontext bereitzustellen.

Diese Experimente haben eine Richtung für Unterstützung und Analyse vorgegeben. Eine fertige Assistentenoberfläche und die koordinierte Integration in das Automationssystem befinden sich weiterhin in Entwicklung.

Dieser Bedarf führte auch zu meiner separaten Arbeit an vom Menschen gesteuerten, teilautonomen KI-Workflows und wiederverwendbaren Entwicklungs-Templates.

Systemstruktur

Die entstehende Architektur trennt Geräteverantwortlichkeiten von Datenkoordination und Benutzerinteraktion.

ESP32-Geräte übernehmen zugewiesene Aufgaben für Messung, Kommunikation, Hub, Bridge und Protokollierung. MQTT stellt die Messaging-Ebene bereit, über die Gerätedaten in die Ubuntu-basierte Umgebung übertragen werden.

Das Dashboard soll dem Benutzer Systeminformationen zugänglich machen. Die Forschung zu lokaler KI untersucht eine zusätzliche Assistenzebene zur Interpretation von Informationen und zur Unterstützung der Systemüberwachung.

Diese Trennung ermöglicht es, jeden Teil zu entwickeln und zu bewerten, während die Integration fortgesetzt wird.

Aktueller Stand & nächste Schritte

Das Projekt hat sich von Versuchen mit kommerziellen Geräten zu einem kommunizierenden ESP32-Netzwerk, zentralem Datenaustausch und Experimenten mit lokalen Modellen entwickelt.

Die Dashboard-Arbeit wurde in Flutter durchgeführt. Eine Neuentwicklung in Python ist geplant; der Abschluss ist für Ende 2026 vorgesehen. Die Schnittstelle für das lokale LLM befindet sich weiterhin in F&E.

Die weitere Arbeit konzentriert sich auf die Benutzeroberfläche, die Koordinationssoftware, die Zuverlässigkeit der Sensoren und die fortgesetzte Bewertung der Betriebskontinuität. Dies sind Entwicklungsziele und keine fertigen Fähigkeiten.

Persönliche Bedeutung

In ASUNODE bringe ich die Erfahrung zusammen, die ich in meinem Berufsleben gesammelt habe. Elektrotechnik, Kommunikation, Infrastruktur, Software und praktische Fehlersuche tragen alle zum selben System bei.

Das Projekt regt mich außerdem an, vertraute Probleme mit Werkzeugen und Methoden neu zu betrachten, die ich zuvor übersehen hatte. Die Entdeckung von Ansätzen wie Node-RED hat erweitert, wie ich über Koordination und Automation denke.

Für mich bedeutet ASUNODE „mein Vermächtnis für morgen“: das fortgesetzte Bemühen, angesammeltes Wissen in Systeme zu verwandeln, die den tatsächlichen Bedürfnissen der Menschen dienen.