OpenClaw Skill ile Roborock’u Ajan Tabanlı ve Erişilebilir Yönetmek

by

⏱️ 30 dk tahmini okuma süresi
📝 5271 kelime
♿ WCAG 2.2 Uyumlu
Bu Makaleyi Sesli Dinleyin
Doğal Türkçe ses sentezleyici hazır



Akıllı temizlik robotunu doğal dille yönetmek ilk bakışta basit görünür: “Salonu temizle” denir, robot da çalışır. Oysa güvenilir bir sistemin görevi, bu cümleyi doğrudan cihaz komutuna çevirmekten çok daha fazlasıdır. Doğru robotu seçmek, haritayı güncel okumak, oda adını doğrulamak, cihazın o komutu gerçekten desteklediğini denetlemek, riskli işlemleri ayırmak ve verilen komutun fiziksel dünyada başlayıp başlamadığını gözlemlemek gerekir.

Bu kılavuzda OpenClaw üzerinde bir Skill ile Roborock benzeri akıllı cihazları ajan tabanlı, güvenli ve erişilebilir biçimde yönetebilecek bir mimari kuruyoruz. Örnekler temizlik robotu üzerinden ilerlese de aynı desen; akıllı priz, termostat, perde, hava temizleyici ve benzeri cihazlara uyarlanabilir.

Temel ilke: Dil modeli cihazı doğrudan yönetmemeli; kullanıcı niyetini yapılandırılmış bir isteğe dönüştürmeli, politika ve doğrulama katmanlarından geçen bu istek de cihaz adaptörü tarafından çalıştırılmalıdır.

1. “Ajan tabanlı yönetim” ne demektir?

Klasik otomasyonda giriş ve sonuç önceden bellidir: Saat 10.00’da robotu başlat. Ajan tabanlı yönetimde ise kullanıcı hedefi doğal dille tarif eder:

  • “Mutfakla antreyi bir kez temizle.”
  • “Sağına yarım metre ilerle.”
  • “Fırçaların bakım durumu nasıl?”
  • “Temizliği duraklat ve şarja dön.”

Ajan, bu isteği anlamlandırır; eksik olan ancak güvenle çıkarılamayan bilgiyi sorar; cihaz yeteneklerini ve anlık durumu okur; uygun aracı seçer; sonucu doğrular ve kullanıcıya anlaşılır biçimde bildirir. Bu yaklaşımın değeri yalnız doğal dil değildir. Asıl değer, bağlamı koruyan ve kanıt toplayan bir karar döngüsü kurmasıdır.

Sağlam bir döngü şu adımlardan oluşur:

  1. Niyeti belirle.
  2. Hedef cihazı ve kapsamı doğrula.
  3. Güncel cihaz durumunu ve yeteneklerini oku.
  4. İsteği tipli parametrelere dönüştür.
  5. Yetki ve güvenlik politikasını uygula.
  6. Komutu bir kez gönder.
  7. Komutun başladığını taze durum verisiyle doğrula.
  8. Tamamlanma gerekiyorsa geçmiş kaydından kanıtla.
  9. Sonucu erişilebilir ve eyleme dönük bir dille aktar.

İçindekilere dön

2. Skill, araç ve cihaz adaptörü aynı şey değildir

OpenClaw belgelerinde Skill, ajana belirli bir işi nasıl yapacağını öğreten bir klasör ve SKILL.md yönergesi olarak tanımlanır. Araç ise ajanın çağırabildiği gerçek işlemdir. Eklentiler de yeni çalışma zamanı yetenekleri sağlayabilir. Bu ayrım mimarinin temelidir.

  • Skill: Ne zaman hangi aracın kullanılacağını, hangi kontrollerin yapılacağını ve sonucun nasıl anlatılacağını belirler.
  • Politika kapısı: Okuma, rutin hareket, ayar değişikliği ve yıkıcı işlemleri sınıflandırır.
  • Cihaz adaptörü: Roborock protokolünü ya da kullanılan kütüphaneyi tek biçimli komutlara çevirir.
  • Sürücü/kütüphane: Cihazla bulut veya yerel ağ üzerinden konuşur.
  • Doğrulayıcı: Komut kabul edildi mi, robot gerçekten başladı mı, iş tamamlandı mı sorularını ayrı ayrı yanıtlar.

Bu ayrım sayesinde doğal dil katmanı değişse bile cihaz kontrolü korunur; farklı marka bir robot eklendiğinde de tüm sohbet mantığını yeniden yazmak gerekmez.

İçindekilere dön

3. Önerilen mimari

Aşağıdaki metin şeması, uçtan uca akışı gösterir:

Kullanıcı
  → Telegram / web / klavye / isteğe bağlı ses
  → OpenClaw ajanı
  → Skill: niyet, kapsam, diyalog ve yanıt kuralları
  → Güvenlik kapısı: yetki, allowlist, parametre doğrulama
  → Cihaz adaptörü: ortak komutlar ve normalize JSON
  → python-roborock veya üretici API'si
  → Roborock

Roborock
  → durum / hata / pil / harita / geçmiş
  → cihaz adaptörü
  → doğrulama ve olay katmanı
  → erişilebilir durum mesajı
  → kullanıcı

Şemadaki her ok bir güven sınırıdır. Kullanıcı metni, model çıktısı, oda adları, harita koordinatları ve cihaz yanıtları doğrulanmadan bir sonraki katmana aktarılmamalıdır.

Neden tek bir dev komut dosyası yerine katmanlar?

Tek dosyalık bir prototip çalışabilir; fakat zamanla üç sorun çıkarır: Dil modelinin ürettiği parametreler cihaz çağrısına karışır, hata ayıklama güçleşir ve erişilebilir geri bildirim sonradan eklenen bir ayrıntıya dönüşür. Katmanlı yapı; test edilebilirlik, cihaz bağımsızlığı ve geri alınabilirlik sağlar.

İçindekilere dön

4. Ön koşullar ve mevcut çözümü değerlendirme

Sıfırdan protokol yazmak yerine önce güncel ve sürdürülen bir kütüphane araştırılmalıdır. python-roborock, Roborock cihazları için çevrim içi ve çevrim dışı kontrol yolları sunan açık kaynaklı bir Python kütüphanesidir. Ancak proje belgeleri, desteklenen özelliklerin cihaz nesline ve trait’lere göre değişebildiğini; API komut listesinin tersine mühendislikle çıkarıldığını ve eksiksiz olmadığını açıkça belirtir.

Bu nedenle:

  • Bir komutun kütüphanede bulunması, her modelde çalıştığını kanıtlamaz.
  • “S8 destekliyor” gibi sabit varsayımlar yerine cihazın bildirdiği yetenekler okunmalıdır.
  • Desteklenmeyen veya boş alanlar sıfır olarak yorumlanmamalıdır.
  • Kütüphane güncellemesi, önce test ortamında doğrulanmalıdır.
  • Yerel kontrol ile bulut kontrolü aynı güven ve gecikme özelliklerine sahipmiş gibi sunulmamalıdır.

İçindekilere dön

5. Elinde Roborock varsa: sıfırdan çalışan sisteme geçiş

Bu bölüm, robotu satın almış ancak OpenClaw bağlantısını hiç kurmamış bir kullanıcının izleyeceği pratik yolu anlatır. Amaç, ilk günden bütün gelişmiş özellikleri açmak değil; önce güvenli bir salt okunur bağlantı kurmak, sonra adım adım hareket yetkisi vermektir.

Adım 1: Robotu önce üreticinin uygulamasında hazırlayın

OpenClaw bağlantısından önce Roborock’un resmî uygulamasında şu temel işlemleri tamamlayın:

  1. Robotu ev Wi-Fi ağına bağlayın ve hesabınızla eşleştirin.
  2. Bekleyen ürün yazılımı güncellemesi varsa üreticinin yönergeleriyle uygulayın.
  3. Robotun evi haritalamasını tamamlayın.
  4. Odaları ayırın ve “Mutfak”, “Salon”, “Antre” gibi benzersiz adlar verin.
  5. Girilmez bölgeleri ve sanal duvarları resmî uygulamadan tanımlayın.
  6. Resmî uygulamadan başlatma, duraklatma ve istasyona dönme işlemlerinin çalıştığını sınayın.

Bu aşama önemlidir; OpenClaw bozuk bir haritayı veya yanlış oda ayrımını kendiliğinden düzeltemez. Resmî uygulama ayrıca kurulum boyunca geri dönüş ve acil kontrol kanalı olarak korunmalıdır.

Adım 2: OpenClaw için bir ana makine seçin

Robotla sürekli konuşacak bir bilgisayar gerekir. Bu bilgisayar:

  • OpenClaw’ın çalıştığı desteklenen bir sistem olmalı,
  • güvenilir ev ağına bağlı kalmalı,
  • Python 3 çalıştırabilmeli,
  • kullanıcı hesabı kilitlendiğinde de gerekli arka plan hizmetlerini sürdürebilmeli,
  • disk şifreleme ve işletim sistemi güncellemeleriyle korunmalıdır.

Ana makineyi herkesin eriştiği ortak bir web sunucusuyla aynı güven sınırına koymayın. Cihaz adaptörü internete doğrudan açılmamalı; uzaktan erişim gerekiyorsa kimlik doğrulamalı OpenClaw Gateway veya güvenli özel ağ üzerinden sağlanmalıdır.

Adım 3: Python ortamını ayrı kurun

Robot kütüphanesini sistem Python’una karıştırmak yerine sanal ortam kullanın. Terminalde örnek kurulum:

mkdir -p robot-yardimcim
cd robot-yardimcim
python3 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install "python-roborock[cli]"

PowerShell kullanan sistemlerde etkinleştirme komutu .venv\Scripts\Activate.ps1 olur. Yalnız Python API’sini kullanacaksanız python-roborock paketi yeterlidir; [cli] eki, resmî depoda belirtilen komut satırı bağımlılıklarını da kurar.

Kurulumdan sonra sürümü kaydedin:

python -m pip show python-roborock

Üretimde sürümü sabitlemek, bir kütüphane güncellemesinin cihaz davranışını habersizce değiştirmesini önler. Yeni sürümü önce salt okunur testlerle deneyin.

Adım 4: Bir defalık hesap oturumu oluşturun

python-roborock deposundaki güncel örnek, hesap e-postasıyla bir giriş kodu istemeyi ve bu kodla oturum verisi almayı gösterir. Akışın özeti şöyledir:

from getpass import getpass
from roborock.web_api import RoborockApiClient

email = input("Roborock hesap e-postası: ")
api = RoborockApiClient(username=email)
await api.request_code()
code = getpass("E-postaya gelen tek kullanımlık kod: ")
user_data = await api.code_login(code)

# user_data ekrana yazdırılmaz.
# İşletim sisteminin güvenli kasasına veya OpenClaw SecretRef'e aktarılır.

Bu örnek bir akış şemasıdır; kalıcı saklama kodu kullanılan işletim sisteminin gizli bilgi kasasına göre yazılmalıdır. E-posta kodunu, oturum verisini veya hesabın parolasını SKILL.md içine, Git deposuna, sohbet mesajına ya da normal loga koymayın. Kurulum yardımcısı yalnız ilk eşleştirmede kullanılmalı; sonraki çalıştırmalarda korunan oturum verisi yüklenmelidir.

Birden çok ev veya cihaz varsa keşfedilen ilk robota otomatik bağlanmayın. Kurulum sırasında seçilen cihaz için sabit bir yerel takma ad oluşturun; örneğin vacuum-main. Gerçek seri numarasını kullanıcı mesajlarında göstermeye gerek yoktur.

Adım 5: Cihazı keşfedin ve yetenek envanteri çıkarın

Resmî python-roborock örneğinde create_device_manager() ile hesaba bağlı cihazlar alınır ve V1 özelliklerini sunan robotlar seçilir. İlk keşifte yalnız şu bilgileri kaydedin:

  • cihazın yerel takma adı,
  • model ve protokol ailesi,
  • durum, sarf malzemesi ve harita trait’lerinin bulunup bulunmadığı,
  • desteklenen istasyon özellikleri,
  • kullanılabilir temizlik ve ayar modları.

İlk test hareket içermemelidir. Önerilen sıra:

1. Hesaba bağlan.
2. Cihazları listele.
3. Seçilen cihazın yeteneklerini oku.
4. Pil, durum ve hata alanlarını yenile.
5. Sonucu normalize JSON olarak kaydet.
6. Bağlantıyı kapat.

Robotun durumunu okuyamıyorsanız hareket komutuna geçmeyin. Önce hesap bölgesi, ağ erişimi, kütüphane sürümü ve cihaz protokolünü kontrol edin.

Adım 6: Adaptörü önce salt okunur çalıştırın

adapter.py içinde ilk aşamada yalnız şu yöntemleri uygulayın:

capabilities
status
sensors-or-consumables
map-summary
rooms
history

Her yöntemin tek bir JSON belge döndürmesi, OpenClaw’ın ham Python nesnelerini yorumlamaya çalışmasını önler. Aşağıdaki kuralları daha baştan uygulayın:

  • Zaman aşımı için son başarılı veriyi “canlı” diye döndürmeyin.
  • Eksik alanı null, desteklenmeyen alanı unsupported olarak işaretleyin.
  • Zaman damgasını ve cihaz takma adını ekleyin.
  • Hesap, token, IP ve seri numarası gibi alanları çıktıya koymayın.
  • Harita görseline ek olarak oda adlarını ve robot konumunu metinle verin.

Terminalde yapılacak ilk kabul testi basit olmalıdır:

python robot_cli.py capabilities
python robot_cli.py status
python robot_cli.py rooms

Bu üç çağrı aynı cihazı gösteriyor ve hata vermiyorsa bir sonraki aşamaya geçilebilir.

Adım 7: Skill’i OpenClaw’a ekleyin

Hazırlanan klasörü OpenClaw çalışma alanındaki skills/robot-yardimcim/ dizinine yerleştirin. SKILL.md içinde mutlak, başka bilgisayarda çalışmayacak yollar yerine {baseDir} kullanın. Python yorumlayıcısının yolu ortam değişkeni veya güvenilir bir başlatıcı üzerinden belirlenebilir.

Skill’in yüklendiğini doğrulayın:

openclaw skills list

Ardından hareket içermeyen bir ajan testi çalıştırın:

openclaw agent --message "Robot yardımcımın pilini ve hata durumunu söyle."

Beklenen sonuç; taze durum verisi, açık zaman damgası ve kısa Türkçe açıklamadır. Yanıtta teknik yol, gizli bilgi veya uydurulmuş sensör değeri görünüyorsa hareket yetkisini açmayın.

Adım 8: Hareket komutlarını kademeli açın

İlk hareket testi için evin boş olduğu bir zamanı ve güvenli, açık bir alanı seçin. Sıra şu olmalıdır:

  1. status ile robotun istasyonda veya güvenli durumda olduğunu doğrulayın.
  2. start yerine mümkünse tek, iyi tanımlanmış bir oda seçin.
  3. Oda adını güncel haritadan kimliğe çevirin.
  4. Komutu açık --execute bayrağıyla bir kez gönderin.
  5. Tek bir taze durum okumasıyla robotun başladığını doğrulayın.
  6. Duraklatma ve istasyona dönme komutlarını sınayın.
  7. Son geçmiş kaydında alan, süre ve tamamlanma durumunu kontrol edin.

Bu aşamada robotun yanında fiziksel olarak bulunmak, yanlış oda eşlemesi veya harita sorunu varsa müdahale etmeyi kolaylaştırır. İlk test başarılı olmadan bölge koordinatları, uzaktan hedefe gitme ve zamanlanmış görevler açılmamalıdır.

Adım 9: Erişilebilir kullanıcı kanalını seçin

Ekran okuyucu kullanan biri için en hızlı başlangıç çoğu zaman metin tabanlı bir kanal veya erişilebilir OpenClaw arayüzüdür. İlk kullanım sözlüğü kısa tutulabilir:

“Robotun durumu nasıl?”
“Odaları listele.”
“Mutfağı bir kez temizle.”
“Duraklat.”
“Şarja dön.”
“Ana fırçanın bakım süresi ne kadar?”

Komutlar doğal dilde farklı söylenebilse de sonuçlar tutarlı olmalıdır. Örneğin “şarja dön” ve “istasyona git” aynı tipli niyete çevrilebilir. Robot hoparlöründen ses çıkaran özellikler varsa metin kanalında da “Hoparlörümden seslendim” gibi eşzamanlı geri bildirim verilmelidir.

Adım 10: Günlük kullanım ve bakım

Kurulum bittikten sonra sistem tamamen unutulmamalıdır. Aylık veya sürüm değişikliğinde şu kontroller yapılabilir:

  • Salt okunur durum ve oda testleri hâlâ geçiyor mu?
  • Kütüphane sürümü ve değişiklik kaydı incelendi mi?
  • Oda adları veya kimlikleri değişti mi?
  • Gizli oturum verisinin süresi doldu mu?
  • Arka plan izleyici, kullanıcı sorgularıyla çakışıyor mu?
  • Loglarda gizli bilgi veya gereğinden fazla harita verisi var mı?
  • Duraklatma, durdurma ve istasyona dönme yolu hâlâ çalışıyor mu?
  • Ekran okuyucu durum mesajlarını odağı kaybetmeden duyuruyor mu?

Robot hesabı değişirse ya da cihaz satılırsa yerel takma ad, oturum verisi ve önbellekli harita kayıtları güvenli biçimde kaldırılmalıdır.

İçindekilere dön

6. Skill klasörünü kurmak

En küçük yapı şöyledir:

skills/
└── robot-yardimcim/
    ├── SKILL.md
    ├── scripts/
    │   ├── robot_cli.py
    │   └── adapter.py
    └── references/
        ├── command-policy.md
        └── accessibility-checklist.md

OpenClaw çalışma alanındaki Skill’ler skills/ altında tutulabilir. SKILL.md dosyasının YAML üst bilgisinde en az name ve description bulunur. Skill içinden paketle gelen dosyalara {baseDir} ile başvurulabilir. Ortam gereksinimleri de metadata ile belirtilebilir.

Örnek, sadeleştirilmiş bir SKILL.md başlangıcı:

---
name: robot-yardimcim
description: Eşleşmiş temizlik robotunun durumunu okur; kullanıcı isteğiyle güvenli temizlik ve hareket komutlarını uygular.
metadata: {"openclaw":{"requires":{"bins":["python3"]}}}
---

# Robot Yardımcım

- Durum iddialarını her zaman taze cihaz verisine dayandır.
- Oda kimliği veya koordinat tahmin etme.
- Salt okunur işlemler ile cihazı değiştiren işlemleri ayır.
- Kullanıcının açık hareket isteği yoksa robotu hareket ettirme.
- Komut kabulünü tamamlanma olarak sunma.
- Başarısız hareket komutunu otomatik tekrarlama.
- Yanıtları kısa, doğal ve ekran okuyucuyla anlaşılır Türkçe üret.

CLI: `python3 {baseDir}/scripts/robot_cli.py <işlem>`

description alanı önemlidir; OpenClaw Skill’i ne zaman yükleyeceğine bu tanımdan da karar verir. Buna rağmen SKILL.md içine parola, oturum belirteci, e-posta veya yerel ağ anahtarı yazılmamalıdır.

İçindekilere dön

7. Adaptörün görevi: tek biçimli, tipli çıktı

Cihaz adaptörü, farklı protokol yanıtlarını ajanın güvenle kullanabileceği bir şemaya dönüştürmelidir. Örneğin durum sorgusu her zaman aynı üst düzey alanları döndürebilir:

{
  "ok": true,
  "observed_at": "2026-09-29T10:30:00+03:00",
  "device_id": "vacuum-main",
  "state": "cleaning",
  "battery_percent": 78,
  "error": null,
  "area_m2": 12.4,
  "duration_seconds": 1260,
  "raw": {}
}

Burada üç ayrıntı kritiktir:

  1. observed_at, verinin ne zaman okunduğunu gösterir.
  2. Desteklenmeyen bilgi 0 değil, null veya unsupported olarak döner.
  3. Teknik inceleme için ham yanıt saklanabilir; kullanıcıya ise yalnız gerekli ve anlaşılır alanlar sunulur.

Adaptörün ortak arayüzü marka bağımsız tasarlanabilir:

class VacuumAdapter:
    async def capabilities(self) -> dict: ...
    async def status(self) -> dict: ...
    async def map(self) -> dict: ...
    async def history(self, limit: int = 5) -> dict: ...
    async def start(self) -> dict: ...
    async def clean_rooms(self, room_ids: list[int], repeat: int) -> dict: ...
    async def pause(self) -> dict: ...
    async def dock(self) -> dict: ...

Böylece üst katman app_segment_clean gibi üreticiye özgü komutları bilmek zorunda kalmaz.

İçindekilere dön

8. Komutları risk sınıflarına ayırmak

Her çağrıyı aynı yetki düzeyinde çalıştırmak doğru değildir. Pratik bir sınıflandırma şöyledir:

A. Salt okunur işlemler

Pil, durum, hata, bakım sayaçları, oda listesi, harita özeti ve temizlik geçmişi bu gruptadır. Bunlar cihazı değiştirmez; yine de özel yaşam verisi içerebilecek harita veya geçmiş bilgileri gereksiz yere dışarı aktarılmamalıdır.

B. Rutin ve geri alınabilir işlemler

Temizliği başlatma, duraklatma, devam ettirme, belirli odaları temizleme ve istasyona dönme bu gruptadır. Kullanıcının açık isteği bu işlemleri yetkilendirebilir. Aynı konuşmada “mutfağı temizle” denmişken ayrıca anlamsız bir onay turu eklemek erişilebilirliği ve akıcılığı bozar.

C. Ayar değişiklikleri

Fan gücü, su seviyesi, ses düzeyi, çocuk kilidi veya zamanlayıcı gibi ayarlar tip, aralık ve cihaz desteği bakımından doğrulanmalıdır. Önce mevcut değer okunmalı ve değişiklik sonucu tekrar kontrol edilmelidir.

D. Yıkıcı veya güvenlik açısından hassas işlemler

Harita silme, Wi‑Fi bilgilerini sıfırlama, kayıt silme, ürün yazılımı ya da güvenlik ayarlarını değiştirme bu sınıftadır. Normal komut listesinden ayrı tutulmalı; açık kapsam, ek bayrak veya onay gerektirmelidir. OpenClaw’ın yürütme onayları ve allowlist yaklaşımı burada ikinci bir güvenlik katmanı oluşturabilir.

Basit bir kapı şöyle çalışabilir:

READ = {"get_status", "get_consumable", "get_map"}
DESTRUCTIVE = {"delete_map", "reset_wifi", "delete_clean_record"}

def authorize(command, *, execute=False, allow_destructive=False):
    if command not in READ and not execute:
        raise PolicyError("Bu işlem açık bir çalıştırma isteği gerektiriyor.")
    if command in DESTRUCTIVE and not allow_destructive:
        raise PolicyError("Bu işlem için yıkıcı işlem yetkisi gerekiyor.")

İçindekilere dön

9. Doğal dili tipli niyete çevirmek

Dil modeli doğrudan kabuk komutu üretmek yerine sınırlı bir niyet şeması doldurmalıdır:

{
  "intent": "clean_rooms",
  "target_device": "vacuum-main",
  "rooms": ["Mutfak", "Antre"],
  "repeat": 1
}

Sonraki katman, oda adlarını güncel harita eşlemesiyle kimliğe çevirir. “Mutfak” bulunamıyorsa en yakın tahmini sessizce seçmek yerine kısa bir açıklama ve mevcut oda listesi sunulur. Bu yaklaşım, dil modelinin ikna edici ama yanlış bir oda kimliği uydurmasını engeller.

Aynı kural koordinatlı hareket için daha da önemlidir. “Sağıma yarım metre gel” isteğinde “sağ”ın haritaya göre mi, robotun baktığı yöne göre mi olduğu tanımlanmalıdır. Güvenli tasarımda:

  1. Harita ve robot konumu güncellenir.
  2. Hedef hareket ettirmeden hesaplanır.
  3. Girilmez bölgeler ve sınırlar denetlenir.
  4. Kısa ömürlü bir önizleme belirteci üretilir.
  5. Yalnız bu belirteçle hareket komutu verilir.

Bu iki aşamalı düzen, modelin eski bir haritadan kalan koordinatı yeniden kullanmasını önler.

İçindekilere dön

10. “Komut kabul edildi” ile “iş tamamlandı” aynı değildir

Fiziksel cihazlarda en sık yapılan hata budur. API çağrısının başarılı dönmesi yalnız komutun kabul edildiğini gösterebilir. Robot birkaç saniye sonra engel, düşük pil, elle durdurma, harita uyuşmazlığı veya bağlantı sorunu nedeniyle çalışmayı bırakabilir.

Bu nedenle görev yaşam döngüsü ayrı durumlarla izlenmelidir:

requested
→ validated
→ accepted
→ observed_started
→ in_progress
→ completed | interrupted | failed | unknown

Bir temizlik komutundan sonra en az bir taze durum okuması yapılmalıdır. “Tamamlandı” demek için yalnız robotun boşta olması yeterli değildir; son temizlik kaydındaki tamamlanma alanı, süre ve alan gibi kanıtlar birlikte değerlendirilmelidir. Kanıt yoksa doğru sonuç unknown ya da “başladığını doğrulayamadım”dır.

Mutasyon çağrısını otomatik tekrarlamak da risklidir. İlk yanıt ağda kaybolmuş olsa bile robot komutu almış olabilir. Körlemesine ikinci kez oda temizliği veya ayar değişikliği göndermek çift çalışmaya neden olabilir. Önce durum okunmalı, ardından kullanıcıya gerçek gözlem bildirilmelidir.

İçindekilere dön

11. Eşzamanlılık: arka plan takibi kullanıcı komutunu boğmamalı

Robot bağlantıları çoğu zaman tek oturum, tek soket veya sınırlı istek hızıyla çalışır. Bu yüzden bir işlem kilidi yararlıdır. Ancak kilit tasarımı hatalıysa dakikalık bir izleyici, kullanıcının “Şu an ne yapıyorsun?” sorgusunu sürekli engelleyebilir.

Sağlam yaklaşım:

  • Cihaz başına tek mutasyon kilidi kullanın.
  • Okuma sorgularına kısa ve sınırlı bekleme verin.
  • İnteraktif isteklere arka plan yoklamasından daha yüksek öncelik tanıyın.
  • İzleme sıklığını cihaz ve kullanıcı ihtiyacına göre sınırlayın.
  • Kullanıcı istemiyorsa sürekli yoklamayı kapatın.
  • Kilit sahibini ve zamanını loglayın; kilit dosyasını tek başına “iş sürüyor” kanıtı saymayın.
  • Hareket komutlarını çakışmada otomatik sıraya koymayın; eski bir komut sonradan beklenmedik biçimde çalışabilir.

Buradaki erişilebilirlik boyutu da önemlidir: Ekran okuyucu kullanan bir kişi durum bilgisini istediğinde, arka plandaki görünmez bir görev yüzünden sürekli teknik hata duymamalıdır.

İçindekilere dön

12. Erişilebilir kontrol deneyimi nasıl tasarlanır?

WCAG 2.2 doğrudan robot donanımına değil, robotu yöneten web veya uygulama arayüzüne uygulanır. Yine de aşağıdaki ilkeler sohbet kanalında, kontrol panelinde ve mobil uygulamada birlikte düşünülmelidir.

Metin birincil, ses isteğe bağlı olmalı

Sesli komut kullanışlıdır; ancak tek yol olmamalıdır. Kullanıcı aynı işlemi klavye, ekran okuyucu veya metin mesajıyla da yapabilmelidir. Bu yaklaşım WCAG 2.1.1 Klavye ve 2.5.6 Eşzamanlı Girdi Mekanizmalarıyla uyumludur.

Harita sürükleme zorunlu tutulmamalı

Haritada bir noktayı sürükleyerek seçmek, görmeyen veya motor becerisi kısıtlı kullanıcılar için erişilebilir değildir. Oda listesi, yön ve mesafe girişi, koordinat alanları ve “mevcut konumdan sağa 50 cm” gibi metinsel alternatifler sağlanmalıdır. Bu tasarım WCAG 2.5.7 Sürükleme Hareketleri ilkesini karşılamaya yardımcı olur.

Kontrollerin adı, rolü ve durumu programatik olmalı

“Başlat”, “Duraklat”, “Şarja dön” ve oda seçimleri gerçek düğme/checkbox bileşenleri olmalı; yalnız simge ya da görsel konumla anlatılmamalıdır. Etiketler kısa ama bağlamlı olmalıdır: “Mutfağı seç”, “Temizliği duraklat”. Bu nokta WCAG 4.1.2 Ad, Rol, Değer ile doğrudan ilişkilidir.

Durum güncellemeleri odağı çalmamalı

Robot çalışmaya geçtiğinde veya hata oluştuğunda ekran okuyucuya bilgi verilmelidir; fakat klavye odağı her güncellemede başka yere taşınmamalıdır. Web arayüzünde role="status" veya uygun canlı bölge kullanılabilir:

<p id="robot-status" role="status" aria-live="polite">
  Temizlik başladı. Pil yüzde 78.
</p>

Kritik ve acil hata dışında polite duyuru, kullanıcının o anda dinlediği içeriği kesmez. WCAG 4.1.3 Durum Mesajları, odağı değiştirmeden programatik olarak belirlenebilen geri bildirim ister.

Hata mesajı eyleme dönük olmalı

“RPC error -32000” yerine “Robot çevrim dışı görünüyor; komut gönderilmedi” denmelidir. Hata ile öneri birbirinden ayrılmalıdır. Sensör bakım süresi dolmuşsa “Sensör kesin kirli” denmemeli; “Bakım sayacı sensör temizliğini öneriyor” denmelidir.

Zaman ve ölçüler anlaşılır olmalı

Ham saniye ya da milimetre yerine “12 dakika”, “0,5 metre” ve “12,4 metrekare” gibi okunabilir birimler sunulmalıdır. Tarih ve saat, kullanıcının saat diliminde açıklanmalıdır.

Robotun fiziksel sesi, metnin yerine geçmemeli

“Beni bul” gibi komutlar robot hoparlöründen ses üretebilir. Bu, robotun yerini bulmaya yardımcı olur; ancak işitme engelli kullanıcılar için uygulama veya mesaj kanalında eşzamanlı metin geri bildirimi bulunmalıdır. Tersine yalnız görsel bildirim de yeterli değildir.

Doğal dil, doğruluktan ödün vermemeli

Robot “Pilim yüzde 78, istasyondayım” diyebilir; fakat “Kendimi harika hissediyorum” gibi sensörlerle doğrulanamayan ifadeler kullanmamalıdır. Birinci tekil anlatım deneyimi insancıllaştırabilir; gerçek durumu uydurmaya gerekçe olamaz.

İçindekilere dön

13. Gizli bilgiler ve mahremiyet

Akıllı ev sistemi; ev haritası, oda adları, temizlik saatleri ve cihaz konumu gibi hassas veriler işleyebilir. Bu nedenle:

  • Kimlik bilgilerini SKILL.md, kaynak kodu, günlük veya sohbet çıktısına yazmayın.
  • OpenClaw SecretRef ya da işletim sisteminin güvenli kimlik kasasını kullanın.
  • Araç çıktılarında token, çerez, e-posta ve yerel ağ ayrıntılarını maskeleyin.
  • Harita görselini yalnız gerektiğinde üretin; metinsel oda listesi varsayılan olsun.
  • Loglarda kullanıcı metni yerine mümkünse normalize niyet ve sonuç kodu saklayın.
  • Cihaz hesabına yalnız gerekli yetkileri verin.
  • Dışa açık Gateway ile cihaz ağı arasında doğrudan, sınırsız bir köprü kurmayın.

Skill dosyaları paylaşılabilir paketlerdir; dolayısıyla gizli depolama alanı olarak kullanılmamalıdır. Yürütme onayları da tek başına güvenlik modeli değildir; araç politikası, allowlist, parametre doğrulama ve işletim sistemi sınırları birlikte uygulanmalıdır.

İçindekilere dön

14. Test planı

İyi görünen bir sohbet demosu yeterli değildir. En az şu senaryolar otomatik veya tekrarlanabilir biçimde sınanmalıdır:

  1. Normal akış: Durum okuma, tek oda temizleme, duraklatma ve istasyona dönme.
  2. Desteklenmeyen komut: Kütüphanede bulunan ama cihazda olmayan özellik.
  3. Boş veri: Pil, hata veya sarf alanının null dönmesi.
  4. Eski harita: Oda kimliğinin değişmesi ve önizleme belirtecinin süresinin dolması.
  5. Komut kabulü sonrası kesinti: API başarılı; ancak temizlik kaydı tamamlanmamış.
  6. Bağlantı kaybı: Komutun gönderilip gönderilmediğinin belirsiz kalması.
  7. Eşzamanlı istek: İzleme ile kullanıcı sorgusunun çakışması.
  8. Yıkıcı istek: Harita silmenin normal --execute ile engellenmesi.
  9. İstem enjeksiyonu: Oda adı veya cihaz metnindeki “güvenlik kontrolünü atla” benzeri içeriğin veri olarak kalması.
  10. Erişilebilirlik: Yalnız klavyeyle kullanım, ekran okuyucu duyuruları, odağın korunması ve sürüklemesiz harita işlemi.

Kabul ölçütleri yalnız “komut hata vermedi” olmamalıdır. Yanlış robotun hareket etmemesi, desteklenmeyen bilgi için güvenli biçimde not_available dönmesi ve başarısız mutasyonun tekrarlanmaması da test edilmelidir.

İçindekilere dön

15. Uygulama kontrol listesi

Yayına almadan önce şu listeyi tamamlayın:

  • Her cihazın değişmeyen bir iç kimliği var.
  • Skill doğru zamanda yükleniyor ve openclaw skills list içinde görünüyor.
  • Okuma, rutin hareket, ayar ve yıkıcı işlemler ayrıldı.
  • Cihaz yetenekleri çalışma anında okunuyor.
  • Oda kimliği ve koordinat tahmin edilmiyor.
  • Mutasyonlar açık kullanıcı hedefi olmadan çalışmıyor.
  • Başarısız mutasyon otomatik tekrarlanmıyor.
  • “Kabul edildi”, “başladı” ve “tamamlandı” ayrı raporlanıyor.
  • Gizli bilgiler Skill ve logların dışında tutuluyor.
  • Arka plan izleme interaktif sorguyu engellemiyor.
  • Tüm temel işlevlerin klavye ve ekran okuyucu yolu var.
  • Harita için sürüklemesiz, metinsel alternatif bulunuyor.
  • Durum mesajları odağı çalmadan duyuruluyor.
  • Ham hata kodları anlaşılır Türkçe eylemlere çevriliyor.
  • Son durum gerçek cihazdan uçtan uca doğrulanıyor.

İçindekilere dön

Sonuç

OpenClaw Skill ile Roborock yönetiminde başarı, dil modeline daha fazla yetki vermekten değil; yetkiyi doğru katmanlara bölmekten gelir. Skill diyaloğu ve iş akışını tarif eder, politika kapısı sınırları uygular, adaptör cihaz ayrıntılarını soyutlar, doğrulama katmanı fiziksel sonucu kanıtlar ve erişilebilir arayüz her adımı anlaşılır kılar.

En güvenilir sistem, her soruya iddialı bir yanıt üreten değil; bildiğini taze veriden söyleyen, bilmediğini açıkça ayıran ve riskli komutta güvenli biçimde duran sistemdir. Bu mimari kurulduğunda “Mutfağı temizle” cümlesi, yalnız rahat bir kısayol olmaktan çıkar; izlenebilir, erişilebilir ve farklı akıllı cihazlara genişletilebilir bir ev otomasyonu sözleşmesine dönüşür.

İçindekilere dön

Kaynaklar

İçindekilere dön

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

✅ Uygulama Başarıyla Güncellendi!
🟢 Profil Uygulandı