Forum Użytkowników Stacji Pogodowych
Stacje Pogody - hardware => Stacje Pogody => Wątek zaczęty przez: YERZY W. w 26 Luty, 2024, 13:22:58
-
Cześć wszystkim, czy ktoś może mi wyjaśnić jak wygląda synchronizacja z serwerami pogodowymi?
Obecnie używam HP2553 i nigdy nie miałem takich problemów. Mam dodaną stację i do ecowitt.net i na WG.
Wczoraj chciałem na apce sprawdzić zmianę ciśnienia i zorientowałem się że stacja widocznie nie ma połączenia z siecią bo nie zaciąga danych. Po restarcie połączenie wróciło ale na aplikacji brakuje danych z tych trzech dni (widocznie od tego czasu to trwało). Oczywiście w pamięci stacji te dane się znajdują. W tej chwile wszedłem na WG i jest ta sama historia tzn po przywróceniu połączenia na nowo zapisuje dane ale brakuje tych z 3 dni przerwy.
W jaki sposób przebiega synchronizacja danych?
Zakładałem że po wznowieniu połączenia załaduje te wszystkie brakujące, ale tak się nie stało. Wygląda to tak że stacja wysyła aktualne dane na serwer w danym momencie (załóżmy co 10 min) i jakakolwiek przerwa w połączeniu, czy też brak zasilania spowoduje że dane nie wyjdą chociaż są w pamięci urządzenia. Tak ma być?
-
Ecowitt i inne firmy (nawet Davis, sic!) uznają ostatnio, że już żyjemy w takich czasach, że brak prądu lub brak Internetu się nie zdarza, więc nie zaprzątali sobie głowy tym, by dodać pamięć logującą dane, do swoich urządzeń.
Konsole i bramki Ecowitt posiadają tylko pamięć ulotną, coś jak RAM w komputerze, która po wyłączeniu zasilania jest tracona. Jesteś offline, dane nie lecą do chmury, tracisz je. Pozostaje logować dane na kartę SD, lub korzystać w sieci lokalnej np. z komputera z oprogramowaniem logującym (CumulusMX, WeatherDisplay, EasyWeather, inne). Wtedy masz pewność, że nawet, jak jest awaria sieci od operatora, to w sieci lokalnej dane są cały czas rejestrowane, a następnie, ww. programy, mają możliwość nadgonienia ich w serwisach pogodowych typu WeatherUnderground, WeatherCloud, etc.
No taka polityka. Wszystko w chmurze.
-
Wczoraj chciałem na apce sprawdzić zmianę ciśnienia i zorientowałem się że stacja widocznie nie ma połączenia z siecią bo nie zaciąga danych. Po restarcie połączenie wróciło ale na aplikacji brakuje danych z tych trzech dni (widocznie od tego czasu to trwało).
Moim zdaniem na konsoli brakuje informacji, czy ostatni transfer danych do serwisów pogodowych zakończył się powodzeniem, czy nie (np. zielona kropka ok, czerwona problem).
W jaki sposób przebiega synchronizacja danych?
Zakładałem że po wznowieniu połączenia załaduje te wszystkie brakujące, ale tak się nie stało. Wygląda to tak że stacja wysyła aktualne dane na serwer w danym momencie (załóżmy co 10 min) i jakakolwiek przerwa w połączeniu, czy też brak zasilania spowoduje że dane nie wyjdą chociaż są w pamięci urządzenia. Tak ma być?
Wygląda na to, że pomiędzy stacją a serwerem jest komunikacja "jednokierunkowa", tzn. stacja wysyła dane co określony czas i nie sprawdza, czy dane zostały poprawnie odebrane. Czyli system typu "wysyłasz dane i nie przejmujesz się co dalej". Gdy jest problem z połączeniem czy z serwerem, to po prostu tych danych nie ma. Żeby nie było utraty danych, musiałaby być komunikacja "dwukierunkowa", czyli stacja sprawdzałaby, czy dane zostały poprawnie odebrane, i jakieś rozwiązanie, które by ponownie przesyłało zaległe pomiary, najlepiej w wolnym czasie pomiędzy kolejnymi planowanymi przesłaniami, bo wiadomo, że aktualne dane są priorytetem. Także serwer musiałby akceptować dane pogodowe z przeszłości.
-
Dzięki za odpowiedź.
Wychowałem się na WH1080 ( prawie 14 lat) ale stacja nie była na stałe podpięta do PC więc nigdy nie udostępniałem danych pomiarowych. Jedynie co jakiś czas ściągałem sobie dane poprzez oprogramowanie EasyWeather które podczas synchronizacji zaciągnęło wszystkie te brakujące od ostatniego razu. W zeszłym roku przesiadłem się na 2553 i po prostu założyłem (niestety błędnie) że z serwerami pogodowymi działa to w ten sam sposób.
Chmura tu nie ma znaczenia - Dropbox, czy Onedrive to też chmura a synchronizacja działa w taki sposób jak powinna (przynajmniej wg mnie).
"Także serwer musiałby akceptować dane pogodowe z przeszłości."
Dokładnie w ten sposób bym to rozwiązał - zaciąga wszystkie brakujące dane od ostatnio zapisanych na serwerze do czasu aktualnego.
Rozumiem wasze tłumaczenie odnośnie zasady działania komunikacji - po prostu jestem bardzo zaskoczony/zawiedziony że tak ma być :(.
-
Wychowałem się na WH1080 ( prawie 14 lat) (..)
Nie ty jeden kolego ;)
Co do Wh1080, to ta stacja ma pamięć wewnętrzną z możliwością zapisu 4080 rekordów (1 rekord = 1 linia danych pomiarowych). Dlatego to hula z EasyWeather lub Cumulusem. Jak wspominałem, obecne "pokolenie" stacji meteo, z reguły nie posiada tej funkcji. Miast rejestrować na wbudowany logger, to dane wysyłane są od razu do chmury. Osobiście boleję nad tym, no ale co poradzisz?
-
No ale tutaj też mam włożone SD które pozwala na spory zapis danych. Ubolewam nad tym że te zapisane dane nie są synchronizowane z serwisami pogodowymi, a jedynie te w czasie rzeczywistym.
-
Co do Wh1080, to ta stacja ma pamięć wewnętrzną z możliwością zapisu 4080 rekordów (1 rekord = 1 linia danych pomiarowych). Dlatego to hula z EasyWeather lub Cumulusem. Jak wspominałem, obecne "pokolenie" stacji meteo, z reguły nie posiada tej funkcji. Miast rejestrować na wbudowany logger, to dane wysyłane są od razu do chmury. Osobiście boleję nad tym, no ale co poradzisz?
Jeżeli stacja nie ma pamięci wewnętrznej, a chcemy mieć archiwum pomiarów, to można sobie z tym poradzić w prosty sposób: Jak na własnej stronie archiwizować pomiary ze stacji pogodowej? (https://stacje-pogody.pl/artykul_jak_na_wlasnej_stronie_archiwizowac_pomiary_ze_stacji_pogodowej,139.html)
No ale tutaj też mam włożone SD które pozwala na spory zapis danych. Ubolewam nad tym że te zapisane dane nie są synchronizowane z serwisami pogodowymi, a jedynie te w czasie rzeczywistym.
Może być ustawiony inny interwał archiwizowania danych (np. co 5 minut) i inny do przesyłania do serwisów pogodowych (np. co 3 minuty). Tak więc, raczej nie można by przesyłać danych już zarchiwizowanych. Ale powinien być jakiś bufor (np. na 1000 rekordów), w pamięci stacji lub na karcie, na dane które nie zostały z jakiegoś powodu przesłane (np. problemy z połączeniem). Po rozwiązaniu problemu, nawiązaniu połączenia, dane z bufora byłyby sukcesywnie przesyłane do serwisów pogodowych, w czasie pomiędzy normalnymi transmisjami. Tak, moim zdaniem, powinni to rozwiązać.
-
Może być ustawiony inny interwał archiwizowania danych (np. co 5 minut) i inny do przesyłania do serwisów pogodowych (np. co 3 minuty). Tak więc, raczej nie można by przesyłać danych już zarchiwizowanych. Ale powinien być jakiś bufor (np. na 1000 rekordów), w pamięci stacji lub na karcie, na dane które nie zostały z jakiegoś powodu przesłane (np. problemy z połączeniem). Po rozwiązaniu problemu, nawiązaniu połączenia, dane z bufora byłyby sukcesywnie przesyłane do serwisów pogodowych, w czasie pomiędzy normalnymi transmisjami. Tak, moim zdaniem, powinni to rozwiązać.
W Ecowitt'ach tak to nie działa niestety. Karta SD służy zasadniczo do 2 celów. Aktualizacji oprogramowania oraz zapisu (nie odczytu) danych. Stacja absolutnie nie korzysta z tych danych, by np. eksportować je gdzieś dalej. To taka proteza loggera i tyle.
Autor chce mieć gwarancję, że dane na zewnętrznych serwisach będą aktualne? To kupić Raspberry Pi, postawić CMX i puszczać przez niego dane w świat. Dodatkowo podpiąć konsolę pod UPS w razie braku zasilania (brak podtrzymania bateryjnego, to kolejna głupia koncepcja obecnych stacji). Taka konfiguracja, daje bardzo duże ratio pozyskania i eksportu danych.
-
Autor chce mieć gwarancję, że dane na zewnętrznych serwisach będą aktualne? To kupić Raspberry Pi, postawić CMX i puszczać przez niego dane w świat. Dodatkowo podpiąć konsolę pod UPS w razie braku zasilania (brak podtrzymania bateryjnego, to kolejna głupia koncepcja obecnych stacji). Taka konfiguracja, daje bardzo duże ratio pozyskania i eksportu danych.
Nie, autor chciałby u siebie w jakiejś apce mieć aktualne/wszystkie dane.
Jeżeli stacja nie ma pamięci wewnętrznej, a chcemy mieć archiwum pomiarów, to można sobie z tym poradzić w prosty sposób: Jak na własnej stronie archiwizować pomiary ze stacji pogodowej? (https://stacje-pogody.pl/artykul_jak_na_wlasnej_stronie_archiwizowac_pomiary_ze_stacji_pogodowej,139.html)
A czy jakaś aplikacja "pogodowa "byłaby wstanie zaciągnąć dane z własnego archiwum np CSV??
-
A czy jakaś aplikacja "pogodowa "byłaby wstanie zaciągnąć dane z własnego archiwum np CSV??
W arkuszu kalkulacyjnym możesz dane CSV analizować, robić wykresy...
-
(...)Wczoraj chciałem na apce sprawdzić zmianę ciśnienia i zorientowałem się że stacja widocznie nie ma połączenia z siecią bo nie zaciąga danych. Po restarcie połączenie wróciło
(...)
Zdiagnozowałeś powód utraty komunikacji stacja pogody-serwery pogodowe ?
Np:
* brak Internetu przez wskazany przez Ciebie okes 3 dni - czyli okres braku danych na serwerach pogodowych
* wysokie skoki napięcia,
* chwilowa utrata zasilania rutera,
* chwilowa utrata zasilania stacji bazowej.
W wyniku trzech ostatnich punktów mogła nastąpić utrata synchronizacji z internetowym serwerem czasu.
Charakteryzuje się to tym, że czas na stacji bazowej jest inny niż np czas w smartfonie. Ta rozbieżność czasu jest "gwarantem", że brak jest synchronizacji stacja-serwer pogodowy a zgodność tych czasów jest warunkiem koniecznym aby
pakiet danych ze stacji bazowej mógł być wysłany w górę sieci.
Teoretycznie taka synchronizacja powinna powrócić samoczynnie poprzez ustawienie automatyki w opcjach ustawiania - ale technika płata figle...
-
(...) W jaki sposób przebiega synchronizacja danych? (...)
W komunikacji stacja-serwery występuje synchronizacja czasu w oparciu o zegar internetowy oraz przesyłanie danych czyli pakietów danych ze stacji bazowej do serwerów pogodowych. Serwery pogodowe oraz stacje bazowe prywatne czyli nasze pracują w oparciu o protokoły TCP/IP bez innych protokołów towarzyszących np UDP. Nasze stacje to proste urządzenia transmisyjne. Działają na zasadzie "wyślij" pod wskazany adres i "zapomnij" realizuje to TCP.
Oznacza to, że pakiet danych wędruje pod wskazany adres IP po przypadkowej trasie rutowanej doraźnie na podstawie dostępności pośrednich węzłów transmisji danych.
Ten adres, czas życia pakietu, ilość max węzłów pośrednich oraz priorytet danych zapisany jest w ramce pakietu. Twoja stacja o ile się nie mylę wysyła takie pakiety co 16sek oraz wartość ciśnienia dodatkowo co 60sek. Każdy z tych pakietòw rutuje inną, przypadkową drogą. Jeżeli sieć jest zapchana/zakorkowana to długość drogi wydłuża się poprzez próbę ominięcia korków innymi węzłami. Gdy max ilość węzłów zostanie przekroczona pakiet ulega likwidacji. To samo się dzieje gdy czas rutowania zostanie przekroczony - zwyle to jest ok. 7-10s. Nasze pakiety mają najniższe priorytety tzn 7.
Co to wszystko oznacza?. Oznacza to, że pakiet wysłany np co 16s nie zawsze dotrze do celu. Bo przekroczy czas życia, bo pobłądzi i zaliczy za dużą ilość węzłów komunikacyjnych czyli stacji teletransmisyjnych i też straci życie, bo stacja utraci synchronizację czasu i nie wyśle pakietu. Z braku stosowania w technologii naszych stacji oraz serwerów pogodowych protokołów kontrolujących dotarcie pakietu do celu stacja nie wie czy pskiety dotarły do celu i nie podejmuje prób wysłania ponownie zagubionego pakietu. Tak by się stało gdyby zaimplementowany był protokoł UDP. On właśnie wysłałby polecenie zwrotne, wysłania dubletu gdy stwierdzi, że pakiet nie dotarł do celu.
Ale nie ma tu wielkiej straty ponieważ serwery pogodowe kolekcjonują przez okres 5min. dane przetransportowane przez pakiet danych w przestrzeni ładunkowej takie jak, temp, wilgotność itp - uśredniają je i w tabeli wyświtlają wartości uśrednione z 18stu pakietów a dodatkowo wyświetlają na grafikach wartości chwilowe. Wartości chwilowe są istotne dla obserwacji online zmian kier i wartości wiatru czy np nasłonacznienia oraz UV.
Przez 5min do kolekcji na serwerze pogodowym trafia 5x60s=300s : 16s = 18 pakietòw. Jeżeli jeden zginie po drodze to nie ma wielkiej straty dla uśrednionej wartości z 5min transmisji. Gorzej jest z wartościami chwilowymi bo np nie zostanie wyświetlony ekstremalny podmuch wiatru z zagubionego pakietu.
Tak więc, transmisja danych przebiega w kier. stacja ---> serwer pogody a nie na odwrót.
To tak obrazowo wygląda. ;)
(...) Wygląda to tak że stacja wysyła aktualne dane na serwer w danym momencie (załóżmy co 10 min) i jakakolwiek przerwa w połączeniu, czy też brak zasilania spowoduje że dane nie wyjdą chociaż są w pamięci urządzenia. Tak ma być?
Stacja nie wysyła pakietów co 10min ale co 16s i dodatkowo pakiet z ciśnieniem co 60s. Serwery pogodowe archiwizują dane co 5min a nie co 10min.
Stacja wytwarza pakiet danych co 16 i 60s i :
* wysyła na serwer pogodowy
* kolekcjonuje pakiet 16sto i 60 sekundowy w swojej pamięci
* uśrednia dane w kolekcji i wyświetla je w tabeli stacji w interwale ustawionym w panelu ustawień np co 10min.
* wyświetla na LCD dane chwilowe z 16 i 60 sekund.
Jeżeli stacja nie wytworzy pakietu lub wytworzy ale nie wyśle z powodów o których powyżej w pierwszym akapicie, bądż wyśle ale pakiety zaginą lub stracą życie to na serwerze pogodowym takie dane nie pojawią się. Serwer nie wie czy i jakie pakiety wysłała stacja, stacja nie wie które pakiety dotarły do celu a które straciły życie. Dlatego nie jest możliwe "dosłanie " brakujących pakietów do serwera przy obecnie stosowanej technologii transmisjii danych w stacjach oraz przez operatorów serwerów pogodowych.
-
Z braku stosowania w technologii naszych stacji oraz serwerów pogodowych protokołów kontrolujących dotarcie pakietu do celu stacja nie wie czy pakiety dotarły do celu i nie podejmuje prób wysłania ponownie zagubionego pakietu. Tak by się stało gdyby zaimplementowany był protokół UDP. On właśnie wysłałby polecenie zwrotne, wysłania dubletu gdy stwierdzi, że pakiet nie dotarł do celu. (...) Serwer nie wie czy i jakie pakiety wysłała stacja, stacja nie wie które pakiety dotarły do celu a które straciły życie. Dlatego nie jest możliwe "dosłanie " brakujących pakietów do serwera przy obecnie stosowanej technologii transmisjii danych w stacjach oraz przez operatorów serwerów pogodowych.
Stacja powinna wiedzieć, że dane dotarły do celu, ponieważ przesyłając dane (np. protokołem WU) serwer po odebraniu danych i ich przetworzeniu wysyła odpowiedź "success", co oznacza, że poprawnie odebrał dane. Tak więc, wygląda na to, że albo stacja nie odczytuje tych odpowiedzi, albo odczytuje, ale nic z tym nie robi, bo nie ma napisanej obsługi "błędów" (powtórnego przesyłania).
Nie wiem, w jakim języku mają oprogramowanie te stacje. Ale w języku logiki, powinno wyglądać to tak: jeżeli "odpowiedź serwera"<>"success" to dane nie zostały poprawnie odebrane przez serwer i należy coś z tym zrobić, czyli przesłać ponownie lub zapamiętać i ponownie przesłać później.
Stacja nie wysyła pakietów co 10min ale co 16s i dodatkowo pakiet z ciśnieniem co 60s. Serwery pogodowe archiwizują dane co 5min a nie co 10min.
"co 16s i dodatkowo pakiet z ciśnieniem co 60s" - to są najprawdopodobniej czasy aktualizacji pomiarów na wyświetlaczu. Czas zapisu danych w pamięci i przesyłania do serwisów pogodowych może być różny, jest zależny od ustawień stacji (np. 1-240 minut).
-
"co 16s i dodatkowo pakiet z ciśnieniem co 60s" - to są najprawdopodobniej czasy aktualizacji pomiarów na wyświetlaczu.
Czas zapisu danych w pamięci i przesyłania do serwisów pogodowych może być różny, jest zależny od ustawień stacji (np. 1-240 minut).
Poruszyłeś tu różne kwestie i dlatego dla uporządkowania tematu posegreguję prezentacje danych:
1. na wyświetlaczu konsoli
2. w tabeli danych konsoli,
3.w kokpicie stacji na grafice serwera pogodowego do obejrzenia np na smartfonie
4. w tabeli serwera pogodowego do obejrzenia np w smartfonie,
tak jak to zrobiłem w moim poprzednim postcie:
Ad 1. Aktualizacja na wyświetlaczu konsoli odbywa się co 16s dla parametrów mierzonych przez zespolony czujnik zewnętrzny i co 60s dla ciśnienia mierzonego przez czujnik wewnętrzny.
Co 16 i 60s - czyli w interwale wysyłania takich pakietów danych od czujników do konsoli jakie zaprogramował producent stacji.
Dla porównania wyświetlacza konsoli i danych prezentowanych w kokpicie stacji na serwerze pogodowym przeskoczę od razu do pktu 3.
Ad 3. Aktualizacja jest widoczna identycznie jak na wyświetlaczu konsoli co 16 i 60s z pewnym poślizgiem transmisji danych. Czas aktualizacji odliczany jest właśnie w kokpicie stacji widoczny w górnej części np na serwerze WU.
Właśnie te zmiany są widoczne dla parametrów dynamicznych takich jak pomiary wiatru czy nasłonecznienia i są dowodem na docieranie do celu czyli do serwera pogodowego pakietów danych co 16 i co 60s. i nie dotyczą tylko aktualizacji wyświetlacza konsoli jak napusałeś powyżej.
Nie jest to więc jak piszesz tylko prawdopodobne wyświetlanie danych na wyświetlaczu konsoli ale ròwnoczesne wysłanie w tym samym interwale 16 i 60s pakietu danych w górę sieci do serwera pogodowego - co widać na serwerze pogodowym patrząc na dynamiczne parametry.
Od strony technicznej wygląda to tak, dla przykładowego czujnika zewnętrznego stacji.
Czujnik zewnętrzny co 16s tworzy pakiet z kilku parametrów i wysyła go po WiFi do konsoli, konsola rozpakowuje pakiet, wyciąga z niego poszczególne pomiary (temp., UV, wilgotność itd) i aktualizuje wyświetlacz konsoli - jednocześnie umieszczając te parametry w tabelach w konsoli.
Jednocześnie konsola odebrany pakiet z czujnika zewn. modyfikuje poprzez utworzenie nowej ramki wg instrukcji protokołów TCP/IP - wprowadzając pomiary do części ładunkowej i adresując jednocześnie cały pakiet zgodnie z adresami serwerów pogodowych. Asap wysyła taki pakiet w górę sieci.
Natomiast punkty 2 i 4 dotyczą archiwizacji danych w konsoli i na serwerze. I właśnie tych punktów dotyczy druga kwestia poruszona przez Ciebie czyli Czasu....
I tak:
Czas zapisu danych w pamięci konsoli jest taki jaki user stacji ustawi sobie w Ustawieniach konsoli i zwykle jest to minimum 5min i max 240min jak napisałeś. I pomimo, że na wyświetlaczu konsoli dane się zmieniają co 16s to w tabeli zmieniają się co interwał ustawiony przez usera. Są to dane uśrednione z pomiarów w 16s interwałach.
Ale te ww ustawienia w konsoli nie dotyczą bezpośrednio archiwizacji danych na serwerze pogodowym.
Np serwer pogodowy WU archiwizuje standardowo co 5min. nadchodzące pakiety. Warunek jest taki o czym nie napisałem we wcześniejszych postach powyżej, że stacja musi wysyłać takie pakiety z interwałem conajmniej 5min i mniejszym. Jeżeli wyśle co 5min to parametry archiwizowane są na wprost ci 5min. Jeżeli wysyła z większą częstotliwiściwlą np co 16s to serwer kolekcjonuje kolejne pakiety, uśrednia co 5min i umieszcza w tabeli pomiarowej dla danej stacji.
Jeżeli stacja wysyła np co 20min bo ma tylko takie możliwości to siłą rzeczy na serwerze pogodowym w tabeli pojawią się pomiary co 20min. a nie co co standardowe 5min ustalone przez operatora serwera. Dla przykładu stacje lotniskowe IMGW wysyłają takie dane co 1h i w tabelach na serwerze dane archiwizowane są co 1h - przeważnie są to pełne godziny.
Tak więc archiwizacja danych w konsoli i na serwerze pogodowym odbywa się wg ròżnych zasad. O interwale archiwizacji w konsoli decyduje user. O interwale na serwerze pogodowym decyduje operator serwera.
Na częstotliwość wysyłania pakietòw z czujników do konsoli stacji po WiFi oraz z konsoli do serwera pogodowego po IP nie ma wpływu user lecz zaimplementowane oprogramowanie i jest to dla zaawansowanych stacji zwykle 16s i 60s dla ciśnienia.
PS. @Parasol, może metodą polemizowania rozruszamy ponownie to Forum na czym powinno Ci zależeć jako adminowi ;)
-
Właśnie te zmiany są widoczne dla parametrów dynamicznych takich jak pomiary wiatru czy nasłonecznienia i są dowodem na docieranie do celu czyli do serwera pogodowego pakietów danych co 16 i co 60s. i nie dotyczą tylko aktualizacji wyświetlacza konsoli jak napusałeś powyżej.
Nie jest to więc jak piszesz tylko prawdopodobne wyświetlanie danych na wyświetlaczu konsoli ale ròwnoczesne wysłanie w tym samym interwale 16 i 60s pakietu danych w górę sieci do serwera pogodowego - co widać na serwerze pogodowym patrząc na dynamiczne parametry.
Dane pogodowe są wysyłane przez stacje na serwery pogodowe co jakiś czas, który jest ustawiany w konfiguracji stacji. Jeżeli ustawisz interwał wysyłania danych na serwery pogodowe (upload interval) na 5 minut, to co 5 minut stacja połączy się z serwisem pogodowym i prześle dane. Nie będzie to ani częściej ani rzadziej - dokładnie co 5 minut.
Np serwer pogodowy WU archiwizuje standardowo co 5min. nadchodzące pakiety. Warunek jest taki o czym nie napisałem we wcześniejszych postach powyżej, że stacja musi wysyłać takie pakiety z interwałem co najmniej 5min i mniejszym. Jeżeli wyśle co 5min to parametry archiwizowane są na wprost ci 5min. Jeżeli wysyła z większą częstotliwościową np co 16s to serwer kolekcjonuje kolejne pakiety, uśrednia co 5min i umieszcza w tabeli pomiarowej dla danej stacji.
Dlatego, moim zdaniem, nie ma sensu wysyłać danych częściej, niż w odstępach czasowych, w jakich serwis pogodowy je przechowuje. Czyli np. WU ma 5 minutowe odstępy czasowe, czyli konfigurujesz wysyłanie w stacji (upload interval) na 5 minut.
-
Dlatego nie jest możliwe "dosłanie " brakujących pakietów do serwera przy obecnie stosowanej technologii transmisjii danych w stacjach oraz przez operatorów serwerów pogodowych.
Myślę że to sformułowanie zamyka temat. Dzięki za wszystkie wyjaśnienia.
-
Dane pogodowe są wysyłane przez stacje na serwery pogodowe co jakiś czas, który jest ustawiany w konfiguracji stacji. Jeżeli ustawisz interwał wysyłania danych na serwery pogodowe (upload interval) na 5 minut, to co 5 minut stacja połączy się z serwisem pogodowym i prześle dane. Nie będzie to ani częściej ani rzadziej - dokładnie co 5 minut.
Dlatego, moim zdaniem, nie ma sensu wysyłać danych częściej, niż w odstępach czasowych, w jakich serwis pogodowy je przechowuje. Czyli np. WU ma 5 minutowe odstępy czasowe, czyli konfigurujesz wysyłanie w stacji (upload interval) na 5 minut.
@Parasol - czym innym jest proces wysyłania pakietów na serwery prez stacje bazowe a czym innym proces archiwizacji tych pakietów na serwerach.
WU wyświetla uśrednione dane z 18stu pakietów co 5min zebranych od danej stacji w ciągu właśnie 5min - dla przykładowej stacji z interwałem 16s.
Ale zauważ, że stacja bazowa wysyła do sieci dane w takim interwale jak zaszył to w aplikacji producent. To widać online na zegarze zliczającym czas od ostatniego przesłania pakiety w kokpicie stacji na WU.
-
Panowie mam jeszcze jedną sprawę powiązaną z tematem. Rozumiem już zasadę wysyłania danych (a nie synchronizacji) na serwery pogodowe. Po wysłaniu i przetworzeniu zostają one zapisane na "koncie" użytkownika i stanowią bazę danych do generowania wykresów (przeglądarka/ aplikacja etc)
Oglądam sobie właśnie przez przeglądarkę swoja historię i mam jakieś dziwne śmieci:
np: Ciśnienie spadło do 700 a w Himalaje czujnika nie zabierałem, albo temp wewnętrzna 1,5 C.
Fakt że są to jednorazowe przypadki. O ile u siebie na komputerze jak ściągnę dane to mogę usunąć (poprawić) te anomalie ale pytanie o serwery? Rozumiem że właściciele serwisów pogodowych nie umożliwiają takiej funkcjonalności ale pytanie tylko: czy od strony technicznej nie dałoby się edytować danych (poszczególnych rekordów)? Tylko tak z ciekawości pytam.
2. Przy okazji zapytam też czy jest to możliwe że stacja pogodowa zaciągnie dane nie ze swoich czujników?
(tłumaczyłoby to w jakiś sposób te anomalie). Mam w swojej statystyce np pomiar PM2.5 a nie posiadam czujnika jakości powietrza :) To skąd stacja to wzięła?
3. Nie chcę zakładać osobnego wątku (a może by się przydał). Czy jest jakaś różnica pomiędzy czujnikami Ecowitt a Misol? Na internecie znalazłem treść:
"They are the same thing. They are both made by Fine Offset. Branding will be different is all. Misol is a Fine Offset reseller. Ecowitt is a reseller too but they are a bit special in that they are like a sister company or like a subsidiary company."
Może pracują na innej częstotliwości?
Chciałbym dokupić trochę czujników do stacji a na Ali okazuje się że te Misola są zdecydowanie tańsze np Ecowitt WH51 (wilgotność gleby) kosztuje ok 75PLN a Misola 38PLN. Podobnie jest z innymi. Jakiś powód?
-
(...) 2. Przy okazji zapytam też czy jest to możliwe że stacja pogodowa zaciągnie dane nie ze swoich czujników?
(tłumaczyłoby to w jakiś sposób te anomalie). Mam w swojej statystyce np pomiar PM2.5 a nie posiadam czujnika jakości powietrzya :) To skąd stacja to wzięła? (...)
Tak, to możliwe. Czujniki zespolone mają co prawda swoje ID ale one nie zapobiegają temu aby inna stacja bazowa/konsola zaciągnęła z niego dane lub, że Twój jest odczytywany przez pobliską stację.
Będzie tak doputy, dopóki te czujniki będą pracowały na tej samej częstotliwości.
W Polsce nasze stacje mogą pracować na 868 MHz (zalecana, bo odporna na zakłócenia innych elektroenergetycznych urządzeń) oraz na 433 MHz.
Warunkiem koniecznym dla zaistnienia zaciągnięcia innych danych jest zbyt długi czas pomiędzy kolejnymi wysłanymi pakietami po WiFi przez Twój czujnik zespolony do Twojej stacji bazowej/konsoli. Jeżeli w tej przerwie w eterze pojawi się inny sygnał na tej częstotliwiści z pakietem danych sfirmatowanych podobnie jak jak pakiet Twojej stacji to zostanie on odczytany jako swój gdy przerwa jest zbyt długa lub gdy w pobliżu jest inny podobnie działający czujnik jak np. do pomiaru jakości powietrza.
Warunek: musi to być przerwa odpowiednio długa.
Dlaczego ? Ponieważ oprogramowanie stacji gwarantuje komunikację po WiFi pomiędzy Twoją konsolą i Twoim czujnikiem zespolonym tylko na "pewien" krótki okres braku sygnału ze swojego czujnika.
W jaki sposób ? Właśnie dzięki swojemu ID czujnika. Konsola w trakcie takiej przerwy przez jakiś czas dzięki rozpoznaniu "swój-obcy" nie odczytuje innego ID.
Nie wiem jak to jest w Twojej stacji, ale w podobnych produktach nry ID czujników np. wewnętrzny, zewnętrzny, itp można odczyrać w konsoli w odpowiedniej zakładce.
-
(...) O ile u siebie na komputerze jak ściągnę dane to mogę usunąć (poprawić) te anomalie ale pytanie o serwery? Rozumiem że właściciele serwisów pogodowych nie umożliwiają takiej funkcjonalności ale pytanie tylko: czy od strony technicznej nie dałoby się edytować danych (poszczególnych rekordów)? Tylko tak z ciekawości pytam. (...)
Nie ma takiej opcji ani przed wysłaniem pakietu danych w górę sieci a tym bardziej gdy są one już rozpakowane i zapisane w archiwach na serwerach.
-
(...) 3. Nie chcę zakładać osobnego wątku (a może by się przydał). Czy jest jakaś różnica pomiędzy czujnikami Ecowitt a Misol? Na internecie znalazłem treść:
"They are the same thing. They are both made by Fine Offset. Branding will be different is all. Misol is a Fine Offset reseller. Ecowitt is a reseller too but they are a bit special in that they are like a sister company or like a subsidiary company."
Może pracują na innej częstotliwości?
Chciałbym dokupić trochę czujników do stacji a na Ali okazuje się że te Misola są zdecydowanie tańsze np Ecowitt WH51 (wilgotność gleby) kosztuje ok 75PLN a Misola 38PLN. Podobnie jest z innymi. Jakiś powód? (...)
Dla jasności, powyższy cytat w j. ang. mówi:
"To są te same produkty. Obydwa są produkowane przez firmę Fine Offset. Branding będzie inny, to wszystko. Misol jest sprzedawcą Fine Offset. Ecowitt również jest sprzedawcą, ale jest trochę wyjątkowy, ponieważ przypomina firmę siostrzaną lub spółkę zależną."
Z treści wynika, że są to te same produkty, a w sieci na Aliexpres znalazłem przy produktach "zamiennik".
FineOffset ma patent na softy produkowanych przez siebie stacji i są one bliźniaczo do siebie podobne - mowa o softach. I tak jak w powyższej info, FineOffset zezwala na sprzedaż pod inną marką. Tak jest już od kilkunastu lat z innymi produktami.
Jak sam zauważyłeś ważne jest aby produkt miał tę samą częstotliwość co Twoja stacja bazowa/konsola - 868 lub 433 MHz.
Sprawdziłem w sieci, przykładowe produkty marki Misol w opisie mają wyraźnie zaznaczone jaka to częstotliwość.
Na tym forum kompatybilność czujników innych stacji ze stacjami Ecowitt jest szeroko skomentowana przez znawcę Ecowitt. Fizycznie to porównywał i zalecał np drobne korekty w kalibracji pomiarów w konsoli aby były zbieżne z formatem Ecowitt.
-
Dzięki za wyjaśnienia. Jestem pod wrażaniem wiedzy na temat "technikaliów".
Co do 2. Rozumiem że stacja może "zaciągnąć" wartości od obcych czujników, niemniej jednak wartości te chyba powinny być podobne/realne ( a tu ciśnienie 700hpa?).
Co do 3. Coś mi się w tym opisie angielskim nie do końca zgadzało "Branding will be different is all" Z tego co znalazłem na forach zagranicznych to gryzie oprogramowanie itd. (w sumie słusznie).
Wydaje mi się że największą różnicą jest to że praktycznie wszystkie czujniki z brandem Misol są na 433Mhz, a Ecowitt na 868Mhz
-
... dzięki za splendor ;) i "podziękowanie" pod Avatarem ;)
Ad.2... mogą być podobne ale... nie muszą...
Dlaczego?
a) nie wiesz jaki format danych ma obca stacja
b) nie wiadomo czy jest to REL czy ABS - może źle zastosował przelicznik ABS vs REL ?
c) nie wiadomo czy user obcej stacji ma pojęcie o kalibracji - może mieć przypadkowe ustawienia
d) nie wiesz gdzie obcy user położył czujnik - może w lodówce...dot. temp.
Ad. 3... nie wszystkie mają 433 - mają też 868MGz.
Dlaczego Misol taniej ? Może marka wchodzi na rynek ?
Travelist sprzedaje produkty hotelowe o 50% taniej w hotelach nawet ☆☆☆☆☆ np Grand Lubicz w Ustce z takim samym bogatym pakietem jak klienci którzy kupili to w recepcji hotelu... a kwota różni się w tysiącach !!! za tydzień pobytu - i też pytanie dlaczego ? ;)
-
Do @YERZY W.
Więcej o kompatybilności czujników pomiędzy różnymi stacjami pogody_klik (http://stacjepogody.waw.pl/index.php?topic=2844.msg20607#msg20607)
Ten user - znawca Ecowitt o którym pisałem powyżej to @Felix - poczytaj jego posty
-
2. Przy okazji zapytam też czy jest to możliwe że stacja pogodowa zaciągnie dane nie ze swoich czujników?
(tłumaczyłoby to w jakiś sposób te anomalie). Mam w swojej statystyce np pomiar PM2.5 a nie posiadam czujnika jakości powietrza :) To skąd stacja to wzięła?
Raczej nie ma takiej możliwości, ponieważ czujniki mają własne ID. ID czujnika jest unikalne i stałe. W konsoli jest "Sensor ID Setup" tam wszystkimi czujnikami zarządzasz, aktywujesz lub deaktywujesz dany czujnik. Jeżeli nie chcesz odbierać informacji z jakiegoś czujnika, to go po prostu dezaktywujesz (ID).
3. Nie chcę zakładać osobnego wątku (a może by się przydał). Czy jest jakaś różnica pomiędzy czujnikami Ecowitt a Misol? Na internecie znalazłem treść:
"They are the same thing. They are both made by Fine Offset. Branding will be different is all. Misol is a Fine Offset reseller. Ecowitt is a reseller too but they are a bit special in that they are like a sister company or like a subsidiary company."
Może pracują na innej częstotliwości?
Chciałbym dokupić trochę czujników do stacji a na Ali okazuje się że te Misola są zdecydowanie tańsze np Ecowitt WH51 (wilgotność gleby) kosztuje ok 75PLN a Misola 38PLN. Podobnie jest z innymi. Jakiś powód?
Z tego co mi wiadomo, to Fine Offset i Ecowitt to jedna firma. Pod marką Ecowitt sprzedawane są stacje detalicznie, końcowemu użytkownikowi. Natomiast Fine Offset współpracuje z firmami i sprzedaje stacje "hurtowo", czyli w dużych ilościach. O kompatybilności czujników pisałem tutaj: https://aleforum.pl/index.php?topic=40.msg50#msg50 (https://aleforum.pl/index.php?topic=40.msg50#msg50)
Warunkiem koniecznym dla zaistnienia zaciągnięcia innych danych jest zbyt długi czas pomiędzy kolejnymi wysłanymi pakietami po WiFi przez Twój czujnik zespolony do Twojej stacji bazowej/konsoli.
Dlaczego ? Ponieważ oprogramowanie stacji gwarantuje komunikację po WiFi pomiędzy Twoją konsolą i Twoim czujnikiem zespolonym tylko na "pewien" krótki okres braku sygnału ze swojego czujnika.
Komunikacja WiFi służy do przesyłania danych do serwisów pogodowych. Konsola z czujnikami komunikuje się na częstotliwościach radiowych 433 Mhz lub 868 Mhz...
-
Raczej nie ma takiej możliwości, ponieważ czujniki mają własne ID. ID czujnika jest unikalne i stałe. W konsoli jest "Sensor ID Setup" tam wszystkimi czujnikami zarządzasz, aktywujesz lub deaktywujesz dany czujnik. Jeżeli nie chcesz odbierać informacji z jakiegoś czujnika, to go po prostu dezaktywujesz (ID).
Właśnie "raczej". Też mi się tak wydawało ale nie jestem pewien z powodów empirycznych (zdjęcie poniżej) a zapewniam że czujnika powietrza jeszcze nie posiadam. Pomijam powód który opisywał "Rychu_Świbno" ponieważ warunek długiej przerwy w łączności nie wystąpił.
Tak samo wartość tego ciśnienia: Czy logika stacji nie powinna być taka że jeżeli np.: wartość kolejna X jest większa od poprzedniej Y więcej niż Z (np. 10hPa) = odrzuć pomiar/wartość. Przecież tak po ludzku na logikę ciśnienie tak szybko nie spada/rośnie. No chyba że na Śląsk doleciałaby ruska rakieta z bomba próżniową!
niestety przez takie śmieci wykres ciśnienia wygląda nienaturalnie, a oczywiście nie ma możliwości ustawienia scali osi (od do) bo to nie Excel.
Komunikacja WiFi służy do przesyłania danych do serwisów pogodowych. Konsola z czujnikami komunikuje się na częstotliwościach radiowych 433 Mhz lub 868 Mhz...
Stacje Misol niby są również na 868 Mhz, ale z tego co zauważyłem na Ali to praktycznie wszystkie czujniki Misol są 433Mhz.
Również na stronie www.misolweather.com ( o ile to ich oficjalna) też wszystko jest na 433.
-
Musisz ustalić, gdzie jest problem, bo może to występować tylko w serwisie pogodowym.
Czy logika stacji nie powinna być taka że jeżeli np.: wartość kolejna X jest większa od poprzedniej Y więcej niż Z (np. 10hPa) = odrzuć pomiar/wartość.
To nie jest dobry pomysł, bo jeżeli wystąpiłaby naturalna anomalia, to stacja nie zarejestrowałaby tego. Przykładem może być wybuch Hunga Tonga-Hunga Ha'apai (https://stacje-pogody.pl/artykul_czy_domowa_stacja_pogodowa_moze_zarejestrowac_wybuch_wulkanu,120.html).
-
Polemika @Parasol vs @ Rychu_Świbno:
2.Przy okazji zapytam też czy jest to możliwe że stacja pogodowa zaciągnie dane nie ze swoich czujników?
(tłumaczyłoby to w jakiś sposób te anomalie). Mam w swojej statystyce np pomiar PM2.5 a nie posiadam czujnika jakości powietrza To skąd stacja to wzięła?
Pomijam powód który opisywał "Rychu_Świbno" ponieważ warunek długiej przerwy w łączności nie wystąpił.
Tak, to możliwe.. Czujniki zespolone mają co prawda swoje ID ale one nie zapobiegają temu aby inna stacja bazowa/konsola zaciągnęła z niego dane lub, że Twój jest odczytywany przez pobliską stację.
Raczej nie ma takiej możliwości, ponieważ czujniki mają własne ID. ID czujnika jest unikalne i stałe.
@Parasol, wprowadzasz userów w błąd z tym ID stacji. W tym co napisałeś powyżej jest prawdą to, że czujniki do stacji, te wewnętrzne czy zewnętrzne posiadają intywidualne ID.
Dzięki nim, user może monitorować czy konsola przyjmuje pakiety po WiFi od swojego czujnika czy obcego.
Ten ID zapewnia też - jak napisałem powyżej - to że konsola nie przyjmie pakietu od obcego czujnika przez pewien okres gdy nie dotarł pakiet swojego czujnika czyli swojego ID.
@YERZY --> Ten okres - z mojego doświadczenia - to 3-5 interwałów pomiędzy pakietami wysyłanymi co 16s - ta techniczna przerwa jest niezauważalna dla usera oraz niewidoczna w zestawieniu danych w konsoli i na serwisie pogodowym. To jest taki bufor czasowy jaki FineOffset zaszył kilka lat temu w softach swoich stacji. Właśnie po to aby "dać szansę" czujnikowi własnemu na skuteczne przesłanie pakietu do swojej konsoli.
Przerwa wynika np z chwilowych zakłóceń w eterze. Gdy przerwa jest dłuższa niż te 3-5 interwałów (ok 1min lub mniej) to, w to miejsce wchodzi pakiet z ID obcego czujnika.
Tak więc @Parasol - to nieprawda co piszesz, że konsola nie przyjmie obcego czujnika.
Zawsze przyjmie - czego przykładem są moje czujniki. Pochodzą one od różnych stacji i z pierwotnym zakupem kompletu z konsolami nic wspólnego nie mają. Stacje są leciwe i dokompletowywane różnymi czujnikami zakupionymi jako części zamienne. Mają one różne ID od tych zakupionych jako nowe. Mało tego, jedna z nich doposażona jest czujnikiem od innego typu stacji.To wszystko hula i nie przekłamuje - co można obejrzeć klikając w linki w topce tego posta.
Powyżej podałem też wyboldowany link do dyskusji na ten temat z @Felixem który jeszcze głębszych wymian/badań dokonał - nawet w stosunku do hub-a D1000 nowej generacji.
I wniosek, ID obcego czujnika nie są przeszkodą do wysłania pakietów do innej przypadkowej stacji. Gdyby tak było to niemożliwa byłaby wymiana czujnika uszkodzonego na sprawny.
@Parasol - myślę, że moje ponowne wyjaśnienia zamykają temat, podawanie innych info na ten temat to wprowadzanie w błąd userów.
Warunkiem koniecznym dla zaistnienia zaciągnięcia innych danych jest zbyt długi czas pomiędzy kolejnymi wysłanymi pakietami po WiFi przez Twój czujnik zespolony do Twojej stacji bazowej/konsoli.
Dlaczego ? Ponieważ oprogramowanie stacji gwarantuje komunikację po WiFi pomiędzy Twoją konsolą i Twoim czujnikiem zespolonym tylko na "pewien" krótki okres braku sygnału ze swojego czujnika.
Komunikacja WiFi służy do przesyłania danych do serwisów pogodowych. . (...)
@Parasol i tu również wprowadzasz szum informacyjny w zakresie "Komunikacji czujnik - konsola" vs Komunikacja czujnik -serwis pogodowy".
Prawda jest taka, że WiFi służy wyłącznie i tylko wyłącznie ! do komunikacji czujnik-konsola. Od konsoli do serwisu pogodowego nie jest wykorzystywany protokół WiFi - bez wgłębiania się w całą ich piętrową strukturę - ale protokół TCP/IP.
Dlatego to suma protokołów WiFi i TCP/IP zapewnia komunikację od czujnika via konsola do serwisu pogodowego a nie tylko WiFi jak napisałeś.
@Parasol - myślę, w sposób obrazowy wyjaśniłem - po raz kolejny - funkcje ID czujników oraz rolę protokołów WiFi i TCP/IP w procesie komunikacji: czujnik - konsola via konsola - serwis pogodowy.
Pozdrawiam i życzę podtrzymania życia tego Forum. To jest jedyny taki portal w sieci w j. polskim - to skarbnica wiedzy z profesjonalnie prowadzoną przez Ciebie bazą danych dot. stacji, w tym nowości rynkowych. Szkoda gdyby to zniknęło z sieci.
-
To jest jedyny taki portal w sieci w j. polskim - to skarbnica wiedzy z profesjonalnie prowadzoną przez Ciebie bazą danych dot. stacji, w tym nowości rynkowych. Szkoda gdyby to zniknęło z sieci.
To akurat "święta prawda". Tak jak tu zajrzałem (niezalogowany) kilkanaście lat temu jak wybierałem swoją pierwszą stację, zawsze traktowałem to miejsce jak zbiór wiedzy. Po prostu wcześniej zawsze w postach znajdowałem odpowiedzi na swoje "bolączki". Ja również mam nadzieję że nie zniknie.
-
@Parasol, wprowadzasz userów w błąd z tym ID stacji. W tym co napisałeś powyżej jest prawdą to, że czujniki do stacji, te wewnętrzne czy zewnętrzne posiadają intywidualne ID.
Tak więc @Parasol - to nieprawda co piszesz, że konsola nie przyjmie obcego czujnika.
I wniosek, ID obcego czujnika nie są przeszkodą do wysłania pakietów do innej przypadkowej stacji. Gdyby tak było to niemożliwa byłaby wymiana czujnika uszkodzonego na sprawny.
@Parasol - myślę, że moje ponowne wyjaśnienia zamykają temat, podawanie innych info na ten temat to wprowadzanie w błąd userów.
Nie wprowadzam nikogo w błąd. Nie mam tej stacji, a oprogramowanie w różnych wersjach może być różne, dlatego napisałem "raczej nie ma takiej możliwości", ponieważ czujniki mają własne unikalne ID i jest możliwość rejestracji i dezaktywacji czujnika o danym ID. Popatrz na załączone zdjęcie (instrukcja) konfiguracji sensorów "Sensor ID", masz przy ustawieniach "register" (zarejestrować) i "disable" (wyłączyć), czyli możesz go aktywować i odbierać dane, albo wyłączyć, czyli nie odbierać danych. Tak więc, jeżeli nie chcesz odbierać danych z danego czujnika, to go wyłączasz.
(http://stacjepogody.waw.pl/proxy.php?request=http%3A%2F%2Fstacjepogody.waw.pl%2Findex.php%3Faction%3Ddlattach%3Btopic%3D3222.0%3Battach%3D5106%3Bimage&hash=31fbb5d64e2a723f6e3c3b4d317f7cb4)
@Parasol i tu również wprowadzasz szum informacyjny w zakresie "Komunikacji czujnik - konsola" vs Komunikacja czujnik -serwis pogodowy".
Prawda jest taka, że WiFi służy wyłącznie i tylko wyłącznie ! do komunikacji czujnik-konsola. Od konsoli do serwisu pogodowego nie jest wykorzystywany protokół WiFi - bez wgłębiania się w całą ich piętrową strukturę - ale protokół TCP/IP.
Dlatego to suma protokołów WiFi i TCP/IP zapewnia komunikację od czujnika via konsola do serwisu pogodowego a nie tylko WiFi jak napisałeś.
@Parasol - myślę, w sposób obrazowy wyjaśniłem - po raz kolejny - funkcje ID czujników oraz rolę protokołów WiFi i TCP/IP w procesie komunikacji: czujnik - konsola via konsola - serwis pogodowy.
Czujniki przesyłają informacje do konsoli wykorzystując częstotliwości radiowe (433/868 MHz). Konsola odbiera informacje z czujników (433/868 MHz) i wykorzystując router WiFi, przesyła pomiary do serwisów pogodowych. Tak to działa. Jeżeli ktoś nie wie, o co w tym chodzi, jak działa, to polecam poradnik: Kilka informacji, które powinieneś wiedzieć kupując stację pogodową (https://stacje-pogody.pl/artykul_kilka_informacji_ktore_powinienes_wiedziec_kupujac_stacje_pogodowa,117.html).
To akurat "święta prawda". Tak jak tu zajrzałem (niezalogowany) kilkanaście lat temu jak wybierałem swoją pierwszą stację, zawsze traktowałem to miejsce jak zbiór wiedzy. Po prostu wcześniej zawsze w postach znajdowałem odpowiedzi na swoje "bolączki". Ja również mam nadzieję że nie zniknie.
Nie wiem czy nie zniknie, od 2014 nie jestem właścicielem tego forum, przez cały 2023 i część 2022 nie można było się zarejestrować, nie działało wysyłanie mail, pisałem o tym tutaj: http://stacjepogody.waw.pl/index.php?topic=3171.0 . Dlatego założyłem nowe forum o tej tematyce, które znajdziecie tutaj: https://aleforum.pl/index.php?board=4.0
-
(http://stacjepogody.waw.pl/proxy.php?request=http%3A%2F%2Fstacjepogody.waw.pl%2Findex.php%3Faction%3Ddlattach%3Btopic%3D3222.0%3Battach%3D5106%3Bimage&hash=31fbb5d64e2a723f6e3c3b4d317f7cb4)
Z jakiej to jest stacji? Nie potrafię u siebie znaleźć takiego widoku.
Czy ktoś wie gdzie można edytować numerację kanałów czujników wilgotności?
-
Z jakiej to jest stacji? Nie potrafię u siebie znaleźć takiego widoku.
Czy ktoś wie gdzie można edytować numerację kanałów czujników wilgotności?
Ze stacji Sygonix SY-5479628 (https://stacje-pogody.pl/2149_stacja_pogody_sygonix_sy_5479628.html). Jest w "Setup" w pozostałych (innych) ustawieniach "More" więcej ustawień itp.
-
Dzięki, mam.
Właśnie zrozumiałem dlaczego zaciągnęło mi kiedyś dane z PM2.5. Otóż miałem tam dodane dwa takie czujniki, jak i kilka innych których fizycznie nie posiadam (np. WS80).
Stacja była fabrycznie nowa. Czy to możliwe że w procesie produkcyjnym lub testowania parują na próbę jakieś czujniki ze stacją? A nawet jeśli , to chyba później dane powinny być wyczyszczone. W historii mam dane tylko od momentu kiedy ją uruchomiłem, tak samo dane serwisów pogodowych, czy sieci WiFi to to też wszystko było puste.
W tej chwili uporządkowałem listę czujników i mam tylko te własne, ale dziwnie to wygląda.