Zaczynając przygodę w „oficjalną deweloperkę” HomeKit, miałem przeczucie, że porywam się z motyką na słońce. I to przeczucie nadal mi towarzyszy. Jednak nie zmienia to faktu, że tworzenie własnych rozwiązań „smart home” opartych na HomeKit daje dużo frajdy. Na martwienie się trudnościami z certyfikacją i ewentualną produkcją przyjdzie jeszcze czas.
Ostatnio opisywałem, co należy zrobić, aby ubiegać się o licencję dewelopera MFi. Przypomnę, że nie jest to specjalnie trudne ani drogie.
Teraz nadszedł czas na konsumpcję pierwszych korzyści
z posiadania licencji MFi. Dla mnie na razie największą zaletą jest dostęp do gotowych bibliotek programowych przygotowanych dla różnych mikrokontrolerów, które pozwalają na w miarę szybkie tworzenie własnych rozwiązań.
Wielu producentów mikrokontrolerów i układów dla SmartHome oferuje gotowe biblioteki zgodne z HomeKit. Są one przetestowane pod względem zgodności z rygorystycznymi wymogami Apple i jeżeli sami nic nie zrobimy źle, to testy programowe powinny się udać. W portalu MFi znajdziecie listę producentów oferujących SDK oraz informacje, jakiego rodzaju połączenia są obsługiwane. Może to być IP (Wi-Fi, Ethernet) lub Bluetooth. Każde z nich ma pewne zalety i wady.
Wi-Fi wyróżnia się stabilną i szybką reakcją, jednak nie nadaje się do urządzeń mających zasilanie bateryjne. Dodatkowo z racji możliwości zerwania sesji np. z powodu braku zasilania lub restartu nie nadaje się zbyt dobrze dla urządzeń sterujących czy wyzwalających określone akcje w automatyce HomeKit. Ethernetowe mają podobne cechy jak Wi-Fi, a ponadto wymagają połączenia kablem do lokalnej sieci, np. routera. Bluetooth pozwala na długą pracę przy zasilaniu z baterii oraz z racji automatycznego łączenia nadaje się na przyciski i inne urządzenia, które wysyłają dane sterujące automatyką. Nie wymaga też infrastruktury sieciowej. Jego wadą jest czasem dłuższy czas reakcji oraz pewne ograniczenia w zasięgu.
Jeżeli nie macie jeszcze licencji MFi,
a chcecie sprawdzić, czy Wasze ulubione mikrokontrolery, które potraficie już programować, mają gotowe SDK, wystarczy, że wpiszecie w wyszukiwarkę nazwę firmy lub model oraz „HomeKit SDK”. Z bardzo dużym prawdopodobieństwem pojawią Wam się wyniki kierujące bezpośrednio do opisu konkretnego SDK HomeKit. Nie liczcie od razu na dostęp do bibliotek. To uzyskuje się dopiero po weryfikacji licencji MFi przez oferującego gotowe rozwiązania. Niektóre rozwiązania są płatne, ale na szczęście najpopularniejsze oferowane są za darmo. Jedynie należy mieć odpowiednie układy czy płytki developerskie.
Ja zdecydowałem się na bardzo popularny i znany mi już mikrokontroler ESP32 chińskiej firmy Espressif. Jest to następca bardzo popularnego, ale nienadającego się dla HomeKit ESP8266. Na razie Espressif oferuje dla niego SDK IP (Wi-Fi), ale planowana jest, choć bez konkretnego terminu udostępnienia, wersja Bluetooth. ESP32 obsługuje oba standardy. Ten układ ma jeszcze więcej zalet. Jest bardzo tani, płytki deweloperskie kosztują poniżej 10 dolarów, a moduły nawet mniej niż 4$. Ma sporo gotowych innych bibliotek, a w sieci łatwo można znaleźć pomoc. Bez problemu daje się je programować na macOS, i to na wiele sposobów.
Jeżeli już teraz chcemy tworzyć konkurencję dla The Button Fibaro
lub zamków Gerdy, czyli własne urządzenia HomeKit na Bluetooth, to polecam norweskie nRF52832. Moduły i płytki deweloperskie są droższe niż Espressif i czasem trudniej się je programuje na macOS, ale też są popularne.
Oczywiście po udostępnieniu przez Apple dokumentacji „amatorskiej” HomeKit powstaje sporo projektów bibliotek dostępnych publicznie. Jednak patrząc, jak wiele problemów napotykają ich twórcy i użytkownicy, nie żałuję, że podjąłem trud zdobycia licencji MFi.
Uwaga! Choć w iOS 11.3 można używać programowej autentykacji urządzeń HomeKit, to większość gotowych SDK jeszcze tej możliwości nie oferuje. Dlatego do mikrokontrolerów należy podłączać chip MFi Apple. Mając licencję, można je kupić i nie zbankrutować przy tym. Jednak i bez nich daje się rozpocząć programowanie, bo i nRF52, i ESP32 oferują rozwiązania tymczasowe, ale w HomeKit będzie się pojawiać ostrzeżenie, tak jak przy korzystaniu z HomeBridge i innych nieoficjalnych rozwiązań.
Od obu firm można otrzymać pomoc, gdy napotkamy trudności. Zważywszy na mój angielski, opiekunowie SDK HomeKit wykazują się sporą dozą cierpliwości, a ich porady są użyteczne.
O SDK dla ESP32 można się ubiegać, pisząc na adres: homekit_sdk@espressif.com. Należy podać numer licencji MFi, e-mail, który jest zarejestrowany w Apple, oraz dane firmy. Po weryfikacji będziemy proszeni o podpisanie umowy o zachowaniu poufności, z wielką okrągłą pieczęcią z czerwoną gwiazdą. Dlatego nie pytajcie mnie o szczegóły kodu.
Po dostęp do SDK nRF52 można się zgłosić na forum. Nie należy od razu podawać naszych danych. Po opublikowaniu prośby jakaś życzliwa osoba z Nordic Semi zamieni nasz wątek na prywatny i wtedy będziemy mogli bezpiecznie dokończyć zgłoszenie.
Powodzenia! Ja już mam pewne sukcesy i coś już mi działa, choć z nRF52 będę chyba potrzebował pomocy.
Cześć. Cieszę się, że trafiłem na Twój felieton, dotyczący tematu HomeKit. Oczywiście licencja MFi żeby mieć dostęp do oficjalnych kodów źródłowych by się przydała, ale chyba na tym etapie jest to mi nie potrzebne, a poza tym i tak nie mam firmy.
Do czego zmierzam? Pisałeś, że ESP8266 się nie nadaje do HomeKit. Możesz napisać, dlaczego tak uważasz? Przecież istnieje w sieci esp-open-rtos i zrobiony i działający do tego esp-homekit na ESP8266. Ja co prawda uparłem się, że przepiszę ten kod na framework Arduinowy, bo RTOS jakoś do mnie nie trafia, ale jest „gotowiec”.
Druga sprawa. Pisałeś, aby nie pytać o szczegóły kodu i rozumiem dlaczego o to prosiłeś. Ale czy jest szansa abyś w punktach opisał jak wygląda cały proces wymiany danych? Od parowania do wymiany danych, w punktach. Z hobbystycznej dokumentacji Apple nie wynika jednoznacznie co po czym następuje, a ja lubię kodować etapami. Mam już zrobioną obsługę mDNS i aplikacja Dom ładnie widzi mój ESP8266, teraz czas na dalsze kroki. Parowanie itd, ale tu zaczynają się proceduralne schody, co po czym następuje. Nigdzie w sieci nie mogę znaleźć prostego opisu, step-by-step co po czym następuje.
Dzięki!
Dzięki!
Jest wiele amatorskich „gotowców” HomeKit dla ESP8266. Nawet trochę działają, jednak problem jest z tworzeniem kluczy i szyfrowaniem. 82xx nie ma sprzętowego wspomagania. O ile dla amatorów do zabawy nie jest to wielkim problemem, to Apple zarzuca czasy w jakich pewne rzeczy muszą się zmieścić. Te czasy są istotne tylko prze certyfikacji, więc niby działa. Aby było śmieszniej, to Apple stworzył swoją część ADK dla rdzeni ESP8266, jednak Espressif nie bardzo jest w stanie zrobić swoją część (kod związany ze sprzętem). Po prostu nie nadąża. Dlatego pobawić się można, jednak nie da się tego skomercjalizować.
Ja bym się nie pchał w Arduino. To nawet dla ESP8266 jest słabe (chodzi o tą pętlę) rozwiązanie. RTOS używam tylko w ESP32, bo to natywne środowisko. W 82xx używam NONOS. Lekki, sporo przykładów i mało miejsca zajmuje.
A w dokumentacji publicznej nie ma diagramów kto inicjuje działani i jak przebiega wymiana danych? W tym niestety wiele Ci nie podpowiem, bo to odwalają dostępne dla MFi biblioteki.
Może podejrzyj kod tych „gotowców” na ESP8266? Najdziesz na githubie.
Pobaw się też ESP32, cena minimalnie większa, a znacznie łatwiej się programuje (mniej ograniczeń), no i szybciej działa
Teraz już wiem co miałeś na myśli pisząc, że ESP8266 się nie nadaje 🙂 Spróbuję jednak przełamać się i popatrzeć na RTOS/NONOS, zobaczymy co z tego wyjdzie. Co do dokumentacji właśnie nie znalazłem niczego konkretnego, a przeglądanie kodów źródłowych „gotowców”, by dowiedzieć się co następuje po czym to jest jakaś masakra, zwłaszcza jak nie zna się frameworka RTOS (bo tylko na niego są gotowce jeśli chodzi o HomeKit). Ale będę próbować!
Dlatego RTOS warto poznać. Generalnie jest prosty i wiele oferuje. Wystarczy oswoić się z taskami i tym, że mogą sobie komunikaty przekazywać (bardzo ułatwia życie)
Do tego przerwania i callbacki, ale z tego to i Ardiuno korzysta
Dasz radę! Ja też zaczynalem od Arduino.
Chyba w RTOS wkurza mnie to, że kompilacja kodu następuje z poziomu wiersza poleceń programem make. Mam za małą wiedzę na temat tych frameworków, żeby spokojnie wystartować, bo przecież mnóstwo konfiguracji siedzi w plikach TXT i Makefile projektu 🙁 A mam wrażenie, że te frameworki na PlatformIO są jakieś okrojone…
Jeżeli chodzi o ESP8266 to spokojnie w Platformio ogarniesz. A co to make itp. to większość projekto ma to gotowe i nie musisz nic ruszać. Zresztą na macOS trudno ESP8266 w terminalu obsługiwać, bo nie ma oficjalnego środowiska. Ja 8266 tylko w Platformio ogarniam (pod Code).
Za to ESP32 pięknie działa w terminalu i make manuconfig bardzo ułatwia życie
Na Macu też? Bo ja nie mogłem zainstalować toolchaina esp-rtos-sdk z uwagi na niewspieranie crosstool-ng (http://crosstool-ng.github.io/2018/11/26/macos.html). Błąd jaki mi wyskakiwał przy instalacji toolchaina opisany jest tu: https://github.com/crosstool-ng/crosstool-ng/issues/1174
Ja tylko na Mac pracuję.
To jest dal 32 czy 82? Bo ja środowiska dla ESP82 nie instalowałem, bo nie ma oficjalnego tylko jakieś „adaptacje”.
Za to ESP32 ma dobrze przygotowane i dość łatwe w instalacji.
To mogła był właśnie w takim razie ta kwestia, próbowałem zainstalować esp-open-rtos, które wymaga toolchaina eps-open-sdk, którego z kolei nie mogłem zainstalować z uwagi na powyższe. Będę próbował z ESP32 🙂