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:
- 16 cyfrowych wejść (obsługa do 16-tu przełączników)
- 16 cyfrowych wyjść (obsługa 16-tu urządzeń na zasadzie włącz/wyłącz)
- obsługa magistrali One Wire
- obsługa LIRC (sterowanie pilotem na podczerwień)
- łatwe i trwałe połączenie z Raspberry PI
- łatwe i trwałe podłączanie urządzeń i czujników
- dostęp do pozostałych PIN'ów GPIO
- 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ć.
Witam może Pan podać nazwy układów znajdujących się na tej płytce ?
OdpowiedzUsuńWitam, są podane wielokrotnie w treści wpisu :)
Usuńto układy MCP23017
Ten komentarz został usunięty przez autora.
UsuńWitam
OdpowiedzUsuń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.
Witam,
Usuń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
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ń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ń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.
Usuń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.
..to jeszcze jedna uwaga. Żeby była łatwiejsza komunikacja na etapie uruchamiania wysłałem zaproszenie na Hangout.
UsuńTen komentarz został usunięty przez autora.
UsuńStąd można pobrać link do jar'a z bindingiem MCP23017 dla OPENHAB2
Usuń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
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ńsprawdź czy użytkownik openhab jest dodany do grup gpio i i2c.
Usuń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
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.
Usuń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.
Na probe wrzuciłem oficjalny
Usuń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.
W którym bindingu? Tym z openhab 1.x czy tym moim?
UsuńCoś chyba mój ostatni komentarz wcieło. Użyłem org.openhab.binding.mcp23017-1.10.0-SNAPSHOT.jar
UsuńPobralem tego Jara z https://openhab.ci.cloudbees.com/job/openHAB1-Addons/lastSuccessfulBuild/artifact/bundles/binding/org.openhab.binding.mcp23017/target/
Usuń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.
Usuń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.
Dzięki na dniach będę sprawdzał. Układ mam już zmontowany tak więc mam na czym przetestować.
OdpowiedzUsuńWitam,
OdpowiedzUsuń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.
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ńte 7 wynika z tego że tyle akurat potrzebowałem :)
Usuń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
Dziekuje za odpowiedz, ale uwazam ze nie tedy droga.
Usuń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)
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ńJa również pozwolę sobie nie zgodzić się z opinią +Piotr.
Usuń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!
Dziekuje za cenne informacje, nie ma to jak wymiana doswiadczen w zespole. Z tego co widze dzilacie wszyscy w pojedynke (ja tez).
Usuń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.
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ń516 wejsc bo do kazdego pomieszczenia doprowadzona jest skretka, wiec z kazdego pomieszczenia 4x4 przyciskow to daje 16.
OdpowiedzUsuń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
Mam tez pytanie dlaczego tylko 7x MCP?, ja zrobilem 2 zestawy po 4 i pracuja bez zarzutu, adresowanie od 000 .. 111 (0..7).
OdpowiedzUsuń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.
Z tą 7xMCP to oczywiście mój błąd. Da się podłączyć 8 sztuk
Usuń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.
UsuńCzy masz jakis sposob na shakowanie tego by bylo szybciej? albo
czy jestes w stanie przekonac mnie ze Rpi zrobi to szybciej?
szczerze mówiąc nie spotkałem się z tym problemem. Nie próbowałem podłączyć takiej ilości układów
UsuńA czy probowales tego z chipami MCP23S17 na SPI a nie IIC(MCP23017)?
OdpowiedzUsuń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 ...
Również walczę z układem MCP23017 w połączeniu z Openhabem oraz z gotowym modułem z 16 przekaźnikami.
OdpowiedzUsuń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,
czy możesz opisać jak skonfigurowac mcp23017 z openhabem 2 ? próbowałem i działa bardzo niestabilnie, ciągle sie wyłącza...
OdpowiedzUsuńpomógł dopiero downgrade kernela...
OdpowiedzUsuńA dokładnie miałem ten sam problem
OdpowiedzUsuńA teraz po ponownym uruchomieniu mam taki błąd:
OdpowiedzUsuń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)
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ń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.
OdpowiedzUsuń@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.
Czy mogę prosić o ponowne wystawienie bindingu org.openhab.binding.mcp23017-2.1.0-SNAPSHOT.jar
OdpowiedzUsuń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
U mnie dziala ze standardowym bindingiem tu macie moje kroki instalacji
OdpowiedzUsuńhttps://drive.google.com/open?id=1_daFzuBHS8SJpVVHYO9mfIlXRp081uMjDGZXqss_8JU
Ale czy działa z poziomu openhaba?
OdpowiedzUsuńTak wszystko dziala. Przykladowa definicja itemu:
Usuń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
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ńTo są wszystkie kroki co wykonuje
OdpowiedzUsuń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 ?
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.
Usuń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?
Blad zglosilem w lipcu https://github.com/openhab/openhab1-addons/issues/5237 niestety na razie nie zostalo to poprawione
UsuńMimo wszystko dzięki. Teraz walczę z input'em. Mam nadzieje, że to już z górki.
UsuńInput słabo działa, dlatego przymierzam sie do magistrali CAN
Usuń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ń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ńJa korzystam z MCP i opóźnienia są poniżej sekundy. Dla zapalania świateł i włączania urządzeń praktycznie niezauważalne
UsuńTen komentarz został usunięty przez autora.
Usuń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ńTen komentarz został usunięty przez autora.
OdpowiedzUsuń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ń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ńjakie napięcie stosujesz ? 5v ?
Usuńczy skrętki są prowadzone blisko przewodów elektrycznych ?
czy indukują sie napięcia i powoduje to dziwne zachowanie wejść?
Też jestem ciekawy tych informacji. Jestem w trakcie budowy i jeszcze przed okablowaniem. Nie chce później ryć ścian.
Usuńskrętka 5e z ekranem kosztuje sto złotych za 300 metrów. nie ma sensu kombinować z innym kablem :)
UsuńWitam serdecznie,
OdpowiedzUsuńprzyznam, że zupełnie przypadkowo trafiłem na blog'a, ale już po paru chwilach miałem go zapisanego w ulubionych.
Przymierzam się do zbudowania prostego sterowania na Raspberry Pi.
Chcę sterować szesnastoma przekaźnikami, na forum Arduino poczytałem trochę o MCP23017 i znalazłem kilka wpisów na temat SX1509 - https://www.sparkfun.com/products/13601 Generalnie układ bardzo podobny, niestety nigdzie nie znalazłem informacji na temat podłączenia do Raspberry, a tym bardziej na temat SX1509 i OpenHab.
Czy miał Pan okazję testować taki układ? Czy da się to cudo podłączyć analogicznie jak MCP23017? Będę wdzięczny za sugestie.
P.S. Dlaczego OpenHab a nie np Home Assisiant? Jak ze stabilnością OpenHab'a? zastanawiam się jak długo potrafi pracować bez restartów, zawieszania.
Pozdrawiam i czekam na kolejne inspirujące wpisy!
A dlaczego SX1509 a nie MCP? Do MCP jest dzialajacy binding w Openhab. Co do Openhab'a to u mnie chodzi od pol roku i nie zauwazylem zeby sie zawiesil chociaz co pewien czas go restartuje bo rozwijam caly system. Ja Home Assistance nie znam ale jak mowimy o OpenHab to trzeba powiedziec ze jest dobrze przemyslany.
OdpowiedzUsuńJesli chodzi o MCP to bede mial plytki z tym ukladem za jakis czas bo zamowilem u chinczyka PCB a ze mozna bylo zamowic min.10 sztuk to bede mial do odsprzedania. Plytka wyglada tak https://photos.app.goo.gl/jOGOvGvauZG8vDw12 tyle ze ja sprzedaje sama plytke bez czesci (no chyba ze ktos chce to ewentualnie moze byc zmontowana ale bedzie duzo drozej)
W sumie nie napisalem te zlacza srubowe to wejscia 5V a do sterowania uzywam tazme ktora mozna podlaczyc do plytki z przekaznikami
OdpowiedzUsuńJa zamówiłem taką płytkę: https://www.aliexpress.com/item/MCP23017-Serial-Interface-Module-IIC-I2C-SPI-MCP23S17-Bidirectional-16-Bit-I-O-Expander-Pins-10Mhz/32841066462.html chcę ją dać bezpośrednio pod Pi a osobne zasilanie dać na przekaźniki.
OdpowiedzUsuńPisałem trochę na forum Arduino (jako, że na nie wcześniej trochę robiłem) i na nim oparłem schemat (https://preview.ibb.co/k1KmH6/16_Relays_V2_bb.png) ale wiem, że Arduino nie ogarnie tego co planuję, dlatego RaspberryPi + OpenHab.
Pi za kilka dni będzie, reszta elementów też, wiec zacznę zabawę.
Na razie szukam informacji i staram się rozplanować projekt.
Generalnie na początek kilka DS18B20 + przekaźniki do podłogówki i do rolet.
Z czasem pewnie będę rozwijał projekt.
Pytam o stabilność OpenHub'a bo zależy na tym, żeby całość się nie zawieszała. Na Arduino idzie łatwo dorzucić zewnętrzny Watchdog, co do Raspberry (jeszcze) nie wiem jak.
Korzystam z powyższej płytki i swojego bindingu do openhab2 już od kilku miesięcy i myślę że mogę ze spokojnym sumieniem stwierdzić że rozwiązanie działa stabilnie.
UsuńMiałem jeden problem z kartą pamięci rasberry PI, ale to standardowy problem Raspberry a nie OpenHab'a
Dzięki za odpowiedz. Śledzę na GitHub'ie temat binding'u :)
UsuńO jakim problemie z kartą piszesz? Jak wspominałem dopiero zaczynam przygodę z Pi i OpenHab'em
Generalnie na raspberry PI zdarzają się problemy że karta pamięci potrafi "paść". Karty SD mają ograniczoną trwałość i stąd problem. Ale nie ma to związku z Openhab'em i samą automatyką.
UsuńJa generalnie mam zawsze zapasową kartę ze skonfigurowanym systemem, więc w razie takiego przypadku od razu jestem w stanie podnieść system
Tylko jedna uwaga binding MCP z Openhab działą z 2.1 po wykonaniu pewnych kombinacji w Openhab natomiast w 2.2 na razie nie udało mi się uruchomić bindingu. A wam się udało?
OdpowiedzUsuńnie próbowałem jeszcze. na razie jadę na 2.1
UsuńWitam, niestety link https://github.com/aogorek/openhab2-addons/tree/master/addons/binding/org.openhab.binding.onewiregpio nie działa.
OdpowiedzUsuńPoszukuję sposobu jak podłączyć DS18B20 do OpenHab'a, niestety wszędzie gdzie szukam znalazłem binding ze skryptem lub poradę żeby wykorzystać 1Wire<->USB.
W Samej javie da się dostać do 1Wire: https://raspberrypi.stackexchange.com/questions/40222/java-and-ds18b20.
Uprzejmie proszę o odświeżenie linku i o informację na temat bindingu. Z góry wielkie dzięki.
Znalazłem :)
Usuńhttps://github.com/openhab/openhab2-addons/pull/1852
Czy mogę jakoś pomóc? Dzisiaj dotarł mój Pi, czekam jeszcze na zasilacz i zabieram się za konfigurację. Obydwa bindingi (OneWire i MCP23017) będą bardzo pomocne. Testować je będę na pewno.
Jak tylko doczytam jak skonfigurować środowisko pod Windowsem mogę spróbować poprawić wskazane w pull requeście błędy.
Dlaczego pi4j a nie jpigpio? Znalazłęm ostatnio ciekawy pull request (https://github.com/openhab/openhab2-addons/pull/1334) binding gpio.
Jak uda sie tobie uruchomic MCP23017 pod najnowsza wersja OpenHaba to daj znac..ja po paru minutach poddalem sie i czekam na innych :)
OdpowiedzUsuńOk, więc zrobiłem refactor bindingu do MCP23017.
OdpowiedzUsuńStąd można pobrać jar'a
https://drive.google.com/open?id=1rwHsG6asZmBLi3MuePjQVKqCOPkWiD9N
a stąd instrukcję konfiguracji, bo zupełnie zmieniło się podejście do tematu:
https://drive.google.com/open?id=1Xsyj2rzXXGjzH_vBqUgd0FEDkaF5s8Td
Zapraszam do testów i uwag :)
Dzięki za update :) Pi już dotarł, lada dzień będzie MCP23017, z chęcią zweryfikuję działanie.
UsuńWielka prośba o binding do OneWire, chciałbym go wykorzystać z DS18B20.
CZy to jest wersja dla OH 2.2 ?
UsuńPonawiam pytanie, czy ta wersja bindingu jest na 2.2 ?
Usuńtak, działa na 2.2
UsuńUdało się to uruchomić pod OH 2.2 ?
OdpowiedzUsuńtestowałem i jak narazie wszystko działa.
OdpowiedzUsuńPrzekonfigurowania wymagały pliki things/items.
nie do końca wiedziałem czy piny nazywają sie A0..A7,B0...B7 czy A0..A15 - nie ma tego w dokumentacji. Pierwsza wersja jest poprawna.
Jeszcze jedno pytanie - czy jest szansa aby dopisać opcję konfiguracyjną w przypadku przekaźników sterowanych niskim stanem ? Wtedy logika jest odwrotna. Da sie ustawić default state = low, jednak to powoduje ze wszystkie grafiki działają odwrotnie. Wielka prośba o uwzględnienie :)
OdpowiedzUsuńWitam,
OdpowiedzUsuńWidzę że w OH 2.3 pojawił się twój binding do MCP. Dotychczas używałem starego i miałem takie definicje itemow:
Contact PIRDetectorSalon "Czujnik ruchu salon" { mcp23017="{ address:21, pin:'B2', mode:'DIGITAL_INPUT'}" }
ale to przestało działać, w dokumentacji w dalszym ciągu jest info że tak się definuje itemy. Natomiast jak zrobiłem:
Contact PIRDetectorSalon "Czujnik ruchu salon" { channel="mcp23017:mcp23017:fe1937e0:input#B2" }
zaczęło działać.
Ten komentarz został usunięty przez autora.
UsuńSprawa się wyjaśniła, wczoraj zauważyłem, że przy starym bindingu w dokumentacji jest napisane że jest legacy.
OdpowiedzUsuńNatomiast z nowym bindingiem są, kłopoty. Jeszcze próbuje dobrze zreprodukować ale na ten moment problem się pojawia przy zmianie definicji itemów. Po podmianie pliku z itemami dostaję błąd w logach:
2018-08-12 10:50:45.725 [ERROR] [ome.core.thing.link.ThingLinkManager] - Exception occurred while informing handler: This GPIO pin already exists: GPIO A1
com.pi4j.io.gpio.exception.GpioPinExistsException: This GPIO pin already exists: GPIO A1
at com.pi4j.io.gpio.impl.GpioControllerImpl.provisionPin(GpioControllerImpl.java:552) ~[?:?]
tak wygląda definicja w pliku z intemami:
Contact FloorHeatingAuto "Ogrzewanie podlogowe automatyka" {channel="mcp23017:mcp23017:fe1937e0:input#A1"}
Jakby to był tylko wpis do loga to byłby mały problem natomiast sytuacja jest taka, że odczytywanie niektórych wejść z MCP23018 nie działają. Próbowałem dojść dlaczego problem pojawia się dla niektórych wejść ale na razie nie znalazłem żadnego klucza. Z niketórami wejściami nie ma problemów a dla niektórych są błędy i problemy z odczytyem.
Pytanie gdzie takie błędy zgłaszać? Czy jest system bugtrackingu i czy jest jest szansa na poprawę takich błędów czy raczej dać sobie spokój i zostać przy starym OH i starym pluginie?
Hej, a skąd kupujesz swoją elektronikę? Kojarzysz może sklep https://dlaelektrykow.pl/115-wylaczniki-silnikowe? Zastanawiam się, czy nie kupić stamtąd kilku rzeczy, ale wolałabym posłuchać opinii kogoś, kogo uważam za specjalistę ;)
OdpowiedzUsuńNie ukrywam, że ja również marzę o domu w pełni inteligentnym. Czy kiedykolwiek będę jego właścicielem? Kto wie... Chciałbym, aby został wyposażony w system firmy https://www.se.com/pl/pl/work/solutions/system/s1/buildings-systems.jsp zastępujący kilka, w pełni niezależnych systemów.
OdpowiedzUsuńU mnie poza elementami inteligentnego domu postawiłem także na monitoring, dzięki temu wiem co się dzieje w domu nawet podczas mojej nieobecności. Macie u siebie też takie systemy? alarm swoją drogą oczywiście.
OdpowiedzUsuńStworzenie inteligentnego domu potrzebuje wielu urządzeń, sterowników, czujników i wielu innych. Wszystkie je można znaleźć na stronie https://www.interblue.pl/ Zależne od tego jest, aby wszystko odpowiednio do własnego domu dopasować. W razie potrzeby wiele doradzić się w stanie specjaliści.
OdpowiedzUsuńMoże ktoś ponownie wrzucić plik z krokami instalacji MCP23017?
OdpowiedzUsuńW wersji 2.5 jest jakiś błąd, który podobno można zniwelować wrzucając plik .jar z wersji 2.4 do /usr/share/openhab2/addons ale dalej mam taki problem
"Tried to access not available I2C bus: Remote I/O error"
przy tworzeniu nowego mcp23017 thing
próbowałem już wielu rozwiązań, boot/config.txt, install i2c-tools itp dalej ten sam problem :(
Ja nadal jadę na OpenHab 2.2, więc nie pomogę. Pytanie czy odinstalowałeś AddOn z wersji 2.5, przed ręcznym wrzuceniem tego z 2.4?
UsuńChyba próbowałem z zainstalowanym(wtedy pojawiały się 2 pozycje MCP23017 z przy tworzeniu nowego thing) i bez zainstalowanego 2.5, różne kombinacje.
UsuńSam binding wydaje się działać bo bez wrzucenia v2.4 do addons wyskakuje inna informacja :
"An error occurred while calling method 'ThingHandler.handleCommand()' on 'org.openhab.binding.mcp23017.internal.handler.Mcp23017Handler@107c4f9': null
java.lang.NullPointerException: null"
z dodanym v2.4 występuje problem jak wyżej pisałem z dostępem do I2C.
I właśnie nie wiem czy na czystym Raspbianie muszę coś więcej konfigurować, plik boot/config.txt albo instalować jakieś dodatkowe biblioteki dla I2C.
Np. polecenie "i2cdetect -y 1" zwraca "command not found"
więc czegoś brakuje ale właśnie chce znaleźć opis krok po kroku bo już próbowałem wielu rzeczy.
Pracuje na Raspberry 3b+
Mirek - już dawno przesiadlem się na domoticz gdzie obsługa MCP po prostu działa bez problemu. Tobie też radzę bo bazowanie na 1osobowym projekcie jest ryzykowne. Nic oczywiście nie ujmując pomysłowi.
OdpowiedzUsuńJa używam binding mcp pod 2.4 i nie ma żadnych problemów. Co do domoticz to jednak on przy openhabie wygląda i jest zrobiony dość siermieznie
OdpowiedzUsuńwszystko prawda, ale jest prosty i działa ;)
OdpowiedzUsuń.
OdpowiedzUsuńTen komentarz został usunięty przez administratora bloga.
OdpowiedzUsuńTen komentarz został usunięty przez autora.
OdpowiedzUsuńWitam serdecznie, autora. Zainteresował mnie blog oraz projekt który autor tutaj zrealizował. Czy w dalszym ciągu istnieje możliwość kupna takiej płytki o której autor wspomina ?. Z chęcią nabędę takową,. w jaki sposób mogę się skontaktować ?
OdpowiedzUsuńInteligentny dom w dzisiejszych czasach to absolutna rewolucja, która w znaczny sposób ułatwia życie. Choćby same inteligentne żarówki reagujące na głos lub aplikację.
OdpowiedzUsuńPozdrawiam,
https://spectrumsmart.pl/
U nas w domu też rządzi elektronika. Bardzo to ułatwia życie. Mąż ostatnio też wprowadza elektronikę do firmy :) Mysle, ze na dobre nam to wyjdzie. Części chyba będzie zamawiał od firmy TS PCB, która produkuje m.in obwody drukowane.
OdpowiedzUsuńProces Montaż monitoringu Rzeszów to kluczowy element zapewnienia bezpieczeństwa w wielu przestrzeniach - od domów prywatnych, przez sklepy, aż po obiekty przemysłowe. Instalacja systemów monitoringu nie tylko odstrasza potencjalnych włamywaczy, ale również umożliwia rejestrowanie materiału wideo, który może posłużyć jako dowód w przypadku incydentu. Dzięki monitoringowi, właściciele mogą na bieżąco śledzić sytuację wokół swojej nieruchomości, nawet będąc z daleka, co dodatkowo zwiększa ich komfort psychiczny.
OdpowiedzUsuń