Podívej se, jak máš nastavený beacony (obvykle jednotky ms). Na delší dobu ho neuspíš. Navíc musíš generovat aktivitu, i když se nic neděje, aby nespadl TCP socket,... Pokud jde o low power, WiFi bylo, je a (zdá se, že i) bude odepsaný.
Když připočítáš relativní náročnost stacku, bezpečnost (může být přímo vidět z internetu / napíchnuto z mobilu), latence při výskytu 50 sítí v jednom miístě a další srandy okolo, tak je WiFi v IoT celkově tak nějak nepoužitelný :/
Je nejaky rezim ktery by to jenom poslouchalo pri co nejnizsim moznem prikonu a na dotaz by to odeslalo data a zase jen poslouchalo? Pokud tam pustim demo app s OLED displayem co vypisuje silu signalu a jinak tam po WiFi zadna data netecou tak to bere cca okolo 80mA, z toho OLED cca 10mA. Je v otmhle nejaka sance to jeste srazit aby byl jen na prijmu a pokud mozno (energeticky narocne) nic neodesilal?
Tak režimy pro sníženou spotřebu (sleep) na klientovi (CLI) jsou už ve starších verzích 802.11, otázka je, zda by je uměl ESP32 a samozřejmě zda to podporuje příslušný AP (např. speciální pole v beacon). 802.11ah dokonce může nechat CLI naslouchat např. každý 4. beacon v němž AP signalizuje CLI pořadavek na komunikaci. I přístup do kanálu od CLI se dá z hlediska spotřeby vylepšit, např. pomocí Restricted Access Window nebo správným managementem při uspávání stanic CLI. Viděl však někdo někdy WLAN zařízení v takovémto provozu?
Jakmile jsme ale v řádu minut a více, je nejlepší CLI uspat a v dohodnutých intervalech probouzet a znovu se do WLAN přihlásit.
no ten rezim by mel byt v tom smyslu ze by mel pozue kontinualne naslouchat, v nejhorsim tak treba co deset sekund kratce komunikovat jestli pro nej nejsou nove zpravy na serveru. Mam to postavene na ESP8266, ESP32 zatim neplanuji vzhledem k tomu ze na tohle mam vyrobene jiste mnozstvi PCB a vlastne me ta zprava o ESP32 nastvala, kdyby prisla o mesic driv tak bych to postavil cele na nem, takhle si pockam az se na ESP32 udela komunita, IDE bude nejake rozumne, SDK a cena taky pujde dolu. Takze zpet, nejeake napady na ESP8266 a kontinualni prijem bez energeticky drahych odpovedi?
Získat dokumentaci k rádiu v ESP8266 a přepsat ten jejich binární blob tak, aby byly podporovány "power saving" procedury 802.11. Samozřejmě tyto procedury musí umět i AP, takže nejlépe si napsat AP na ESP, protože na "power saving" procedury výrobci WLAN krabiček z vysoka kašlou. Jasně, tohle je nereálné, zvláště když ESP8266 je mrtvý (ať žije ESP32). Takže jediná šance na snížení spotřeby s ESP8266 je provádět management na nejvyšších vrstvách, tj. v dohodnutém časovém intervalu probouzet rádio na ESP autentifikace/autorizace/výměna dat nějakým protokolem/odhlášení/uspání rádia. Pokud se to bude dít v delších časových intervalech, tak spotřeba na to, že je to 802.11, nebude tak šílená. Stále však zůstává nutnost použití napájecího zdroje schopného dodat pořádný proud po jistou dobu.
S příchodem ESP32 je tu šance, že kód rádia bude uvolněn. Pak by snad bylo jen otázkou času, kdy komunita "power saving" procedury přidá, nebo dokonce znásilní rádio k trochu jinému pro IoT vhodnějšímu režimu komunikace, než 802.11. Anebo se objeví nějaké jiné laciné moduly vhodné pro IoT ala NRF s větším výkonem. Uvidíme.
To je nějaké divné, kolega (http://www.valachnet.cz/lvanek/diy/iot/index.html) to provozuje na dvě slušné baterky minimálně dva měsíce.
Powerbanka muze mit mizernou ucinnost pri nizkych odberech. Precijen je to opacne pouziti, nez na jake je stavena. Kdyz neco nabiji "vysokym proudem", treba pul ampery, tak se v tom nejake miliampery (na zobrazeni stavu pomoci led, ziveni chipu,hlidajiciho spotrebu a dalsi kraviny) uplne ztrati.