Wemos D1 odesílání dat přes WiFi do Firefoxu.

[pocitujlasku]

exception 4 je prave ten watchdog, pretecenie je kod 3. V programe mas nieco, co ho zasekne na par sekund. napr. cakanie na data, typu while (!data.available) alebo pod.

[Valdano]

...stále Soft WDT reset...

Napište sem kompletní zdroják jak máte zatím konkrétně řešeného toho klienta, u kterého se to resetování děje. Podle toho pak můžeme zkusit úpravu tak, aby se tomu dalo předejít.

[Celeron]

Už vím, v čem je dílo. Všechny případy WiFi klientů, co jsou v IDE u knihoven pro ESP8266 končí v Loop:

Kód: Vybrat vše

    Serial.println("disconnecting from server.");
    client.stop();

    // do nothing forevermore:
    while (true);

To znamená, že po uplynutí WD se klient rozjíždí znova od Setup. Jak to udělat jinak aby se to obešlo bez WD jsem zatím nezkoumal. Na to zobrazení teplot je to asi vuřt.
Spíš mě trápí něco jinýho. Mám dva objekty každej má svoji WiFi s malinko rozdílným SSID. Pass je stejnej. Pokud měly stejnej název, tak to blblo. No a potřebuju aby ten displej se dokázal připojit na jednu nebo druhou síť. Snad to umí knihovna <ESP8266WiFiMulti.h>

[Valdano]

Už vím, v čem je dílo. Všechny případy WiFi klientů, co jsou v IDE u knihoven pro ESP8266 končí v Loop

Pokud jste v kódu nechal na konci loop() nekonečnou smyčku while (true); pak se není čemu divit, že to jde do resetu na WDT, ale už na první straně tohoto tématu jsem psal, že to máte vypustit. Opakování je vhodné řešit přechody mezi různými stavy, navázání spojení, čtení a čekání atd. a ne resetem v podstatě celého počítače. To je docela "prasárna" vhodná tak leda při nějakém dočasném testování, ale ne pro reálný dlouhodobý provoz i když se vám to třeba jeví jako, že to nemusí nevadit. Obecný způsob řešení jsem naznačil pomocí tzv. "stavového automatu" tj. ten switch kde různé stavy představují jednotlivé case.

To znamená, že po uplynutí WD se klient rozjíždí znova od Setup. Na to zobrazení teplot je to asi vuřt.

Díky tomu resetu se rozjíždí znova celý Wemos, a to není zrovna moc dobré řešení. Zatím bez displeje to vidíte jen přes SerialMonitor, ale až tam doděláte zobrazování na displeji tak ten reset bude pravděpodobně na displeji znatelný.

No a potřebuju aby ten displej se dokázal připojit na jednu nebo druhou síť. Snad to umí knihovna <ESP8266WiFiMulti.h>

Pokud se má klient umět připojit buď na jednu nebo na druhou Wifi síť, ale nikdy nemá být připojen na obě Wifi sítě současně pak nepotřebujete ESP8266WiFiMulti a mělo by stačit si to vyřešit opět ve stavovém automatu v loop(), a to tím, že část pro navázání na Wifi co máte zatím v setup() přesunete do jednoho ze stavů stavového automatu v loop(). Postupné stavy ve stavovém automatu v loop() by mohly být zhruba tyto:

Stav 1: Rozhodnutí zda se bude navazovat spojení do Wifi sítě A nebo B.
Stav 2. Navázání spojení a přihlášení k příslušné Wifi síti.
Stav 3. Navázání spojení klienta k příslušnému web serveru v té Wifi síti.
Stav 4. Poslání žádosti klienta na web server o stránku s daty.
Stav 5. Načtení a vyseparování hodnot z dat přijatých od web serveru.
Stav 6. Zobrazení hodnot na displeji.
Stav 7. Stop klienta a tím i rozvázání spojení s web serverem.
Stav 8. Ukončení spojení vůči Wifi síti.
Stav 9. Stav čekání tj. nějaká prodleva před dalším pokračováním a po uplynutí opět přechod do stavu 1.

Loop() by měl při každém průchodu skončit tj. nic nedržet v nekonečné smyčce while (true) a rozhodování řešit již zmíněnými přechody mez různými stavy ve stavovém automatu.

Nějak tak by to mělo vypadat a pokud nikdy nebudete potřebovat současné spojení do dvou nebo více sítí najednou pak dle mého názoru nepotřebujete ESP8266WiFiMulti.

[Celeron]

ESP8266 MultiWifi se nikdy nepřipojuje na dvě sítě najednou. Umí pouze oscanovat okolí a připojit se na jednu síť s nejsilnějším signálem, která je v seznamu povolených sítí. Pokud se klient přemístí do místa slabého signálu, najde si jinou silnější síť ze seznamu.

[Valdano]

Nikdo z nás tady asi zatím neví jak to chcete vůbec používat. Pokud to tedy zde chcete nějak řešit tak byste měl víc ozřejmit to s jakým konkrétním použitím z hlediska případné mobility u toho klienta s displejem počítáte. Pokud by měl být klient umístěn jen stabilně na jednom místě pak to zřejmě nebude potřeba.

Web server poskytující hodnoty měření bude předpokládám stabilně stále na jednom místě připojený stále k jedné wifi síti. Smysl by to mohlo mít pokud by ten klient měl být mobilní ve smyslu volně přesouvatelný na různá místa třeba ve více objektech, přičemž v každém objektu by byl samostatný web server připojený k samostatné wifi.

[Celeron]

Dnes jsem chtěl nainstalovat server měření teplot do reálnýho provozu a zpátky na stromy. I když mobil při scanu ukazoval v místě umístění serveru teplot -56dBm, Wemos D1 se nechytal. Překvapilo mě, že v místě umístění krom mý sítě nebylo naprosto nic zvenčí. Doprčic, přístupák je 7m daleko ale skrz železobeton strop a je to sklep 180 cm podlaha pod terénem. Takže to, co jsem nechtěl a to tahání LAN kabelu a nejspíš i přidání switche a tahání 230V napájení bude asi realita. Sice existuje Wemos D1 s pendrek anténou, která by možná mohla chodit ale zrovna ho nikde kolem nemaj a že to půjde je nejistý.
Takže jsem se zase vrátil na měření teplot přes UNO a posíláním dat přes W5500 co mi již chodí delší dobu. Zkusil jsem to převrátit z UNO na Wemose D1 a zase to není až tak jednoduchý, některý piny Wemose se chovají dost jinak než na UNO, třeba GPIO15.

No a co ten klient s displejem? No předpokládám, že ho budu občas potřebovat přenýst z jednoho objektu (WiFi sítě) do druhýho. Na tom snad není nic divnýho, to přeci umí každej mobil, tablet i NTB. Navíc to mám koncipovaný tak, aby se na server mohlo kouknout z čehokoliv a i zvenčí přes NAT.

[pocitujlasku]

Nezufaj, vykasli sa na wifi a skus rf moduly na 433Mhz. ak potrebujes preniest par bajtov jednym smerom, tak je to lepsie riesenie a maju aj nizsiu spotrebu. A malo by to preliezt aj cez stenu lepsie ako wifi.
mam na mysli Nieco taketo
prijimac mozes pripojit na wemos a mas data na wifine.
stoji to stovku, a to by stalo za vyskusanie. Arduino ma na to aj kniznice, pouziva to jednen pin a ked vysielace nebudu vysielat naraz, tak vies v pohode prijimat aj z viacerych modulov.

[Valdano]

Doporučuji použít modul sériového portu HC-12 SI4463 na 433MHz, který má ve volném prostoru dosah až cca 1000m. Přes několik zdí se rozsah sice dost zkrátí, ale pořád bude větší než u těch slabších modulů na 433MHz. Vysílač na tomto modulu má nastavitelný výkon až do 100mW. Konfigurace se provádí pomocí AT příkazů jako u modemů. Modul je současně přijímač i vysílač. Návod na použití toho modulu s Aduinem viz tento odkaz předpokládám nebude velký problém si ho upravit pro Wemos.

[Celeron]

No ono se řekne použij HC12 na 433 MHz. Jenže, to bych musel třeba na Arduino Pro Mini, změřit teploty, poslat je přes sériovej port do HC12. Na druhý straně zase HC12, seriový data z něj do ESP8266, tam z toho udělat hatmatilku a poslat ji na WiFi. Stejně bych musel tahat kabel napájení. Při připojení přes LAN můžu poslat data a napájení po jednom UTP.
Dnes jsem lámal Wemos D1 s W5500. Na UNO s W5500 mi to chodilo už dřív, ale stále málo paměti pro dynamický proměnný a ani přesun přes macro F moc nepomohlo. Wemos má paměti podstatně víc a zvládá i ty kupy keců kolem HTML a CSS.
U Wemose je komunikace na LAN docela pakárna. Knihovny Ethernet.h a Ethernet2.h s ESP8266 nechodí. Musí se použít prapodivná kombinace <SPI.h> , <ESP8266WiFi.h> a <W5500lwIP.h>. A před spuštěním ethernetu se musí pomocí SPI nakonfigurovat pár parametrů. No a nakonec připojení na ethernet se musí používat funkce LAN knihovny <W5500lwIP.h> a vytvoření serveru zase volat funkce <ESP8266WiFi.h>. Kdybych nenašel na netu příklad, tak bych to nikdy nedal dohromady.

[pocitujlasku]

ked tam hodis cistu atmegu, nastavis usporny rezim, ze sa ma prebudit raz za cas, zmerat a odoslat, tak to vies napajat dlhu dobu aj z baterky. Schvalne nepisem nejake arduino, lebo to ma v sebe aj prevodnik usb-serial a ten len zvysuje spotrebu.
nemas doma nejaky "server" - pocitac, ktory ti bezi stale? tam by si mohol pichnut prevodnik + HC12 a udaje + stranku generovat tam. Nejake stare raspbery, co ma mizernu spotrebu, ale dostatocny vykon aj na napr. databazu na ukladanie dat. Ja som donedavna tak mal raspi3, kde bezal webserver, databaza, chodili tam logy z mikrotikov a bezal mi tam moj server v .net pre inteligentnu domacnost.

Programovanie nie je o tom, ze pospajam par kniznic a mam hotovo. To je prave ta pakarna, kedy 90% len sedis a kreslis a skusas a 10% je samotne pisanie kodu.

[Celeron]

Právě jsem zmastil i klienta, kterej nepadá na WD. Takže ještě k tomu přibastlit TFT 2,8" a mělo by být hotovo v 1. verzi. Pak to chci ještě trochu vyšperkovat v HTML. Sondy už mám taky v kotelně nabastlený. Tak jen připojit. Plošáky už taky dorazily.

[Celeron]

TFT displej na klientovi mi ukazuje teploty ze serveru. Ještě tam dodělat v grafice trendy teplot proti měření před cca 10 minutama.
Ale narazil jsem na trochu kosmetickej problém. Knihovna GFX.h a ILI9341 nemají podporu češtiny. Nevíte někdo, zda se někde na netu neválí pro tyhle knihovny sady fontů nejlíp v KOI-8, kde jsou od 80h do 0FFh znaky s nabudeníčkama? Že by se mě to chtělo ručně editovat se mě teda moc nechce. V podstatě by mě stačily znaky malý č, á, ý.

[Valdano]

Něco je na GitHubu viz tento odkaz, ale nemám s tím žádnou zkušenost.

[Celeron]

Díky ale nějak se mě s tím nedaří. Vypadá to, že když v GFX nedefinuješ nějakou TT znakovou sadu z podadesáře FONTS, tak to využívá sadu ze souboru glcdfont.c, což je standard ASCII 5 x 7 font. Ten by měl zabírat co znak, to 5 byte. Když jsem si to zkoušel z HEX namalovat, tak vychází nějaký podivný znaky, který sice maji nějakou grafickou logiku ale nepoznávám je. Kdoví, jak to má ta knihovna zorganizovaný. A do jejího rozboru se mě teda vůbec nechce.
Edit: tak jsem zkusil v souboru glcdfont.c do prvních pěti byte zadat 3Fh. Při výpisu char(0) se mi původně prázdný znak vybarvil celý pole. Takže soubor s fonty je správný, tak teď nalýzt v tý hromadě hexu ty správný znaky, přidat k ním nabudeníčka a vrazit je buď někam do rozsahu ASCII 0-31 a nebo nad 127.