Integracja oświetlenia IKEA TRADFRI z systemem Fibaro w kilku prostych krokach

W tym artykule pokażę, jak połączyć system inteligentnego domu Fibaro (wersja Z‑Wave) z oświetleniem IKEA i bramką TRADFRI. Na rynku jest coraz więcej tego typu „inteligentnych” urządzeń, ale niestety wraz z rosnącą ich liczbą rośnie liczba problemów, gdy powinny one współpracować. Jaki bowiem jest sens posiadania kilku systemów w domu, sterowanych z kilku różnych apek i używania dodatkowych aplikacji typu IFTTT do ich współpracy? Żaden – lepiej wszystko mieć w jednym miejscu.

Do napisania tego artykułu zaś skłonił mnie fakt, że w internecie praktycznie brak kompleksowych materiałów na ten temat – coś tam można znaleźć, niestety mocno nieaktualnego i tylko w języku angielskim, więc trochę się namęczyłem, zanim przełożyłem to na działającą konfigurację. Mam nadzieje, że skorzysta z tych doświadczeń jeszcze ktoś oprócz mnie :)

Aby połączyć system oświetlenia IKEA z systemem Fibaro opartym o standard Z‑Wave potrzebne będą dodatkowo takie gadżety:

• bramka IKEA TRADFRI, obecnie za 149 zł

• dowolny serwer linuksowy, na przykład Raspberry Pi, za ok. 150-400 zł (w zależności od wyposażenia i akcesoriów - wcale nie musi to być najnowszy model)

Mój zestaw oświetlenia jest bardzo skromny, bo jest to tylko jeden sterownik z listwami LED nad blatem w kuchni. Niezależnie jednak od liczby urządzeń, procedura jest identyczna i pozwala dodać wiele różnych świateł. Aby programowo sterować systemem IKEA, konieczny jest zakup bramki sieciowej TRADFRI i podłączenie jej do sieci LAN kablem (nie posiada modułu WiFi). Najlepiej też od razu nadać bramce stały adres IP na routerze. U mnie będzie to 192.168.1.250. Przy instalacji warto zrobić sobie również zdjęcie spodu urządzenia, gdzie znajdują się kody uwierzytelniające – przyda się później.

Najgorszym momentem całej procedury jest podłączenie rzeczonej bramki do systemu IKEA. Na tym etapie każdy zwykle posiada już sparowanego z systemem pilota zdalnego sterowania… Otóż wówczas nie da się już dodać bramki, trzeba system zresetować i dodać wszystko na nowo. Jeśli jest to jeden sterownik, tak jak u mnie, to pół biedy, a jeśli więcej… trzeba zacisnąć zęby, czasem wspiąć się na drabinę albo zanurkować pod meble i zgodnie z instrukcją w IKEA połączyć wszystko ze sobą jeszcze raz. Bramka TRADFRI pełni wówczas funkcję „hosta”, a nie pilot.

Ok, zakładam, że bramka jest już podłączona, a oświetleniem można sterować z aplikacji IKEA lub z pilota. Czas podpiąć to do Fibaro. Bezpośrednio oczywiście nie jest to możliwe, ponieważ IKEA wybrała standard bezprzewodowy Zigbee, a Fibaro tradycyjnie korzysta ze standardu Z-Wave. Być może zmieni się to wraz z kolejnymi aktualizacjami do Fibaro Home Center 3, które ma obsługiwać również urządzenia Zigbee, ale na razie nie zanosi się na to. Potrzebny jest więc pośrednik. Tak się składa, że Zigbee to standard używany również przez żarówki Philips Hue, co ułatwia sprawę, bo wsparcie tych urządzeń jest dość dobre wśród społeczności zapaleńców inteligentnego domu. Skorzystamy więc z aplikacji diyHue, która emuluje sterownik systemu Hue i udostępnia proste REST API pozwalające sterować urządzeniami.

Przechodzimy do Raspberry Pi, na którym zainstalowany jest system Raspbian. Gorąco polecam instalację Dockera, ponieważ wspomniana aplikacja diyHue posiada także oficjalnie przygotowany i wspierany przez twórców obraz dockerowy. Sama instalacja Dockera na malinie jest bardzo prosta i tylko minimalnie bardziej skomplikowana niż na najpopularniejszych wiodących dystrybucjach Linuksa.

Zakładamy katalog dla naszej aplikacji:

mkdir /var/docker/diyHue
cd /var/docker/diyHue

W katalogu tym zakładamy podkatalog export, w którym przechowywana będzie konfiguracja:

mkdir export

Możemy teraz skorzystać z docker-compose, aby przygotować konfigurację. Instalacja docker-compose jest jednak dość złożona na Raspbianie, a przynajmniej u mnie nie do końca wszystko zagrało. Proponuję dla ułatwienia pominąć go i samemu napisać prosty skrypt shellowy do uruchomienia kontenera z diyHue:

#!/bin/bash
docker run \ 
  -d \ 
  --name diyHue \ 
  --network="bridge" \ 
  -e 'MAC=b8:27:eb:ec:17:d0' \ 
  -e 'IP=192.168.1.251' \ 
  -v /var/docker/diyHue/export/:/opt/hue-emulator/export/:rw \ 
  -p 9980:80/tcp \ 
  --restart always \ 
  diyhue/core:latest

Co my tu mamy? Uruchamiamy kontener w tle (-d), nazywamy go diyHue i korzystamy z trybu sieciowego bridge – aplikacja diyHue została tak przygotowana, abyśmy nie musieli używać trybu host i współdzielić warstwy sieciowej z systemem hosta. Mimo wszystko, gdyby pojawiły się jakieś kłopoty np. z UPnP, można spróbować to ustawienie przełączyć. W trybie bridge musimy obowiązkowo podać jako zmienne środowiskowe adres MAC oraz adres IP, pod jakimi widziana jest malina w naszej sieci. Na koniec montujemy przygotowany wcześniej, pusty katalog export w odpowiedniej ścieżce i publikujemy port 80 z kontenera – w zasadzie dowolny. Najlepiej żeby nie był to domyślny port 80, bo narażamy się na konflikty w przyszłości. Ja wybrałem 9980. Dla korzystania z REST API nie ma to znaczenia, nie wiem jednak jak np. z apkami Philips Hue na telefony gdyby ktoś chciał ich używać – ja nie używam. Konfigurację kontenera zamyka polityka restartów (always, dzięki czemu kontener będzie uruchamiany zawsze po restarcie systemu).

Nadajemy prawa do uruchomienia skryptu i odpalamy go. Docker pobierze obraz i uruchomi kontener:

chmod +x launcher.sh ./launcher.sh

Po uruchomieniu możemy śledzić logi aplikacji (parametr -f będzie na bieżąco drukować na ekranie nową zawartość loga aż do przerwania przez CTRL-C):

docker logs diyHue -f

Przechodzimy do przeglądarki i wywołujemy panel webowy aplikacji pod adresem http://192.168.1.251:9980 (jest to po prostu adres Raspbery Pi i port opublikowany przez Dockera). Interfejs aplikacji jest dość surowy, ale nie o wrażenia estetyczne tutaj chodzi. Musimy zrobić tylko dwie rzeczy i mamy go już na zawsze z głowy.

Pierwszą rzeczą jest dodanie bramki IKEA TRADFRI, a wraz z nią wszystkich sparowanych z nią sterowników oświetlenia. Wchodzimy w opcję Import from Tradfri i wpisujemy adres IP naszej bramki (nie maliny!), a także 16‑znakowy kod zabezpieczeń ze spodu obudowy. Po kliknięciu Save powinniśmy ujrzeć komunikat o liczbie wykrytych i dodanych do aplikacji diyHue urządzeń.

Drugą rzeczą jest dodanie użytkownika, którym będziemy posługiwać się, aby strzelić do REST API i zarządzać stanem oświetlenia. W tym celu właśnie z owego API skorzystamy. Możemy wykorzystać Postmana, curla albo webowego interfejsu samej aplikacji diyHue dostępnego pod adresem http://192.168.1.251:9980/debug/clip.html. Zanim cokolwiek będziemy mogli jednak zrobić, trzeba zasymulować „naciśnięcie przycisku” na bramce Philips Hue i autoryzację nowego urządzenia. Robimy to wchodząc w opcję Link device w menu głównym, podając domyślną nazwę użytkownika Hue oraz hasło Hue. Wpisujemy te dane ponownie do formularza, klikamy Activate i od tej pory mamy 30 sekund na wykonanie następnego kroku.

Wysyłamy na endpoint /api żądanie POST z następującą zawartością:

POST /api

{
  "devicetype": "fibaro" 
}

Powyższy „typ urządzenia”nie ma znaczenia, jest to tak naprawdę nazwa własna użytkownika. W odpowiedzi otrzymamy informację o sukcesie i identyfikator użytkownika. Koniecznie zapiszmy go, będziemy się nim posługiwać w przyszłości.

Zanim przejdziemy do integracji z Fibaro, warto przetestować, czy wszystko działa. Spróbujmy pobrać informacje o naszym oświetleniu:

GET /api/(tutaj identyfikator)/lights

W odpowiedzi otrzymujemy szczegóły na temat stanu poszczególnych sterowników. W tej chwili ten o identyfikatorze 1 jest wyłączony.

Spróbujmy włączyć światło, tym razem żądaniem PUT:

PUT /api/(tutaj identyfikator)/lights/1/state

{ 
  "on": true, 
  "bri": 254 
}

Jak widać, jasność podawana jest w skali 0‑254. Wyłączając światło można, ale nie trzeba podawać w tym parametrze 0. Najważniejszy jest stan. Jeśli mielibyśmy jakieś żarówki RGBW, to tutaj przy włączaniu moglibyśmy określić także poszczególne kolory.

Na koniec zapiszmy konfigurację na stałe:

GET /save

Zwróćcie uwagę, że powyższy endpoint nie jest już w przestrzeni API. Można go oczywiście wywołać także wpisując po prostu adres w przeglądarce.

Znając endpointy do sterowania oświetleniem i posiadając użytkownika jesteśmy już „w (inteligentnym) domu” i możemy zrobić ze światłem praktycznie wszystko z dowolnego miejsca. Jeśli chodzi o integrację z Fibaro, to moją propozycją jest skonfigurowanie wirtualnego urządzenia dla każdego sterownika (żarówki), dzięki czemu będzie można oddzielnie i wygodnie nimi sterować.

Logujemy się do Fibaro Home Center 2 (taką centralkę posiadam) i dodajemy nowe urządzenie wirtualne. Jako adres IP oraz port podajemy oczywiście namiary na aplikację diyHue, tak jak przed momentem w przeglądarce.

Zależnie od tego, jakie konfigurujemy urządzenie, dodajemy odpowiednie przyciski czy suwaki. Jak wspominałem, ja posiadam ściemniane oświetlenie nad blatem w kuchni, dlatego konfiguruję suwak z natężeniem światła. Poniższy kod LUA załatwia tę sprawę dla urządzenia o ID równym 1:

hueLightID = 1; 
hueUserHash = '(tutaj identyfikator)'; 

vDeviceID = fibaro:getSelfId();
hueIP = fibaro:get(vDeviceID, "IPAddress");
huePort = fibaro:get(vDeviceID, "TCPPort");

if (_sliderValue_ == 0) then 
  hueBrightness = _sliderValue_;
  hueOn = false;
else 
  hueBrightness = math.floor(_sliderValue_ * 2.54);
  hueOn = true;
end

Hue = Net.FHttp(hueIP,huePort);
response, status, errorCode = Hue:PUT('/api/'..hueUserHash..'/lights/'..hueLightID..'/state', '{"on":'..tostring(hueOn)..',"bri":'..hueBrightness..'}');

if (tonumber(status) == 200) then 
  if (hueOn) then 
    fibaro:call(vDeviceID, "setProperty", "currentIcon", 1008);
  else 
    fibaro:call(vDeviceID, "setProperty", "currentIcon", 1007);
  end
end

Ostatni blok instrukcji jest opcjonalny – ustawia stosowną ikonkę dla światła włączonego. Oczywiście wcześniej te ikonki musimy wgrać do Fibaro, a następnie ustalić ich identyfikatory.

Pozostaje przetestować! Opisane rozwiązanie ma jedną wadę – jeśli w międzyczasie ktoś będzie bawić się pilotem, stan urządzenia wirtualnego w Fibaro nie zostanie zaktualizowany. Nie wpływa to na możliwość zarządzania tym urządzeniem, natomiast może być istotne w niektórych scenariuszach. Nic nie stoi na przeszkodzie, żeby odpytać w razie potrzeby API diyHue o aktualny stan urządzenia. Odpytywanie go w głównej pętli urządzenia wirtualnego co sekundę wydaje mi się jednak przerostem formy nad treścią i osobiście nie zdecydowałem się na to.

Prawdziwa zabawa naturalnie dopiero przed nami, bo sterowanie ręcznie z aplikacji Fibaro światłem to akurat najmniej ciekawy scenariusz. Teraz z powodzeniem można wziąć się za stworzenie scen, które będą automatycznie włączać i wyłączać światło w określonych momentach. W moim przypadku wyzwalaczem jest czujnik ruchu w kuchni. Dodatkowo w godzinach nocnych, po 23 i przed 6 światło zapala się u mnie na najniższym poziomie jasności. Tę część konfiguracji zostawiam już jednak Wam, a sobie być może na inny artykuł ;)