# KURTOGLU SINAN

Ingénieur en électrotechnique et électronique
Systèmes embarqués · Énergie ·
Logiciels

![Emblème ASUNODE](<../assets/asunode-smart-home-local-ai-integration-illustration.png>)

<a id="content"></a>

## Fiche projet

Projet

ASUNODE — Maison connectée et intégration d’IA locale

Catégorie

Sécurité domestique et automatisation électrique

Mon rôle

Conception du système · Développement embarqué · Intégration et tests

Année

2026

Durée

Février 2026 — en cours

Outils

ESP32 · MQTT · Ubuntu · Home Assistant · Flutter · Python · PostgreSQL · Local LLM · RAG · Obsidian

Statut

Tests de prototypes · Développement du tableau de bord · R&D en IA locale

<a id="case-title"></a>

## ASUNODE — Maison connectée et intégration d’IA locale

Un projet d’ingénierie en cours qui réunit sécurité domestique, automatisation électrique, appareils embarqués distribués et recherche sur l’IA locale.

<a id="overview"></a>

## Aperçu du projet

ASUNODE a débuté en février 2026 avec un objectif pratique : construire un système domestique qui associe sécurité, commande électrique et supervision de manière à répondre aux besoins réels des utilisateurs.

Le projet a évolué en six étapes, des produits domotiques commerciaux à un réseau ESP32 sur mesure, un échange de données par MQTT et des expériences avec des modèles de langage locaux. Les premiers tests du produit ont débuté en juillet 2026. Le développement du tableau de bord et de l’interface de l’assistant local se poursuit.

Chaque étape a modifié ma compréhension du problème. Connecter des appareils était le point de départ ; un fonctionnement fiable, des informations utiles et un comportement coordonné sont devenus les objectifs d’ingénierie centraux.

<a id="role"></a>

## Mon rôle et ma contribution

J’ai défini les exigences, sélectionné et évalué les appareils, configuré les plateformes logicielles et mené des expériences matérielles et de communication.

Au fil du projet, j’ai attribué des rôles aux appareils embarqués, testé l’échange d’informations entre hubs, introduit une messagerie centralisée et évalué des modèles de langage locaux pour l’analyse de données.

Ce travail rassemble mon expérience des systèmes électriques, de l’électronique, des communications, de l’informatique et de l’intégration logicielle. Il met aussi en évidence des lacunes dans mes approches antérieures et me donne une raison pratique de les réexaminer.

<a id="journey"></a>

## Parcours de développement

### Étape 1 — Intégration de produits domotiques commerciaux

J’ai d’abord construit autour de produits compatibles Apple HomeKit, en utilisant un iPad, un HomePod et une Apple TV avec des appareils de Philips Hue, Yale, Aqara et Meross.

L’éclairage, les interrupteurs, les caméras, les capteurs et les hubs offraient des fonctions initiales opérationnelles. Cependant, l’augmentation des coûts et des problèmes de connexion dans mon installation ont limité la progression. L’intégration de la commande et de la supervision de l’alimentation électrique prévues à base de Wago ajoutait de la complexité entre des environnements de gestion distincts.

Cette étape m’a donné une expérience pratique de la configuration et de la communication des appareils. Elle a aussi montré que les fonctions disponibles ne répondaient pas encore à mes attentes pour une maison intelligente.

### Étape 2 — Comparaison d’écosystèmes de produits

J’ai ensuite testé des produits de Sonoff, Tapo, Xiaomi Mi et Interra au regard des fonctions requises par le projet.

Les différences de comportement logiciel se sont révélées importantes. L’enregistrement des caméras et les capacités des hubs variaient, et les combinaisons que j’ai testées n’offraient pas de solution unifiée pour toutes les exigences.

Cette expérience a déplacé mon évaluation vers la façon dont les appareils se comportent ensemble, la façon dont l’information est conservée et l’influence des choix logiciels sur la sécurité et l’usage quotidien.

### Étape 3 — Coordination centrale avec Home Assistant

Home Assistant offrait une voie pour coordonner différents produits via une plateforme logicielle commune. J’ai commencé à configurer des intégrations et obtenu de meilleurs résultats qu’aux étapes précédentes, bien que le fonctionnement continu et la stabilité restent des sujets de préoccupation dans mon installation.

Une installation à petite échelle dans une résidence pour personnes âgées a rendu l’importance de la fiabilité plus concrète. Ces personnes pouvaient bénéficier de l’automatisation, mais leurs besoins exigeaient plus que des télécommandes pratiques.

Cette expérience a renforcé l’orientation du projet vers un comportement utile, la continuité et la relation entre le système et ses utilisateurs.

### Étape 4 — Exploration du matériel embarqué

J’ai exploré les cartes de développement et les équipements réparables dont je disposais déjà. Arduino offrait un point de départ accessible, NodeMCU apportait des capacités Wi-Fi pratiques, et une carte de développement MSP correspondait à mon approche d’ingénierie.

La disponibilité des modules en Turquie a influencé les choix. Mon attention s’est portée de plus en plus sur les composants Espressif, dont j’ai étudié le matériel, les SDK et les options de développement, notamment Arduino et Zephyr.

De petits chargements de programmes sur un ESP32-C6 ont fourni une première base d’évaluation pratique.

### Étape 5 — Réseau ESP32 distribué et MQTT

<a id="s5-title"></a>

Réseau ESP32 distribué et MQTT

<a id="s5-desc"></a>

Vue conceptuelle de nœuds de tâches ESP32 et d’un pont d’extension de couverture, de deux hubs partageant des informations de capteurs et vérifiant la fraîcheur des données, et du transfert de données vers MQTT sur Ubuntu. Les fonctions des appareils comprennent la mesure du temps, les journaux d’événements et la surveillance des interruptions via des mécanismes Dead Man’s Switch. Les connexions représentent des relations fonctionnelles et non un protocole radio ou une topologie de réseau physique particuliers.

TÂCHES DES APPAREILS

COORDINATION DES HUBS

MESSAGERIE CENTRALE

Nœuds de tâches ESP32

Tâches de mesure assignées

Pont de couverture

Couverture étendue

ESP32 HUB A

Informations capteurs

ESP32 HUB B

Informations capteurs

MQTT sur Ubuntu

Échange centralisé

Partage de données

Vérifier fraîcheur

Données

Mesure du temps · Journaux d’événements · Dead Man’s Switch / surveillance des interruptions

J’ai regroupé les appareils ESP32 par fonction. Certains jouaient le rôle de hubs, un autre servait de pont pour étendre la couverture, et d’autres assuraient la mesure du temps et la journalisation indépendante des événements.

J’ai aussi travaillé sur l’échange d’informations entre deux hubs, notamment pour identifier quelle information de capteur était la plus récente. Des expériences de communication et des mécanismes « Dead Man’s Switch » ont soutenu les efforts de détection des interruptions et de réduction de leur impact.

L’introduction de MQTT sur Ubuntu a permis aux appareils de se concentrer sur leurs tâches assignées tout en transmettant les données à un environnement logiciel central.

Les appareils communiquaient et envoyaient des informations de capteurs, mais le comportement des capteurs et la continuité nécessitaient encore des améliorations. Je restais responsable d’interpréter les informations et de gérer le système, ce qui a conduit à l’étape suivante.

### Étape 6 — Recherche sur un assistant IA local

J’ai installé des modèles de langage locaux, appris à les exploiter et leur ai confié des tâches expérimentales d’inspection et d’analyse de données. Des modèles des familles Qwen, Gemma, CodeGemma et Llama ont été évalués dans la limite des ressources matérielles disponibles.

J’ai ensuite commencé à préparer une approche basée sur la récupération avec RAG, PostgreSQL et Obsidian. L’objectif est de fournir à un assistant local les informations pertinentes du projet et le contexte du système.

Ces expériences ont fixé une direction pour l’assistance et l’analyse. Une interface d’assistant achevée et une intégration coordonnée avec le système d’automatisation restent en cours de développement.

Ce besoin a aussi donné lieu à mon travail distinct sur des workflows d’IA semi-autonomes guidés par l’humain et des templates de développement réutilisables.

<a id="structure"></a>

## Structure du système

L’architecture en cours de développement sépare les responsabilités des appareils de la coordination des données et de l’interaction avec l’utilisateur.

Les appareils ESP32 assurent des tâches assignées de mesure, de communication, de hub, de pont et de journalisation. MQTT fournit la couche de messagerie qui transfère les données des appareils vers l’environnement basé sur Ubuntu.

Le tableau de bord vise à rendre les informations du système accessibles à l’utilisateur. La recherche sur l’IA locale explore une couche d’assistance supplémentaire pour interpréter les informations et soutenir la supervision du système.

Cette séparation permet de développer et d’évaluer chaque partie pendant que l’intégration se poursuit.

<a id="as-title"></a>

Structure du système ASUNODE

<a id="as-desc"></a>

Le réseau d’appareils ESP32 existant transfère des données via MQTT sur Ubuntu. Les connexions en pointillés montrent l’intégration en cours de développement avec un tableau de bord et un assistant IA local. La préparation du contexte RAG utilise PostgreSQL et Obsidian. Des modèles locaux ont été testés ; l’intégration de l’assistant reste en recherche et développement.

RÉSEAU D’APPAREILS

ÉCHANGE DE DONNÉES

INTÉGRATION EN COURS

Appareils ESP32

Capteurs · tâches

2 hubs · pont de couverture

Horodatage · journaux

MQTT

Hôte Ubuntu

Tableau de bord

Travail Flutter → réécriture Python

Assistant IA local

Modèles testés · interface en R&D

Préparation du contexte RAG

PostgreSQL · Obsidian

Flux existant

Développement / R&D

<a id="status"></a>

## État actuel et prochaines étapes

Le projet est passé d’essais d’appareils commerciaux à un réseau ESP32 communicant, à un échange centralisé de données et à des expériences avec des modèles locaux.

Le travail sur le tableau de bord a été réalisé en Flutter. Une réécriture en Python est prévue, avec un achèvement visé pour fin 2026. L’interface du LLM local reste en R&D.

Les travaux à venir portent sur l’interface utilisateur, le logiciel de coordination, la fiabilité des capteurs et l’évaluation continue de la continuité de fonctionnement. Ce sont des objectifs de développement et non des capacités achevées.

<a id="significance"></a>

## Signification personnelle

ASUNODE est l’endroit où je rassemble l’expérience accumulée tout au long de ma vie professionnelle. Génie électrique, communications, infrastructures, logiciel et dépannage pratique contribuent tous au même système.

Le projet m’encourage aussi à reconsidérer des problèmes familiers à travers des outils et des méthodes que j’avais négligés. La découverte d’approches comme Node-RED a élargi ma façon de penser la coordination et l’automatisation.

Pour moi, ASUNODE signifie « mon héritage pour demain » : un effort continu pour transformer le savoir accumulé en systèmes qui répondent aux besoins réels des personnes.

Sinan KURTOĞLU ©
