Praktyczne wykorzystanie AI w elektronice i elektryce cz.2

MrWilgosz · 10 stycznia

Architektura systemu: gdzie AI spotyka elektronikę w sterowaniu oświetleniem

W poprzednim artykule wprowadziłem koncepcję wykorzystania sztucznej inteligencji jako warstwy interpretacyjnej pomiędzy człowiekiem a systemami embedded. Tym razem przechodzimy od teorii do praktyki i przyjrzymy się architekturze systemu. Jednym z najbardziej naturalnych sposobów wykorzystania AI w elektronice jest przetwarzanie mowy potocznej na polecenia zrozumiałe dla urządzeń elektrycznych i elektronicznych. W rzeczywistości jednak jedynym ograniczeniem zastosowań AI jest wyobraźnia. Pokażę przykład sterowania oświetleniem w inteligentnym domu za pomocą naturalnej, potocznej mowy.

Nie będzie to tutorial krok po kroku, lecz analiza projektowa, pokazująca jak w sposób inżynierski i bezpieczny integrować AI z elektroniką – tak, aby system pozostał przewidywalny i niezawodny.

Proszę nie traktować fragmentow kodu jako gotowego rozwiązania. Jest to jedynie kierunek w jakim powinnismy iść. Krótkie fragmenty kodu pisane są w php, ponieważ jest to prosty i zrozumiały język. Osobiście w swoich aplikacjach korzystam z JAVA lub Python

Filozofia projektowa: AI jako tłumacz, nie jako wykonawca

Najczęstszym błędem w projektach łączących AI z elektroniką jest przypisywanie modelom językowym zbyt dużej odpowiedzialności. W praktyce prowadzi to do systemów trudnych do debugowania i nieprzewidywalnych.

Dlatego przyjmuję prostą zasadę:

AI to zaawansowany parser języka naturalnego, nie system sterowania.

Model językowy:

nie steruje przekaźnikami,
nie podejmuje decyzji wykonawczych,
nie zna hardware’u.

Jego jedynym zadaniem jest przekształcenie nieprecyzyjnych, ludzkich poleceń w ustrukturyzowane dane, które następnie są przetwarzane przez deterministyczny system.

Dla instalacji oświetleniowej z 12–15 punktami świetlnymi oznacza to jasno zdefiniowany kontrakt komunikacyjny w formacie JSON, będący jedyną dozwoloną formą komunikacji pomiędzy AI a warstwą wykonawczą.

Architektura trójwarstwowa: separacja odpowiedzialności

Cały system można opisać jako prostą architekturę trójwarstwową:

[ Warstwa 1: Interfejs użytkownika ]
↓ (mowa → tekst)
[ Warstwa 2: Logika AI ]
↓ (JSON → walidacja)
[ Warstwa 3: System wykonawczy ]
↓
MQTT → ESP32 → Przekaźniki

Każda warstwa:

ma jednoznacznie określoną odpowiedzialność,
może być rozwijana i testowana niezależnie,
może zostać wymieniona bez przebudowy całego systemu.
To dokładnie ta sama zasada, którą stosuje się w systemach przemysłowych i automatyce budynkowej.

Warstwa 1: konwersja mowy na tekst

Punktem wejścia do systemu jest zawsze głos użytkownika. Jego zamiana na tekst może odbywać się na dwa sposoby.
Opcja przeglądarkowa – SpeechRecognition API
Najprostsze i często wystarczające rozwiązanie to wykorzystanie Web Speech API bezpośrednio w przeglądarce:

//minimalistyczna wersja przeglądarkowa
const recognition = new SpeechRecognition(); 
recognition.lang = 'pl-PL'; 
recognition.continuous = false; 
 
recognition.onresult = (event) => { 
 const userCommand = event.results[0][0].transcript; 
 // np. "Włącz światło w salonie i kuchni, zgaś w sypialni" 
 sendToAIProcessing(userCommand); 
}; 
recognition.start();

Zaletą tego podejścia jest brak backendu do STT i natychmiastowa reakcja systemu – idealne rozwiązanie dla domowej aplikacji webowej.

Opcja serwerowa – OpenAI Whisper

Jeżeli potrzebujemy:

większej dokładności, obsługi długich wypowiedzi, pracy w hałaśliwym środowisku warto sięgnąć po wyspecjalizowane modele STT, takie jak Whisper. Wadą jest konieczność przesyłania audio do API, ale jakość rozpoznawania jest zauważalnie wyższa.

Warstwa 2: logika AI – serce systemu

To tutaj zachodzi kluczowy proces: transformacja swobodnej wypowiedzi użytkownika w ustrukturyzowany JSON, który może zostać bezpiecznie przetworzony przez system embedded. Nie jest to „magia AI”, lecz efekt dobrze zaprojektowanych promptów.

Konstrukcja promptów: inżynieria, nie zgadywanie

Prompt nie jest pytaniem – jest specyfikacją zachowania systemu. Dla sterowania oświetleniem musi on jednoznacznie definiować:

format odpowiedzi,
listę wszystkich lamp i ich identyfikatorów,
mapowanie nazw potocznych na nazwy techniczne,
zasady interpretacji kontekstu.

Przykładowa implementacja w PHP:

<?php 
 
class LightingPromptBuilder 
{ //Budujemy promt systemowy
   private const SYSTEM_PROMPT = <<<PROMPT 
Jesteś sterownikiem oświetlenia w inteligentnym domu.
Twoim JEDYNYM zadaniem jest analiza poleceń użytkownika i zwracanie stanu WSZYSTKICH lamp w systemie.

ZASADY:
1. ZWRACAJ WYŁĄCZNIE czysty JSON bez dodatkowych znaków, komentarzy czy formatowania
2. Każda lampa musi mieć określony stan 'on' lub 'off'
3. Jeśli polecenie nie dotyczy lampy, zachowaj jej aktualny stan
4. Interpretuj synonimy i potoczne nazwy zgodnie z mapowaniem

FORMAT ODPOWIEDZI - JSON z wszystkimi lampami:
{
  "living_room_main": "on|off",
  "living_room_spot": "on|off",
  "kitchen_main": "on|off",
  "kitchen_counter": "on|off",
  "hallway": "on|off",
  "bathroom_main": "on|off",
  "bedroom_main": "on|off",
  "bedroom_bedside": "on|off",
  "office_main": "on|off",
  "kids_room_main": "on|off",
  "garden_path": "on|off",
  "garage_entrance": "on|off",
  "front_door": "on|off"
}

MAPOWANIE NAZW:
- salon, pokój dzienny → living_room_main, living_room_spot
- kuchnia → kitchen_main, kitchen_counter
- korytarz, przedpokój → hallway
- łazienka → bathroom_main
- sypialnia → bedroom_main, bedroom_bedside
- gabinet, biuro → office_main
- pokój dziecka → kids_room_main
- ogród, ścieżka → garden_path
- garaż → garage_entrance
- drzwi, wejście → front_door
- wewnętrzne → wszystkie lampy wewnętrzne
- zewnętrzne → wszystkie lampy zewnętrzne

PRZYKŁADOWE POLECENIA I INTERPRETACJE:
"Włącz światło w salonie" → włącza living_room_main, living_room_spot
"Zgaś światło w kuchni" → wyłącza kitchen_main, kitchen_counter
"Oświetl ogród" → włącza garden_path
"Wyłącz wszystkie światła" → wyłącza WSZYSTKIE lampy
"Zostaw tylko światło w sypialni" → wyłącza wszystkie poza bedroom_main, bedroom_bedside
"Włącz oświetlenie zewnętrzne" → włącza garden_path, garage_entrance, front_door
PROMPT; 
 
   public function buildPrompt(string $userCommand, array $currentState): array 
   { 
       //dodajemy aktualny stan lamp		     
       $context = "Aktualny stan oświetlenia:\n"; 
       foreach ($currentState as $light => $state) { 
           $context .= "{$light}: {$state}\n"; 
       } 
       //zwracamy kompletny prompt który zostanie przeslany do AI
       return [ 
           'system' => self::SYSTEM_PROMPT, 
           'user'   => "{$context}\nPolecenie: \"{$userCommand}\"" 
       ]; 
   } 
}

Komunikacja z API: minimalizm i kontrola

Integracja z API AI powinna być odporna na błędy sieci i nieprzewidywalne odpowiedzi. Przykładowy kontroler:

<?php

class AILightingController
{
    private LightingPromptBuilder $promptBuilder;

    public function __construct()
    {
        // tworzymy obiekt LightingPromptBuilder
    }

    public function processCommand($userCommand)
    {
        $currentState = $this->getCurrentLightingState();
        $prompt = $this->promptBuilder->buildPrompt($userCommand, $currentState);
        $response = $this->callAIWithRetry($prompt);
        $json = $this->extractAndValidateJson($response);

        return json_decode($json, true);

    }

    private  function extractAndValidateJson($aiResponse)
    {
        $cleaned = preg_replace('/```json|```/i', '', $aiResponse);
        $cleaned = trim($cleaned);
        //Tutaj mozna zastosować bardziej rozbudowana wlidację
        if (!str_starts_with($cleaned, '{') || !str_ends_with($cleaned, '}')) {
            throw new RuntimeException("Nieprawidłowy JSON od AI");
        }
        return $cleaned;
    }

    private  function getCurrentLightingState(): array
    {
// Przykładowy stan – w praktyce z bazy lub cache
        return [
            'living_room_main' => 'off',
            'kitchen_main' => 'on',
// ...
        ];
    }

    private function callAIWithRetry($prompt)
    {
        // Przesłanie promptu do AI API np. API OpenAI
    }
}

Kluczowe jest to, żeby odpowiedź AI poddać każdorazowo walidacji.

Warstwa 3: interfejs sprzętowy – MQTT jako most

Po otrzymaniu poprawnego JSON-a dane trafiają do warstwy wykonawczej. Najlepszym wyborem jest tu MQTT – lekki, asynchroniczny i doskonale wspierany przez ESP32.

Każda lampa ma własny topic, np.:

home/lighting/living_room/main 
home/lighting/kitchen/counter
// .......

ESP32 subskrybuje te tematy i steruje przekaźnikami dokładnie tak, jakby polecenie pochodziło z aplikacji lub harmonogramu czasowego.

Dla mikrokontrolera AI nie istnieje – widzi tylko komunikaty MQTT.

Przykłady interpretacji w praktyce

„Włącz światło w salonie”
→ mapowanie „salon”
→ living_room_main = on, living_room_spot = on

„Zostaw tylko światło w kuchni”
→ backend przekazuje aktualny stan
→ AI ustawia wyłącznie lampy kuchenne na on

„Wyłącz to światło”
→ backend "pamięta ostanio włączone światło"
→ kontekst trafia do promptu
→ AI wyłącza właściwe lampy

Ale zrozumiałe będą również polecenia takie jak "Zapal wszystkie lampy", "Wyłącz całe oświetlenie", "Jest ciemno w pokoju gościnnym" czy "Włącz światła na zewnątrz"

Bezpieczeństwo i niezawodność

W dobrze zaprojektowanym systemie:

AI nie ma dostępu do hardware’u
każda odpowiedź jest walidowana
istnieje klasyczny interfejs jako fallback
wszystkie komendy są logowane

To pozwala korzystać z AI bez utraty kontroli nad systemem.

Wnioski i następne kroki

Integracja AI z elektroniką to nie rewolucja, lecz ewolucja interfejsu użytkownika. Kluczowe zasady to:

separacja odpowiedzialności,
jasno zdefiniowane kontrakty (JSON),
deterministyczna logika wykonawcza,
pełna kontrola nad zachowaniem AI.

W tej architekturze ESP32 nie „wie”, że w systemie istnieje AI – i właśnie dlatego całość pozostaje stabilna.

W kolejnym artykule pokażę, jak rozszerzyć ten system o czujniki ruchu, światła i temperatury oraz jak łączyć harmonogramy czasowe z komendami głosowymi, tworząc faktycznie inteligentne oświetlenie, a nie tylko zdalnie sterowane.

Edytowano 10 stycznia przez MrWilgosz