OpenHab - sterowanie za pomocą poleceń głosowych

Aplikacja OpenHab na Androida (habDroid) ma bardzo ciekawą i użyteczną funkcjonalność sterowania głosem. Mając już działającą konfigurację OpenHab należy do naszego pliku *.items dopisać:

String VoiceCommand

dokładnie w takiej postaci.

W momencie rozpoznania głosu habDroid do elementu o nazwie VoiceCommand wysyła rozpoznaną treść.
Przykładowy plik zawierający jeden przełącznik o nazwie salonLed z możliwością sterowania głosem powinien wyglądać następująco:

OpenHab posiada możliwość definiowania tzw. reguł (rules). Reguły muszą znajdować się w katalogu

configurations/rules

w pliku o rozszerzeniu

*.rules

W celu określenia jaka  jaka akcja powinna być wykonana po otrzymaniu zdefiniowanej komendy głosowej należy utworzyć odpowiednią regułę. Załóżmy że chcemy sterować elementem salonLed. Należy wtedy utworzyć plik z regułą, np.

voice.rules 

o następującej treści:
Jak widać reguły definiowane są w prostym i dość czytelnym języku skryptowym.
Aby sterować kolejnymi urządzeniami trzeba po prostu dodać nowe elementy w pliku *.items oraz nowe reguły dla nich w pliku *.rules

To praktycznie cała konfiguracja, jak widać jest banalnie prosta. Zastosowań można znaleźć wiele, na przykład jedną komendą głosową można otworzyć bramę wjazdową, bramę garażową i zapalić halogen na podjeździe. Można wtedy zapomnieć o pilotach :)
Dla miłośników IPhone'ów mam niestety złą wiadomość. Sterowanie głosowe działa wyłącznie na Androidzie.

Na koniec przykładowy film z działania funkcjonalności:

OpenHab, arduino i mqtt binding

Klon arduino możesz zakupić tanio  na aliexpres. Poniższy link to link afiliacyjny. Skorzystanie z niego Ciebie nic dodatkowo nie kosztuje a ja otrzymam niewielką prowizję która wspomoże rozwój tego bloga. Dzięki!

http://ali.pub/2hk8rp

Jak już pisałem wcześniej komunikacja arduino z OpenHab za pomocą TCP nie sprawdziła się w praktyce. Za to z czystym sumieniem mogę stwierdzić że komunikacja za pomocą MQTT działa znakomicie.

Przy takim rozwiązaniu dochodzi jednak dodatkowa warstwa pośrednia - broker.
W uproszczeniu można powiedzieć że broker zajmuje się rozprowadzaniem komunikatów do zainteresowanych klientów.

Rozwiązanie to działa na zasadzie mechanizmu Publish - subscribe.
Odpowiednie urządzenia mogą publikować (Publish) komunikaty w danym temacie (TOPIC). Klienci podłączają się do brokera informując go że są zainteresowani (subscribe) komunikatami z danego tematu.

Przenosząc to na płaszczyznę automatyki domowej ja zastosowałem następującą architekturę:

Na Raspberry PI zainstalowałem broker MQTT. Najpopularniejszym brokerem obecnie jest chyba Mosquitto.

Aby zainstalować mosquitto należy wykonać następujące polecenie:

sudo apt-get install mosquitto mosquitto-clients

Po instalacji pojawi się katalog:

/etc/mosquitto

w którym znajduje się plik konfiguracyjny brokera

mosquitto.conf

Wystarczy bardzo prosta konfiguracja:

Jak widać z powodu bezpieczeństwa wyłączyłem anonimowy dostęp do brokera. W tym przypadku należy utworzyć plik

 /etc/mosquitto/password_file

,w którym zapiszemy login i hasło do brokera z którego  będą korzystać Arduino i OpenHab.
Plik powinien zawierać wpis w postaci:

login:hasło

Teraz należy zrestartować broker poleceniem:

/etc/init.d/mosquitto restart

Następnie można przetestować działanie brokera. Dostępne są dwa programy:

mosquitto_sub 

do obsługi subskrypcji oraz

mosquitto_pub 

do obsługi publikowania.

Na początku należy uruchomić polecenie:

mosquitto_sub -h localhost -u login -P hasło -t /house

co oznacza że utworzyliśmy klienta który podłączył się do brokera na serwerze localhost przy użyciu loginu "login" i hasła "hasło" (zdefiniowanych w pliku password_file). Klient subskrybował wszystkie wiadomości w temacie (TOPIC) /house.

Po wykonaniu polecenia klient oczekuje na komunikaty.

W drugiej konsoli należy uruchomić polecenie:

mosquitto_pub -h localhost -u login -P hasło -t /house -m test

Oznacza to że na brokerze pod adresem localhost opublikowaliśmy wiadomość o treści "test" w temacie /house

Jeśli wszystko wykonaliśmy poprawnie na konsoli na której uruchomiliśmy mosquitto_sub powinna pojawić się zawartość wiadomości, czyli "test"

Dla eksperymentu można uruchomić kilka klientów mosquitto_sub nasłuchujących dany "topic". Na wszystkich jednocześnie powinna pojawić się treść opublikowanego komunikatu


Mając działający broker można przystąpić do konfiguracji OpenHab.

W tym celu należy przekopiować plik jar o nazwie

org.openhab.bindings.mqtt-1.5.0.jar (numer wersji może być inny)

 do katalogu addons serwera openhab.
W pliku konfiguracyjnym

configuration/openhab_default.cfg

należy dopisać następujące linie:

Załóżmy że chcemy sterować halogenem. W tym przypadku plik

configurations/items/house.items

powinien wyglądać następująco:

Oznacza to że w naszej konfiguracji mamy jeden przełącznik odpowiadający za załączanie halogena.
Załączenie przełącznika OPUBLIKUJE wiadomość o treści "halogen#1" na brokerze mqtt w topic'u "/house". Wyłączenie przełącznika OPUBLIKUJE wiadomość o treści "halogen#0" na brokerze mqtt również w topic'u "/house"
Dodatkowo obsługa tego przełącznika SUBSKRYBUJE topic /houseIn na tym samym brokerze.
W pliku

transform/halogen.map 

powinno znaleźć się mapowanie treści otrzymanej wiadomości na stan przełącznika.
Plik powinien mieć następującą zawartość:

halogen#1=ON
halogen#0=OFF

Nasłuchiwanie służy do aktualizacji stanu przełącznika. Pamiętajmy że halogen można zapalić również zwykłym przełącznikiem na ścianie. Wówczas OpenHab powinien się o tym dowiedzieć aby wyświetlić odpowiedni stan przełącznika.

To cała konfiguracja po stronie OpenHab. Należy tylko zrestartować usługę.

Pozostaje jeszcze obsługa po stronie mikrokontrolera.
Bibliotek do obsługi mqtt na arduino jest kilka. Ja wykorzystałem bibliotekę PubSubClient którą znalazłem pod adresem:
http://knolleary.net/arduino-client-for-mqtt/

Poniżej przedstawiam fragmenty kodu które obrazują zasadę działania:
Nie jest to kompletny kod, ponieważ całość wraz z obsługą wszystkich przekaźników które mam obecnie jest zbyt duża żeby wklejać je na bloga. Większe fragmenty publikowane były już w poprzednich wpisach. Myślę że osoby obeznane z tematem bez problemu powinny poradzić sobie z wykorzystaniem podanych fragmentów. W przypadku pytań  piszcie w komentarzach.

Jedyny fragment który sprawiał problemy to okolice wiersza 45. Po  pewnym czasie od momentu restartu arduino przy wciskaniu przełączników sprzętowych przestawały dochodzić potwierdzenia do OpenHab. Okazało się że z jakichś nieokreślonych powodów było zrywane połączenie między Arduino a MQTT. Dodanie sprawdzania stanu i ponownego połączenia w przypadku gdy połączenie nie było aktywne rozwiązało problem.

Po tych zmianach cały układ działa bardzo stabilnie i myślę że można stwierdzić że można go z powodzeniem wykorzystywać w warunkach produkcyjnych

Sterownik oświetlenia schodów na ATMEGA328P - wdrożenie produkcyjne

EDIT: Po 10 latach powstała nowa wersja płytki. Możesz też kupić gotowe PCB nowej wersji, i zbudować sterownik samemu. Więcej szczegółów w tym wpisie: Sterownik oświetlenia schodów. Ciąg dalszy po prawie 10 latach :)

Ostatnio bardzo dużo się u mnie działo w temacie przeprowadzki do nowego domu, przez co niestety zaniedbałem trochę bloga. Mam jednak nadzieję że teraz znajdę trochę więcej czasu na nowe wpisy. Udało się produkcyjnie odpalić sterowanie oświetleniem za pomocą arduino i OpenHab. Wrażeniami z tego rozwiązania podzielę się jednak w kolejnych wpisach.
Dzisiaj chciałem pochwalić się działaniem sterownika oświetlenia schodów, o którym pisałem jakiś czas temu. Płytka leżała sobie od tego czasu w szufladzie i czekała aż schody będą gotowe.
Teraz już mogę pokazać końcowy rezultat. Warstwa sprzętowa pozostała bez zmian. Gruntownie zostało zmienione oprogramowanie. Wcześniejsza wersja nie przyjmowała żadnych sygnałów w trakcie zapalania / gaszenia oświetlenia. Obecnie nie ma już tego ograniczenia.
W projektach tego typu świetne jest to, że mając jedno rozwiązanie sprzętowe można zmieniać działanie układu jedynie modyfikując oprogramowanie układu ATMEGA.
Przykładowo - w trakcie korzystania z oświetlenia pojawiła się potrzeba zapalania światła na stałe, bez automatycznego gaszenia. W prosty sposób udało się osiągnąć efekt jedynie zmieniając program.
Fajne... :)

Jeśli macie jakieś pytania lub uwagi, piszcie w komentarzach
Pod tym adresem znajdziecie pliki Eagle ze schematem i płytką (pamiętajcie że płytkę trzeba "oblać masą" przed wydrukiem):

https://drive.google.com/file/d/0BzJpXXOh01BRcTc4YXRyOUJnR00/view?usp=sharing&resourcekey=0-QLeEtdx8OaUEFYTvnlSHrg
EDIT2: Załączam aktualny kod źródłowy:

OpenHab, arduino, inteligentny dom, sterowanie za pośrednictwem protokołu TCP

Jakiś czas temu obiecałem opisanie sterowania urządzeniami za pośrednictwem Arduino i OpenHab przy pomocy protokołu TCP.
Niestety nie jest to tak bezproblemowe jak mogłoby się wydawać, więc nie zdecydowałem się na wykorzystanie takiego rozwiązania w produkcyjnych warunkach, ale opiszę to co udało mi się ustalić. Być może komuś się przyda.

Zacznijmy zatem od początku.
W pierwszym kroku należy pobrać OpenHab RuntimeCore.
Znajdziemy je pod adresem http://www.openhab.org/downloads.html
Po rozpakowaniu archiwum zip, należy zajrzeć do katalogu configurations.
Konieczne będzie utworzenie tzw. sitemap'y. Jest to struktura głównego menu, w którym możemy grupować sobie urządzenia na przykład wg pomieszczeń w których się znajdują, czyli salon, łazienka, piętro itd. 
W moim przykładzie będę chciał sterować tylko jednym urządzeniem, załóżmy że będzie to taśma led w salonie.
Zatem moja sitemap'a będzie znajdowała się w pliku house.sitemap w podkatalogu sitemaps i będzie zawierała następujące wpisy:

sitemap Dom label="Menu główne"
{
Frame {
Group item=Salon label="Salon" icon="firstfloor"
}

}

Następnie musimy utworzyć plik house.items w podkatalogu items, gdzie określamy kontrolery naszych urządzeń. Dla naszego przypadku testowego będzie on wyglądał następująco:

Znalazł się w nim jeden element typu Switch, który może przyjmować wartości ON oraz OFF.
Następnie jest informacja iż obsługa przełącznika ma być realizowana za pośrednictwem protokołu TCP, oraz konfiguracja wyjściowa (elementy ze znakiem ">") i wejściowa (elementy ze znakiem "<").
Określone zostało również mapowanie komend które zostanie wykorzystane przy zmianie stanu przycisku. Mapowanie znajduje się w pliku salonled.map. Pliki mapowań umieszczamy w podkatalogu transform. Plik salonled.map w moim przypadku wygląda następująco:

ON=salonled#
OFF=salonled#

Oznacza to że zarówno przy komendzie "ON" (włączenie przełącznika), jak i przy komencie "OFF" (wyłączenie przełącznika) na adres 192.168.0.5:8888 (adres IP arduino) zostanie wysłany ciąg znaków "salonled#".

W ten sposób załatwione mamy sterowanie taśmą LED po stronie OpenHab. Co jednak w przypadku gdy stan oświetlenia zostanie zmieniony bez udziału OpenHab? Na przykład za pomocą przełącznika na ścianie? Konieczne jest aby informacja o zmianie stanu dotarła do OpenHab, aby mógł on wyświetlić użytkownikowi który może znajdować się daleko od domu aktualny stan oświetlenia.

Do tego wykorzystałem komunikację zwrotną, czyli OpenHab również będzie nasłuchiwał na wybranym porcie, a Arduino przy każdej zmianie stanu oświetlenia będzie wysyłało informację na podany numer IP.

W pliku house.items widać że mapowanie w konfiguracji wejściowej OpenHab zrobione jest za pośrednictwem JavaScriptu. Jest to spowodowane problemami na które w międzyczasie się natknąłem.

Założyłem że w przypadku załączenia oświetlenia Arduino wyśle komunikat salonled#1 a w przypadku wyłączenia salonled#0. Pomimo tego że obsłużyłem takie komendy w mapowaniu OpenHab konfiguracja nie działała poprawnie. Dopiero po analizie kodu źródłowego OpenHab'a i podłączeniu JavaScriptu który umożliwił wyświetlenie w log'u komunikatów które docierają do OpenHab okazało się że treść polecenia jest dużo dłuższa i uzupełniona pustymi znakami. Prawdopodobnie przesyłany był pełny bufor TCP - nie badałem tego tematu dokładniej.

Rozwiązaniem okazało się trim'owanie komunikatu i ręczne obsłużenie mapowania na odpowiedni stan przycisku. Udało się to osiągnąć następującym skryptem JS (OpenHab wspiera skrypty RHINO), który umieściłem w pliku salonled.js w podkatalogu transform:


Należy jeszcze włączyć obsługę TCP w OpenHab.
W tym celu należy pobrać dodatkowe plugin'y (OpenHab AddOns), a następnie plik org.openhab.binding.tcp-1.4.0.jar (lub inna wersja) skopiować do katalogu addons z serwera OpenHab.
W pliku configurations/openhab_default.cfg należy odkomentować linię

tcp:port=25001

Dzięki temu OpenHab będzie nasłuchiwał na porcie 25001
Teraz można uruchomić OpenHab skryptem startup.sh (lub startup.bat w przypadku Windows) upewniając się wcześniej że mamy zainstalowaną odpowiednią wersję javy.
Po chwili pod adresem;

http://localhost:8080/openhab.app?sitemap=house

dostępne powinno być menu główne naszej konfiguracji.

To już cała konfiguracja po stronie OpenHab. Pozostaje kod źródłowy po stronie Arduino.

Odsyłam tutaj do wpisu http://technika-laika.blogspot.com/2014/04/arduino-sterowanie-przekaznikiem-za.html gdzie jest pierwotna wersja kodu źródłowego, dokładniejszy opis i wyjaśnienie nazewnictwa plików.
Jedyne zmiany które się pojawiają to zmiany komunikacji zwrotnej w pliku network.ino:

oraz dodanie wysłania komunikatu zwrotnego w pliku salon_led.ino: Działanie całej kongfiguracji można zobaczyć na poniższym filmie:

 Generalnie zamierzony cel został osiągnięty, natomiast problemy na które się natknąłem, konieczność zrywania połączenia po obsłudze komunikatu, opóźnienia przy wznawianiu połączenia przez OpenHab powodują że nie polecam takiego rozwiązania w warunkach produkcyjnych. Być może ktoś z Was poradził sobie z tymi problemami. Jeśli tak, proszę o informację w komentarzach. Dużo ciekawiej zapowiada się komunikacja za pomocą mqtt którą postaram się zademonstrować w kolejnym wpisie.

Inteligentny dom oparty na OpenHab - wstęp

OpenHab to oprogramowanie dzięki któremu możemy połączyć urządzenia domowe oparte na różnych technologiach i protokołach w jeden sprawnie działający system inteligentnego budynku.
Główną częścią OpenHab jest tzw. OpenHab Runtime. Jest to aplikacja webowa napisana w całości w Javie, działająca pod kontrolą serwera Jetty.

OpenHab Runtime działa w oparciu o zestaw plików konfiguracyjnych. Są to niestety pliki tekstowe, brak jest jakichkolwiek narzędzi do graficznej konfiguracji. Autorzy zapewnili jednak narzędzie o nazwie OpenHabDesigner bazujące na Eclipse IDE, które zapewni nam podświetlanie błędów, oraz kolorowanie i uzupełnianie składni plików konfiguracyjnych co jest dość dużą pomocą. Dodatkowo dość czytelne przykłady i nie najgorsza dokumentacja sprawiają że konfigurowanie nie jest takie straszne.

Dostępne są również aplikacje na iOS oraz na Androida pozwalające na sterowanie automatyką z poziomu telefonu lub tabletu.

Całość wydana jest na licencji Eclipse Public Licence, co oznacza że mamy pełny dostęp do kodu źródłowego.

Generalnie w instalacjach inteligentnych budynków dużym problemem jest niezgodność protokołów transmisji pomiędzy dostawcami poszczególnych rozwiązań. Mamy chociażby standardy KNX, z-Wave, Fritz i wiele innych.
Gdy zdecydujemy się na jedno z rozwiązań stajemy się na stałe przywiązani do jednej firmy, która zwykle każe sobie słono płacić za każde dodatkowe elementy.

OpenHab jest próbą rozwiązania tego problemu.
Spójrzmy najpierw na architekturę (schemat pobrany ze strony http://www.openhab.org/)

Jak widać na schemacie, podstawowym elementem systemu jest szyna zdarzeń (Event Bus). która jak sama nazwa wskazuje zarządza zdarzeniami zachodzącymi w systemie.
Generalnie wyróżnić należy dwa typy zdarzeń: commands - czyli komendy wydawane przez użytkownika (lub inne źródła), oraz state change czyli zdarzenie zmiany statusu danego elementu systemu.

Tworząc własną konfigurację przygotowujemy tzw. Sitemap'ę czyli plik w którym opisujemy interfejs użytkownika. Co ciekawe interfejs ten wygląda później identycznie na wszystkich urządzeniach - w przeglądarce, na telefonie lub tablecie.
Dodatkowo definiujemy listę elementów (items) kontrolujących nasz system. Mogą to być przełączniki, suwaki, pola tekstowe wyświetlające stan elementów systemu - na przykład temperaturę w pomieszczeniu i kilka innych. Dla każdego z tych elementów w konfiguracji określamy sposób komunikacji z odpowiednim urządzeniem (binding) - czy to będzie KNX, połączenie szeregowe, bluetooth, czy też połączenie TCP. Obecnie dostępnych jest kilkadziesiąt różnych protokołów. Istnieje również możliwość dopisywania nowych, dostosowanych do własnych potrzeb. Każdy z elementów ma zdefiniowane komendy sterujące (np dla elementu typu Switch komendy to ON oraz OFF). W konfiguracji umieścić należy dodatkowo mapowanie poleceń wysyłanych lub odbieranych z urządzenia zewnętrznego na odpowiednie komendy elementu OpenHab.

System daje nam  dużą dowolność jeśli chodzi o sposób zapisu zdarzeń  w systemie. Może być to proste logowanie w pliku tekstowym, ale też zapisywanie stanu czujników w bazie danych, oraz generowanie wykresów na podstawie wyników.

Możliwości konfiguracji OpenHab'a są na prawdę olbrzymie. Myślę że warto zapoznać się z konfiguracją demo którą można uruchomić bez instalowania aplikacji u siebie.

Ja dopiero zaczynam poznawać jego możliwości i w miarę postępów postaram się opisać tutaj moje doświadczenia. W pierwszej części pojawi się komunikacja z Arduino za pomocą TCP, która niestety nie okazała się bezproblemowa.

Arduino - sterowanie przekaźnikiem za pomocą przełącznika lub przez sieć

Opisane w poniższym wpisie elementy możesz zakupić na aliexpres. Poniższe linki to linki afiliacyjne. Skorzystanie z nich Ciebie nic dodatkowo nie kosztuje a ja otrzymam niewielką prowizję która wspomoże rozwój tego bloga. Dzięki!

Przekaźnik: http://ali.pub/2hk8br

Klon Arduino mega: http://ali.pub/2hk94c

Ethernet shield: http://ali.pub/2hk97n

W poprzednim wpisie opisałem mój pomysł na stosunkowo wygodne podłączenie do arduino przekaźników oraz przełączników. Tym razem pokażę jak takie połączenie można wykorzystać w praktyce. Jak pewnie zauważyliście na zdjęciach, dołączyłem do mojego arduino ethernet shield dzięki któremu będzie możliwe sterowanie urządzeniami za pośrednictwem sieci ethernet.

Przykład który pokażę pozwala na załączenie lub wyłączenie przekaźnika za pomocą przycisku dzwonkowego, lub za pomocą pakietu TCP o odpowiedniej treści.
Jeśli będziemy potrafili załączyć przekaźnik pakietem TCP, będziemy mogli sterować nim z poziomu dowolnego urządzenia - z komputera, telefonu, tabletu...

Przypuśćmy że chcemy sterować przekaźnikiem załączającym oświetlenie LED w salonie.

Program sterujący dla przejrzystości podzieliłem na 3 pliki:

1. _01_homeController.ino

Jest to główny plik zawierający funkcję inicjującą oraz pętlę główną
2.  _02_salon_led.ino
W tym pliku zawarta jest obsługa przycisku oraz przekaźnika
3. _03_network.ino
W tym pliku zawarta jest obsługa połączenia sieciowego
Wydaje mi się że kod jest dość przejrzysty i czytelny. Nie będę zatem opisywał go linia po linii.

Zwróćcie uwagę na nazewnictwo plików które zastosowałem. Arduino IDE sortuje zakładki w projekcie w sposób alfabetyczny. Na początku nazwałem pliki

salon_led.ino
network.ino

zakładka z plikiem network.ino ustawiła się przed zakładką salon_led.ino

otrzymywałem wtedy błąd "SALON_LED_REMOTE_COMMAND was not declared in this scope" w linii 55'tej pliku network.ino.
Nie pomaga tutaj żadne include'owanie plików. Jedyne co pomogło to przeorganizowanie zakładek. Dziwne... Ale tak jest :).
Podłączony układ wygląda następująco:

Działanie całego układu najlepiej zobrazuje poniższy film:

Komunikację sieciową z Arduino trochę ławiej byłoby zrobić za pomocą pakietów UDP, chciałem jednak żeby ten wpis był wstępem do sterowania urządzeniami poprzez OpenHab a niestety natrafiłem na problemy z połączeniem OpenHab i Arduino za pośrednictwem UDP.

Inteligentny dom sterowany za pomocą Arduino - podłączanie przewodów do mikrokontrolera

Opisane w poniższym wpisie elementy możesz zakupić na aliexpres. Poniższe linki to linki afiliacyjne. Skorzystanie z nich Ciebie nic dodatkowo nie kosztuje a ja otrzymam niewielką prowizję która wspomoże rozwój tego bloga. Dzięki!

Przekaźnik: http://ali.pub/2hk8br
Klon Arduino mega: http://ali.pub/2hk94c
Ethernet shield: http://ali.pub/2hk97n


Jak pisałem w poprzednim wpisie zwykłe podłączenie czujników do Arduino za pomocą pojedynczych przewodów jest bardzo podatne na przypadkowe rozłączenia. Przy połączeniu dwóch czy trzech elementów nie ma to większego znaczenia. Ja szacuję że będę wykorzystywał około 20 cyfrowych pinów. W przypadku gdybym musiał odłączyć arduino (a nastepnie podłączyć ponownie) o pomyłkę byłoby bardzo prosto. Okazałoby się wtedy że na przykład przełącznikiem od światła w salonie włączam nawadnianie ogrodu... Mało kusząca wizja, szczególnie dla osoby która akurat wtedy leżałaby na trawniku :)

Jedynym sensownym rozwiązaniem które mi przyszło do głowy jest zaprojektowanie odpowiedniej płytki która odseparuje błędogenne połączenia od samego mikrokontrolera.

U mnie najwięcej będzie połączeń typu - jeden pin do przekaźnika i jeden do przełącznika który nim będzie sterował. Pod tym kątem projektowałem płytkę. Powstała ona w programie Eagle i wygląda następująco:

Do połączeń przewodów sygnałowych wykorzystałem złącza ARK. Do połączenia płytki z Arduino wykorzystałem 20-żyłową taśmę IDC.

Płytka po wytrawieniu wygląda tak:

Nie jest to jeszcze wersja finalna. Krawędzie nie zostały wyrównane i wyszlifowane, ale na to przyjdzie jeszcze czas.
Po podłączeniu do Arduino całość wygląda tak:

Na płytce znalazło się 9 kanałów. Każdy kanał to:
 +5V
GND
Sygnał do przekaźnika
Sygnał do przełącznika (poprzez rezystor podpięty do masy).

Do każdego z kanałów będzie podpięta jedna skrętka od jednego urządzenia którym będę sterował.

Problem pojawił się z połączeniem taśmy z Arduino. Nie znalazłem niestety gniazda IPC z męską końcówką. Postanowiłem zatem wykorzystać zwykłe goldpiny z których powyjmowałem bolce i powkładałem je w odpowiednie wejścia w Arduino. Przed podłączeniem wtyczki wygląda to tak:

Wbrew pozorom całe połączenie trzyma się dość stabilnie i działa bez zarzutu. Jeśli macie inny pomysł na takie połączenie proszę o informację :).
Niestety przy projektowaniu płytki nie udało mi się uniknąć błędów. Planowałem że taśma zostanie podłączona do Arduino od skrajnej lewej strony patrząc z tyłu płytki, zaczynając od dwóch pinów z masą. Dlatego też dwa skrajne piny na mojej płytce są podpięte do masy. Takie rozwiązanie pozwalało mi w przyszłości w razie potrzeby podłączyć obok drugą podobną płytkę. I wszystko działa świetnie dopóki nie podłączam do Arduino Ethernet Shielda, który jak się później dowiedziałem blokuje piny 50, 51, 52, 53. Przy takim połączeniu tracę zatem możliwość sterowania dwoma z dziewięciu przekaźników. Dlatego zdecydowałem się na wpięcie taśmy od prawej strony Arduino (zaczynając od pinu 22) nie podłączając dwóch ostatnich pinów (GND). Minusem tego rozwiązania jest to że masę pomiędzy Arduino a płytką muszę podłączyć  odrębnym przewodem. Nie jest to większy problem ponieważ przewidziałem dodatkowe złącze ARK na +5V i GND. Plusem natomiast jest to, że mamy dostępne wszystkie 9 kanałów zaprojektowanych na płytce - możemy więc sterować 9-cioma urządzeniami.

Na chwilę obecną takie połączenie jest dla mnie wystarczające. Jeśli będzie taka potrzeba, konieczne będzie wykonanie drugiej płytki z wyeliminowanym błędem.

Podsumowując:
Dzięki wykorzystaniu takiej płytki skrętki wpięte  będą do złącz typu ARK, które zapewniają trwałe i solidne połączenie. Połączenie z Arduino będzie wykonane za pomocą jednej taśmy (i masy - co da się w razie potrzeby wyeliminować). Ewentualna wymiana mikrokontrolera powinna zatem odbyć się w sposób szybki i bezproblemowy co w środowisku "produkcyjnym" jest bardzo istotne :).

Inteligentny dom sterowany za pomocą arduino - koncept

Przy okazji budowy domu zaplanowałem sobie kilka elementów, którymi można będzie sterować zdalnie - w dowolny sposób - telefonem, z przeglądarki, pilotem...

Dedykowane rozwiązania tego typu są strasznie kosztowne. Na szczęście na etapie budowy można położyć odpowiednie kable samemu a do sterowania wykorzystać chociażby Arduino.

Ja zaplanowałem głównie sterowanie oświetleniem. Dodatkowo będę mógł jeszcze sterować bramą garażową, bramą od ogrodzenia, elektrozaworem od nawadniania ogrodu i domofonem.

Zależało mi aby instalacja elektryczna w budynku była  standardowa - tak aby w przypadku większej awarii mikrokontrolera można było w prosty sposób wrócić do korzystania z niej w tradycyjny  sposób.

Wybrałem następujące rozwiązanie:
Do każdej puszki w ścianie w której będzie przełącznik od oświetlenia którym chcę sterować poprowadziłem dodatkową skrętkę. Wygląda to mniej więcej tak:

Do tak przygotowanej puszki można:

1.  podłączyć zwykły przełącznik - a tym samym korzystać z instalacji tradycyjnie

2. to co nas bardziej interesuje: 

umieścić w puszce przekaźnik, na przykład taki:

Przekaźnik musi być jak najmniejszy tak aby zmieścił się w puszce za przełącznikiem.

Taki przekaźnik można obciążyć prądem o maksymalnym natężeniu 10A, ale do większości zastosowań jest to w zupełności wystarczające.

Przewody (faza i zero), które normalnie podłączone są do przełącznika podłączamy do wyjścia przekaźnika, ponieważ to on będzie odpowiadał za zamykanie i rozłączanie obwodu.

Zwykły przełącznik musimy zamienić na przełącznik dzwonkowy (bezstanowy), ponieważ światło będziemy załączać chwilowym impulsem wysyłanym do mikrokontrolera. To Arduino będzie pamiętało aktualny stan żarówki (włączona/wyłączona) i w razie potrzeby będzie wysyłało sygnał załączenia/wyłączenia do przekaźnika.

Do sterowania całym obwodem wykorzystamy 5 żył z naszej skrętki:

Do przekaźnika:

 +5V

GND

Sygnał

Do przełącznika dzwonkowego:
+5V
Sygnał

Jeśli jest taka potrzeba napięcie +5V można puścić jedną żyłą i  rozdzielić je już w puszce na przekaźnik i przełącznik (daje nam to oszczędność jednej żyły), ale to dodatkowe kombinowanie w i tak już ciasnej puszce, więc wygodniejsze jest wykorzystanie dwóch przewodów z napięciem.

Cały schemat połączenia dla jednego przekaźnika i jednego przełącznika wygląda następująco:

Oczywiście podłączenie żarówki przedstawione jest w sposób poglądowy.

Każde dodatkowe urządzenie którym chcemy sterować należy podłączyć w sposób analogiczny.
Jak widać ze schematu jedno połączenie zajmuje dwa cyfrowe piny Arduino. Dlatego zdecydowałem się na wykorzystanie Arduino Mega (a dokładnie jego klona). Dzięki temu powinno się udać obsłużyć wszystkie urządzenia którymi zamierzam sterować za pomocą jednego Arduino.

Arduino zostanie umieszczone w szafce Rack znajdującej się w garażu. Tam zbiegają się wszystkie przewody.
Na razie wygląda to tak :)

Jak łatwo sobie wyobrazić podłączanie przełączników i przekaźników bezpośrednio do Arduino spowoduje dużą plątaninę przewodów. Dodatkowo będzie bardzo podatne na przypadkowe rozłączenia. Ewentualna wymiana uszkodzonego mikrokontrolera byłaby również bardzo kłopotliwa. Moja propozycja rozwiązania tego problemu oraz oprogramowanie dla arduino pojawią się w jednym z kolejnych wpisów.

Do kontroli stanu przekaźników z poziomu telefonu, tabletu  i przeglądarki wykorzystam OpenHab (http://www.openhab.org/) - świetne rozwiązanie na licencji OpeSource napisane w Javie.
Przetarłem już pierwsze ścieżki, więc o tym również będzie w kolejnych wpisach :)

Raspberry PI - sterowanie serwomechanizmem

W sieci można znaleźć co najmniej kilka metod sterowania serwomechanizmem za pomocą Raspberry PI.

Według mnie najwygodniejsze jest wykorzystanie biblioteki Servoblaster.

Biblioteka jest częścią pakietu PiBits, hostowanego na GitHub'ie.

Aby pobrać kod na Raspberry PI wykonujemy polecenie:

git clone https://github.com/richardghirst/PiBits/

Następnie przechodzimy do katalogu Servoblaster poleceniem:

cd PiBits/ServoBlaster/

Są dwie metody wykorzystania biblioteki. Może ona działać jako moduł jądra Linuksa, lub jako demon w przestrzeni użytkownika. Druga opcja jest według mnie zdecydowanie wygodniejsza i prostsza do wykorzystania, zatem zajmiemy się nią.

Na początek należy skompilować bibliotekę:

cd  user/
make

Po chwili będziemy mieli wykonywalny plik servod, którego opcje możemy wyświetlić poleceniem:

./servod --help

Możemy teraz przetestować działanie biblioteki uruchamiając ją poleceniem:

sudo ./servod

W tym momencie powinien być dostępny plik

/dev/servoblaster 

do którego będziemy wysyłać polecenia sterujące serwomechanizmami

Podłączmy zatem servo do Raspberry Pi
Pobór prądu serwomechanizmu jest zdecydowanie większy niż to co jest w stanie dostarczyć Raspberry PI, zatem w tym przypadku również konieczne jest wykorzystanie zewnętrznego źródła zasilania. Schemat podłączenia na płytce prototypowej wygląda następująco:

Bardzo ważne jest podłączenie servo i Raspberry PI do wspólnej masy.

Biblioteka servoblaster potrafi sterować maksymalnie ośmioma serwomechanizmami.
Mapowanie numerów silniczków na piny GPIO wygląda następująco:


0 on P1-7  GPIO-4
1 on P1-11 GPIO-17
2 on P1-12 GPIO-18
3 on P1-13 GPIO-21
4 on P1-15 GPIO-22
5 on P1-16 GPIO-23
6 on P1-18 GPIO-24
7 on P1-22 GPIO-25

Po podłączeniu serwomechanizmu możemy sprawdzić jego działanie.

Wydanie polecenia:


echo 0=50% > /dev/servoblaster

ustawi zerowe serwo - czyli to podłączone do pinu GPIO-4 (P1-7) w pozycję 50%.

Polecenie:

echo 1=10% > /dev/servoblaster

ustawi serwo nr 1 (pin GPIO-14) w pozycję 10%.

Można również podać komendę w postaci:

echo 0=150 > /dev/servoblaster

co spowoduje przesunięcie serwo nr 0 w pozycję 150 kroków.

Jeśli chcemy przesunąć serwomechanizm o względną wartość (czyli np o 20 kroków względem aktualnej pozycji), możemy wydać polecenie:

echo 0=+20 > /dev/servoblaster

Biblioteka ma dużo większe możliwości konfiguracji. Szczegóły można znaleźć w bardzo przejrzystej dokumentacji.

Do konfiguracji pozostała jeszcze jedna bardzo istotna rzecz - uruchamianie demona ./servod przy starcie Raspberry PI.

Aby to zrobić wydajemy polecenia:

cd /home/pi/PiBits/ServoBlaster/user/
sudo make install

Odpowiednie skrypty zostaną skopiowane do /etc/init.d i po restarcie komputera demon servod powinien wystartować automatycznie.

Działanie całego układu można zobaczyć na poniższym filmie:

Raspberry Pi - sterowanie modułem laserowym

Kolejnym krokiem przy budowaniu zabawki dla kota jest sterowanie modułem laserowym przy pomocy Raspberry PI.

Niestety nie można podpiąć modułu laserowego bezpośrednio do wyjścia GPIO w RPI ponieważ jesteśmy w stanie wyciągnąć z niego prąd o maksymalnym natężeniu 16mA. Jest to zdecydowanie za mało do wysterowania modułu.

Pozostaje zatem zasilenie lasera z zewnętrznego źródła, i wykorzystanie Raspberry PI jedynie do wysłania sygnału włącz/wyłącz. Najprostsze jest zrobienie tego za pomocą tranzystora.

Schemat połączenia wygląda następująco:

Nie znalazłem symbolu modułu laserowego, wykorzystałem zatem diodę LED, pamiętać jednak należy że zwykłej diody LED nie można podłączać bezpośrednio do zasilania bez rezystora.

Dodatkowo przygotowałem schemat podłączenia na płytce prototypowej (tutaj również dioda LED zamiast modułu - przy podłączeniu zwykłego LED'a należy dodać dodatkowy rezystor)

Po złożeniu prototypu można sprawdzić jego działanie.
Wyjściami GPIO możemy sterować bezpośrednio z linii poleceń Raspberry PI.
Wydajemy polecenia które przygotują wyjście GPIO4 do sterowania:

sudo bash
cd /sys/class/gpio
echo 4 > export
cd gpio4
echo out > direction
i teraz aby włączyć laser wydajemy polecenie:

echo 1 > value
aby wyłączyć wydajemy polecenie

echo 0 > value
Całość można zobaczyć w działaniu na poniższym filmie:

Raspberry Pi - konfiguracja wifi z wiersza poleceń

Na potrzeby opisywanej we wcześniejszym wpisie zabawki dla sierściucha potrzebowałem czystej instalacji Raspbiana, którą następnie będę odpowiednio konfigurował.
Zakładam że system nie będzie korzystał z trybu graficznego, zatem wszystkie ustawienia trzeba wykonać z wiersza poleceń.

Na pierwszy ogień poszła konfiguracja wifi, ponieważ domyślnie Raspbian jest skonfigurowany jedynie do obsługi sieci przewodowej za pomocą DHCP.

Dotychczas zawsze modyfikowałem pliki konfiguracyjne ręcznie.
Należy wtedy odpowiednio zmodyfikować pliki:

/etc/network/interfaces

oraz

/etc/wpa_supplicant/wpa_supplicant.conf

Ostatnio natrafiłem jednak na narzędzie które pozwala skonfigurować połączenia bez żmudnego wpisywania parametrów w plikach. Jest to konsolowa wersja dość popularnego managera połączeń sieciowych WICD.

Zakładam że mamy dostępne Raspberry Pi z działającym przewodowym połączeniem internetowym, oraz podłączoną do USB kartą WiFi.

 

Na początku należy zainstalować odpowiedni pakiet. Robimy to poleceniem 

sudo apt-get install wicd-curses

Następnie uruchamiamy konfigurator poleceniem:

sudo wicd-curses

Powinniśmy wtedy zobaczyć aktualne połączenie sieciowe, oraz listę dostępnych sieci bezprzewodowych:

Teraz należy klawiszami kursora najechać na sieć bezprzewodową i (UWAGA!!!) wcisnąć strzałkę w prawo. W moim przypadku wciśnięcie enter powodowało zawieszenie sesji sesji ssh którą łączyłem się z laptopa do Raspberry Pi. Nie badałem co było przyczyną - mogło to być albo zerwanie połączeń sieciowych, albo zawieszenie Pi. Podejrzewam pierwszą przyczynę.

W każdym razie po wciśnięciu strzałki w prawo pojawi się ekran konfiguracji połączenia, gdzie musimy wybrać kofigurację IP, DNS, szyfrowanie itd.

Po zakończeniu wpisywania ustawień należy wcisnąć F10.

I to już cała konfiguracja. Można odpiąć kabel ethernet i po restarcie urządzenia Raspberry Pi powinno już działać z kartą wifi.

Ten sposób jest zdecydowanie wygodniejszy od ręcznej konfiguracji, chociaż trzeba mieć na uwadze że też może sprawiać pewne problemy.