sobota, 11 marca 2017

"Inteligentny" dom na Raspberry PI

Jakiś czas temu opisywałem moje rozwiązanie automatyki domowej oparte na arduino i Raspberry PI
Polegało to mniej więcej na tym, że wszystkie przekaźniki którymi chciałem sterować, przełączniki z których odbierałem sygnały oraz czujniki temperatury z których korzystałem, podłączone były do arduino mega z ethernet shieldem. Za przechowywanie stanów poszczególnych urządzeń odpowiadało arduino. Na Raspberry PI zainstalowany miałem serwer MQTT. Arduino wysyłało wszystkie sygnały do MQTT skąd pobierał je sobie OpenHAB i udostępniał je użytkownikowi poprzez GUI web'owe lub aplikację mobilną. Dodatkowo OpenHab mógł przesyłać zdalne polecenia użytkownika do MQTT skąd odbierało je arduino i aktualizowało stan urządzeń domowych.

Rozwiązanie to miało jedną podstawową zaletę: działało :)
W trakcie użytkowania pojawiło się jednak kilka problemów o których już wspominałem w poprzednich postach. Były to między innymi:


  • skomplikowana architektura - w przypadku problemów było sporo miejsc do weryfikacji. 
  • problemy przy zanikach energii - w przypadku arduino z ethernet shield'em pojawiają się problemy z poprawnym wznowieniem pracy po zaniku energii. System potrafił zawieszać się przy starcie i konieczne było ręczne odłączenie od zasilania i ponowne uruchomienie. Czasami kilkukrotne. W internecie pojawiają się opisy takich przypadków. Niektórzy doradzają wrzucenie dodatkowego kondensatora pomiędzy PIN reset i GND (o ile dobrze pamiętam :) ), ale w moim przypadku niewiele to pomogło
  • samoczynne załączanie/wyłączanie urządzeń przy skokach napięcia. Tutaj przyczyny nie udało mi się namierzyć. Próbowałem podpinać urządzenia do dodatkowych stabilizatorów, ale nic to nie dało. Nie było to jakoś mocno uciążliwe, bo zdarzało się stosunkowo rzadko, ale jednak była to dość spora rysa na stabilności całego rozwiązania
  • niewygodne podłączanie urządzeń do arduino - podłączanie czujników i przekaźników bezpośrednio do PIN'ów arduino w przypadku "produkcyjnego" rozwiązania to generalnie bardzo słabe rozwiązanie. Co prawda rzadko po podłączeniu czegokolwiek się dotyka, ale arduino miałem w szafie razem z innymi urządzeniami do których co jakiś czas zaglądam i o rozpięcie czegoś było bardzo łatwo. Dorobiłem sobie co prawda dodatkową płytkę ze złączami śrubowymi do których wpiąłem urządzenia, ale i tak nie było to rozwiązanie komfortowe
  • problematyczne wprowadzanie zmian do systemu - dodanie nowego czujnika oprócz podpięcia sprzętu wymagało zmian w kodzie arduino, przenoszenia laptopa do garażu gdzie był hardware, podpinania po USB do arduino, programowania układu, testowania i w przypadku błędu powtarzania wszystkiego kilkukrotnie - niefajne :)
Po ponad dwóch latach korzystania z takiego systemu zacząłem zastanawiać się jak uprościć całą architekturę tak aby większość z powyższych problemów wyeliminować. Podświadomie czułem, że w tej sytuacji arduino jest zupełnie zbędne, że do wszystkiego w zupełności powinno wystarczyć Raspberry PI. Problemem jest jednak ograniczona liczba PIN'ów GPIO. 

W poprzednim wpisie Raspberry PI i dodatkowe piny GPIO na kilku układach mcp23017 oraz przełącznik na tranzystorze opisałem w jaki sposób można te problemy obejść. Pozostało jedynie zaprojektowanie odpowiedniego układu który spełniał będzie wszystkie moje wymagania, zapewniał elastyczność i możliwość dalszej rozbudowy, oraz płytki na której możliwe będzie wygodne  podpinanie urządzeń do Raspberry. Zdefiniowałem następujące wymagania:
  1. 16 cyfrowych wejść (obsługa do 16-tu przełączników)
  2. 16 cyfrowych wyjść (obsługa 16-tu urządzeń na zasadzie włącz/wyłącz)
  3. obsługa magistrali One Wire
  4. obsługa LIRC (sterowanie pilotem na podczerwień)
  5. łatwe i trwałe połączenie z Raspberry PI
  6. łatwe i trwałe podłączanie urządzeń i czujników
  7. dostęp do pozostałych PIN'ów GPIO
  8. możliwość obsługi urządzeń zasilanych różnym napięciem
Zadanie było dość czasochłonne, ale myślę że założony efekt udało mi się osiągnąć. Zrobiłem schemat i projekt w Eagle, zdecydowałem jednak że nie będę sam trawił płytki. Zamówiłem w jednej z firm oferujących taką usługę. Takie oto płytki otrzymałem:




To pierwszy prototyp, jak widać jeszcze nie do końca polutowany. 
Płytka zaprojektowana jest pod 40-pinowe złącze GPIO dostępne od Raspberry Pi 2.
W tym przypadku podłączenie jest bardzo wygodne i trwałe - za pośrednictwem 40-żyłowej taśmy wpinanej do Raspberry i do płytki.
Nic nie stoi jednak na przeszkodzie żeby podłączyć ją do starszej wersji RPI gdzie złącze było 26-cio pinowe. W tym przypadku jednak podłączenie musi być inne - na przykład przewodami female-female:


Podłączenie jest proste, ponieważ złącze na płytce odpowiada  portowi GPIO w Raspberry.

Płytka zawiera wszystkie elementy o których pisałem  w wymaganiach:

Teraz kilka słów wyjaśnienia i opis działania.
Płytkę należy podłączyć do portu GPIO Raspberry PI. Oprócz tego, należy podłączyć dodatkowe źródło zasilania DC. Zdecydowałem się na takie rozwiązanie ponieważ RPI ma zbyt małą wydajność prądową aby obsłużyć 16 urządzeń zewnętrznych które mogą mieć różne wymagania. Jak widać na zdjęciu na płytce mamy 16 tranzystorów. Wszystkie wyjścia zaprojektowane są jako klucze tranzystorowe. Układy MCP23017 załączają poszczególne tranzystory podając zewnętrzne zasilanie na poszczególne wyjścia. Z tego wynika bardzo ciekawa cecha - w zależności od tego jakie napięcie podamy jako zewnętrzne źródło zasilania, takie urządzenia będziemy mogli podpinać do wyjść. Przykładowo, podpinając płytkę do +5V będziemy mogli sterować przekaźnikami które wymagają 5V, podpinając płytkę do +12V będziemy na wyjścia mogli podpinać urządzenia 12-voltowe, na przykład taśmy LED. Jest tutaj jednak ograniczenie - wszystkie wyjścia muszą działać na tym samym napięciu. Kolejna cecha płytki pozwala jednak obejść to ograniczenie. Jak widać na płytce jest dodatkowe wyjście GPIO do którego teoretycznie można podpiąć drugą  taką samą płytkę. Wtedy jedną płytkę podpinamy do +5V a drugą do +12V. Mamy wtedy 16 wyjść +5V i 16 wyjść +12V. I tak dalej.... Do drugiej możemy podpiąć trzecią, do trzeciej czwartą :). Na każdej płytce trzeba jedynie za pomocą zworek zmienić adresowanie układów MCP23017. Ograniczeniem jest jedynie liczba adresów - 3 bity, czyli możemy obsłużyć 7 układów MCP - z czwartej płytki musielibyśmy wyjąć jeden układ MCP - są w podstawkach, więc nie ma problemu. Nie testowałem jeszcze takiego rozwiązania - nie mam tylu płytek :), ale teoria mówi że takie rozwiązanie powinno działać. Pozostało mi jeszcze do zbadania ograniczenie prądowe wszystkich podpiętych urządzeń - to jeszcze przede mną. Ze wstępnych obliczeń wynika, że do 2A powinno działać bez ryzyka przegrzania - to jeszcze będę badał.

Kolejna uwaga - na wyjścia można podpinać jedynie urządzenia które da się załączyć za pośrednictwem dwóch przewodów (plus i minus). Pozwala to na przykład załączać przekaźniki, ale tylko jednokanałowe. Mają one 3 piny. Podpinamy  minus do minusa, a plus z płytki jednocześnie do plusa i sygnału na przekaźniku. Dla mnie takie rozwiązanie jest wystarczające. Steruję jednokanałowymi przekaźnikami ukrytymi w puszkach ściennych. Sterowanie wielokanałowymi modułami przekaźnikowymi może być problematyczne, ponieważ mają one wspólne zasilanie dla wszystkich kanałów. Nad rozwiązaniem tego ograniczenia być może jeszcze popracuję, ale na razie nie widzę jakiejś większej potrzeby.

Na płytce jest 16 wejść cyfrowych. Są to zwykłe 2-pinowe złącza. Zwarcie pinów powoduje podanie napięcia +5V na odpowiedni kanał układu MCP23017 i stamtąd możemy odczytać stan przycisku.

Dodatkowo na płytce umieściłem 3-PIN'owe złącze LIRC, do którego można bezpośrednio podpiąć odbiornik TSOP. Złącze podpięte jest do napięcia 3,3V z RPI więc działały będą jedynie układy TSOP obsługujące takie napięcie. Osobiście sprawdzałem na TSOP4836 i działa bez zarzutu.

Do płytki można wpiąć bezpośrednio 10 urządzeń OneWire. Każde wejście ma 3 PIN'y (+5V, GND, SIGNAL). Urządzenia wpinamy bezpośrednio, bez dodatkowego rezystora, który umieściłem już na płytce. 

To już chyba wszystkie funkcje płytki. U mnie płytka zastąpiła poprzednią konfigurację około miesiąc temu i jak dotąd działa bez zarzutu. Praktycznie wszystkie z wymienionych na początku wpisu wad zostały usunięte. 

No i największa zaleta - to w jaki sposób wykorzystamy płytkę, w czym napiszemy oprogramowanie zależy już tylko od nas. Można skorzystać z pythona, javy, c, czy nawet pisać skrypty w bash'u. Ogranicza nas praktycznie tylko wyobraźnia. Wszystko można wygodnie testować logując się na RPI po ssh i uruchamiając programy. Nie trzeba za każdym razem programować arduino :)

Ja postanowiłem że nadal pozostanę przy OpenHab uruchomionym na RPI.

Do OpenHab 1.x jest "binging" obsługujący układy MCP23017. Prawdopodobnie da się z niego skorzystać. Ja przy okazji zmiany architektury przesiadłem się również na OpenHab 2.0. 
Niestety binding nie działał, musiałem zatem napisać swój. Kod oczekuje na "code review". Jeśli go przejdzie prawdopodobnie znajdzie się w oficjalnym wydaniu OpenHab 2.1.

Niecierpliwi znajdą go tutaj:

Do obsługi czujników temperatury podpiętych do złącz OneWire również nie było binding'u. Tutaj również musiałem napisać swój. Również oczekuje na code review. 

Kod znajdziecie tutaj:
Konfiguracja OpenHab to już jednak temat na oddzielny wpis.
 
Podsumowując: 
 całe rozwiązanie zajęło mi mnóstwo czasu, począwszy od prototypu na płytce stykowej, poprzez schemat i projekt w eagle, lutowanie układu, pisanie oprogramowania, ale zdecydowanie było warto. Całość działa dużo stabilniej niż poprzednie rozwiązanie, a co najważniejsze jest dużo wygodniejsze i elastyczniejsze. Jestem w stanie sobie wyobrazić dużo więcej zastosowań takiej płytki niż tylko automatyka domowa. 
U mnie obecnie płytka obsługuje:

  • 7 przekaźników do sterowania oświetleniem lub gniazdkami
  • przełączniki do obsługi przekaźników
  • 7 czujników temperatury One Wire DS18B20
  • sterowanie przekaźnikami za pomocą pilota
  • do jednego wejścia podłączyłem zamiast przełącznika kontaktron i mam stały podgląd stanu bramy garażowej (zamknięta/otwarta)

Wszystko to na jednym Raspberry PI i opisywanej płytce :)

W trakcie prac przygotowałem trzy prototypy płytki. Jeden działa produkcyjnie, jeden mam do dalszych testów i jeden został "wolny". Jeśli ktoś będzie zainteresowany mogę go odsprzedać. 
Cena - 150 zł. Dość wysoka, ale wykorzystane części nie są tanie (głównie tranzystory i układy MCP), trawienie płytki też trochę kosztowało a i pracy włożyłem sporo. 
Chętnych proszę o kontakt na priv. Mogę wystawić aukcję na allegro.

Jeśli zainteresowanie będzie większe przygotuję jeszcze kilka takich płytek.

Z tego też powodu niestety nie zamieszczę na razie projektu w eagle. Natomiast nie ma tam żadnej wiedzy tajemnej i na podstawie mojego poprzedniego wpisu gdzie załączyłem diagram połączeń MCP, oraz ogólno dostępnej w internecie wiedzy, każdy zainteresowany powinien być w stanie takie rozwiązanie przygotować.
  
 

58 komentarzy:

  1. Witam może Pan podać nazwy układów znajdujących się na tej płytce ?

    OdpowiedzUsuń
    Odpowiedzi
    1. Witam, są podane wielokrotnie w treści wpisu :)

      to układy MCP23017

      Usuń
  2. Witam
    Jak Pana binding ma się do http://docs.openhab.org/addons/bindings/mcp230171/readme.html bo w dokumentacji napisane jest że można ją użyć z OpenHab2 tyle że nie bardzo mogę znaleźć JAR który miałbym użyć. Co do pana bindingu to jak jak wyglada proces instalacji? Zrobilem w swoim zakresie plytke (a wlasciwie uzylem plytke prototypowa) z MCP tylko teraz zastanawiam sie jak najprosciej ja sterowac, przez moment myslalem o zastosowaniu bindingu Exec (tym bardziej że będę używał tylko wyjścia) ale jesli jest cos lepszego to czemu nie skorzystac.

    OdpowiedzUsuń
    Odpowiedzi
    1. Witam,

      mnie bindingu z podanego przez Pana linku nie udało się uruchomić na OpenHab2. Dlatego zdecydowałem się napisać własny. Instalacja mojego bindingu polega na wrzuceniu jar'a do odpowiedniego katalogu. Wtedy jest już widoczny w OpenHab i można dodawać swoje "Thing"'i. Zabawa przez "exec" oczywiście jest możliwa, ale mało komfortowa

      Usuń
    2. To jeszcze pytanie gdzie można znaleźć JAR do pana bindingu? Druga sprawa na ile stabilny jest binding, czy na coś trzeba uważać? Czy jest potrzebna instalacja jakieś dodatkowej bibloteki czy wszystko jest w JARze?

      Usuń
    3. W oficjalnej dystrybucji jeszcze go nie ma. PullRequest czeka na akceptację. Postaram się wieczorem gdzies go wrzucić jak będe w domu. Jeśli chodzi o stabilność - działa u mnie w domu od kilku miesięcy bez zarzutów, ale to na razie tylko mój przypadek użycia. W razie problemów mogę oczywiście pomóc

      Usuń
    4. Ze względu na to, że ilość IO w RPi2 była za mała w mojej instalacji muszę użyć MCP tak więc z przyjemnością z tej bibloteki skorzystam przy okazji będę beta testerem :) Przy okazji czy jest jakaś różnica w obsłudze IO jak już uruchomie MCP z pana bibloteką w porównaniu z standardowym uzyciem GPIO Binding? Co ile są próbkowane wejścia z MCP, możliwe że podłącze wejścia MCP do wykrywania alarmów z czujek PIR/kontaktronów i pytanie jak długi musi być impuls.
      Ostatnie pytanie nie jest związane bezpośrednio z Pana bibloteką ale ogólnie z użyciem wejść z czym ma Pan zapewne doświadczenie. Chciałbym użyć wejść jak pisałem wyżej do wykrywania alarmu z czujnika PIR - większość po prostu zwiera styki, pytanie tylko czy taki czujnik bezpośrednio mogę podłączyć do RPi albo MCP jeśli kabel ma 15 metrów do czujki? Czy przy takim kablu nie pojawią się zakłócenia, zwłaszcza jeśli puszcze 3,3V.

      Usuń
    5. ..to jeszcze jedna uwaga. Żeby była łatwiejsza komunikacja na etapie uruchamiania wysłałem zaproszenie na Hangout.

      Usuń
    6. Ten komentarz został usunięty przez autora.

      Usuń
    7. Stąd można pobrać link do jar'a z bindingiem MCP23017 dla OPENHAB2
      https://drive.google.com/open?id=0BzJpXXOh01BRWkFiXzdKX09BdmM
      na rasberry trzeba umieścić go w /usr/share/openhab2/addons (w przypadku instalacji openhab'a z paczek

      Usuń
    8. Ok wrzuciłem w końcu plik do ../addons (akurat mam wersję snapshotową bo w stabilnej są prolemy z Z-wave). Pytanie czy ten binding gdzieś się powinien pojawić?

      Usuń
    9. sprawdź czy użytkownik openhab jest dodany do grup gpio i i2c.
      Prawdopodobnie nie - trzeba będzie go dodać, dodatkowo trzeba zainstalować rozszerzenie "openHAB 1.x Compatibility Layer" - w sumie to nie wiem dlaczego to jest potrzebne - jeszcze będę to weryfikował, ale obecnie jest potrzebne

      Usuń
    10. To może tak, mam zainstalowanego habiana i to snapshot openHAB 2.1.0~20170508211313-1 (Build #912). Biestety w wersji stabilnej zle dziala Z-Wave 2.0. Co do dodania do grupy gpio/i2c to mam uruchomionego z roota niestesty przynajmniej pod openhabianem dodawanie uzytkownika openhabian do grupy gpio nie pozwolilo na uzytkowanie portow.
      Tak czy inaczej wrzucenie do wspomnianego katalogu nie nie spowodowalo (przynajmniej nie znalazlem zeby cos sie zmienilo). W kazdym razie na liscie add-on->Binding nic nie przybylo :( Co do "..compatibility layer" to gdzie znajde JARa bo w standardowym wykazie tego nie ma.

      Usuń
    11. Na probe wrzuciłem oficjalny
      snapshot i co ciekawe działa na razie bez problemów. Jeszcze tylko nie testowałem wejśc, o ile pamiętam mcp ma wbudowane pullup rezystory pytanie czy da się je uaktywnić z poziomu konfiguracji openhab.

      Usuń
    12. W którym bindingu? Tym z openhab 1.x czy tym moim?

      Usuń
    13. Coś chyba mój ostatni komentarz wcieło. Użyłem org.openhab.binding.mcp23017-1.10.0-SNAPSHOT.jar

      Usuń
    14. Pobralem tego Jara z https://openhab.ci.cloudbees.com/job/openHAB1-Addons/lastSuccessfulBuild/artifact/bundles/binding/org.openhab.binding.mcp23017/target/

      Usuń
    15. Wczoraj zrobilem upgrade do openhab 2.1 i standardowy binding powoduje ze caly systemi nie moze wystartowac tak wiec sprobowalem uruchomic twoj plugin. Wrzucilem go do katalogu pluginow - openhabian wystartowal.
      Niestety sa jakies problemy z dzialaniem, zrobilem taki wpis:
      Switch MainWaterValve "Zawor glowny wody" (MainWaterValve) { mcp23017="{ address:20, pin:'A0', mode:'DIGITAL_OUTPUT', defaultState:'HIGH'}" }

      pozniej taki

      Switch MainWaterValve "Zawor glowny wody" (MainWaterValve) { mcp23017="{ address:20, pin:'A0', mode:'DIGITAL_OUTPUT', defaultState:'LOW'}" }

      i na wyjsciu A0 stan byl bez zmian :( Ustawialem recznie rejestry z uzyciem i2cset i udawalo sie A0 ustawic w stan wysoki i niski.

      Usuń
  3. Dzięki na dniach będę sprawdzał. Układ mam już zmontowany tak więc mam na czym przetestować.

    OdpowiedzUsuń
  4. Witam,
    Wydaje mi sie ze plytka dosc rozbudowana jak na 'tylko' 7 przekaznikow i czujnikow oraz na wyjscia do ich obslugi.
    Zbudowalem uklad 2 plytek z 516 wejsciami do obslugi a do dyspozycji mam 160 przekaznikow. Wszystkie podpiete na tasmach 20pinowych.
    Przekazniki zgrupowane po 2x8 = 16szt.
    Dziwie sie czemu 7 przekaznikow skoro 8 jest typowe.
    przekazniki nawet sprzedawane sa w zestawach 'bitowych' tj 1,2,4,8,16 itd.

    Swego czasu oferowalem jakies wspolne podejscie do tematu bo zajmuje sie podobnymi rzeczami.

    Jesli ktos bedzie zainteresowany moge podeslac kilka fotek.
    pozdrawiam.

    OdpowiedzUsuń
    Odpowiedzi
    1. Chętnie zobaczę te 516 wejść :) Przy tej ilości to chyba sterujesz jakąś średniej wilekości linią produkcyjną bo ja np. w domu doliczyłem się jakiś 30-40 wejśc i 30-40 wyjść :)

      Usuń
    2. te 7 wynika z tego że tyle akurat potrzebowałem :)
      Ja wykorzystuję tylko do sterowania kilkoma światłami + bramą i furtką. Te przekaźniki u mnie nie są na żadnej płytce - każdy siedzi sobie w puszce elektrycznej, więc o żadnej "typowości" nie ma tu mowy :). A płytka rozbudowana bo jeszcze mam trochę planów, ale nie wiem kiedy znajdę czas żeby je zrealizować.
      A jeśli chodzi o samą płytkę, to zbudowałem już drugą wersję.
      Trochę ulepszona - prezentację można zobaczyć na filmie:
      https://www.youtube.com/watch?v=wLtMUCwz3mY

      Usuń
    3. Dziekuje za odpowiedz, ale uwazam ze nie tedy droga.
      Rpi to microcomputer a Arduino to microcontroler dlatego sformuowanie 'powinno wystarczyc Rpi' tu nie pasuje. Posluze sie alegoria w stylu: jest taxi ale wystarczy mi TIR do przewiezienia pizzy.
      Wg mnie Rpi jest po prostu:
      1. za drogie, za dwukrotnosc ceny mozna kupic 100% komputer (uzywany laptop) do tego z monitorem, klawiatura, bateria, gniazdami, systemem, itp, itda do Rpi trzeba wszystko dokupywac. Moze lepiej zostawic ten laptop w garazu i uzywac jak jest potrzebny
      2. strasznie energochlonny bo utrzymuje karte graficzna i inne peryferia kiedy w odole nie sa potrzebne.
      Ja na swoj projekt tez duzo czasu poswiecilem, kilka x wszedlem w slepa uliczke ale nie bylo nikogo kto by mnie zawczasu naprostowal.
      Z mojej perspektywy Rpi w tym wydaniu to tez slepa uliczka.
      A co to przekaznikow to expandery tez maja po 8 lub 16 rozszerzen wiec mozna caly expander przeznaczyc na przekazniki i uzywac tyle ile potrzeba. 7 tu nie pasuje (wg mnie oczywiscie)

      Usuń
    4. Ja osobiście się nie zgodzę z tą opinią. Moim zdaniem użycie Rpi w przypadku automatyki domowej (w wydaniu amatorskim) to dobry wybór. Daje bardzo dużą elastyczność, owszem zużycie energii większe niż w prostym kontrolerze ale jeśli wydaje się tysiąc albo parę tysięcy na automatykę to można powiedzieć że te zużycie jest pomijalne.Prawdę mówiąc raz miałem styczność z projektem (i to który się sprzedaje na rynku) i tak wybrali kontroler i na tym zapuścili jeden z systemów czasu rzeczywistego i niestety to była jedna ze złych decyzji. RPi daje tobie spory zapas mocy co więcej jest nadzieja,że jak zabraknie tej mocy to można będzie się przesiąść na nowszy model. Do tego jest bardzo duża łatwość modyfikacji systemu co jest rozwiązaniem niezbędnym w domowej automatyce.

      Usuń
    5. Ja również pozwolę sobie nie zgodzić się z opinią +Piotr.
      Pamiętać należy że Raspberry nie zapewnia w moim przypadku jedynie sterowania przekaźnikami, ale również działa na nim OpenHab, który zapewnia GUI do sterowania + zapis danych z czujników. W przypadku arduino i tak dodatkowy komputer do tego jest potrzebny. Dodatkowo arduino nie daje takiej elastyczności - do RPI można się zalogować, prosto śledzić logi, rekonfigurować.
      Jeśli chodzi o cenę - oryginalne arduino kosztuje też niemało. Możemy kupić oczywiście chińskiego klona, ale możemy kupić również klona RPI (orange PI itd). W moim przypadku do RPI nic nie musiałem dokupować, zamontowane jest w skrzynce rozdzielczej - podłączanie przez ssh - kompletnie nie potrzeba żadnych akcesoriów. Z tą energochłonnością również bym nie przesadzał. Mierzyłem watomierzem - pobór < 4W. Wg mnie to dobry wynik.
      Czy RPI to ślepa uliczka? Działa u mnie stabilnie, spełnia swoje zadanie - mnie wystarcza, ale zgadzam się że dla niektórych może nie być wystarczające. Nadal nie wiem o co chodzi z tą 7-mką przekaźników - ta siódemka wynika u mnie tylko i wyłącznie z moich potrzeb. Potrzebuję wysterować dokładnie 7. nie jest to żadne ograniczenie i wymóg. Pozdrawiam!

      Usuń
    6. Dziekuje za cenne informacje, nie ma to jak wymiana doswiadczen w zespole. Z tego co widze dzilacie wszyscy w pojedynke (ja tez).
      Nie mam tez czasu na prezentowanie w calosci mojego rozwiazania jak to jest zrobione tutaj. Mam troche inny pomysl niz Rpi ale nie bede sie rozpisywal. Odpowiem na zapytanie. Pozdrawiam i jeszcze raz dzieki.

      Usuń
    7. I to jest clue tematu :) Nie ma jednego idealnego rozwiązania. Każde rozwiązanie jest dobre jeśli działa :) Dodatkowo jeśli zostało wykonane własnymi rękami i z własnego pomysłu to już jest mega satysfakcja :)

      Usuń
  5. 516 wejsc bo do kazdego pomieszczenia doprowadzona jest skretka, wiec z kazdego pomieszczenia 4x4 przyciskow to daje 16.
    W skrocie to 32 pomieszczenia max z czego do kazdych drzwi wejsciowych po skretce lub dzie do sterowania grupowego np oswietleniem/ roletami/ odrodem itp co daje realnie poza tym ok 25 obslugiwanych pomieszczen.
    Z tych 16 nie trzeba wszystkiego uzywac ale z doswiadczenia widze ze i tak malo bo np przyciski:
    3- zapalaja obwody osw 1,2,3
    3- gasza obwody osw 1,2,3
    1- przycisk gasi wszystko
    2- na sciemnianie/rozjasnianie
    2- na rolete1 opuszczanie/podnoszenie
    2- na rolete2 opuszczanie/podnoszenie
    2- na ust temp wewn +/-
    i co zostaje???? ;-(
    podesle cos w weekend

    OdpowiedzUsuń
  6. Mam tez pytanie dlaczego tylko 7x MCP?, ja zrobilem 2 zestawy po 4 i pracuja bez zarzutu, adresowanie od 000 .. 111 (0..7).
    Dla zainteresowanych fotki.
    Ja do zlacz OneWire uzylem RTC DS1307 i dolutowalem kilka wyjsc. Zalaczylem tez monitor LCD0.96' do wyswietlania danych z czujnikow oraz aktualny czas z opcja wyswietlania adresow podpietych czujnikow do OneWire bus. Do tego LCD ma kilka layoutow sterowanych przyciskami i/-. Wszystko na ok9 pinach ARD.

    OdpowiedzUsuń
    Odpowiedzi
    1. Z tą 7xMCP to oczywiście mój błąd. Da się podłączyć 8 sztuk

      Usuń
    2. mamtylko problem z czasem skanowania tych wejsc przez 8xMCP23017, wychodzi po ok 60 millis na szt, przy 8szt to juz prawie 500 millis. dodajac pozostala czesc kodu robi sie prawie 0.7 sekundy. dla czujnikow to nie ma znaczenia ale do sapalania swiatla jest irytyjace.
      Czy masz jakis sposob na shakowanie tego by bylo szybciej? albo
      czy jestes w stanie przekonac mnie ze Rpi zrobi to szybciej?

      Usuń
    3. szczerze mówiąc nie spotkałem się z tym problemem. Nie próbowałem podłączyć takiej ilości układów

      Usuń
  7. A czy probowales tego z chipami MCP23S17 na SPI a nie IIC(MCP23017)?
    SPI jest szybszy!
    Zamierzam przelozyc to wsystko, ale u mnie na pinach busa SPI pracuje TLC5940 wiec musze jeszcze tego scalaka przelozyc na inne piny.
    Ten scalak wykonuje kod w ok 15 millis wiec na innym CLK niz ten z SPI bedzie wolniejszy ale nawet jesli 10x to jest to akceptowalne.
    Czy w tym masz jakies doswiadczenie, czy probowales?
    Mam gotowe plytki na 4scalaki MCP23017, z adresowaniem na zworkach, z wyjsciami na przewody poprzez RJ45 (podlaczanie proste i pewne). Zestawisz 2 plytki i juz jest 8 scalakow. Jakbys chcial ...

    OdpowiedzUsuń
  8. Również walczę z układem MCP23017 w połączeniu z Openhabem oraz z gotowym modułem z 16 przekaźnikami.
    Niby wszystko działa, ale działa na odwrót czyli wtedy kiedy w dashboard w openhabie switch jest ustawiony w pozycji OFF przekaźnik jest załączony a kiedy jest ustawiony w pozycji ON jest wyłączony.

    Cały szkopuł w tym, że moduł z przekaźnikami załącza poszczególne przekaźniki stanem niskim, a nie wysokim, stąd ten problem.

    Czy zastanawiał się Pan może nad dodaniem możliwości konfiguracji z poziomu "iteams" jaki stan ma załączać wyjście.
    Tak jak to działa w przypadku GPIO można wybrać opcje [activelow=yes]

    Pozdrawiam,

    OdpowiedzUsuń
  9. czy możesz opisać jak skonfigurowac mcp23017 z openhabem 2 ? próbowałem i działa bardzo niestabilnie, ciągle sie wyłącza...

    OdpowiedzUsuń
  10. pomógł dopiero downgrade kernela...

    OdpowiedzUsuń
  11. A teraz po ponownym uruchomieniu mam taki błąd:

    2017-09-03 23:06:13.776 [ERROR] [ome.core.thing.internal.ThingManager] - Exception occurred while initializing handler of thing 'mcp23017:mcp23017switch:c468fec9': jav$
    java.util.concurrent.ExecutionException: java.lang.NumberFormatException: For input string: "20.0"

    ktoś sobie już z nim poradził ? (openhab2.1)

    OdpowiedzUsuń
  12. Ale to juz mi cos wyglada z konfiguracja, 20 to jest defaultowy adres MCP. A dziala tobie I2C - sprawdz reczne zalaczanie MCP z poziomu lini polecen.

    OdpowiedzUsuń
  13. tak, zdecydowanie o to chodzi. Problem występuje wyłącznie kiedy dodaje switch-a z GUI. Wpisując ręcznie, problem nie występuje. Szkoda bo trudniej sie zarządza elementami.

    @Piotr - podeślij jakieś informacje o Twoim rozwiązaniu... zamierzam podłączyć 128 portów (64 przekaźniki, 64 wejścia). Trochę mnie zmartwileś wydajnością IC2.

    OdpowiedzUsuń
  14. Czy mogę prosić o ponowne wystawienie bindingu org.openhab.binding.mcp23017-2.1.0-SNAPSHOT.jar
    Zamieszczonego wyżej w linku nie mogę pobrać.
    Zainstalowałem raspbiana i openhab 2.0.0-1 niestety pomimo stosowania poleceń z strony http://docs.openhab.org/addons/bindings/mcp230171/readme.html#item-configuration brak reakcji.
    Układy działają ponieważ z palca mogę bez problemu zmieniać stan portu poleceniem gpio -x mcp23017:64:0x21 write 64 1

    OdpowiedzUsuń
  15. U mnie dziala ze standardowym bindingiem tu macie moje kroki instalacji
    https://drive.google.com/open?id=1_daFzuBHS8SJpVVHYO9mfIlXRp081uMjDGZXqss_8JU

    OdpowiedzUsuń
  16. Ale czy działa z poziomu openhaba?

    OdpowiedzUsuń
    Odpowiedzi
    1. Tak wszystko dziala. Przykladowa definicja itemu:
      Switch FloorHeatingValve1 "Silownik ogrzewania podlogoweg strefa 1" (FloorHeatingValve1) { mcp23017="{ address:20, pin:'B0', mode:'DIGITAL_OUTPUT', defaultState:'HIGH'}" }

      a tak np. ustawiam sendCommand(MainWaterValve,OFF)

      Instalowalem 2-3 razy od zera openhaba i za kazdym razem dzialalo ale warto sprawdzic na poczatek z poziomu rpi czy dziala a pozniej z openhaba. Trzeba zwrocic uwage zeby openhab mial dostep do i2c ja przynajmniej openhaba odpalam z roota

      Usuń
    2. Postawiłem openhabiana i taki sam efekt jak przy raspbianie. Z linii komend bez problemu mogę sterować wyjściem mcp23017 a z poziomu openhaba nie. Działa jedynie GPIO maliny. Poza bindingiem GPIO masz włączony jeszcze jakiś?

      Usuń
  17. To są wszystkie kroki co wykonuje
    https://docs.google.com/document/d/1_daFzuBHS8SJpVVHYO9mfIlXRp081uMjDGZXqss_8JU/edit?usp=sharing

    Pytanie czy robisz dokladnie jak opisalem. Wazne zeby zainstalowac openhabiana 2.1 i oczywiscie mowa o instalacji na RPi. Druga sprawa jak dodales ten binding do Openhaba i wklej jak wyglada twoja definicja itemu i przykladowej reguly. Pytanie czy patrzyles co sie wyswietla w /var/log/openhab2/events.log ?

    OdpowiedzUsuń
    Odpowiedzi
    1. Hej. No teraz to mi działa. Jeszcze nie wiem czy jako input ale sterować diodą mogę. Problem był kernel. Czyli polecenie rpi-update 52241088c1da59a359110d39c1875cda56496764. Na nowym nie działa. Po wgraniu binda na nowym kernelu nawet sam openhab nie chce się uruchamiać tylko się restartuje. na zaproponowanym przez Ciebie kernelu jest ok.
      Openhaba startuje w z uprawnieniami openhaba. Dodałem go do grupy i2c. Więc na root raczej nie muszę.
      Skąd wiedziałeś, że akurat tego kernela trzeba użyć? Czy kiedyś będzie działać na nowych?

      Usuń
    2. Blad zglosilem w lipcu https://github.com/openhab/openhab1-addons/issues/5237 niestety na razie nie zostalo to poprawione

      Usuń
    3. Mimo wszystko dzięki. Teraz walczę z input'em. Mam nadzieje, że to już z górki.

      Usuń
    4. Input słabo działa, dlatego przymierzam sie do magistrali CAN

      Usuń
    5. Mowisz o wejsciach opartych o MCP? Ja z wejsciami robilem proste testy i wyglada ze dziala. Oczywiscie trzeba liczyc sie z opoznieniem no ale akurat tym co steruje jesli dostane sygnal po 5s to tez jest ok. Do szybkiego reagowania uzylbym jednak automatyke na Arduino sterowana odgodnie przez Openhab

      Usuń
    6. Tak. Właśnie chciałem na MCP. 5s to porażka. 1s to dużo ale do przyjęcia. To jest pewne, że takie właśnie opóźnienie występuje?

      Usuń
    7. Ja korzystam z MCP i opóźnienia są poniżej sekundy. Dla zapalania świateł i włączania urządzeń praktycznie niezauważalne

      Usuń
    8. Ten komentarz został usunięty przez autora.

      Usuń
    9. Anatol dzięki za info. Jest tak jak piszesz. Nie wiem jak będzie gdy dojdzie więcej układów MCP. Planuje wykorzystać wszystkie. Mam nadzieje, że opóźnienie będzie nieznaczne.

      Usuń
  18. Ten komentarz został usunięty przez autora.

    OdpowiedzUsuń
  19. Jakie macie doświadczenia z przewodami do wejść mcp23017? Stosujecie skrętki komputerowe? Jakieś inne telefoniczne czy ekranowane? Jaka jest odporność układu na zakłócenia? Jakieś elementy filtrujące? Jakie macie najdłuższe odcinki?

    OdpowiedzUsuń
    Odpowiedzi
    1. ja mam wszystko na skrętce 6cat, nieekranowanej. Obecnie w układzie mam 2 MCP. Najdłuższa skrętka to coś pomiędzy 20 a 30 metrów. Problemów nie zauważyłem

      Usuń