Jak sterować swoim domem? Poniżej znajdziecie instrukcję wdrożenia krok po kroku własnego rozwiązania ,,inteligentnego domu” sterowanego z chmury – z wykorzystaniem instancji Aruba Cloud oraz platform Domoticz i Arduino.
Komputery otaczają nas wszędzie. W naszym codziennym życiu praktycznie na każdym kroku zderzamy się z ,,inteligentną elektroniką”. Od dziesiątek lat przedmioty codziennego użytku są wyposażane w mikrokomputery. To, co jednak spowodowało, że na nowo zaczęliśmy definiować ich możliwości, to fakt masowego podłączania przedmiotów codziennego użytku do ogólnodostępnej sieci Internet. Generalizując, możemy wręcz powiedzieć, że do chmury podłączane są już całe domy. Bierzmy się zatem do roboty!
Nowa przygoda z mikrokontrolerami, czyli ,,Arduino Starter Kit”
Arduino jest otwartą platformą programistyczną dla gotowego systemu wbudowanego o tej samej nazwie, ale występującego w różnych wersjach. Najpopularniejszą z nich jest odmiana UNO, aktualnie na rynku dostępna jest już trzecia jej rewizja, bazująca na 8-bitowym mikrokontrolerze Atmel AVR (Automatic Voltage Regulator) – ATMega 328P. Układ ten posiada 32 KB pamięci flash, 2 KB pamięci SRAM i 1 KB pamięć EEPROM. Arduino UNO to gotowa płytka drukowana i w cenie około 20 € poza samym mikrokontrolerem otrzymujemy:
- 14 złączy wejścia/wyjścia (cyfrowych),
- możliwość wykorzystania do 6 złączy wejścia/wyjścia (z 14 cyfrowych) jako kanały PWM (Pulse Width Modulation),
- 6 wejść analogowych,
- obsługa magistrali komunikacyjnych: USART, I2C, SPI.
Z wykorzystaniem magistrali komunikacyjnych możemy zarówno sterować zewnętrznymi układami (wyświetlacz LCD na magistrali I2C), jak i odbierać/wysyłać dane do komputera.
W realiach świata IoT najbardziej optymalnym rozwiązaniem jest realizowanie komunikacji w oparciu o transmisję bezprzewodową. Najczęściej spotykanym rozwiązaniem jest wykorzystanie częstotliwości 433 MHz, powszechnie używanej w różnego rodzaju rozwiązaniach takich jak: czujniki parametrów środowiskowych (stacje pogody / termometry bezprzewodowe), systemy zdalnego sterowania (piloty do bram, zabawki), systemy przemysłowe (transmisja szeregowa). Zaletą komunikacji wykorzystującej tę częstotliwość jest większy niż w przypadku pasm 2.4/5 GHz zasięg działania i lepsza odporność na zakłócenia. Jest to możliwe dzięki stosunkowo wąskiemu kanałowi komunikacyjnemu (25 kHz), przez co przepustowość transmisji danych jest znacznie ograniczona. Przez wzgląd na to, że powszechne w użyciu zarówno w środowiskach domowych, jak i przemysłowych, są sieci WLAN, rozwiązania IoT są coraz częściej wyposażane w odpowiednie moduły Wi-Fi. Dla każdego początkującego, chcącego zgłębić tajniki mikrokontrolerów i myślącego o zbudowaniu własnego rozwiązania ,,Internetu Rzeczy”, polecamy gotowe zestawy startowe. Są wyposażone we wszystko, co jest na początku potrzebne do zbudowania własnego prostego rozwiązania. Dla potrzeb niniejszego artykułu zbudowaliśmy jeden z takich układów – system kontroli dostępu RFID sterujący elektrozamkiem (sterowanie silnikiem krokowym). Z efektem końcowym prac tego układu możecie zaznajomić się na poniższym wideo:
Zbudowanie i zaprogramowanie całego układu zajęło nam nie więcej niż 20 minut, przy czym skorzystaliśmy tutaj z gotowego, ogólnodostępnego kodu takiego rozwiązania pobranego z GitHuba, przerabiając go tylko nieznacznie na własne potrzeby.
Oczywiście na sam początek sugerujemy zacząć od prostych rozwiązań, takich jak np. czujnik temperatury czy czujnik ruchu / dźwięku. Zbudowanie takiego układu stanowi też bardzo dobry początek dla tych z Was, którzy myślą o uczynieniu swojego domu / mieszkania coraz bardziej ,,inteligentnym”.
Domoticz
Domoticz stanowi otwartą, uniwersalną i otartoźródłową platformę do zarządzania funkcjami inteligentnego domu. W zależności od potrzeb i posiadanych rozwiązań, może być uruchomiony na platformach Linux (x86/x86_64), Windows czy ARM (x32/x64). Jeśli posiadamy już gotowe rozwiązanie działające w oparciu o Arduino, teraz najistotniejszą kwestią jest zbieranie z niego danych i zapewnienie bezpiecznego dostępu do nich – bez względu na naszą (jako użytkownika systemu) lokalizację. Sam Domoticz może działać np. na naszym Raspberry Pi – w takim wypadku musimy zapewnić dla niego bezpieczny dostęp do zarządzania. Bardzo często nie jest to zadanie łatwe, zwłaszcza w przypadku domów zlokalizowanych w oddaleniu od dużych miast. Zazwyczaj wtedy pozostaje nam możliwość wykorzystania łącza radiowego lub usługi transmisji danych zapewnianej przez operatora komórkowego. W przypadku planów i taryf dla użytkowników domowych uzyskanie własnego publicznego adresu IP czy też możliwość realizacji połączeń ,,ze świata” nie jest po prostu możliwe.
W takim wypadku Arduino możemy doposażyć w moduł sieciowy – Ethernet (bezpieczniej i stabilniej) lub WLAN (np. Arduino WiFi Shield), a następnie wysyłać wszystkie informacje do naszego serwera Domoticz zlokalizowanego w chmurze. Oczywiście w takim wypadku zachęcamy do zabezpieczenia połączenia z wykorzystaniem bezpiecznego tunelu VPN.
W dalszej części artykułu skupimy się właśnie na takim scenariuszu i zainstalujemy oraz skonfigurujemy pakiet Domoticz w ramach systemu CentOS jako instancji Aruba Cloud VPS. Jeżeli jeszcze takiego serwera nie posiadacie i go nie wdrażaliście, to – jak zawsze – odsyłamy do naszych poprzednich artykułów.
Ponadto – co zakładamy w naszym scenariuszu – komunikację pomiędzy siecią LAN (gdzie znajduje się Arduino) a serwerem Aruba realizujemy w oparciu o tunel IPSec VPN. Co prawda, sam panel Domoticza możemy uruchomić na protokole HTTPS, to jednak dane będziemy przesyłać z wykorzystaniem protokołu HTTP. Po podłączeniu do świeżo wdrożonej instancji Cloud VPS zaczynamy od zaktualizowania systemu operacyjnego oraz sklonowania repozytoriów z GitHuba zawierających kod źródłowy Domoticza:
yum -y install epel-release yum -y update && yum -y upgrade
Kolejno instalujemy wymagane pakiety:
yum -y install git '@Development tools' wget libusb.x86_64 perl-core zlib-devel mlocate systemd-devel libgudev1-devel libssh.x86_64 python34-devel.x86_64 python34 python3-devel glibc-static libstdc++-static curl curl-devel libuv libuv-devel bash-completionInstalujemy cmake w odpowiedniej wersji:
sudo yum -y install cmake3
ln -s /usr/bin/cmake3 /usr/bin/cmakePobieramy i kompilujemy biblioteki OpenSSL ze źródeł:
cd /usr/local/src/ wget https://www.openssl.org/source/openssl-1.0.2t.tar.gz tar xzvf openssl-1.0.2t.tar.gz && cd openssl-1.0.2t ./config --prefix=/usr/local/ssl --openssldir=/usr/local/ssl shared zlib make make test make install cd /etc/ld.so.conf.d/ echo ' /usr/local/ssl/lib ' > openssl-1.0.2t.conf ldconfig -v mv /bin/openssl /bin/openssl.BAK
Tworzymy skrypt, który pozwoli nam zdefiniować nowe zmienne środowiskowe dla OpenSSL: vim /etc/profile.d/openssl.sh. Zawartość:
OPENSSL_PATH="/usr/local/ssl/bin"
export OPENSSL_PATH
PATH=$PATH:$OPENSSL_PATH
export PATHNadajemy uprawnienia i ustawiamy zmienne:
chmod +x /etc/profile.d/openssl.sh
source /etc/profile.d/openssl.shSprawdzamy ścieżkę i wersję OpenSSL:
which openssl
openssl version -aWynik poleceń powinien być zgodny z poniższym zrzutem:
Następnie pobieramy i instalujemy biblioteki boost:
mkdir /opt/boost && cd $_ && \ wget https://dl.bintray.com/boostorg/release/1.71.0/source/boost_1_71_0.tar.gz && \ tar xzvf boost_1_71_0.tar.gz && cd boost_1_71_0 && ./bootstrap.sh && ./b2 stage threading=multi link=static --with-thread --with-date_time --with-system --with-atomic --with-chrono --with-regex --with-iostreams --with-python && ./b2 install threading=multi link=static --with-thread --with-date_time --with-system --with-atomic --with-chrono --with-regex --with-iostreams --with-python
Jako ostatni krok przed instancją Domoticza – dogrywamy biblioteki OpenZWave, również kompilowane ze źródeł:
cd /opt/ && git clone https://github.com/OpenZWave/open-zwave open-zwave-read-only && cd open-zwave-read-only/ && git pull && make && make install
Finalnie przystępujemy do instalacji Domoticz:
cd /opt && git clone https://github.com/domoticz/domoticz.git domoticz && cd domoticz && cmake -DOPENSSL_ROOT_DIR=/usr/local/ssl -DOPENSSL_LIBRARIES=/usr/local/ssl/lib -DCMAKE_BUILD_TYPE=Release CMakeLists.txt CONF_SWAPFILE=1024 make
Po pomyślnie ukończonej instalacji po raz pierwszy w celach testowych uruchamiamy Domoticza jako proces:
./domoticzOczywiście ręczne uruchamianie rozwiązania za każdym razem nie wchodzi w grę, dlatego musimy skonfigurować i utworzyć nową usługę dla Domoticza. Najpierw tworzymy odpowiedniego użytkownika:
useradd domoticz && chown -R domoticz /opt/domoticz
Następnie tworzymy plik: /etc/systemd/system/domoticz.service. Uzupełniamy go poniższą zawartością i zapisujemy:
[Unit]
Description=domoticz_service
[Service]
User=domoticz
Group=domoticz
ExecStart=/opt/domoticz/domoticz -www 8080 -sslwww 8443
WorkingDirectory=/opt/domoticz
[Install]
WantedBy=multi-user.targetWłączamy i uruchamiamy usługę:
systemctl enable domoticz
systemctl start domoticzNa koniec tworzymy odpowiednie reguły FirewallD:
firewall-cmd --add-port=8080/tcp --permanent
firewall-cmd --add-port=8443/tcp --permanent
firewall-cmd --reloadKonfiguracja
W celu wysyłania informacji do naszego chmurowego Domoticza nasz zestaw Arduino musieliśmy wyposażyć w moduł Wi-Fi. Wykorzystany został tutaj dedykowany układ Arduino WiFi Shield. Sam przykładowy kod skonfigurowania połączenia do sieci WPA2 został udokumentowany na stronie z opisami bibliotek: https://www.arduino.cc/en/Tutorial/ConnectWithWPA
Kolejnym elementem, jaki ,,dobudowujemy” do naszego rozwiązania, jest mechanizm wysyłania żądań HTTP z wykorzystaniem wspomnianego wcześniej modułu, który również został uwzględniony w dokumentacji projektu Arduino: https://www.arduino.cc/en/Tutorial/WiFiWebClient. Standardowo do interfejsu Domoticza logujemy się z wykorzystaniem przeglądarki. Powita nas ekran startowy (Dashboard) wraz z informacją o braku zdefiniowania ulubionych urządzeń:
W zasadzie to żadne urządzenie nie jest dodane i ten proces musimy dopiero zrealizować. Domoticz jako platforma zainstalowana na RaspberryPi wspiera obsługę złączy GPIO. My jednak system wdrożyliśmy w oparciu o instancję chmurową Aruba. W związku z tym obsługa urządzenia może być realizowana tylko z wykorzystaniem komunikacji sieciowej. Domoticz wspiera przekazywanie parametrów z wykorzystaniem API działającego w oparciu o JSON. Zasadniczo więc nasze rozwiązanie, takie jak czujnik temperatury, musi wysyłać właściwie skonstruowane żądania HTTP GET do Domoticza. Dla parametru typu temperatura takie żądanie będzie miało następującą składnię:
/json.htm?type=command¶m=udevice&idx=IDX&nvalue=0&svalue=TEMP
gdzie:
IDX = ID naszego urządzenia (czujnika temperatury),
TEMP = wartość temperatury.
Jeżeli macie potrzebę skonfigurowania przekazywania zupełnie innych parametrów (np. wilgotność, ciśnienie atmosferyczne lub wysyłanie dowolnego komunikatu tekstowego), to opis wszystkich możliwości znajdziecie dokładnie w TEJ SEKCJI dokumentacji. Potrzebujemy zatem naszego parametru IDX. W tym celu musimy skonfigurować nowe urządzenie. W głównym panelu Domoticza rozwijamy opcję Setup i przechodzimy do sekcji Hardware:
Następnie dodajemy urządzenie typu Dummy, które zasadniczo nic nie robi, ale pozwoli nam na dodanie wirtualnych czujników (komunikujących się właśnie z wykorzystanie API JSON). Nadajemy nazwę dla naszego urządzenia, z listy rozwijanej wybierając Dummy i klikając na Add:
Po dodaniu urządzenia będziemy je od razu widzieli i poprzez kliknięcie na opcję Create Virtual Sensor możemy wybrać typ czujnika i nadać mu nazwę:
Gdy czujnik jest już dodany, przechodzimy do menu Setup -> Devices, gdzie będziemy mogli podejrzeć status naszych urządzeń. W naszym projekcie poza czujnikiem temperatury dodatkowo skonfigurowaliśmy odczyt informacji nt. zamka otwieranego pastylką RFID (zapisy GRANTED/DENIED):
Nasza platforma jest już gotowa. Na razie oczywiście pełni bardzo podstawowe funkcje, ale możliwości jej rozbudowy zarówno po stronie tego, co może wspierać Domoticz, jak i możliwości Arduino są w zasadzie ograniczone budżetem i czasem potrzebnym na dalsze zgłębianie tajników mikrokontrolerów AVR.
Za opracowanie i opublikowanie tego artykułu otrzymujemy wynagrodzenie.
Komentarze
Atmel AVR (Automatic Voltage Regulator) – make my day :-D
no trochę fantazja poniosła autora z tym Automatic Voltage Regulator :D
Twoja nieznajomość angielskiego również zrobiła mi dzień :P
Jemu to powiedz: https://www.youtube.com/watch?v=3ishbTwXf1g :-D
Atmel AVR to nie jest skrót od Automatic Voltage Regulator. AVR to rodzina mikrokontrolerów Atmela i nie rozwija się tego jako skrót (historycznie mogło to być skrótem, ale nie od regulacji napięcia)
Pierwsze wersję stworzyło dwóch studentów z Norweskiej Wyższej Szkoły Technicznej (Alf-Egil Bogen, Vegard Wollan). Od ich nazwisk wzięło się: Alf and Vegard’s RISC processor.
Problemem dla mnie zawsze bylo zasilanie – ciezko upchnac gotowe uklady w sciane (a zabezpieczenie pradowe, a zeby to wygladalo?), a i wymieniac baterie od arduino co jakis czas tez glupim rozwiazaniem – choc pewnie prostszym…
Prawda, na szczęście są już rozwiązania które można wpinać w jedną fazę (jeden drut)
Jedna faza kolego potrzebuje DWÓCH drutów.
Cześć mikrokontrolerów pobiera znikome ilości prądu, a nie które potrafią przejść w stan uśpienia. Odpowiednie oprogramowanie układu powinno wydłużyć czas życia na baterii.
Sensowne rozwiązanie to akumulator + panel słoneczny do ładowania, wymaga dodatkowej elektroniki i oprogramowania.
Można próbować: esp8266 D1 mini + przekaźnik SSR + HLK-PM01 220V-5V. To już powinno się zmieścić.
Switch ethernet PoE > PoE splitter > Ethernet shield > Arduino
Projektując dom lub robiąc generalny remont należy rozłożyć po każdym pokoju od 1-4 kable ethernet Cat5 i przynajmniej 1-2 Cat7
Zasilacz/switch PoE należy podłączyć pod 220V, inverter i panele fotovoltaniczne lub 12v z regulatorem napięcia. Warto użyć także wiatraka i diody prostowniczej trójfazowej
Można też użyć UPS żeby w nocy w razie braku słońca i wiatru ciągnąć z baterii UPS
Najnowsze zasilacze PoE mogą przesłać 70-100W prądu ( np. maly telewizor lub Hi-Fi, mniejsze rekuperatory), starsze około 12-15W ( panel dotykowy, kamera internetowa, sterowanie roletami, sterowanie PWM wiatrakami zasilanymi z sieci)
ESP 8266 lub ESP 32 też jest ciekawym rozwiązaniem na start w mikrokontrolery.
Hmm, sam nie wiem czy tego typu artykuły są bardziej reklamą czy antyreklamą. Z jednej strony fajnie, ze ktoś porusza taki temat. Z drugiej jest tu tyle niedociągnięć technicznych, przekłamań czy bzdur (jakiś link do źródła rozwinięcia skrótu AVR?) ze szkoda już wyliczać.
Czy może być coś głupszego jak zarządzanie domem poprzez chmurę?
@John Sharkrat
Czy chodzi Ci o to, że a) każdą chmurę można zhakować, b) da się zrobić automatykę domową bez chmury, c) automatyka domowa jest ogólnie bez sensu, d) jedyną słuszną automatyką domową jest żona/dzieci? ;) („- Obywatelu kapralu, kiedy wynalezione zostaną maszyny do obierania ziemniaków? – Zostały wynalezione, i Wy, szeregowy Kowalski, jesteście najnowszym modelem”)
Chodzi mi o to, czym napisałem w tym prostym i wydawałoby się zrozumiałym zdaniu.
@John Sharkrat
Wiem, to była taka zaczepka :(
Serio promujecie Arduino? Z3s zawsze trzymało poziom, a tu taki klops.
Można prosić o uzasadnienie i rozwinięcie myśli?
automatyzacja domu przez arduino to jak budowanie domu z klocków lego
OK, w tym kontekście się zgadzam. Myślę, że tutaj bardziej chodziło o pokazanie jak prosto i tanio można coś zrobić. Myślę, bo ten artykuł jest pełen kardynalnych błędów i uproszczeń, przez co jest zupełnie nieprzydatny :-)
Arduino to widzę sens do zaprototypowania logiki, żeby potem wymienić na adekwatniejsze podzespoły
O wiele tańszym rozwiązaniem niż arduino jest Tasmota na ESP8233. Są dostępne gotowe moduły wykonawcze na które można je wgrać (Sonoff), można tez w prosty sposób złożyć stacje z czujnikami i elementami wykonawczymi korzystając z modułów Wemos. Całość komunikuje się po wbudowanym WiFi, więc nie trzeba kombinować z dodatkowymi modułami radiowymi. Dostępne są tez moduły montowane w puszkach w ścianie (Shelly). Sonoff i Shelly są zasilane bezpośrednio z sieci, więc nie trzeba się martwić o wymianę baterii.
Do komunikacji potrzebny jest jeszcze broker MQTT, ale wszystko jest gotowe w paczkach, i może działać na tym samym serwerze co Domoticz (ew. można postawić na małym komputerku gdzieś w sieci domowej).
Automatyka domowa. Temat rzeka, często bardzo odległy od współczesnej automatyki przemysłowej, coś jak automatyka bramowa. Na dzień dzisiejszy ma to sens tylko w budynkach niejednorodzinnych. Dom to poważna sprawa – stoi kilkadziesiąt lat. Arduino – fajna zabawka, mikrokontroler w przystępnej formie. Do sterowania akwarium ok, ale do domu, który ma stać kilkadziesiąt lat?
Raczej mało jest jeszcze jakichkolwiek automatyk wytrzymujących kilkadziesiąt lat. Jest jeszcze na chodzie coś z lat 60 ubiegłego tysiąclecia?
Jakakolwiek elektromechanika po góra 10 latach wymaga wymiany. Co nie zmienia oczywiście faktu, że robienie na ArduinoUno „na kabelkach” raczej nie jest ani zbytnio szczęśliwe, ani tym bardziej trwałe. To bardziej na sprawdzenie idei, jak ktoś traktuje taki „inteligentny” dom zrobić, to jednak bez płytki, obudowy i konkretnego zasilania to tylko zabawa.
Naprawdę? To jakim cudem jeżdżą ci samochody mające po 20-30 lat np. Audi 200 czy Audi V8 czy Mercedes 600S? Jakim cudem mój ojciec ma instalację inteligentnego domu z 1994 rok i to działającą do dzisiaj i to bezawaryjnie? Może wymienił ze dwa przekaźniki chociaż o to bym się nie założył. Włączniki na ścianie wymieniał ze względu na remonty i przestarzały wygląd. Moja działa od 2008 bez problemu.
Widzisz różnicę pomiędzy „kilkadziesiąt” a „od 2008”? :-) A w Audi 200 też pewnie nic od początku nie robione?
A rozumiesz, że 25 czy 30 lat to już kilkadziesiąt? W samochodach głównie robi się mechanikę, ewentualnie silniki nawiewu, alternator, i rozrusznik. Mówiąc o samochodach mówiłem, że takie jeżdżą, a nie że posiadam tak stare samochody.
Przy czym w domu masz na ogół temperaturę 15-30 st, a w samochodach od -30 do ponad 100 st. a i tak elektronika pada w nich sporadycznie.
Zgodnie z twoimi teoriami to ŻADEN samochód starszy niż 10 lat nie ma prawa działać.
To samo w inteligentnych domach opartych o normalne systemy renomowanych dostawców jak np Gira, ABB czy JUNG.
Dlaczego miąłbym wymieniać moduł mający obciążalność 2000W, który włącza oświetlenie 500W?
To nie ja napisałem, że elektronika wymaga wymiany po 10 latach.
OK, to może podpowiedzcie Koledzy @Wiktor @Morris @John Sharkrat, bo mam właśnie do czynienia z budynkiem dwurodzinnym, w którym w latach 90-tych zostały zrobione pewne elementy automatyki, z których niektóre zostały niedokończone, inne zdążyły się popsuć (o czym właściciel się przekonał, kiedy brama skasowała mu auto), a do żadnych nie ma dokumentacji. Ja byłbym zwolennikiem wyprucia wszystkiego i zrobienia całkowicie od nowa (oczywiście bez chmury), ale właścicielowi szkoda, bo się przywiązał. Jest sens w tym grzebać, czy poczekać na większą katastrofę?
Znaczy się chcesz mu zrobić dobrze czy tego chce czy nie, a na końcu jeszcze kazać sobie zapłacić? ;]
Każdą instalacje trzeba konserwować, w nowej też może czujnik nie zadziałać. Nie ruszałbym dopóki instalacja nie stwarza zagrożenia a koszty serwisowe nie są duże.
@adrb
He he, chciałbym, ale na aż taki efekt nie liczę :D W sensie nie sądzę, że nagle akurat mi na tyle zaufają, że dadzą zrobić i zapłacą. Nie mam takiej charyzmy.
Ale i tak muszę się z tym nieszczęsnym budynkiem spotykać (nie każcie wyjaśniać, na trzeźwo się nie da). I niektóre jego absurdy biją po kieszeni mnie (do wyjaśnienia tego musiałbym upić się mocno), więc trochę próbuję z nimi walczyć. Chcę przynajmniej w głowie sobie ułożyć opinię na ten temat, moje stanowisko negocjacyjne ;) Do tego muszę zrozumieć możliwe drogi wyjścia z sytuacji, ocenić ich wykonalność i opłacalność, zebrać argumenty, itp.
Zaciekawiła mnie tutejsza dyskusja na temat trwałości systemów automatyki. Bo ja mam tendencję konserwować systemy, ale w pewnym momencie koszt obsługi długu technologicznego robi się za duży – i chcę wychwycić ten moment.
Co do niestwarzania zagrożenia, sprawa jest dyskusyjna. Oprócz bram polujących na auta & zwierzęta są też rażące prądem poręcze schodów itp niespodzianki.
Ta automatyka to samoróbka czy coś znanego?
@John Sharkrat
Dobre pytanie. Z dotychczasowego rozpoznania wygląda, że elementy były zamawiane w lokalnych firmach które się polikwidowały, a te firmy czasem używały coś znanego (jakieś ABB np widzę, ale to mniejszość), czasem nonejmowego na zasadzie „będzie pan zadowolony”. Ogólnie totalna mozaika, każda rzecz ma swoją centralkę, centralki nie działają itd. Kable w budynku kładł syn właściciela i ten kręgosłup systemu wygląda jeszcze najprzyzwoiciej, ale do tych kabli każdy fragment automatyki (zawory, pompa, bramy, itd) podłączał inny lokalny dostawca, który chyba nie w każdym przypadku wiedział co robi.
@wk moja rada zostaw.
A tak z ciekawości to co planowałeś mu zainstalować?
@John Sharkrat
>>@wk moja rada zostaw.
>>A tak z ciekawości to co planowałeś mu zainstalować?
Ciężko opisać bo za moment wszyscy rzucą się mi tłumaczyć jak bardzo jestem głupi, a ja sam wbrew pozorom dość nieźle zdaję sobie z tego sprawę, tylko że świadomość tego nie rozwiązuje problemu ;/
Jak już wyżej po kawałku napisałem, sytuacja jest dość chora, a ja miałbym chęć ją rozwiązać technicznie, bo dyplomacją już próbowałem bez skutku. Głównie to chciałbym uzyskać kontrolę nad tymi systemami, czyli ustanowić możliwość komunikacji z maksymalnie wieloma z nich na wspólnym czytelnym interfejsie. Intuicyjnym wyborem dla mnie byłoby postawienie do tego jakiegoś lapka z linuxem i coś jak openHAB (o tej logice, tylko w tym przykładzie akurat Java średnio mnie zachęca).
Ale tak, wszyscy macie rację, że można się z tym urobić i nic nie osiągnąć, po czym jeszcze być obwinionym o rzekome zepsucie (tak jakby którykolwiek z tych podsystemów nie był zepsuty już teraz).
Dobra, nie było tematu.
Powiem krótko – nie dasz rady, bo nie masz kwalifikacji i doświadczenia. Tak jak nie zrobisz z Trabanta luksusowej limuzyny, a kogoś z aspergerem kierowcą F1.
Nie ma znaczenia jakie masz układy, bo problem leży w twoich umiejętnościach i pieniądzach.
Zaproponuj im proste operację, niech poszukają kogoś innego do realizacji swoich pomysłów, ale tylko w celu, aby poznali opinie i ceny z jakim to się wiąże u ludzi z doświadczeniem, którym doprowadzenie do stanu używalności zajmie z 5x mniej czasu niż tobie, a efekt końcowy będzie z 10x lepszy.
Poza tym nie wierzę, że w instalacji z lat 90 wszystko było połączone.
Brama nie działa, to wymieniasz, sterownik, piloty czujki nie muszą być od tego samego producenta, co zainstalowane. Jedyne co musi się zgadzać to sterowanie siłownikami. Siłowniki masz na 12V,24V i 230V. Najlepiej wymienić wszystko.
Jak można się przywiązać do siłownika otwarcia bramy?
@John Sharkrat
Ale jak to – ja nie dam rady?!? (żart)
Przede wszystkim dziękuję Ci za poświęcenie czasu na rozmowę ze mną, dla mnie to jest naprawdę pomocne, bo pozwala mi spojrzeć na sprawę z innego punktu widzenia.
Z pięciu wymienionych przez Ciebie rzeczy; kwalifikacje, doświadczenie, umiejętności, układy, pieniądze – najłatwiej mi upgrade’ować umiejętności (a poprzez nie – doświadczenie). To taki dodatkowy ficzer tych osób, które nie miałyby szans zostać kierowcami F1 ;) Dlatego w ogóle zadałem sobie pytanie, czy i co mógłbym zrobić z tym skansenem, w którym przez nieuwagę utknąłem. A Ty i @ardb zadaliście ważniejsze pytania – czy warto, czy właściciel posługuje się logiką, i czy to moja sprawa. Na dwa pierwsze pytania odpowiedź na pewno brzmi „nie”. Na trzecie – „to zależy”. W związku z tym nie zacznę tej roboty, a spróbuję głębiej przemyśleć, od czego zależy, czy to moja sprawa ;( Dziękuję.
„Jak można się przywiązać do siłownika otwarcia bramy?”
Zwykła gadka jak ktoś nie chce wydać mamony. Jeżeli właściciel nie chce wymienić nawet czujki przy bramie za parę złotych to na jakieś grubsze prace nie ma co liczyć. Można jeszcze pójść kierunku wyliczenia mu kosztów naprawy auta itp. – jak do rozsądku nie da się odwołać to może do chciwości ;]
btw: openhab jest jednym z lepszych darmowych kontrolerów, a javy nie ma się co bać (na javie embedded openhab bierze jakieś 40mb pamięci) odpalisz to na wszystkim co obsługuje linuksa
@adrb
Dzięki :)
Akurat jeżeli chodzi o łączność, szedłbym w rdzenie Espressif np. ESP8266. Ponieważ ktoś wyniósł papiery z fabryki, jest pod to kompilator i Arduino, a Wifi jest wbudowane. Dokładanie pełnego stosu TCP do Atmegi328 tylko dlatego by wysyłać dane to marnowanie potencjału, one powinny się zajmować czymś innym.
Dodatkowo zawsze po zrobieniu i sprawdzeniu prototypu na Arduino Uno, robimy na stykowej pełny układ bez płytki Arduino (z samym uC), po czym najlepiej by było gdyby przenieść to na osobne PCB. Dzięki temu mamy znacznie lepszą odporność na uszkodzenia
Au. „Najbardziej optymalne” rozwiązanie? RLY?
Zawiodłem się. Jako praktyk w zakresie amatorskiego smart home. Zabawy z arduino są dla 10-latków. Minimum to moduły typu sonoff na esp8266 czy shelly do puszek. Domoticz na VPS? Raczej na raspberry pi, bezpieczniej i bez uzależnienia od połączenia internetowego. Poza tym są ciekawsze alternatywy jak openhab czy home assistant.
Dokładnie. Poza tym skoro ktoś bawi się amatorskie, hobbystyczne rozwiązania, to nie będzie stawiał serwera w chmurze, bo go zwyczajnie nie stać. A ten co ma kasę kupi jakiegoś gotowca.
Arduino i dodatki po 20€?
Sonoff dla mało obeznanych z elektroniką albo ESP8266 i nawet gotowe moduły do niego, możliwości (szybszy procesor itp) dużo większe za 1/3 ceny.
Artykuł napisany trochę tak, jakby autor zatrzymał się z wiedzą o mikrokontrolerach i IoT 5 lat temu.
1. AVR stands for „Alf (Egil Bogen) and Vegard (Wollan) 's Risc processor” (https://web.archive.org/web/20120623131604/http://www.cse.unsw.edu.au/~pcb/avr/avr.html)
2. Nie rozumiem tego stwierdzenia:
„Zaletą komunikacji wykorzystującej tę częstotliwość [433 MHz] jest większy niż w przypadku pasm 2.4/5 GHz zasięg działania i lepsza odporność na zakłócenia. Jest to możliwe dzięki stosunkowo wąskiemu kanałowi komunikacyjnemu (25 kHz), przez co przepustowość transmisji danych jest znacznie ograniczona.”
Ad2.
Zdanie „Jest to możliwe dzięki” jest nie do końca poprawnie sformułowane.
Przy niższej częstotliwości sygnał jest mniej tłumiony więc można go odebrać z większej odległości przy tej samej mocy nadajnika. Minusem jest, to że niższa częstotliwość wymusza użycie kanału o mniejszej szerokości/przepustowości.
2019 i Domoticz? Ehh. No bez żartów.
Dokładnie, widzenie Domoticza razi oczy. W niemal 2020 to wręcz skandal że ten projekt jeszcze istnieje przy Home Assistancie czy OpenHABie.
„najłatwiej mi upgrade’ować umiejętności (a poprzez nie – doświadczenie). ” – a jak zamierzasz je zdobyć? Poprzez czytanie i wykonanie jednej instalacji? Chcesz zdobyć doświadczenie? Zatrudnij się w firmie robiącej takie instalacje na 3 miesiąca i pracuj tam nawet za darmo. To ci więcej da niż przeczytanie wszystkich bredni na temat inteligentnych budynków na elektrodzie i obejrzenie wszystkich filmików na youtube.
Jeśli wymienisz instalację na nową, to wykonana przez ciebie instalacja za 10 lat będzie w tym samym miejscu co jest teraz czyli wszystko do wymiany, a następny gość będzie zastanawiał się co się tu odpier…
Jak chcesz zając się IB/ID, to będziesz musiał wydać kilka tysięcy PLN na szkolenia, plus uprawnienie elektryczne. Tylko płatne szkolenia mają jakąś wartość merytoryczną.
tak z ciekawości.. mógłbyś rozwinąć skrót IB/ID? :)
@John Sharkrat
To są konstruktywne pomysły, ale aktualnie mnie na nie nie stać – ani na pracę przez kilka miesięcy za darmo, ani na komercyjne szkolenia. „Nie dla sławy, lecz dla pieniędzy / siedzę tutaj i pompuję zęzy” ;) I powiedzmy, że między innymi w wyniku tej dyskusji zdecydowałem się skoncentrować wysiłki na lepiej rokujących tematach. Pozdrawiam.