Przeszukaj forum

Witam, chciałbym zrobić domowy Webserver na Raspberry Pi Zero W, napisany w Node.js. O ile potrafię pobrać dane z bazy danych za pomocą Node'a, nie wiem w jaki sposób miałbym przekazać dane z czujników podłączonych do Arduino, do RPi. Przykład: Mam czujnik tempratury Dallas, Arduino, oraz moduł WIFI (ESP8266), lub też Ethernet (Enc28j60). Bez problemu umiem pobrać dane z czujników i wyświetlić je klasycznie w monitorze portu szeregowego, ale jak przekazać je do RaspberryPi, tak aby dało się je pobrać za pomocą Node'a (konkretnie). Preferuję komunikację bezprzewodową, ale jakikolwiek sposób na start naprawdę by mnie zadowolił. Jestem również bardzo otwarty na propozycje, jedyna rzecz przy której się trzymam to Webserver napisany w Node.js Byłbym bardzo wdzięczny za podanie bibliotek, różnych sposobów komunikacji, oraz gotowych przykładów.

Witam, jaki jest najlepszy sposób na przesłanie danych z czujnika (załóżmy temperatury, Dallas) do Arduino. Chciałbym bezprzewodowo wysłać dane z czujnika do Arduino żeby później przekazać je Raspberry Pi. Czy mógłby mi ktoś konkretnie wytłumaczyć jak mógłbym zrobić to z ESP8266, lub NRF24l01?

Elektroniczny Multitool Jak się zaczęło? Ano zaczęło się od tego, że zanabyłem sobie hulajnogę elektryczną. Długo i sumiennie przeglądałem różne recenzje, opisy, wertowałem informacje, aż w końcu zdecydowałem się na Airwheel Z5 Strong, którą na marginesie polecam. Pomimo wielu zalet - w tym kilku rozwiązań unikalnych w tym segmencie urządzeń, jak na przykład wygodne podesty albo łatwo wymienny akumulator - ma jednak pewną niewielką wadę: brak wyświetlacza informującego na przykład o bieżącej prędkości czy o przejechanej drodze. Ponieważ od jakiegoś czasu bawię się Arduino, stwierdziłem, że stosunkowo łatwo powinno dać się skonstruować taki licznik samodzielnie - wystarczy przecież zastosować GPS, który uniezależnia mnie od rozwiązań zastosowanych w hulajnodze. Zacząłem więc powoli kolekcjonować wszystkie niezbędne komponenty. Wyświetlacz Zacząłem trochę nietypowo, bo od wyświetlacza. Zrobiłem już kilka projektów na wyświetlaczach znakowych, ale - oczywiście - nie dają one takich możliwości, jak solidny, kolorowy, a najlepiej dotykowy wyświetlacz. Mój wybór padł na dotykowy wyświetlacz 2.4", pracujący z rozdzielczością 320x240 i komunikujący się przez popularny protokół SPI. Mój wygląda nieco inaczej niż ten w sklepie, ale różnią się płytką z kontrolerem, wyświetlacz jest ten sam. Kontroler Obejrzałem sobie sporo filmików dotyczących podłączania wyświetlaczy do Arduino i uderzyło mnie to, że w większości przypadków liczba klatek na sekundę osiągała bardzo często wartości jednocyfrowe. Jest to zrozumiałe - wszelkie Uno, Leonardo, Micro i tak dalej są taktowane ze stosunkowo małymi częstotliwościami, a przynajmniej zbyt małymi, by osiągnąć zadowalające rezultaty graficzne. Dlatego tym razem porzuciłem całę rodzinę *ino na rzecz chyba nieco mniej znanego kontrolera, Teensy 3.5. Kosztuje swoje, ale dostajemy naprawdę ciężką artylerię: 120 Mhz, 512 kB Flash, 192 kB RAMu, 62 piny, zintegrowany zegar czasu rzeczywistego (trzeba go tylko zasilić bateryjką CR2032), czytnik kart microSD i oczywiście możliwość programowania przez micro USB, bez konieczności stosowania programatorów. Polecam, korzystanie z takiego kombajnu to naprawdę czysta przyjemność. GPS Ta decyzja była stosunkowo prosta, zdecydowałem się na rozwiązanie ekonomiczne i kupiłem prosty GPS komunikujący się przez UART (szeregowo). Przyznam szczerze, że po zakupie Teensy trochę szkoda było mi poświęcić taki świetny kontroler li tylko na licznik do hulajnogi. Dlatego zanabyłem jeszcze popularny czujnik pogodowy BME280 i stwierdziłem, że w czasie, gdy nie będę korzystał z urządzenia jako licznika, zrobię z niego małą stację pogodową. Na wyposażeniu urządzenia znalazł się również czujnik położenia MPU9250, bo zamierzałem napisać rejestrator pochyłości podłoża (i ewentualnie również jego jakości), ale w końcu z tego pomysłu zrezygnowałem. Być może za jakiś czas dopiszę sobie do urządzenia cyfrową poziomicę. Konstrukcja Zacząłem od płytki prototypowej, która błyskawicznie zamieniła się na totalnie zagmatwaną pajęczą sieć przewodów kydexowych. Myślałem na początku, że poprzestanę na niej, ale plątanina ta wyglądała tak dramatycznie, że z pomysłu w końcu zrezygnowałem, traktując go tylko jako prototyp. Sprawdziłem, czy wszystkie urządzenia będą pracowały prawidłowo i generalnie każdy moduł udało mi się uruchomić i pobrać z niego dane, z tym wyjątkiem, że BME280 i MPU9250 odmawiały współpracy podłączone do jednej szyny I2C. Szczęśliwie Teensy oferuje tych szyn chyba z pięć, więc przepiąłem BME na inną i wszystko wstało bez problemu. Kiedy wszystko działało, siadłem do Eagle'a i zaprojektowałem PCB, który miał zastąpić tę nieszczęsną płytkę prototypową. W Polsce jest kilka firm, które wykonują nawet pojedyncze sztuki takich płytek, a moją zamówiłem w firmie Satland Prototype. Musiałem poczekać dwa tygodnie, ale w końcu płytka doszła pocztą i mogłem zacząć lutować. Jakiś czas temu wyposażyłem się w drukarkę 3D, więc po zlutowaniu (i uruchomieniu) wszystkiego siadłem do Fusion 360 i zaprojektowałem obudowę na całe urządzenie. Zadbałem o to, żeby BME został odseparowany wewnętrzną ścianką od reszty urządzenia, bo ekran LCD potrafi się grzać i zafałszowuje odczyty. GPS zamocowałem w osobnym miejscu, wsunięty w odpowiedni slot i zabezpieczony ścianką z drugiej strony, ponieważ niestety wersja, którą kupiłem, nie posiadała żadnych otworów montażowych. Płytka z komponentami siedzi w przygotowanym na jej wymiary wgłębieniu i jest ściśnięta pomiędzy dwiema częściami obudowy, więc nie ma możliwości się przesunąć. Do tego otwór na wyświetlacz, siateczka w przedniej ściance przepuszczająca powietrze do czujnika pogodowego i tyle. Słowo komentarza, bo pewnie padnie takie pytanie: schemat dotyczy nowej wersji płytki z usuniętym radyjkiem NRF, na zdjęciu jest starsza wersja - szczegóły na końcu artykułu. Programowanie Proces programowania musiałem rozłożyć w czasie, ale projekt szedł powoli do przodu. Zacząłem od części pogodowej, ogrom miejsca w programowalnej pamięci kontrolera pozwolił mi poszaleć, więc przygotowałem sobie w C++ klasy odpowiedzialne za obsługę interfejsu użytkownika, spięcie różnych modułów w jedną całość, wyświetlanie grafiki i tak dalej. Również i tym razem dałem się ponieść - nie mogłem znaleźć w Internecie dobrego programu do generowania czcionek w formacie zrozumiałym dla biblioteki ILI9341_t3 przygotowanej przez twórcę Teensy (działa ona szybciej od regularnej biblioteki), a zależało mi na czcionce siedmiosegmentowej - takiej trochę "retro" (widać na screenach). Zapytałem więc Paula o kilka rzeczy, siadłem któregoś wieczoru i wyrzeźbiłem edytor czcionek dla ILI9341_t3. Mój prosty programik może się podobać lub nie, ale najlepszą alternatywą jaką znalazłem jest gigantyczne makro w Excelu, więc sami rozumiecie... Dużym odkryciem było dla mnie, że na platformę Arduino można już programować w Visual Studio Code - Arduino Studio jest wciąż wymagane (bo zawiera wszystkie narzędzia potrzebne do zbudowania programu dla kontrolerka), ale tak naprawdę wszystkie operacje - budowanie, wrzucanie na płytkę, monitor portu szeregowego - można już obsłużyć bezpośrednio w tym świetnym środowisku. Tylko że... niestety Teensy nie jest całkowicie zgodne z Arduino i do budowania na tę platformę potrzebny jest dodatkowy programik, Teensyduino, który nieco modyfikuje Arduino Studio i nie jest kompatybilny z VS Code. Tym niemniej, większość developmentu zrealizowałem w tym ostatnim, jedynie budując i wrzucając aplikację na urządzenie przy pomocy AS. Zastosowałem też własny mechanizm podwójnego buforowania: cały obraz buduję w RAMie i wyświetlam go hurtem w jednym kroku. Ogranicza to trochę lag związany z wyświetlaniem poszczególnych elementów, opóźnienie wciąż jest, ale jest znacznie mniej zauważalne. Kosztowało mnie to prawie połowę pamięci RAM, ale z uwagi na to, że pozostałe komponenty aplikacji prawie go nie zużywają, mogłem sobie na to pozwolić. Źródła trzymam na Gitlabie, chcecie obejrzeć - sklonujcie sobie repo. Efekt W chwili obecnej płytka w trybie stacji pogodowej wyświetla klasycznie: temperaturę, ciśnienie i wilgotność, a także wykresy: bieżący (jasna linia - jeden piksel to 15 sekund) i historia - 1h, 8h lub 24h wstecz.Tryby można przełączać po dotknięciu ekranu - pojawia się wtedy proste menu. Aplikacja wyposażona jest w wygaszacz ekranu, który zapobiega wypaleniu pikseli - szczególnie, że w trybie stacji pogodowej bardzo dużo z nich mogłoby być na to narażone. Po 30 sekundach ekran się wyłącza (wygasza), a włącza ponownie po dotknięciu. Niestety nie udało mi się wyłączyć jego podświetlenia - doczytałem, że w tym ekranie programowo nie da się tego zrobić. Szkoda. W trybie GPS wyświetlane są na razie podstawowe informacje wczytane z odbiornika: prędkość, wysokość n.p.m., kierunek jazdy, liczba satelit, z których odczytywane są dane oraz położenie geograficzne - długość i szerokość. Za jakiś czas dopiszę pewnie tryb "rowerowy", czyli przebyta droga, średnia i maksymalna prędkość i tak dalej. Aplikację mam napisaną na tyle modularnie, że teraz taki moduł mogę już sobie praktycznie niewielkim kosztem poskładać "z klocków". Problemy Człowiek uczy się na błędach, a mądry człowiek na błędach innych. Podczas rozwijania tego projektu nadziałem się na mnóstwo problemów, więc podzielę się moimi rozwiązaniami - być może komuś oszczędzi to czasu i nerwów. Po pierwsze, zasilanie - w dwóch odsłonach. Pierwsza odsłona - pierwotnie na płytce znajdowało się jeszcze radyjko NRF24, ponieważ jakiś czas temu zbudowałem sobie "satelitę" - małą płytkę z czujnikiem temperatury i wilgotności zasilaną z bateryjki CR2032: miałem nadzieję, że w trybie stacji pogodowej urządzenie będzie również ściągało informacje z tego źródła. Testy bez GPSu wypadły pozytywnie - to widać na zdjęciach - ale po podłączeniu wszystkiego i włączeniu zasilania, ekran rozbłysł na chwilę, a potem powolutku przygasł i zgasł całkowicie. Podejrzewałem od razu NRF, chciałem go rozlutować, ale w trakcie tego procesu oderwałem jeden pad na płytce, więc nie miałem już możliwości łatwego sprawdzenia, czy to on jest winien. Żeby uniknąć dalszych uszkodzeń, podrzuciłem płytkę ojcu, który w pracy ma wysokiej klasy rozlutownicę, a ja zaprojektowałem w międzyczasie drugą, tym razem już bez NRFa. Warto zawsze sprawdzić, czy uda się zasilić wszystkie komponenty - ja leniwie pociągnąłem zasilanie wszystkiego z płytki, a mogłem przecież wstawić na płytkę port microSD i pociągnąć dodatkowe ścieżki bezpośrednio z niego - wtedy obciążyłbym zasilacz (który pewnie nawet by nie sapnął), a nie samą płytkę. Druga kwestia - hulajnoga, którą kupiłem, ma w baterii wyjście USB - można (według instrukcji) doładowywać sobie na przykład komórkę (traktować akumulator jako powerbank). Również do tego portu podłączana jest latareczka, którą można sobie włączyć podczas jazdy. Niestety podczas prób terenowych okazało się, że przysiad napięcia podczas rozpędzania jest tak duży, że płytka gaśnie albo się zawiesza. Musiałem więc zasilić ją z osobnego powerbanku, w przyszłości pomyślę nad zasileniem płytki z osobnego akumulatora albo po prostu baterii. Teraz BME280 - małe ostrzeżenie. Układzik jest rewelacyjny, malutki i stosunkowo dokładny... ale się grzeje! Potrafi rozgrzać się na tyle, że zafałszowuje informacje o temperaturze o 1.5-2 stopnie. Rozwiązanie (proponowane nawet przez Boscha) polega na zmniejszeniu dokładności pomiaru (urządzenie może działać w trybie oversampling, czyli robi np. 8 pomiarów i uśrednia - należy to wyłączyć), wyłączeniu filtrowania (które również poprawia jakość pomiarów), przełączyć się w tryb "forced" - wtedy płytka robi pomiar tylko na życzenie - i ograniczyć pomiary do jednego na minutę (!). Ja nie ograniczyłem się tak bardzo, pomiary mam co 15 sekund, ale mimo wszystko układ się grzeje i na początku na wykresie widać delikatny skok temperatury, który po chwili się stabilizuje. Jest również prawdopodobne, że grzeje się nie tyle BME, co wyświetlacz - podobny problem miałem w innej stacji pogodowej z wyświetlaczem znakowym. Tam temperatura skakała do góry o kilka stopniu po uruchomieniu. Kwestia estetyki - nie zadbałem o to, żeby schować obramowanie ekranu z widocznymi ścieżkami panelu dotykowego. W innych projektach nie popełniam już tego błędu, widoczny jest sam ekran (wygląda to o niebo lepiej). Ogólnie jednak jestem zadowolony, płytka jest rozwojowa, a nowe funkcjonalności mogę dodawać programowo, więc podejrzewam, że wzbogacę ją jeszcze o kilka dodatkowych trybów pracy.