W trzeciej, ostatniej części opisu projektu budowy amatorskiej stacji meteo poruszę następujące zagadnienia:
- konfiguracja naszego domowego routera (wpuszczamy ruch z sieci Internet do Raspberry pełniącego rolę serwera WEB),
- podpięcie dowolnej nazwy domenowej z dynamicznym DNS,
- instalacja certyfikatu SSL Let’s Encrypt,
- konfiguracja SSL na naszym Raspberry Pi.
Poprzednie części opisu:
- Solarna stacja meteo z wykorzystaniem Wemos D1 mini Pro oraz Raspberry Pi 3 B+ – część 1
- Solarna stacja meteo z wykorzystaniem Wemos D1 mini Pro oraz Raspberry Pi 3 B+ – część 2
Dane pomiarowe ze stacji:
https://malinowemeteo.zgora.pl
Podstawowym warunkiem pozwalającym na udostępnienie danych z naszej stacji meteo jest posiadanie stałego dostępu do sieci Internet z dynamicznym lub statycznym publicznym adresem IP. Takiego warunku na pewno nie spełniają operatorzy komórkowi (chyba że dokupicie opcję publicznego adresu IP) oraz wielu małych operatorów sieci osiedlowych.
Ja korzystam z dostępu do sieci Internet od UPC – ten operator przydziela dynamicznie publiczną adresację IP. Nie korzystam też z urządzenia dostępowego (“modemu” kablowego) operatora funkcjonującego jako router. Na “modemie” od UPC mam ustawiony tryb Bridge. Dzięki temu na pierwszym porcie LAN “modemu” otrzymuję publiczny adres IP, który następnie “natuję” na własnym routerze. Takie rozwiązanie jest mi potrzebne ze względu na konieczność zestawionych tuneli VPN “site to site”, a router od UPC nie posiada takich możliwości konfiguracyjnych. Dodatkowo własny, w miarę dobry router ma zdecydowanie więcej innych, przydatnych funkcji w porównaniu z urządzeniami od providerów internetowych.
Jeśli chodzi o szybkość łącza, to podstawowe znaczenie ma wartość Upload naszego łącza. W moim przypadku jest to 10 Mb/s. Dla Raspberry, ze względu na jego wydajność w zupełności wystarczy ok. 1 Mb/s.
Przepuszczamy ruch z sieci Internet do naszego serwera WEB
Aby nasza strona www z danymi pomiarowymi hostowana na Raspberry Pi była widoczna w Internecie, musimy przepuścić odpowiedni ruch na naszym domowym routerze. W opcjach konfiguracyjnych routera musimy poszukać opcji Virtual Server / Port Forwarding. Standardowo usługi WEB działają na porcie 80/TCP oraz 443/TCP https. Musimy więc zezwolić na ruch na tych portach do naszej “malinki”.
Dopuszczamy więc taki ruch do adresu IP naszego serwera Raspberry w naszej lokalnej sieci LAN (jak na poniższym przykładzie mojego routera).
Aby sprawdzić, czy działa już dostęp do naszych stron hostowanych na Raspberry Pi w naszej sieci LAN, wystarczy sprawdzić, jaki jest nasz aktualny publiczny adres IP (np.: http://www.ip.pl/m_mojeip_sprawdzip.htm), a następnie, najlepiej na smartfonie z wyłączonym Wi-Fi (ale z włączoną transmisją danych od operatora komórkowego) wpisać w przeglądarce http://nasz.publiczny.adres.ip. Powinniśmy ujrzeć stronę hostowaną na Raspberry Pi.
Podpięcie dowolnej nazwy domenowej do naszego serwera z dynamicznym IP
Jak pewnie zauważyliście, moja strona z danymi ze stacji pogodowej dostępna jest w sieci Internet pod nazwą domenową: https://malinowe.meteo.zgora.pl. Należy więc wykupić u dowolnego dostawcy domen wybraną przez siebie nazwę domeny. Ja wszystkie swoje domeny kupuję i utrzymuję w firmie Netmark. Mają przyzwoite ceny – powyższa domena to koszt 6,15 PLN za pierwszy rok i 23,37 PLN za odnowienie na rok czasu. (Uwaga! Link do firmy Netmark zawiera mój kod do programu partnerskiego – jeśli zdecydujecie się na zakup dowolnych usług w tej firmie, ja będę miał z Waszego zakupu punkty w programie partnerskim).
Ponieważ mój provider nie zapewnia mi stałego, publicznego adresu IP, potrzebuję wykorzystać do tego celu usługę dynamicznego DNS (DDNS) z możliwością podpięcia własnej domeny. Na rynku jest wiele płatnych rozwiązań do tego typu potrzeb. Najbardziej znanym jest http://no-ip.org (obecnie przejęty przez Microsoft). Rozwiązanie jest o tyle dobre, że ma dużo poradników i właściwie po 5 minutach uzyskujemy domenę od nich (.ddns.net, bądź inną darmową). Raz na 30 dni musimy potwierdzać aktywność naszego hosta + specjalnym programem co określony czas dajemy „znać” serwerowi DDNS o naszym nowym adresie IP. Niestety, podpięcie własnej domeny nie jest darmowe i jest to koszt 35 dolarów na rok. Szukając bezpłatnych alternatyw natrafiłem na https://dns.he.net.
Rejestrujemy się na podanej stronie, a następnie dodajemy naszą nową domenę z menu po lewej stronie (Add new domain – w moim przykładzie będzie to na potrzeby tego artykułu domena majsterkowo.zgora.pl). Na stronie dostawcy naszej domeny oddelegowujemy Name Servery (NS) naszej domeny na: ns1.he.net, ns2.he.net, ns3.he.net, ns4.he.net i ns5.he.net. Cierpliwie czekamy, gdyż oddelegowanie domeny może potrwać do 72 godzin (zwykle trwa to około 12 godzin).
W międzyczasie możemy już skonfigurować nasze „odświeżanie”. Wchodzimy na stronę edycji rekordów dla naszej domeny (ikonka z ołówkiem), klikamy w „New A”, wpisujemy w nazwie nazwę domeny i zaznaczamy „Enable entry for dynamic DNS”. IP zostanie zmapowane automatycznie na nasz adres IP, który jest przecież tożsamy z publicznym adresem IP naszego serwera WEB. TTL zostawiamy na 5 minut (czas odświeżenia rekordu po zmianie).
Następnie w kolumnie przy nowo powstałym rekordzie wciskamy przycisk pod kolumną DDNS (dwie strzałeczki w okręgu) i wpisujemy ręcznie, lub generujemy klucz do odświeżania domeny, zapamiętajmy go, gdyż będzie potrzebny później.
Powinniśmy jeszcze dodać rekord CNAME z przedrostkiem www naszej domeny, aby nasza strona otwierała się również po wpisaniu www przed adresem. Ponownie wchodzimy na stronę edycji rekordów dla naszej domeny (ikonka z ołówkiem), klikamy w „New CNAME”
Po poprawnej konfiguracji nasz DDNS powinien wyglądać jak na poniższym obrazku (oczywiście z własną domeną i adresem IP):
Pozostało nam jeszcze skonfigurowanie na Raspberry Pi zadania CRON, które będzie informowało co 5 minut nasz DDNS o naszym adresie IP. W tym celu logujemy się przy pomocy Putty do naszego RPi. Po zalogowaniu wpisujemy komendę:
|
1 |
crontab -e |
Następnie wybieramy edytor, przy pomocy którego będziemy edytować zadania CRON (polecam znany już Nano – 2). W edytorze wpisujemy następujące polecenie:
|
1 |
*/5 * * * * curl -4 "http://majsterkowo.zgora.pl:klucz.odswiezania.domeny@dyn.dns.he.net/nic/update?hostname=majsterkowo.zgora.pl" |
Oczywiście zamieniamy adres http, klucz odświeżania domeny i hostname na własne. Zapisujemy plik (CTRL + o) i zamykamy edytor (CTRL + x). Następnie wpisujemy komendę
|
1 |
sudo service cron start |
Dynamiczny DNS został skonfigurowany. Po około 12 godzinach nasza strona powinna być widoczna pod nazwą naszej domeny.
Instalacja obsługi darmowych certyfikatów SSL Let’s Encrypt oraz konfiguracja protokołu SSL na naszym Rspberry Pi
Od pewnego czasu mamy możliwość pozyskania darmowego certyfikatu SSL dla naszej domeny. Zalecam korzystanie z certyfikatów SSL choćby z uwagi na wyższe wyniki w wyszukiwarce Google. W niedługim czasie przeglądarki (pierwsza będzie Chrome) będą ostrzegać nas, że witryna bez wdrożonego SSL nie jest bezpieczna. Gdy mamy pewność że nasz serwer WEB widoczny jest w sieci Internet pod nazwą domeny, logujemy się do naszego Raspberry Pi i wydajemy następujące polecenia:
|
1 |
sudo apt-get update |
Instalujemy program Certbot, przy pomocy którego wygenerujemy i zainstalujemy certyfikat SSL:
|
1 |
sudo apt-get install certbot |
Następnie generujemy certyfikat SSL poleceniem:
|
1 |
sudo certbot certonly --webroot -w /var/www/html -d majsterkowo.zgora.pl -d www.majsterkowo.zgora.pl |
Oczywiście nazwę domenową zamieniamy na własną. Podajemy adres e-mail na który otrzymamy powiadomienie o zbliżającym się terminie wygaśnięcia certyfikatu i akceptujemy (A) warunki. W ten sposób wygenerowaliśmy i pobraliśmy na nasz serwer niezbędne pliki certyfikatu SSL.
Pozostało nam skonfigurowanie naszego serwera Lighttpd do obsługi SSL. W pierwszej kolejności musimy przenieść klucz prywatny i certyfikat do jednego pliku web.pem poleceniem:
|
1 |
sudo cat /etc/letsencrypt/live/majsterkowo.zgora.pl/cert.pem /etc/letsencrypt/live/majsterkowo.zgora.pl/privkey.pem > /etc/letsencrypt/live/majsterkowo.zgora.pl/web.pem |
Następnie edytujemy plik konfiguracyjny serwera Lighttpd poleceniem:
|
1 |
sudo nano /etc/lighttpd/lighttpd.conf |
I wklejamy na końcu pliku poniższą treść (zamieniając oczywiście nazwę domeny w dziewięciu miejscach na własną):
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 |
$SERVER["socket"] == ":443" { ssl.engine = "enable" ssl.pemfile = "/etc/letsencrypt/live/majsterkowo.zgora.pl/web.pem" # Combined Certificate ssl.ca-file = "/etc/letsencrypt/live/majsterkowo.zgora.pl/chain.pem" # Root CA server.name = "majsterkowo.zgora.pl" # Domain Name OR Virtual Host Name ssl.cipher-list = "EECDH+AESGCM:EDH+AESGCM:ECDHE-RSA-AES128-GCM-SHA256:AES256+EECDH:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4" ssl.honor-cipher-order = "enable" ssl.use-sslv2 = "disable" ssl.use-sslv3 = "disable" ssl.disable-client-renegotiation = "enable" ssl.dh-file = "/etc/lighttpd/dh4096.pem" ssl.ec-curve = "secp384r1" setenv.add-response-header = ( "Strict-Transport-Security" => "max-age=63072000; includeSubDomains; preload", "X-Frame-Options" => "SAMEORIGIN", "X-Content-Type-Options" => "nosniff" ) setenv.add-environment = ( "HTTPS" => "on" ) } $HTTP["scheme"] == "http" { $HTTP["host"] == "majsterkowo.zgora.pl" { # HTTP URL url.redirect = ("/.*" => "https://majsterkowo.zgora.pl$0") # Redirection HTTPS URL } } $HTTP["scheme"] == "http" { $HTTP["host"] == "www.majsterkowo.zgora.pl" { # HTTP URL url.redirect = ("/.*" => "https://majsterkowo.zgora.pl$0") # Redirection HTTPS URL } } $HTTP["scheme"] == "https" { $HTTP["host"] == "www.majsterkowo.zgora.pl" { # HTTP URL url.redirect = ("/.*" => "https://majsterkowo.zgora.pl$0") # Redirection HTTPS URL } } |
Powyższa konfiguracja serwera Lighttpd zapewnia nam (stan na dzień pisania artykułu) w pełni bezpieczną obsługę certyfikatów SSL. Omówienia wymaga linia 11 oraz linie 23 – 39. W standardowej konfiguracji SSL nasz serwer jest podatny na różnego rodzaju ataki związane z błędami w obsłudze SSL. Jednym z warunków poprawnego wdrożenia SSL jest wzmocnienie klucza szyfrującego dla protokołu Diffiego-Hellmana (protokół uzgadniania kluczy szyfrujących). W tym celu należałoby wygenerować specjalny klucz z szyfrowaniem 4096-bitowym na naszym serwerze. Jednak taka operacja na RPi może trwać kilkanaście godzin. Jeśli chcecie skusić się na samodzielne generowanie takiego certyfikatu należy wydać następujące polecenie:
|
1 |
sudo openssl dhparam -out /etc/lighttpd/dh4096.pem 4096 |
Aby nie czekać tych kilkanaście godzin, możemy skorzystać z załączonego do artykułu pliku (zmieniając rozszerzenie pliku z .txt na .pem) i wgrać go na nasz serwer RPi do katalogu /etc/lighttpd/.
Linie 23 – 39 konfigurują nasz serwer Lighttpd w ten sposób, aby wpisanie adresu http://majsterkowo.zgora.pl lub http://www.majsterkowo.zgora.pl lub https://www.majsterkowo.zgora.pl zawsze kierowało na adres https://majsterkowo.zgora.pl
Oczywiście po zapisaniu powyższej konfiguracji serwera Lighttpd należy przeładować usługę poleceniem:
|
1 |
sudo service lighttpd restart |
Teraz możemy wejść na stronę https://www.ssllabs.com/ssltest i wpisać tam adres naszej strony. Po kilku minutach testów powinniśmy uzyskać wynik poprawności konfiguracji protokołów SSL na naszym serwerze. U mnie wygląda to tak:
To już koniec opisu budowy oraz oprogramowania amatorskiej stacji meteo wykorzystującej serwer WEB na Raspberry Pi 3 B+ uruchomiony we własnej sieci LAN. Wszystkim oceniającym oraz komentującym poprzednie części artykułu serdecznie dziękuję. Jeśli macie jakieś pytania również do tej części opisu, zapraszam do ich zadawania w komentarzach lub na mój e-mail.
Doskonały opis, bardzo szczegółowy. Gratuluję i dziękuję.
Tak powinno pisać się artykuły. Ilość informacji w sam raz. Każdy nowicjusz powinien wykonać to zadanie. Gratuluję!
‘Standardowo usługi WEB działają na porcie 80/TCP oraz 443/TCP https. Musimy więc zezwolić na ruch na tych portach do naszej „malinki”.’
Nie musimy zezwalać na akurat tych portach. Mój router (Ma już pewnie z 7 lat, więc nie jest najnowszy) pozwala skierować dowolny zewnętrzny port na dowolny wewnętrzny. Czyli mogę skonfigurować taki adres mojadomena.pl:4444, a otworzy się strona na malinie na porcie 80. Mając kilka serwerów w lanie (wszystkie na portach 80). Mogę mieć je wszystkie pod jedną domeną, mieniając tylko port 4444. Oczywiście można też na malinie postawić serwer na innym porcie.
‘Niestety, podpięcie własnej domeny nie jest darmowe i jest to koszt 35 dolarów na rok.’
Tu też można trafić na rejestratora domen, który pozwala zarządzać rekordami DNS. Mój akurat pozwala i wystarczy swojej domenie dać rekord CNAME.
Oczywiście nie musimy zezwalać na standardowych portach. Jednak poradnik pisałem w ten sposób, aby również początkujący w tematach IT użytkownicy poradzili sobie z tematem. W artykule na zrzucie ekranu z konfiguracji routera Asus jest niewypełniona kolumna Local Port. Właśnie tu możemy wykonać takie ustawienia, o których piszesz.
Odnośnie podpięcia własnej domeny do zmiennego IP, to nie bardzo rozumiem, jak odświeży się rekord CNAME po zmianie IP?
Ej, co się stało moim komentarzem?
Dziś rano dodałem, ale go nie było widać. Przed publikacją sobie go skopiowałem. Skoro tamtego nie było widać, to wkleiłem go i jeszcze raz dodałem. Ale wtedy już pokazał się komunika o duplikacie. A tu nadal komentarza nie ma.
Już jest :) Trafił do spamu.
Ja mam na routerze skonfigurowany dyndns, a u operatora domeny CNAME wskazuje właśnie na tę domenę dyndns. Zależnie od operatora dyndns. Jedni chcą aby co jakiś czas się odpytywać o domenę, nawet bez zmiany IP, innym wystarcza tylko przy przydzieleniu nowego IP. Router już o to zadba. Też zależnie od sprzętu jeden ma możliwość ustawienia co jaki czas ma się odświeżać, inny wykryje zmianę IP, a jeszcze inny będzie odświeżał tylko przy starcie (tego można restartować w jakieś nocnej porze).
Wszystko jasne – tylko co, jak ktoś nie ma routera z możliwością skonfigurowania DDNS, lub też (jak w sporej ilości routerów) do wyboru ma płatne usługi dynamicznego DNS?
Moim celem było napisanie artykułu w formie zrozumiałej nie tylko dla osób zaawansowanych informatycznie, ale także dla zaczynających swoją przygodę w tematach elektroniki i IT.
Nie wiem jak nowe routery, ale wszystkie moje (a mam ich sześć i nie są to najnowsze modele, bo najstarszy ma ponad 10 lat, a najmłodszy chyba 5) mają konfigurację dyndnsa. I nie były to modele z wysokiej półki. Akurat w nich większość dostępnych dostawców dyndsna padła lub zmieniła właściciela i nie da się w nich tego skonfigurować. Z tego co mam do wyboru to jest noip i kilka płatnych. Z tego wnioskuję, że trudno dziś dostać router bez dyndnsa. Z tego co wiem, to nawet pierwszy dostępny w Polsce funbox od orange miał dostęp do noip.
Dokładnie tak jest, jak piszesz. Ale ponieważ mamy w projekcie wykorzystane Raspberry Pi, to żaden problem wykorzystać go do automatycznego odświeżania bezpłatnego dyndnsa, którego podałem w opisie. Rozwiązanie w 100% działające i całkowicie niezależne od posiadanego routera.
Pingback: Instrukcja wykonania amatorskiej stacji meteo – Robert Błaszczak
Pingback: Odczyt temperatury zdalnie przez internet » Arduino, Elektronika, ESP8266, Gadżety, Użytkowe » poradnik zrób to sam na Majsterkowo.pl
Jak wykonać dostęp do maliny jeżeli nie mamy dostępu do routera . Mój dostawca internetu postawił mi swoj router , musiał być jego bo jest na światłowodzie , teraz nawet hasło do wifi ustalam z nim
Uruchom dowolny skaner IP w swojej sieci (np. https://www.advanced-ip-scanner.com/pl/)
W pierwszej części artykułu nt stacji pogodowej został zamieszczony rysunek – “schemat blokowy stacji meteo”.
Gdyby ktoś miał problem z pokonaniem zasięgu przesyłania danych od układu ESP… do własnej sieci WiFi (na schemacie jest pokazana niebieska podwójna strzałka), proponuję zastosowanie pary układów LoRa np.(Heltec`a).Jak wiadomo sieci WiFi są krótkozasięgowe, góra kilkadziesiąt w porywach 2 setki metrów , co może okazać się w szczególnych sytuacjach niemożliwe do przesłania danych. Dlatego też dla większych odległości przenoszenia sygnałów nieodzowne stają się ww. przeze mnie układy. Nie obsługują one wprost sieci WiFi bo oparte są na transmisji radiowej, ale na pokładzie mają dopięty dodatkowo układ ESP32 przy pomocy, którego mogą spiąć się z pobliską siecią WiFi. Ja dane pomiarowe odbieram (rejestruję w systemie bazodanowym SQL) na “malince” z odległości (od 3 do 14 km). Gdyby ktoś miał problem z pokonaniem bariery odległości między układem z sensorami a urządzeniem rejestrującym wyniki, służę pomocą.
Robert gratuluję. W trzech częściach zawarłeś całą kwint esencję tego wszystkiego co potrzeba do uruchomienia własnego systemu pomiarowego opartego na “malince i ESP8266. Super!
Dziękuję za miłą recenzję.
Zainspirował Pan mnie do użycia mojego starego “RPI A” – chciałem wykonać podobny projekt ale nie mam wiedzy (jeszcze) dot. przesyłu radiowego do Raspberry. Mam pytanie czy jest możliwe wykorzystanie modułu FS100A 433mhz (lub innego) do odczytywania danych z BME280 – moim planem jest po prostu wyświetlenie wartości z czujnika na ekranie LCD na Raspberry (na razie bez logowania danych w bazie). Stacja tak samo jak u Pana będzie stała na zewnątrz (ogródek przed domem ok 10 – 15m od). Niestety mam dosyć słaby zasięg Wifi i komunikacja z routerem raczej odpada. Pozdrawiam i dziękuje
Mam pytanie: Czy jest możliwość podpięcia tego wszystkiego pod domoticza?
Nie wgłębiałem się w temat Domoticza, ale z tego co się orientuję, to jest soft (ESPEasy), który bezpośrednio obsługuje Domoticza oraz czujniki użyte w stacji pogodowej.
Po bezproblemowym przejściu części 1 i 2, utknąłem w części 3 na dobre. Zamówiłem domenę zewnętrzną – stopcam.pl,
ustawiłem jak należy parametry w he.net, ustawiłem cron’a:
a także przekierowałem porty w routerze (Huawei B525-23a w sieci T-mobile) następująco:
Port WAN: 80-80, Port LAN: 80-80, IP LAN: 192.168.8.133, TCP.
I nic. Z zewnątrz, strony na Raspberry nie widać.
Szukałem dokumentacji na he.net i znalazłem pod adresem: https://dns.he.net/docs.html
Wypróbowałem wiele opcji i zadziałało to:
Zadziałało – to znaczy w mojej przeglądarce, po wpisaniu “stopcam.pl” pojawia się strona z Raspberry. Bez dodatku “&myip=192.168.8.133” nie pojawia się nic.
Kompletnie nie znam się na sieciach, portach sieciowych.
Może jakieś życzliwe sugestie?
następująco:
/5 * curl -4 “http://stopcam.pl:eGYdlFMuyz7sUb9x@dyn.dns.he.net/nic/update?hostname=stopcam.pl&myip=192.168.8.133”
Ty wskazałeś lokalny adres IP za routerem (z Twojej sieci). Musisz wskazywać publiczny IP przydzielany przez dostawcę Internetu.
Mi DNSy rozwiązują adres stopcam.pl na IP: 192.168.8.33. To jest adresacja prywatna – niedostępna w sieci Internet.
I jeszcze jedna kwestia. Czy na porcie WAN routera (w Twoim przypadku sieć GSM T-Mobile) masz publiczny adres IP? Trzeba mieć wykupioną usługę publicznego IP http://www.t-mobile.pl/r/repo1/tm/documents/doc_00003/D_005_0000249.pdf
Tak, rzeczywiście na to wygląda.
Kierowałem się dokumentacją, podaną w linku powyżej, a tam tak opcja jest.
Gdy w cron’a wpisałem: ” … net/nic/update?hostname=stopcam.pl” z mojego komputera stacjonarnego, wpiętego w tą samą sieć LAN co Raspberry, przeglądarka pokazała, że takiej strony nie ma.
Ale gdy wpisałem w crone’a: ” … nic/update?hostname=stopcam.p&myip=192.168.8.133″ to wtedy w przeglądarce ta strona z Raspberry mi się pojawiała.
Myślałem, że jakiś postęp, choć z zewnątrz strona na Raspberry dalej była niewidoczna.
A nawiasem, czy gdyby z innego komputera ktoś wpisał u siebie stopcam.pl i miał w swojej wewnętrznej sieci
LAN swoje Raspberry Pi z własną stroną pod adresem 192.168.8.133, to wyświetliła by mu się jego strona?
Co do tych DNS, po Twojej uwadze poszukałem sobie w Internecie (bo wcześniej nie wiedziałem, że to w ogóle możliwe) i przekonałem się, że rzeczywiście DNS stopcam.pl pokazuje lokalne IP. Już się czegoś nauczyłem.
Co do tego publicznego adresu IP. Nie wiem, czy dobrze rozumiem, ale nie mam stałego IP. Za każdym połączeniem z Internetem zmienia się. Czy publiczny to stały? Nie mam niczego dodatkowego dokupionego z oferty T-mobile, oprócz zwykłego dostępnu do Internetu.
Sam sobie odpowiem.
Przeczytałem jeszcze raz Twój artykuł i na samym początku pisze jak byk: “Podstawowym warunkiem pozwalającym na udostępnienie danych z naszej stacji meteo jest posiadanie stałego dostępu do sieci Internet z dynamicznym lub statycznym publicznym adresem IP.” Tyle, że aby to zrozumieć, minimalna wiedza z adresowania sieci być musi.
Dziękuję za pomoc, bo było nie było, problem rozwiązany.
Jeszcze raz gratuluję Autorowi wiedzy i umiejętności dzielenia się nią. To coś niezwykłego.
Podziwiam i jestem pod niezmiennym wrażeniem.
Dziękuję za miłe słowa :)
Dzień dobry, a czy da się zrobić coś podobnego. ale np. na działce gdzie nie ma dostępu do stałego łącza? Np. z zastosowaniem nakładki GSM do RPI i z wykorzystaniem internetu mobilnego tak, żeby mieć dostęp do odczytów z czujników z dowolnego miejsca przez www ? Jak bardzo skomplikowałoby to projekt?
Wydaje mi się, że prościej na działce postawić router GSM, a bazę danych umieścić na dowolnym hostingu. Moduł pomiarowy na ESP będzie łączył się z Wi-Fi z routera GSM i wysyłał dane do bazy. Nie potrzebujemy wtedy Raspberry Pi. Z nakładkami GSM może być problem, bo operatorzy przydzielają adresację IP za ich NAT’em. Nie dostaniemy się wtedy do www na Raspberry. Chyba że wykupimy u operatora usługę stałego, publicznego adresu IP.
Świetna uwaga. Dziękuję bardzo za odzew. O mobilnym routerze nie pomyślałem, a to znacznie może uprościć sprawę. Czy wtedy brak stałego publicznego IP nie byłoby problemem? Do takiego rozwiązania starczyłby najtańszy mobilny router i zwykła karta SIM?
Jeśli moduł pomiarowy na ESP będzie wysyłał dane do bazy SQL na jakimś publicznym hostingu, to nie ma potrzeby posiadania publicznego IP. I wystarczy wtedy najprostszy i najtańszy mobilny router.