Cena je $5 a na AliExpressu je aktuálně vyprodáno: http://www.aliexpress.com/store/product/ESP-32-wireless-Bluetooth-serial-WIFI-module-Transcend-ESP8266/1813344_32646340441.html
To já si umím představit, že by ještě někdo používal starší, pomalejší, méně vybavený a omezenější ESP8266, ale pokud je ESP32 při všech těch vlastnostech i úspornější, tak opravdu zbývá jen argument ceny. Mám ale skoro až špatný pocit dát takovou mašinu někam, kde jednou za X hodin odešle jednu hodnotu, psychologicky se s tím peru :)
Chtěl bych spínat plynový kotel pomocí reléčka a mikročipu. Druhý mikročip bych chtěl v patře domu s teplotním čidlem. Komunikace pak mezi sebou. Přemýšlel jsem o ESP8266/ESP32, ale problém je napájení, baterie by byla vhodnější. Co by se k tomuto účelu hodilo nejvíce? Ideálně něco co se dá snadno programovat, nemám s hardwarem zkušenosti, s pájkou to vůbec neumím (software problém není, C/C++, Lua, Python, cokoliv). Ideálně něco co zapojím do USB, naprogramuju, připojím RF a baterku a jede se :-)
A co chces spinat tim relatkem, kdyz je "napajeni problem"?
Rele spina elektriku. Kdyz mas elektriku nepotrebujes baterku. Spinat rele baterkou je nesmysl. To rele by ti tu baterku hned vyzdimalo.
Nejjednodussi je samozrejme zaplatit si reseni od specializovany firmy.
Pokud ale chci levny reseni, tak musis resit jestli ti 2.4GHz signal projde z patra ke kotli (da se vyzkouset pokud mas v patre Wifi router, tak jestli mas wifi signal na mobilu u kotle).
Pokud ano, muzes pouzit treba nodemcu modul z ebay za 75Kc coz je ESP8266 s USB pripojenim a vystupama do breadboardu a programuje se bud v lua, v pythonu nebo pres Arduino IDE ci platformio v C. K tomu modul relatka, AC-DC adapter na 3.3V, nakej ten breadboard a dratky na propojeni a vejdes se do par stovek. V patre pak pripojis naky teplotni cidlo bud primo k pocitaci (raspberry) nebo muzes pouzit zas nodemcu a pripojit k nemu modul teplotniho cidla.
Pokud by ti 2.5GHz ke kotli neprochazelo je lepsi pouzit misto nodemcu arduino s modulem na 433MHz. Dnes asi nepopularnejsi sou moduly RFM69HW s velkym dosahem, ale tam uz se bez aspon zakladniho pajeni asi neobejdes.
Co se tyce napajeni na baterku tam je potreba peclive vybirat jednotlivy komponenty podle spotreby v aktivnim stavu i spotreby ve spanku.
ESP staci pridat v board manageru a chova se jako normalni arduino akorat s wifi funkcemi navic ;) https://github.com/esp8266/Arduino
Asi nebude mít smysl použít Arduino + periférie když tohle s přehledem zvládne všechno a cena bude podobná jako Arduino + periférie... Odpadnou tím starosti o vzájemnou komunikaci, celý to bude nejspíš i úspornější atd. Holt bude ve většině aplikací více než velká výkonová rezerva, ale zase ovládání bude daleko pohodlnější a rychleji se dojde k funkčnímu výsledku. Už se na to těším.
Jinak ten ESP8266 jak již bylo řečeno v článku se dá programovat přímo (SDK, Arduino IDE) a někdy ani to Arduino není potřeba (pokud to podmínky dovolí). Já jsem s tím např. pomocí SDK vytvořil WiFi rádio - ESP8266, 1Mbit SRAM, VS1053, LCD/OLED + tlačítka (I2C port expander) a ještě mám v GPIO rezervu jednoho pinu na přímé připojení SD karty např. pro případné přehrávání MP3...
A co vy si představíte pod pojmem "prototyp"? Řada lidí si pod tím představí první kus, na kterém se v ostrém provozu ověřuje funkčnost. Takže fakt, že většina desek má šílenou spotřebu energie, pro některé oblasti problém je a prototyp se s tím postavit nedá. Pak se buď sáhne po něčem jiném, nebo se použije vlastní deska a Atmega.
Jako prototip to nejspíš nepoužívá vůbec nikdo.
Pokud to však někdo nepoužívá jen jako vývojovou nebo prototypovou desku, je to jeho problém. Arduino se k vestavbě do sériového zařízení naprosto nehodí - nikdy pro to nebylo navrženo. Snad Arduino Micro, za určitých podmínek, má smysl zabudovat do něčeho jiného než je zařízení, určené k výuce a experimentování...
To bylo myšleno tak, že pokud někdo používá Arduino (desku) a k tomu potřebuje ESP8266 tak ESP32 bude nejspíš úspornější než Arduino + ESP8266 a nebude se muset řešit komunikace mezi deskama, protože to bude vše v jednom pouzdru a navíc to bude zabírat i méně místa v prostoru. Předpokládám, že WiFi půjde vypnout, stejně tak i BT + nastavit nižší rychlost a spotřeba od Arduina se moc lišit nebude. Asi takhle, pokud budu potřebovat WiFi nebo BT šáhnu rovnou po ESP32 než to skládat z x desek.
Pokud bude cena obdobná, tak dle mého skromného názoru se vyplatí rovnou použít ESP32. Protože:
1. úspora programátorského času, bo je snazší poznat detailně jednoho zařízení než dvě
2. zařízení je úspornější co se týká spotřeby energie
3. s vypnutou wifi to s klidnou duší použiji jak Arduino, PIC, ... protože cena (a výkon)
4. pokud je potřeba nějaké připojení, tak to wifi&spol jen zapnu
Tak vzdycky najdes extremni pripady. Muzes treba chtit simulovat psani na klavesnici, kde ti ani ESP32 nebude stacit. Ale realne kolik takovych pripadu ma prakticky vyuziti. Ten priklad s prackou ale dost pokulhava. Vazne existuje pracka, ktera ma vic jak 16 tlacitek? Moje pracke se susickou ma dve tlacitka, jeden otocnej ovladac a dotykovej display s deseti kapacitnimi sensory a rek bych ze vic uz by bylo spis na skodu.
Veřejně to vystavené nikde nemám. Je to založené na těchto dvou projektech:
https://github.com/PiotrSperka/ESP8266-WebRadio
https://github.com/espressif/esp8266_mp3_decoder
Koukám, že v tom prvním projektu si tam SRAM mezitím taky dodělal, ale nemá tam displej a I2C expandér na tlačítka (ten je nutnost - ESP8266 má málo GPIO)... Bez SRAM to funguje, ale musí být dobrý příjem a bez SRAM se občas (nebo spíš dost často) rozjedou metadata s audiem (stačí drobný výpadek a zvuk není konzistentní). Když se metadata nepřijímají tak to docela obstojně funguje i bez SRAM. S SRAM a zapnutými metadaty mi to běželo půl dne bez nejmenších zádrhelů. Nemám tam tedy web server a žádnou možnost uživatelského nastavení. Ale je to rádio pro malého kluka a tomu stačí třeba deset předdefinovaných stanic ve zdrojáku (no spíš řekněme dvě a zbytek bude pro nás - rodiče a i dvacet dalších stanic je nad naše možnosti je využít, samozřejmě jich tam můžu nadefinovat třeba 200...). Překlad a nahrání nového firmware s aktualizovanýma stanicema je otázka půl minuty. Beztak by i za 10 let nevěděl co má přes ten web server nastavit - je mu rok a půl :-).
tak on tam nema svuj zdrojak, pouze odkazy na inspiraci, prace v Arduino IDE je opravdu tak hobby projekty, i na XP mi to casto pada i v beznem editoru kdyz pisu zdrojak, naprosto nevypocitatlne a nahodne, tak by me zajimalo nejake lepsi free prostredi, uvidime ... platformio. Mrknu.
> prace v Arduino IDE je opravdu tak hobby projekty, i na XP mi to casto pada i v beznem editoru kdyz pisu zdrojak, naprosto nevypocitatlne a nahodne, tak by me zajimalo nejake lepsi free prostredi
Hledej "Arduino makefile". Pak můžeš používat libovolný editor nebo IDE (třeba i NetBeans) a projekt se kompiluje standardním makefile.
Jako IDE mám Eclipse a je to psaný přímo pomocí SDK. Nikdy před tím jsem s ESP8266 + SDK nedělal, ale za pár dní jsem se do toho trochu dostal abych dokázal upravit ty stávající kódy na to co potřebuji + přidat pár věcí. Nicméně ten Polák má mimo tlačítek už vše napsané tak tam stačí dopsat jenom kód pro ten expandér portů + případný displej.
Máte nějaké konkrétní typy na H8, které by měly podobné parametry jako ESP32 a byly sehnatelné i v počtu několika málo desítek kusů?
Já co jsem našel, tak buď už se neprodávají, nebo mají MOQ v tisících. Přijde mi, že je to typický produkt pro velkoodběratele, který se k normálním smrtelníkům nedostane.
RPi není real-time, takže když budu potřebovat něco sledovat kontinuálně, mohu např. použít smyčku v arduinu a RPi si bude řešit své + občas si přečte pár pinů z arduina. To o RPi ani nemusí vědět, jede si pořád svou smyčku bez přerušení. Náklad + 30 Kč, to se někdy za zjednodušení práce RPi vyplatí. Jistěže to jde i jinak, ale někdy je dobré různé funkce od sebe oddělit.
Jestli RPi je nebo neni realtime zavisi na pouzitym OS/programu. To nesouvisi s HW.
Pokud bych k tomu pouzil Arduino, tak zamozrejme o RPi musi vedet minimalne v tom, aby nakou tu komunikaci s nim umoznilo. Je to naklad navic a programovani navic, ktery pri dobry navrhu neni nutny.
To Arduino bych pouzil pouze v pripade, ze nebudu pocitat s RPi, ale ze komunikace muze probihat jakymkoli pocitacem, treba pres USB. Pak je zase samozrejme moznost se vyprdnout na Arduino a pouzit treba ESP a umoznit tak bezdratovou komunikaci pres Wifi.
No ja pouzivam GCC a do 2 kB se mi vesla bitbangovana komunikace pres I2C s teplotnim cidlem MCP9808, komunikace pres SPI s NRF24L01+ a power management jak pro ATTINY, tak pro MCP i NRF.
V assembleru sem jen kontroloval, ze se to I2C preklada z C spravne.
Psat v assembleru na Arduinu s 32kB Flash mi prijde trochu jako zbytecnej masochismus.
Proč byl autor tak kreativní, že z "Hardware accelerated encryption: AES / SHA2 / Elliptical Curve Cryptography / RSA-4096" udělal akcelerované *SSL*?
Když už pominu, že doufám, že měl na mysli "TLS", tak to nedává vůbec smysl. Má smysl akcelerovat konkrétní krypto-operace a -algoritmz, ale akcelerace protokolu "TLS" je akorát buzzword.
Vymění se používaný algoritmus, a celá akcelerace je k ničemu.
Takže docela by mě zajímalo jestli "AES" znamená AES-128, AES-256 a/nebo AESGCM? Znamená "SHA2" SHA-224, SHA-256, SHA-384 a/nebo SHA-512? Znamená "Elliptical Curve Cryptography" (správně "Elliptic Curve Cryptography") NIST křivky nebo djb křivky nebo co vlastně?
Autor přeložil následující větu z mailu fy Espressif Systems vývojářům a zkrácenou použil v článku:
"Security: Besides integrating hardware accelerators for AES and SSL, we have implemented several important features that are crucial to building secure systems."
Protože zároveň tušil, že ta informace není dost konkrétní ani přesná, přidal do článku odkaz přímo na stránky výrobce, kde snad budou ty nejvíc správné a přesné informace.
To je bohuzel jen pulka informace. Ta druha pulka jsou jejich vlastni upravy. Z toho co tu bylo napsano, tak je ta druha pulka uzavrena. Takze dostaneme pulku auditu - pokud audit najde lwip chybu, muze udelat test a potvrdit ze chyba je i v tomto cipu. Bohuzel to kvuli cemu audit delame: dokazat, ze tam nejsou dalsi chyby, se nepovede.
Nevím, co myslíte, že tu bylo napsáno.
Espressif System se IMHO postupně učí významu open source. Za dva roky na sobě udělali opravdu velký kus práce, a s ESP32 dle svých vlastních slov udělají vše správně hned od začátku. Ve své čínské angličtině John Lee napsal, že cokoliv "above high MAC" bude mít otevřený zdrojový kód. To by se snad mohlo týkat celého TCP/IP stacku. Takže neházejte flintu do žita...
Velmi velmi velmi zajímavý chip. Ovšem z hlediska použitelnosti mě ještě zajímá, v jakých se bude prodávat modulech. Mám doma ESP-01 a ESP-08. To první komunikuje pomocí UARTu jak má, ale zatím jsem neměl čas laborovat s ním natolik, abych si troufnul flashnout firmaware. Ten druhý mi prostě nejede, neumím ho nabootovat do režimu UARTové komunikace, ačkoliv jsem tím strávil cca 6 hodin.
Pokud budou moduly rozumně programovatelné ve stylu Arduina, bude to být pro bastlíře skvělá zpráva.
Pak je samozřejmě otázka, kolik z nich vymyslí něco jiného, než kolo nebo zmrzlinu, která bude twitterovat svou teplotu, či třeba pomocí smartphonu spínanou blikačku na kolo... Přijde mi, že cca 90 % DYI projektů jsou prostě nesmysly.
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.