Inteligentny włącznik światła WiFi z chmurowym API?


12

Potrzebuję sugestii dotyczącej inteligentnego włącznika światła opartego na Wi-Fi, który może być zdalnie sterowany i ma otwarty interfejs API.

Przełącznik światła WeMo nie ma otwartego zdalnego interfejsu API. To samo z innym popularnym TP-Link HS200 . Większość innych zdalnie sterowanych przełączników, które znalazłem, można kontrolować tylko za pomocą ich własnych aplikacji. Istnieje kilka projektów GitHub, które poddały inżynierii wstecznej te aplikacje, ale wolałbym używać API opublikowanych bezpośrednio przez producenta, ponieważ mój projekt jest długoterminowy i nie chcę stawiać na rozwiązania inżynierii wstecznej.

Odpowiedzi:


9

Twoje najbardziej przyszłościowe rozwiązania to takie, które całkowicie oddzielają sprzęt od protokołu .

Twój przykładowy włącznik światła HS200 łączy wiele inteligentnych gniazd w oparciu o system Embedded Linux (źródło jest dostępne w Centrum kodu GPL TP Link ). Szanse są, podobnie jak większość gniazd, systemem bazowym pochodzącym z dziwnej gałęzi dostawcy wspólna dystrybucja Linuksa przeznaczona dla routerów. Inne modele mogą używać ESP8266. Każde z nich może na ogół zastąpić podstawowe oprogramowanie układowe innym, które może działać jako serwer w sieci lokalnej, umożliwiając w ten sposób kontrolę, lub subskrybować wiadomości przekazywane przez coś w rodzaju brokera MQTT w chmurze, umożliwiając wyjście poza -kontrola domu. Zachowujesz pełną możliwość włączenia jednej lub obu ścieżek, zmiany reguł i zmiany dostawców usług.

Jeśli sprzęt, którego używasz, stanie się wtedy niedostępny, ponieważ w pełni kontrolujesz protokół, wszystko, co musisz zrobić, to znaleźć inny sprzęt, na którym chcesz go uruchomić. Przeniesienie kodu po stronie urządzenia między czymś takim, jak OpenWRT Linux powszechny w produktach pochodzących z routera a nieobsługiwanym ESP8266, byłoby dość pracochłonne, ale jest koncepcyjnie proste. Ale przeniesienie go z OpenWRT na jednym chipie routera do OpenWRT na innym, lub przeniesienie go na dowolny Linux (lub jeśli musisz, może nawet Win IoT), który działa na twoim malinowym pi lub Edison lub Beagle Bone, byłby jeszcze bardziej bezpośredni.

Podział ról systemu na odrębne części z wyraźnymi granicami wymaga odrobiny więcej pracy z góry, ale oznacza, że ​​będziesz w stanie zareagować na wszelkie zmiany, w sposób, w jaki nie byłbyś w stanie, gdybyś użył pionowo zintegrowane rozwiązanie od jednego dostawcy.


Dziękujemy za wyjaśnienie ograniczeń związanych z używaniem „pionowo zintegrowanego rozwiązania od jednego dostawcy” oraz korzyści wynikające z luźnego połączenia sprzętu i protokołu. Jeśli długoterminowa weryfikacja przyszłości i całkowita kontrola byłyby naprawdę ważne, być może jest to jedyna droga. Ale teraz szukam tylko trochę lepszego rozwiązania niż jakiś zhakowany interfejs API w github. To, co zaproponowałeś, to dla nas za dużo pracy.
rajendra

4

Jak powiedział Chris, kluczem jest oddzielenie protokołu od sprzętu. Ale to nie znaczy, że musisz wdrożyć własne oprogramowanie! Możesz wybrać przełącznik, który obsługuje powszechny i ​​łatwo dostępny protokół automatyki domowej, taki jak Z-Wave lub Insteon. Są to zamknięte protokoły, ale istnieje wiele różnych producentów, którzy tworzą z nimi interoperacyjne komponenty. Następnie można użyć kontrolera automatyki domowej, który integruje protokoły automatyki domowej z IP.

Używam kontrolera automatyki domowej Vera Edge, który oferuje web API; i są też inne możliwości. Wybrałem Vera, ponieważ cały system działa lokalnie, nie wymagając dostępu do interfejsu hostowanej chmury; nie ma miesięcznej opłaty za usługę, a urządzenie i zasady są całkowicie pod moją kontrolą. Mogę ukryć interfejs API za zaporą, samodzielnie udostępnić interfejs API na zewnątrz lub skorzystać z bezpłatnych usług chmurowych Vera, aby udostępnić interfejs API dla mnie. (Jako plus, Vera ma bardzo aktywną społeczność, która stale dodaje wsparcie dla nowych urządzeń automatyki domowej.) Vera oferuje bezpłatną aplikację na iPhone'a i Androida, ale nie jesteś nią związany. Kilku niezależnych programistów stworzyło własne aplikacje, które wykorzystują API Vera (Grasshopper, VeraMate i ImperiHome to trzy takie produkty), aby zapewnić alternatywne GUI.

Jeśli sprzeciwisz się komercyjnemu produktowi bramy i chcesz włożyć dużo pracy, istnieją również rozwiązania Open Source do wdrażania własnej bramy automatyki domowej, które oferują interfejs API sieci Web. Domoticz i OpenHAB to dwa projekty, które przychodzą mi do głowy. Jednak oba te pakiety są nadal znacznie mniej dojrzałe niż rozwiązania komercyjne i oba wymagają znacznej pracy do wdrożenia. (I wskazałeś, że nie chcesz zhakować razem rozwiązania).

Jedyną wadą, jaką dostrzegam w podejściu opartym na bramce, jest to, że twoje pytanie dotyczy „włącznika światła”, co oznacza ilość jednego urządzenia. Przełącznik fali Z może kosztować od 10 do 40 USD (lub więcej), a bramka komercyjna może kosztować od 100 do 400 USD (lub więcej). W przypadku pojedynczego przełącznika cena prawdopodobnie nie jest tego warta. Jeśli jednak automatyzujesz cały budynek, koszt koncentratora można rozłożyć na dziesiątki urządzeń.


4

Ostatnio kupiłem inteligentne wtyczki Sonoff na eBayu i sflashowałem je niestandardowym oprogramowaniem. Jest to możliwe, ponieważ są oparte na ESP8266. Są bardzo przystępne i dość zaawansowane.

Należy je otworzyć i przylutować pin do złącza na płytce drukowanej, a następnie zaprogramować je za pomocą adaptera FTDI , który można również tanio kupić na eBayu. To całkiem proste.

Po sflashowaniu łączą się z moją siecią Wi-Fi oraz wysyłają i odbierają polecenia MQTT. Używam do tego Home Assistant .

BRUH Automation ma film o nich: https://www.youtube.com/watch?v=-JxPWA-qxAk

wprowadź opis zdjęcia tutaj

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.