W grudniu zeszłego roku (2025) zacząłem pisać mały projekt.
Pomysł był stosunkowo prosty: chciałem stworzyć wirtualne CLU, które będzie można uruchomić na Raspberry Pi albo zwykłym komputerze i podłączyć do istniejącej instalacji Grenton.
Nie planowałem pisać nowego systemu automatyki domowej.
Nie planowałem platformy pluginów, własnego runtime’u Lua, HomeKita, Home Assistanta, MQTT, HTTP, integracji z Satelem, MCP ani kilkudziesięciu innych rzeczy, które ostatecznie się tam znalazły.
Chciałem po prostu rozwiązać kilka problemów, które przeszkadzały mi we własnym domu.
Wszystko potoczyło się zupełnie inaczej.
W pewnym sensie zacząłem ten projekt dziewięć lat temu
Kiedy spojrzałem ostatnio na stare wpisy na tym blogu, dotarło do mnie, że vCLU nie wzięło się właściwie znikąd.
W 2017 roku rozbierałem komunikację Grentona, zaglądałem do OM.LUA, sprawdzałem co CLU ma pod maską i pisałem własny Gate.
Później bawiłem się modułem GATE HTTP, integrowałem rekuperator, IFTTT i inne rzeczy.
Potem napisałem symulator Grentona – Playgorund w LUA, który pozwalał wczytać konfigurację z Grentona i symulować część zachowań w przeglądarce. Ten projekt stał się sercem vCLU. Niektóre pliki mają jeszcze funkcje i metody z tamtego projektu.
Chciałem zbudować środowisko deweloperskie, w którym można przetestować kod. Sprawdzić jak działa. Zasymulować działanie zanim kod zostanie wysłany do CLU.
Po kilku latach wróciłem właściwie do tego samego problemu, tylko z dużo większym doświadczeniem i trochę innym pytaniem:
dlaczego mądry dom to nie po prostu oprogramowanie?
Bez rysowania dzid, bez formularzy, bez tych wszystkich „ułatwień”, które mają sprawić wrażenie, że konfiguracja będzie łatwa i przyjemna.
Język programowania pozwala na wszystko, na pełną kontrolę nad zachowaniem domu. Więc poszedłem w tę stronę.
Pierwsza wersja miała tylko udawać CLU
Pierwotny pomysł był naprawdę niewielki. vCLU miało pojawiać się w Grenton Object Managerze jak normalne CLU.
OM miał je znaleźć, połączyć się z nim i wysłać konfigurację.
Tyle.
Pierwszym dużym wyzwaniem była więc kompatybilność: discovery, protokół komunikacyjny, szyfrowanie, komendy, transfer plików i sposób, w jaki Object Manager traktuje urządzenie.
Kiedy to zaczęło działać, to podpiłem LUA i pliki z symulatora Playground. Okazało, że mam całkiem ciekawy system ze zdarzeniami, jasnymi odpowiedzialnościami i całkiem zgrabną architekturą. Na typ etapie zaczęły krążyć pytania co jeszcze dodać?
Dlaczego nie podłączyć MQTT?
Albo Home Assistanta?
Albo HomeKita?
I w ten sposób z emulatora zaczął powstawać runtime.
Potem projekt zaczął żyć własnym życiem
W styczniu miałem już registry, event bus, Lua i pierwsze integracje.
Później doszedł MQTT.
HomeKit.
Home Assistant.
HTTP.
GPIO.
Pluginy.
Prometheus.
Dashboardy.
MCP i eksperymenty z agentami AI.
Hot reload.
Backupy, audyt zmian, uprawnienia i coraz więcej mechanizmów, które pojawiają się dopiero wtedy, kiedy przestajesz pisać demo, a zaczynasz budować coś, co ma działać miesiącami bez opieki.
W marcu projekt miał już dziesiątki tysięcy linii kodu.
I wtedy chyba pierwszy raz dotarło do mnie, że nie piszę już dodatku do Grentona.
Piszę własny runtime automatyki domowej.
Najważniejsze było dla mnie jedno: niczego nie rozwalić
Od początku vCLU rozwijałem obok istniejącej instalacji.
Nie chciałem przepinać na eksperymentalny kod ogrzewania, alarmu ani rzeczy, od których zależy normalne funkcjonowanie domu.
Dlatego przez długi czas vCLU głównie obserwowało.
Zbierało dane.
Synchronizowało urządzenia do HomeKit i Home Assistanta.
Łączyło różne systemy.
To okazało się bardzo dobrym sposobem testowania.
Dziś vCLU działa w moim domu od tygodni praktycznie bez przerwy.
I chyba najbardziej cieszy mnie nie liczba funkcji, tylko coś znacznie mniej spektakularnego:
przestałem je zauważać.
System po prostu działa.
Nie zaglądam co kilka godzin do logów.
Nie restartuję go codziennie.
Nie zastanawiam się rano, co tym razem się wysypało.
Cały czas znajduję rzeczy do poprawienia i nadal bardzo dużo pracuję nad stabilnością, ale pojawiło się wreszcie to przyjemne poczucie, że projekt zaczyna oddychać sam.
AI napisało sporą część tego projektu
Nie będę tutaj udawał, że vCLU powstało tak samo jak moje projekty sprzed dziesięciu lat.
Nie powstało.
Bardzo dużo kodu pisałem przy pomocy modeli językowych. Zacząłem od wczesnego Claude code – soneta. Wraz z czasem zmieniali się agenci, zmieniał się sposób pracy z nimi, wszystko bardzo przyspieszyło. AI pomagało mi implementować kolejne elementy, pisać testy, dokumentację, refaktoryzować kod i sprawdzać pomysły.
I przyznam, że przed publikacją trochę mnie to przeraża.
Znam kod, ale jego większą część pisało AI. Wiele razy się okazywało podczas review, że AI z jakiegoś powodu napisał te same helpery, złamał istniejącą konwencję. Poszedł na skróty.
Sporo z tego udało mi się wyłapać, ale na pewno są miejsca, których nie wyłapałem. Cały projekt ma masę testów, te testy zapobiegają przed regresjami i chronią projekt przed degradacją.
Naturalne oddzielnie logiki biznesowej (LUA) od frameworka (Go) pozwoliło też dość łatwo trzymać agenta w ryzach, choć często próbował iść na skróty i pisać kod nie w tej warstwie.
Nie chcę, żeby vCLU było AI slop. Choć na pewno trochę jest. Żeby nie wydać ostatniego gniota, bardzo dużo czasu poświęciłem na testowanie.
Dlatego przez ostatnie miesiące dużo więcej czasu niż na dodawanie nowych funkcji poświęcałem na rzeczy znacznie mniej efektowne:
testowanie, upraszczanie, dokumentację, obsługę błędów, reconnecty, migracje, backupy i uruchamianie tego wszystkiego we własnym domu.
Były momenty, że vClu miało wycieki pamięci, zjadało cały RAM, integracje nie działały, timery blokowały runtime.
W tej chwili projekt zajmuje śmiesznie mało pamięci i można go uruchomić nawet na pierwszym RPI.
AI jako użytkownik systemu
W okolicach lutego i marca MCP zaczęło robić się popularne. Szybko je zaadaptowałem, tak żeby agent mógł podejrzeć aktualny stan domu.
Kolejnym krokiem było umożliwienie agentowi pisania kodu.
I wtedy powstał pomysł kilku poziomów dostępu.
Layer 1 – device access
Na tym poziomie agent może pobierać informacje o tym, co dzieje się w domu. Widzi wejścia i wyjścia, wie, czy światła są zapalone, jaka jest temperatura, jaki jest stan urządzeń.
Ma też możliwość zmiany stanu urządzeń, gdy ma do nich odpowiedni dostęp. Np. Włączanie lampki na biurku.
Razem z tą warstwą powstał system uprawnień. To człowiek decyduje, do czego konkretny agent ma dostęp i co wolno mu zobaczyć a co wolno włączyć lub wyłączyć.
Layer 2 – develop
Agenci całkiem dobrze radzą sobie z programowaniem. Z vCLU radzą sobie szczególnie dobrze, bo system został zaprojektowany tak, żeby jego API i model obiektów były dla nich zrozumiałe.
Na tym poziomie agent może pisać kod i uruchamiać go w sandboxie. To było dla mnie bardzo ważne.
Nie chcę, żeby agent podczas testowania napisanej przez siebie automatyzacji otworzył prawdziwą bramę garażową albo zaczął przełączać fizyczne przekaźniki.
Dlatego w sandboxie dostaje kopię obiektów(mocków) domu i może na nich testować swoje rozwiązanie bez wpływu na prawdziwą instalację.
Kiedy skończy pisać automatyzację, może ją przetestować, a następnie wypromować.
Może się to odbyć za zgodą człowieka albo automatycznie, zależnie od nadanych uprawnień.
Cała historia pracy agenta jest zapisywana, więc później można sprawdzić, co zrobił, jaki kod napisał i co uruchamiał.
Layer 3 – execute
To ostatni poziom.
Agent otrzymuje bezpośredni dostęp do wykonywania operacji na prawdziwym systemie.
Tutaj sandbox już go nie chroni. Jeśli ma odpowiednie uprawnienia, może sterować prawdziwymi urządzeniami.
Dlatego ten poziom dostępu powinien być przyznawany świadomie.
Cały projekt został przygotowany tak, żeby agent mógł być jednym z normalnych użytkowników systemu.
Człowiek jest potrzebny przede wszystkim na początku – to on decyduje, na którym poziomie może działać konkretny agent.
Prawie rok później
Od pierwszego commita minęło około dziesięciu miesięcy. Projekt zajmował mi wieczory, wolne chwile i zdecydowanie więcej czasu, niż planowałem.
Po drodze kilka razy całkowicie przebudowywałem fragmenty architektury.
Napisałem dokumentację, testy, tutoriale, stronę i narzędzia potrzebne do tego, żeby ktoś poza mną miał w ogóle szansę tego użyć.
Nagrałem nawet jeden tutorial, który kosztował mnie kilkanaście godzin pracy, a obejrzało go raptem 50 osób.
Dlatego większość wiedzy trafiła ostatecznie do dokumentacji.
I teraz jestem w dość dziwnym miejscu.
Przez prawie rok vCLU było moim prywatnym projektem.
Mogłem zmienić API, wyrzucić połowę kodu albo wszystko przebudować i nikogo to poza mną nie obchodziło.
Za chwilę przestanie być tylko moje.
Ktoś je pobierze.
Ktoś uruchomi.
Ktoś znajdzie błąd pięć minut później.
Ktoś stwierdzi, że zrobiłem coś kompletnie bez sensu.
I prawdopodobnie wszystkie te rzeczy wydarzą się jednocześnie.
Trochę mnie to przeraża.
Ale chyba właśnie dlatego nadszedł czas, żeby je wypuścić.
vCLU 1.0 jest gotowe.
Strona vclu.pl
Dokumentacja: docs.vclu.pl
