ESP-01s: Jak wyświetlić dane z kilku modułów na jednej stronie HTML?

Witam
Jak nie ten dział proszę o przesunięcie.

Problem zapewne banalny ale ponieważ mam małą wiedzę (potrzeba trochę więcej niż sam HTML) , nie mogę jakoś tego przeskoczyć. Coś mi umyka w rozumowaniu. I nie wiem nawet jak zadać pytanie w google by uzyskać odpowiedź którą w dodatku będę umiał zrozumieć .

Zacznę od tego co mam i co chcę osiągnąć:
Mam trzy ESP-01s.
Każdy z nich za przy wykorzystaniu dodatkowego "modułu" mierzy temperaturę (docelowo jeszcze będzie i ciśnienie).
Na każdym jest "postawiony" serwer. ( ładnie brzmi ) i mogę się z każdym połączyć wpisując w przeglądarkę lokalny adres.
Pojawia się wtedy strona która automatycznie aktualizuje (co 500ms) odczytane dane (temperaturę). Więc wszystko niby działa jak należy.

Teraz chce na swoim komputerze lub bardziej na czwartym ESP-01, otworzyć jedną stronę html i zobaczyć na niej temperaturę z każdego ESP oddzielnie. Oczywiście te dane mają się "same" aktualizować powiedzmy co minutę.


Poniżej kod wgrany do ESP (aby było prościej zamiast czujnika jest przekazywany czas - to nie jest ważne)



Taka jest strona index.html też wgrana do ESP:


Wszytko powyżej działa ok.
Dla zasady napiszę też że jak wpiszę w samą przegladarke adres ESP "łamany" przez "adc" ( 192.168.0.10/adc ) otrzymuje sam wynik.

Teraz główne pytanie:

Jak "zapytać" poprzez stronę html umieszczoną na innym serwerze lub na moim komputerze, poszczególne ESP by mi "oddały" swoje chwilowe dane i by się odświeżały co np. sekunda?

To poniżej (dla jednego ESP) nie działa (strona/plik na moim lokalnym komputerze):


Na marginesie sprawdziłem że przy takim rozwiązaniu readyState jest 1 a status = 0

Co zmienić aby to działało? czego nie rozumiem?

A może inne podejście? Jestem otwarty też na inne rozwiązania

Przeglądarki mają zabezpieczenia przed pobieraniem treści bez szyfrowania z innych adresów niż wczytana strona (przez http zamiast przez https). Zobacz czy przeglądarka nie zgłasza jakiegoś błędu przy wykonaniu skryptu.

Tak jak wspomniałem, jeżeli w przeglądarkę wpiszę http://192.168.0.10/adc otrzymuje sam wynik (http samo "ucieka"):


Przy zastosowaniu "kodu dla strony" w komputerze lokalnym nie pokazuje w konsoli żadnego błędu, ale i nic się nie odświeża.




Ale składnia tego zapytania i jego pobrania jest w porządku?

Dodam do powyzszego:

Warto poznać przeglądarkowe narzędzia developerskie, np wbudowane w przeglądarkę Firefox.
Można śledzić dokładnie wszystko co się dzieje, co transmituje, co wyświetla, debugować kod javaScript

Nie znam wszystkiego, ale na początek daj prawy klik na stronie / Zbadaj i się rozejrzyj

U góry jest informacja o 20 błędach. Czego one dotyczą ?
Kliknij na zakładkę "sieć". Zobacz czy operacja XMLHttpRequest jest wykonywana i czym się kończy.

Przepraszam dopiero teraz mogłem podejść do komputera.
Rzeczywiście są błędy:
"Zablokowano żądanie do zasobu innego pochodzenia: zasady „Same Origin Policy” nie pozwalają wczytywać zdalnych zasobów z „http://192.168.0.9/adc” (brakujący nagłówek CORS „Access-Control-Allow-Origin”). Kod stanu: 200."

Czy jest sposób jak to ominąć?

Teraz jest błąd z inna "końcówką"

Musisz zrealizować w ESP serwer HTTPS.

TvWidget napisał:

Musisz zrealizować w ESP serwer HTTPS.

Masz namiary jak to można zrobić? bo sama zmiana nr portu to za mało.


Albo jak innym "prostym" sposobem pobrać dane z ESP i je przedstawiać na bieżąco.
Lub żeby ESP sam wysyłał dane na "obcy" serwer/komputer.

Możesz też pokombinować z dodaniem do nagłówka "Access-Control-Allow-Origin”. To obecnie może już nie zadziałać.

Dodano po 8 [minuty]:

Wysłanie na zewnętrzny serwer oczywiście zadziała.
Zobacz np. https://nodered.org/ Jest to prosty do konfiguracji serwer dedykowany dla automatyki. Może pobrać dane z czujników w takiej postaci jak obecnie i przedstawić je na stronie WWW.
Aplikacja w zasadzie nie wymaga pisania kodu. Stawia się na pulpicie odpowiednie bloczki i łączy się je liniami (wyjście z wejściem). W uproszeniu stawiasz trzy bloczki http client. Wpisujesz do każdego z nich adres URL czujnika. Następnie stawiasz np. trzy pola tekstowe lub wykresy. Ich wejścia podłączasz do wyjść http client.

A może spróbuj protokołu ESPNOW - w necie znajdziesz przykłady.
Warto zajrzeć do tematu na Forum:
https://www.elektroda.pl/rtvforum/topic3672038.html

TvWidget napisał:

Zobacz np. https://nodered.org/

Tego nie znam i muszę trochę z tym popracować i stwierdzić czy mnie "zadowoli"

Co do ESP-Now niby jest to rozwiązanie, ale nie do końca bo i tak musiałbym mieszać "NOW" z wifi. (co jest niby podjęte w tej dyskusji). Docelowo czujników ma być ok 20, średnio po trzy na pomieszczenie. W każdym pomieszczeniu jest AP wifi, z tym że każde z pomieszczeń jest "klatka Faradaya" więc czujniki nie będą się "widzieć" i trzeba by było mieszać protokoły przynajmniej na jednym ESP. Ale muszę się z tym przespać.

Na chwile obecną dziękuje kolegom za rozjaśnienia sytuacji.

Myślę jeszcze jakby wprowadzić coś do kodu, tak by każdy ESP wysyłał sam dane np w formie prostego pliku txt np co minuta do udostępnionego folderu w sieci.
A może ktoś ma jeszcze jakiś pomysł więc jeszcze nie będę zamykał topiku.

A może: https://arduino.stackexchange.com/questions/5...low-cross-domain-requests-on-esp8266webserver
Poza tym najlepiej do takich rzeczy używać mqtt

1. Na standardowy serwer HTTP możesz wysłać dane przez POST. Czyli czujnik musi być klientem HTTP a nie tak jak do tej pory serwerem.
2. MQTT to obecnie dość popularny sposób przesyłania danych. Użycie serwera MQTT będzie dobrym rozwiązaniem jeśli chcesz wyświetlać wyłączenie pomiary on-line. Tu też wymagana jest modyfikacja oprogramowania czujnika.

marek003 napisał:

A może ktoś ma jeszcze jakiś pomysł

Zróznicowane propozycje różnią sie więcej, niz proponowany protokołem (choć też ważne, binarny będzie mniej obciążał maleństwa)
a) posiadanie "punktu centralnego" który trzeba utrzymywać / lub jego brak
b) odporność na częściową niedostępnosć któergoś z hostów / klientów
c) działanie (lub nie) gdy "nikt nie patrzy", np gromadzenie informacji przez limitowane okno czasowe lub długo - do późniejszego wykorzystania
d) konieczność konfigurowania firewalli lub nie
e) i na pewno jeszcze inne

Oraz oczywiście zmienia się początkowa filozofia, że jedynie strona integruje dane cząstkowe w N operacjach HTTP/S - z puntu widzenia końcowej przegladarki filozofie są zupełnie odmienne

xury napisał:

A może: https://arduino.stackexchange....n-requests-on-esp8266webserver

Używam trochę innej biblioteki ale mocno mnie naprowadziłeś, choć ktoś już wcześniej wspomniał o dodaniu nagłówka ale ja jeszcze pod tym względem nie do końca wiedziałem o co chodzi. Poz tym to nagłówek dla "CORS".
Ale w wykorzystanej przeze mnie bibliotece ESPAsyncWebServer na stronie GitHub pod koniec informacji dotyczących tej biblioteki jest:

W niektórych przypadkach, na przykład podczas pracy z CORS lub z jakimś niestandardowym systemem uwierzytelniania, Być może trzeba zdefiniować nagłówek, który powinien zostać dodany do wszystkich odpowiedzi (w tym statyczny, websocket i EventSource). Program DefaultHeaders singleton pozwala to zrobić.
Przykład:


Jak dodałem tą linię (tą pierwszą) przed uruchomieniem serwera wszystko ruszyło.
Więc jestem zadowolony że mój pomysł jednak zadziała.

Co do MQTT i reszty... powoli ja już mam swoje lata i nie łapie tak szybko "nowych systemów". Dodatkowo jestem ekonomistą a nie programistą więc zanim załapie o co chodzi musi chwila minąć.
Zapewne do tego dojdę, ale na razie małymi kroczkami. Chce ruszyć cokolwiek by zaczęło działać. Bo jak działa to to w jakiś sposób "uskrzydla" człowieka i chce się dalej pracować nad pomysłem i później zmieniać coś dalej by było lepsze.

TvWidget napisał:

Na standardowy serwer HTTP możesz wysłać dane przez POST. Czyli czujnik musi być klientem HTTP a nie tak jak do tej pory serwerem.
2. MQTT to obecnie dość popularny sposób przesyłania danych. Użycie serwera MQTT będzie dobrym rozwiązaniem jeśli chcesz wyświetlać wyłączenie pomiary on-line. Tu też wymagana jest modyfikacja oprogramowania czujnika.

Na chwilę obecną bardziej mi pasuje opcja "serwera" HTTP na każdym czujniku by móc "wejść" na każdy indywidualnie (a przy okazji dokonać na nim zdalnej wymiany oprogramowania). Ale wg mnie to nie przeszkodzi w razie czego wysyłać dane przez POST - ale mogę się mylić.
Modyfikacja oprogramowania "czujnika" nie jest problemem ale właśnie słowo "serwer" mnie trochę przeraża że będę musiał stawiać jakiś oddzielny komputer, zarządzać dostępem itd. (do serwera HTTP na ESP już się przyzwyczaiłem - nie mniej to też oddzielne urządzenie i też jak widać dopiero się tego uczę)
Wiem że teraz wyolbrzymiam ale nie mam za dużo wiedzy, choć dużo się domyślam i powoli wchodzę do tej krainy połączeń sieciowych, protokołów, zapytań, serwerów, baz danych itd.

Mnie na studiach uczyli elementów Turbo Pascala a językiem obcym był rosyjski więc ze stronami z wyjaśnieniami po angielsku radze sobie średnio. Niemniej dobrze że one są.

JacekCz napisał:

Zróznicowane propozycje różnią sie więcej, niz proponowany protokołem (choć też ważne, binarny będzie mniej obciążał maleństwa)...

Tak jak pisałem wcześniej. Docelowo chce zrobić "system" monitoringu temperatury w różnych pomieszczeniach z "alarmami" jakby coś było nie tak i jak najbardziej z możliwością obejrzenia historii (danych a może i na wykresie).
Ponieważ nie mam za dużej wiedzy więc robię to na razie małymi kroczkami i jestem otwarty na różne rozwiązania.
Cały projekt jest bardziej dla mojej satysfakcji i zdobycia wiedzy niż do jakiegoś poważnego wykorzystania - niemniej jak już będzie działał bez zarzutu, zostanie na pewno wykorzystany.
...

a) posiadanie "punktu centralnego" który trzeba utrzymywać / lub jego brak
Wydaje mi się że to rozwiązanie jest jak najbardziej pożądane. Mam dwa fizyczne serwery (windows server) które pracują non stop ale mam trochę małą wiedzę jak to by podpiąć by nie popsuło dotychczasowego ich działania i żeby czegoś przez niewiedzę/niedopatrzenie nie otworzyć.
Mam tez parę komputerów (windowsów) które działają non stop więc chyba na razie zacznę od tego.

b) odporność na częściową niedostępnosć któergoś z hostów / klientów
Docelowy program / strona ma dalej działać ale podnieść alarm jak któryś czujnik "zginie" lub pokaże nieodpowiednią wartość.

c) działanie (lub nie) gdy "nikt nie patrzy", np gromadzenie informacji przez limitowane okno czasowe lub długo - do późniejszego wykorzystania
Jak najbardziej powinien zachowywać dan i działać. Myślałem o wykorzystaniu na samym ESP systemu plików LittleFS i pliku txt w którym po sobie wpisywane by były: data, godzina i wynik, a po zapełnieniu powiedzmy 200 kb dane w środku pliku by się nadpisywały od najstarsze.
Przy czym komputer/serwer na którym wyświetlane by były wszystkie dane z czujników tez powinien mieć "własną" i niezależną historię o wiele dłuższą niż 200 kb.

d) konieczność konfigurowania firewalli lub nie
Tu nie wiem co odpisać - nie chciał bym nic otwierać. Na dziś widzę to tylko w sieci lokalnej ale ... jeżeli by to było naprawdę bezpieczne można by to pokazać i na zewnątrz ale nie jest to priorytet.

e) i na pewno jeszcze inne
zapewne tak Ale powoli, nie wszystko na raz. Mi się nie śpieszy i robię to dla własnej wiedzy i satysfakcji więc nie ma ścisku.

Na chwilę obecną dziękują wszystkim za dotychczasowe porady.
Strasznie się ciesze że moja pierwsza koncepcja zadziała - czy ją wykorzystam po waszych sugestiach to inna sprawa
i ewentualnie czekam na więcej np. namiary na stronę ugryźć ESP i to mqtt lub może zacznijmy od jakiś "łopatologi" z samym MQTT

marek003 napisał:

Przy czym komputer/serwer na którym wyświetlane

No właśnie do takich przemyśleń chciałem sprowokować. Komputer na którym jest wyświetlane to NIE JEST serwer w projekcie koncepcyjnym (w wariantach, w których serwer w ogóle istnieje)

marek003 napisał:

Docelowy program / strona ma dalej działać ale podnieść alarm

Program to nie strona (w sensie ogólnym).

marek003 napisał:

Mam tez parę komputerów (windowsów) które działają non stop więc

Problem adresacji (znów, jest odmienny gdy mowa o kleinatch, odmienny gdy o hostach / miniserwerkach). Ciężko złapać różnicę bez głebokiego zrozumienia podstawowych koncepcji sieciowych.

Dodano po 2 [minuty]:

marek003 napisał:

jeżeli by to było naprawdę bezpieczne można by to pokazać i na zewnątrz

To mocno akcentuje PORZĄDNY (w sensie dobrze koncepcyjnie zaprojektowany serwer) - prezentację należy widzieć jako coś zupełnie innego (oddzielić te koncepcje).
Wydaje sie na zewnątrz jest awykonalny scenariusz "o! pojawił się nowy czujnik". Niektóre sposobiki (na datagramach, adresach rozgłoszeniowych itd) sa dostępne tylko w LAN

Dlatego tu chodzi o głębsze koncepcje niz "pstrykajmy protokołem X zamiast Y"

JacekCz napisał:

Dlatego tu chodzi o głębsze koncepcje niz "pstrykajmy protokołem X zamiast Y"

Jacku, właśnie o to chodzi.
Mam za małą wiedzę by wiedzieć od razu czego chcę i zdaję sobie sprawę że moje pytania dla znawców mogą być banalne lub wręcz nieinteligentne. A powiedzmy ostatnim pytaniem po wielu wcześniejszych wyjaśnieniach mogę załamać kogoś, bo trzeba by było od początku zmieniać całą koncepcję. Ale dzięki temu mogę coś poznać i zrozumieć.

Jakbym od razu napisał że chce zrobić aplikacje na serwer która monitoruje temperaturę w paru pomieszczeniach i docelowo poprzez stacje roboczą chciałbym zarządzać każdym czujnikiem. Dodatkowo o alarmach chciałbym być informowany smsami, to jeżeli już byś chciał podjąć temat to zapewne zarzucił byś mnie tak fachową wiedzą żebym usiadł i ... zrezygnował, bo bym nie wiedział o czym mówisz.

Tym razem mam podejście "od szczegółu do ogółu".

Tak na szybko:
Najpierw "odkryłem" mikrokontrolery i moduły. Potem nauczyłem się je programować by np. mierzyły temperaturę z paru czujników z wykorzystaniem I2C i pokazywały to na wyświetlaczu. Potem okazało się że mogą to pokazać również "w sieci" więc znów trochę wiedzy o HTML (i przykłady) i już widzę na stronie wyniki pomiarów. Teraz (po tym topiku) już wiem jak pokazać na jednej stronie wyniki z różnych modułów ESP które się aktualizują same na bieżąco. Na razie tylko pokazać ale ...

Wiem że "strona" to nie program ale za pomocą skryptów w jej kodzie można zrobić wrażenie działającej aplikacji. Do pokazania parunastu temperatur powinna wystarczyć. Wiem że to toporne rozwiązanie ale dość szybko i prosto na tło w postaci np zdjęcia domu (przekroju domu) mogę "nałożyć" w odpowiednich miejscach/pokojach daną temperaturę i już jest efekt "łał". temperatura będzie się stale aktualizować a w razie przekroczeń będzie piszczeć i mrugać. (Oczywiście tym zarządzać będą skrypty w kodzie strony).

Miło by było napisać samodzielny program w C++ ale jestem na to za mały (jeszcze )

O tym wszystkim co wspamniałeś mam jakąś wiedzę ale właśnie nie chcę za bardzo o to pytać bo gdy odpowiesz to nie wiem na chwile obecną czy zrozumiem i będę wiedział z czym to ugryźć.

Np to:

Cytat:

Problem adresacji (znów, jest odmienny gdy mowa o kleinatch, odmienny gdy o hostach / miniserwerkach). Ciężko złapać różnicę bez głebokiego zrozumienia podstawowych koncepcji sieciowych.

No właśnie. Coś wiem, ale nie dogłębnie i znów nie wiem czy zadając pytanie nie załamie jakiegoś fachowca
Myślałem i o tym. Np. by czujniki działały na innej puli adresowej (chyba tak się mówi) bo z obecnej puli 254 adresów niewiele zostało.

Myślałem by czujniki działały we własnej sieci / miały pulę np 192.168.101.01-254 Oczywiście fizycznie by to była ta sama sieć/ te same kable (i nie wiem czy APy wi fi).
i jakoś przekazywały dane do sieci "głównej": 192.168.1.1-245. (przekazywały lub pozwalały "siebie" odczytać)

Nie wiem Nawet nie wiem do końca jakie są możliwości. i czy to zależy tylko od mojej stacji roboczej i wpisaniu nr IP czy jeszcze od ustawień głównego routera w sieci (mam mikrotika).
Dlatego na razie robię wszystko po kroczku by się nie załamać brakiem własnej wiedzy.

marek003 napisał:

ale właśnie słowo "serwer" mnie trochę przeraża

Inaczej niż w handlu sprzętem komputerowym, w teorii sieciowej słowo "serwer" nie wiaże się z wielkością, ceną, zużyciem prądu - to tylko funckja w sieci. Przeciwną jest client. Choc piszesz:

marek003 napisał:

do serwera HTTP na ESP już się przyzwyczaiłem

Wskażę ci jeszcze konieczny podział "projektów badawczych" a "projektów produkcyjnych". Trzeba wiedzieć który projekt jest który, bo mozna samego siebie mocno oszukać. Do pewnej chwili kontunuowac ten tu omawiany, potem zarzucić na rzecz zupełnie nowego, z inną architektura. Nie kontynuować prowizorek. Swoją rolę spełniły, dały doświadczenie

Abstrakcje
Na poziomie planowania koncepcji nie pipcymy się z "prokołem POST", choćby dlatego że może wcale nie bedzie HTTP (choćby MQTT i inne propozycje). Zbyt wcześnie wziąć zbyt dużo szczegółów na klatę to porażka.
Podobnie na poziomie koncepcyjnym składowanie danych określamy abstrakcyjnie, wewnętrzna realizacja plik txt czy mini bazka z zewnątrz nie ma znaczenia (nie jest udostępniana bezpośrednio)

Protokoły
Główny podział na głębokim poziomie to
request-response, synchroniczne, wśród nich HTTP
protokoły asynchroniczne, teraz coś puszczam, a kiedyś w przyszłości może coś dostanę. Tu należa publish-subscribe, np MQTT

Nawet nie próbuję dać pełnej wiedzy, bo się nie da. Kilka strzałek na mapie.