Agent AI pisze automatykę#

W tutorialu Grenton agent AI rozmawia z domem: czyta stany i steruje. Tu idziemy krok dalej: agent pisze kod automatyki, testuje go w sandboxie i wdraża. Nie zgadujesz, czy zadziała, bo zanim kod trafi do domu, przechodzi test na wirtualnym zegarze.


1. Bot z dostępem do sandboxa#

W Integracje → MCP:

  1. W Konfiguracji włącz Włącz serwer MCP i Włącz Dev Mode (Layer 2). Ten drugi to globalny wyłącznik: wyłączasz go, a żaden bot nie zmieni kodu.
  2. W Boty MCP kliknij Dodaj bota, wybierz profile dostępu i włącz Dostęp do sandbox (Layer 2). Exec Mode zostaw wyłączony, bo pozwala uruchamiać kod na żywym systemie z pominięciem sandboxa.
  3. Skopiuj klucz API (vclu_mcp_...). Nie zostanie pokazany ponownie.

Sekcja Instrukcja połączenia na tej samej stronie ma gotową konfigurację dla Claude Code, Codex CLI i Gemini CLI. W skrócie:

{
  "mcpServers": {
    "vclu": {
      "type": "http",
      "url": "http://ADRES_VCLU:8080/mcp",
      "headers": { "Authorization": "Bearer KLUCZ_BOTA" }
    }
  }
}

2. Poproś o automatykę#

Opisz, co ma się dziać, tak jak opisałbyś to elektrykowi:

W nocy (21-6) ruch na czujce w wiatrołapie ma zapalać światło w wiatrołapie
na minutę. Jeśli ktoś zgasi je ręcznie, nie zapalaj przez 10 minut.
Napisz test, pokaż mi diff i poczekaj na moją zgodę przed wdrożeniem.

Agent przechodzi przez stały proces:

  1. Rozpoznanie - czyta opis domu, rejestr urządzeń i historię zmian czujki i światła, żeby znaleźć właściwe obiekty.
  2. Draft - pisze kod do modules/. Draft to kopia robocza, produkcja jeszcze się nie zmienia.
  3. Walidacja - sprawdzenie składni.
  4. Test w sandboxie - kod uruchamia się w izolacji, z wirtualnym zegarem.
  5. Diff - pokazuje różnicę względem tego, co działa teraz.
  6. Wdrożenie - z kopią zapasową poprzedniej wersji.

3. Test na wirtualnym zegarze#

Test to scenariusz: stan początkowy, kroki i oczekiwania. Dla wiatrołapu:

{
  "path": "modules/wiatrolap.lua",
  "at": "2026-10-04T23:00:00+02:00",
  "fixtures": [{ "path": "satel.zone.2", "kind": "satel_zone", "state": 0, "config": { "number": 2 } }],
  "steps": [
    { "set": "satel.zone.2", "value": 1 },
    { "expect_clu_calls": [{ "script": "DOU4992:execute(1, 60000)" }] },
    { "advance": 61 }
  ]
}

Test zaczyna się o 23:00, ustawia czujkę na 1 i sprawdza, czy do CLU poszła komenda zapalenia na 60 s. Komenda jest nagrywana, a nie wysyłana: w sandboxie nic w domu się nie ruszy. Krok advance przesuwa zegar o 61 s bez czekania. Dzięki temu da się sprawdzić także „po 10 minutach” albo „w dzień”.

Sandbox nie wysyła komend do Grentona i nie łączy się z Satelem ani Modbusem. Nie pozwala też uruchamiać procesów ani zapisywać plików, a zapętlony albo zbyt pamięciożerny kod przerywa.

4. Wdrożenie#

Po Twojej zgodzie agent wdraża draft. vCLU zapisuje kopię zapasową poprzedniej wersji, podmienia plik i przeładowuje Lua. Potem sprawdza, czy wdrożone moduły się załadowały. Jeśli nie, wdrożenie jest oznaczone jako nieudane, a agent dostaje listę błędów. Nowa wersja zostaje jednak na produkcji, dopóki jej nie przywrócisz albo agent jej nie poprawi.

Drafty i kopie zapasowe widzisz też sam w edytorze (Editor). Po otwarciu draftu na pasku pojawiają się Validate, Test i Promote, a po otwarciu kopii zapasowej - Restore.

5. Ślad po każdej zmianie#

  • Integracje → MCP → Dziennik audytu sandbox - każdy draft, test i wdrożenie, z nazwą bota.
  • Narzędzia → Historia i audyt - każda zmiana stanu w domu z jej sprawcą. Światło zapalone przez nową automatykę ma sprawcę automation:wiatrolap, a przełączone bezpośrednio przez bota - agent:<id bota> (np. agent:bot-3f2a…).

Co dalej?#