Okazuje się, że blog sprawdza mi się świetnie jako notatnik, w którym zapisuję rzeczy do których później wracam. Przy okazji, bardzo łatwo mogę podzielić z Wami tymi notatkami. Jeżeli jesteś ciekaw jak inżynierowie z Grentona poradzili sobie z integracją telefonu z CLU to klikaj śmiało.
Inicjalizacja
Nie jestem pewien czy ten komunikat jest wysłany z OM czy z telefonu, ponieważ nie śledzę ruchu między telefonem a CLU, tylko ruch między symulatorem telefonu z OMa a CLU. W każdym razie, pierwsza wysłana wiadomość do CLU wygląda następująco:
req:192.168.1.110:008a07:checkAlive()
Jak śledziliście poprzednie posty to wiecie, że jest to wywołanie funkcji dodanej w pliku MAIN.LUA. CLU zwróciło, to czego się spodziewałem. Mianowicie:
resp:192.168.2.200:00008a07:0d1cf150
Czyli to string “0d1cf150”, który jest zaszyty w funkcji checkAlive() z pliku MAIN.LUA. Jest to ID CLU.
function checkAlive()
return "0d1cf150"
end
Pytanie CheckAlive wysyłane jest co kilka sekund. Do tej pory wszystko proste.
Rejestracja klienta
Po włączeniu symulatora wysyłany jest najciekawszy komunikat do CLU. Ma długość aż 260 bajtów (max 2048), jest to jeden z dłuższych dla Grentona.
req:192.168.1.110:000623:SYSTEM:clientRegister(“192.168.1.110”,4344,210,{{DOUT_2485,0},{DOUT_6848,0},{DOUT_8565,0},{DOUT_4705,0},{DOUT_6710,0},{DOUT_3423,0},{DOUT_4513,0},{DOUT_4114,0},{ONEW_SENSOR_7372,0},{ONEW_SENSOR_7372,0}})
Jest to bardzo ciekawy komunikat, ponieważ zawiera kilka informacji. Mianowicie, istnieje obiekt “SYSTEM”, który obok obiektu “OBJECT” odpowiada za połączenie hardware z Lua. Obiekt “SYSTEM” posiada metodę pozwalającą zarejestrować klienta – “clientRegister”. Metoda ta posiada następujące argumenty:
- adres ip klienta – w tym wypadku jest to 192.168.1.110.
- 4344 – port na którym klient nasłuchuje.
- 210 – id klienta / strony w aplikacji
- Ostatnim parametrem jest tablica z obiektami, które klient chce obserwować. Nie jestem pewien co oznacza zero obok nazwy wejścia. Możliwe, że to aktualny stan przycisku w GUI na telefonie.
Na ten komunikat CLU odpowiada następująco:
resp:192.168.2.200:00000623:clientReport:210:{0,0,0,0,0,0,0,0,nil,nil}
Wynik jest łatwy do odczytania. Format jest dziwny, nie jest to JSON, tylko string + JSON. W klamerkach wysłany jest stan poszczególnych modułów wpiętych w CLU, w tej samej kolejności w jakiej zostały zarejestrowane przy pomocy metody SYSTEM:clientRegister. (Termometry zwróciły nil, bo odłączył mi się przewód od CLU).
Synchronizacja z telefonem
Pewnie się zastanawiasz dlaczego klient się pyta jedynie o 9 wejść. Podłączyłem pod Clu 4 moduły. Każdy z nich ma przynajmniej 4 wejścia lub wyjścia co daje więcej niż 9. Okazuje się, że Grenton jako klienta traktuje każdą stronę w aplikacji mobilnej. Dlatego stworzyłem nową stronę z jednym przyciskiem obsługującym DOUT2. Oto jak wygląda komunikacja dla tej strony.
req:192.168.1.110:00e741:SYSTEM:clientRegister(“192.168.1.110”,4344,210,{{DOUT_6848,0}})
Clu naturalnie zwraca mu aktualny stan:
resp:192.168.2.200:00002a7e:clientReport:210:{0}
A gdy nacisnę przycisk. Po chwili otrzymuję następującą wiadomość:
resp:192.168.2.200:000059ee:clientReport:210:{1}
Numery 210 i 4344 są zawsze take same. Prawdopodobnie ma to związek z OM. Spróbuję napisać skrypt i zobaczę co się stanie.
Skrypt
Teraz, skoro wydaje mi się, że wiem jak przebiega komunikacja, to pora sprawdzić czy zgadłem.
Pod linkiem: https://github.com/Domktorymysli/grenton-client-php/blob/master/examples/fake_phone/fake_phone.php znajduje się skrypt, który napisałem w celu przetestowania komunikacji. Skrypt jest podzielony na dwie części. Pierwsza wysyła wiadomość do CLU, że klient obserwuje wyjście DOUT_6848.
$command = new CluRawCommand("req:192.168.2.100:00e741:SYSTEM:clientRegister(\"192.168.2.100\",4000,100,{{DOUT_6848,0}})");
Druga cześć, to nasłuchiwanie na porcie 4000 komunikatów, które nadeśle CLU.
$r = socket_recv($sock, $buf, 2048, 0);
echo "{$buf}\n"; // zakodowana odpowiedź.
Wynik działania skryptu
W Wiresharku można podejrzeć komunikaty. Uruchomienie skryptu spowodowało wysłanie dwóch pierwszych komunikatów, a trzy krotne naciśnięcie przycisku dzwonkowego – kolejnych trzech.
Komunikaty o numerze 3,6,7 wyglądały następująco (zmieniła się wartość z 0 -> 1 -> 0):
resp:192.168.2.200:00000000:clientReport:100:{1}
Komunikat o zmianie przychodzi na telefon bardzo szybko. Jeszcze nie wiem jak zmierzyć czas, ale obstawiam, że mniej niż 100ms.
Podsumowanie
- Wygląda na to, że cała komunikacja jest bardzo prosta i dość szybka.
- Każda strona w aplikacji to osobny Klient. Co jest dobrą wiadomością jeśli chodzi o OpenHaba.
- Ciekawe co obiekt “SYSTEM” jeszcze potrafi?
- Obsługa termostatów to osobny materiał na wpis.
- Nie jestem pewien jak często zwracany jest stan termometrów. Wydaje mi się, że metoda SYSTEM:clientRegister jest wykonywana cyklicznie.
- Ciekawe jak wygląda sterowanie jasnością świateł dla dimmerów?
Pozdrawiam,
T
Genialny Blog sam posiadam GRENTONA, oby tak dalej.