Biztos, hogy az esp termeli a meleget, nem a transzformátor? Lehet, hogy a PUR hab önmagában is megoldaná a problémát.

Ja, egy fontos dolgot elfelejtettem megemlíteni.
Egyelőre szó sincs dobozról. Az egész cuccot pucéron tesztelem, élére állítva, hogy függőlegesen járja a levegő (a táp jó 20 centire van egyelőre). És még így is majdnem egy fokot csal felfelé, ahogy megindul a Wifi! (Wifi nélkül a hiba 0.1, max. 0.2°C.)

Bug és debug fia vagyok én

Az alap problémám nem önmagában a Wifi. Hanem az, ha pár xaros bájt átvitele miatt másodpercekig kínlódik a kapcsolat felvételéhez és közben zabálja a milliampereket. Ha úgy működne, mint egy távirányító, hogy kiköpi az adatokat az éterbe egy századmásodperc alatt, legfeljebb pár hibajavító adat és ennyi, a probléma meg lenne oldva.

Bug és debug fia vagyok én

Ha fix tápod van miért kell bármilyen sleep ? Feleslegesen építed fel, bontod a wifi kapcsolatot ami miatt változik a hőmérséklet és nem tudsz egy "fix" deltát beállítani.
Egyszerűbb lenne ha tudnád, hogy az ESP melegedése miatt mindig n fokkal többet mér az SHT35. Én első menetben megpróbálnám leszigetelni egy EPS/XPS kockával, lásd kép.

Jaaa, hogy úgy? Akkor barátom, tekintve az ESP cca. 65°C-os üzemi hőmérsékletét, a falba építve az az 1°C delta lehet 30 is.
Kezdj el gondolkodni valami alternatív megoldáson. Ajánlom az infra ledet, mint minimális energiaigényű kommunikációs csatorna...

Egyszerűbb lenne ha tudnád, hogy az ESP melegedése miatt mindig n fokkal többet mér az SHT35.

Csak hát ez sajnos nem igaz. Ilyen n nem létezik, azaz ez az érték függ nem csak a pillanatnyi hőmérséklettől,, hanem az eddigi hőmérsékletváltozástól is. Ha ±1°C-szal mérnénk, mint az olcsó termosztátok többsége, akkor még azt lehetne mondani, hogy belefér, de egy precíz eszköznél ez sajnos nem járható út.

Ami talán járható: leszigetelem, kb, ahogy te mondod, de ezzel együtt biztosítom a levegő nagyon jó függőleges áramlását a termosztáton belül, hogy hűlhessen az ESP32 (aryes ötlete).
És mepróbáok nagyon kis fogyasztás árán állandó kapcsolatot tartani a routerrel. Erre vannak technikák, de reméltem, ti többet fogtok tudni mindani erről.

Bug és debug fia vagyok én

A bibi az, hogy nem én vagyok az első, aki WiFi termosztátot épít. Ha mások meg tudták csinálni, nekem is sikerülnie kell!
A 65°C üzemi hőmérséklet az az aktív módra vonatkozik, itt természetesen altatásban fogja tölteni az ideje nagy részét, bármilyen szoftvertechnikában is gondolkoznék. Mi is kell nekem?1) 5-10 mp-enként hőmérsékletet kell mérni.
2) be kell olvasni a touch gombokat, de ez megszakításról megy, irreleváns.
3) és meg kell nézni időnként (még 5 mp-es polling is is belefér), hogy jött-e üzenet a routertől.
Az idő többi részében úgy alukálhat, hogy még a horkolása is kiszűrődhet a dobozból. Ez nem 65°C! Light sleep alatt hónapokat tudnak működni 2–3 ceruzaelemről!

Nincs tiszta véletlenül olyan lehetőség a WiFi protokollnál, hogy rövid üzeneteket ügy cseréljen a szerver és a station, hogy ehhez ne kelljen beloggolni, azaz aktív kapcsolatot létesíteni? Ez huszárvágással megoldaná a kérdést, ugyanis gyakorlatilag bizonyított, hogy nagyon kevés Wifi használattal nem lesz számottevő melegedés.

[ Szerkesztve ]

Bug és debug fia vagyok én

Nem létezik valami olyasszerű technika, hogy a ping-eléshez hasonlóan küldök egy üzenetet egy IP számra, anélkül, hogy ténylegesen belépnék passworddal az adott hálózatba? És nekem csak egy bitet kell visszaküldenie, hogy történt valami, ami miatt érdemes belogolni, vagy aludhatok tovább?

Bug és debug fia vagyok én

Nincs tiszta véletlenül olyan lehetőség a WiFi protokollnál,

De, tiszta véletlenül van. Fogalmam sincs mi ez pontosan, régebben olvastam itt a topikban erről az esp wifi mesh nevű dologról. A leírásban szerepel a "wifi low power" kifejezés, ami kis fogyasztást jelent, tehát kevesebb melegedést.

anélkül, hogy ténylegesen belépnék passworddal az adott hálózatba?

Nem tudom ezt mennyire gondoltad át, de én biztosan nem kérnék a lakásomba olyan vezeték nélküli eszközt, ami nem jelszóvédett...

[ Szerkesztve ]

Szia!

Szerintem az ESPNOW.h library a megoldás.

Köszi, ezt kifejtenéd bővebben?

Bug és debug fia vagyok én

Nem tudom ezt mennyire gondoltad át, de én biztosan nem kérnék a lakásomba olyan vezeték nélküli eszközt, ami nem jelszóvédett...

Lópikula, természetesen az se fájna nekem, hogy minden gyorsüzenet-csomagban legyen egy 128 bites kulcs, ez kábé 1 mikrosecundummal növelné meg a nagy áramú állapotot. Nekem az azonosítási protokoll ledumálása a rossz, ami másodperceket vesz igénybe a normál Wifi belépésnél egy pár ezred másodperc alatt elvégezhető hitelesítés helyett.

Bug és debug fia vagyok én

Közben megtaláltam. Akkor az lenne a poén, hogy x darab termosztáthoz tartozna egy ESP32, mondhatni egy köztes szerver, ami a termosztátokkal röviden és határozottan tudna kommunikálni, és aztán nyugisan ledumálná a dolgokat a routerrel?

Bug és debug fia vagyok én

"Nem létezik valami olyasszerű technika, hogy a ping-eléshez hasonlóan küldök egy üzenetet egy IP számra, anélkül, hogy ténylegesen belépnék passworddal az adott hálózatba?"

De van!

UDP !!!

[ Szerkesztve ]

Az amerikaiak $ milliókért fejlesztettek golyóstollat űrbéli használatra. Az oroszok ceruzát használnak. Én meg arduinot.

Pontosan.

Valami azt súgja nekem, hogy ez lesz a tuti megoldás?

Két lehetőség van:

1) egy kurva erős antennájú ESP32 szerver, amin az összes termosztát adatai megtalálhatóak tükrözve. A mobiltelefonos alkalmazás valójában nem a termosztáttal fog kommunikálni, hanem ezzel a szerverrel, amikor meg kell változtatni a beállításokat. (A felhasználónak nem is kell tudnia, hogy ezek nem updételődnek azonnal.) És minden termosztát a maga nyugis tempójában, 5–10 másodpercenként vagy whatever, amikor hőmérsékletet olvas be, egyúttal frissíti is magát a szerverről. Ez persze nem biztos, hogy fog működni egy 300+ m²-es, csupabeton házban, tehát lehet, hogy több szerverre lesz szükség, melyek egymással is kommunikálnak.
Vagy:

2) ugyanaz, mint az 1), de nem kell a kurva erős antenna, mert a szerver nem az összes termosztáttal kommunikál, hanem csak a legközelebbiekkel. Így a termosztátok fel lesznek fűzve virtuális láncokra. Magyarul, egy termosztát nem csak a saját cuccával foglalkozik, hanem továbbítja is a többiek adatait, hogyha nem a lánc végén van..
Itt az a nagy baj, hogy rendkívül pontos időzítés kell, hogy az összes termosztát ugyanabban a pillanatban ébren legyen. De remélem, hogy az RTC timer van annyira pontos, hogy 5–10 mp-enként garantálja a szinkronizált ébredést.

Mi a véleményed?

Bug és debug fia vagyok én

A Nano-nak 1 KB az EEPROM-ja.
A csipek változóak.
A programnak decimális számok kellenek, az olvasó viszont hexadecimális értékeket olvas ki.
A program képes a hexadecimális értékeket átváltani decimálisra és kiírni a soros monitorra.
Viszont míg a hexadecimális érték 4*2 karakter, addig decimálisban ez változó.
Úgyhogy nem tudom, mennyire lenne elég az 1 KB-t.
Kezdetben 3 csipet akarok felprogramozni, később még nagy esély van további kettőre.
ESP32-vel egyelőre nem akarok foglalkozni. Az extra tanulnivalóval és utánanézéssel jár, de még ez sem megy úgy, ahogy jó lenne. Bár mondjuk az adatok fájlba való írása sem rossz, ha értékeket akarok tárolni. De ez a projekt odébb van.

Ez a külső EEPROM nem rossz ötlet.
Jó lenne valami olvasnivaló, hogy egyáltalán hogyan történik ez a gyakorlatban.
Akár belső EEPROM-ot használok, akár külsőt.
Van valahol erről esetleg magyar nyelvű anyag, vagy be kell érjem az angollal?

az olvasó viszont hexadecimális értékeket olvas ki. A program képes a hexadecimális értékeket átváltani decimálisra és kiírni a soros monitorra.
Viszont míg a hexadecimális érték 4*2 karakter, addig decimálisban ez változó.

Itt valami kavar van. Az olvasó elvileg 8db byte-ot olvas ki, ha az RFID chip UID részéről beszélünk. Azt is kellene eltárolni az EEPROM-ba, 1kB-ba 128db UID fér el.

A 2. teljesen lehetetlen, hogy működőképes koncepció legyen. Arra nem lehet számítani, hogy az RTC pontos lesz (nem az), a szinkronizálás pedig több energiát fog felemészteni, mint amennyit az altatással megspórolsz. És ha mondjuk két hét múlva az egyik kiesik a láncból, mert nem ébred fel időben?

Én egyébként egy 3. lehetőséget választanék: minek 5mp-enként ébreszteni? Aludjon 1 percig az ESP. Mikor felébred, mér egyet, ami talán pontos lesz. Utána felcsatlakozik a kiszolgálóra, lekéri az aktuális parancsot, majd elmegy aludni. Kb. 50mp marad, hogy kihűljön a doboz.
Ha helyben, gombbal van állítgatva, fontos a gyors reakció, de ez a megszakítás miatt garantált is. Távolról pedig nem mindegy, hogy 1 perc múlva kapcsol fűtés vagy 5mp múlva? Milyen gyakran állítja az ember a hőfokot a szobában? Egy évben kétszer?

„Aludjon 1 percig az ESP. Mikor felébred, mér egyet, ami talán pontos lesz”
Nem lesz pontos. Pontos mérésnek azt nevezzük, amikor 5 vagy 10 mp-enként mérjük és ezt percenként átlagoljuk. Másként az az elkerülhetetlenül bosszantó jelenséget fogjuk produkálni, amikor az utolsó tizedesjegy billeg két egymás melletti érték között.

Távolról pedig nem mindegy, hogy 1 perc múlva kapcsol fűtés vagy 5mp múlva?
Nem erről van szó.
Egy smarthome-os mobilalkalmazásnál roppant illendő, hogy, ha nem is azonnal, de legalább pár másodperces késéssel minden termosztát értékét le tudom olvasni. Egy perces késés viszont röhejes. És még nem beszéltünk arról, hogy mi lesz az állítandó paraméterekkel: lesz még egy külön szerverszámítógép, ami a routerhez kapcsolódik, és ami tükrözi az adatokat? Necces, és csak piszkálja a büszkeségemet, hogy 200 bájt átviteléhez 3 másodpercig főzöm a procit.

Egyelőre az a legészszerűbb megoldás, hogy annyi esp32 szerver lesz, ahányra szükség van a teljes lefedéshez, és ezek – mivelhogy itt nulla teljesítménymegkötés van – a ház wifijén is tudnak kommunikálni egymással, ha történetesen egymást már nem látják, csak a termosztátjaikat.

[ Szerkesztve ]

Bug és debug fia vagyok én

De azért legyünk őszinték.
Backup megoldásnak – mármint hogy nyugodjam meg, a projektet mostmár biztos nem kell lemondani, ha jobb nem jut eszembe, ez implementálható – kifejezetten jó ötlet. Habár a számításaim szerint a 7-8 mA-es (vagy akár 10 mA feletti) átlagot így is hozni fogja. Ez már összemérhető azzal, hogy kis árammal állandóan csatlakozik és közbe alszik egyet-egyet.

Tehát akkor most arra kell koncentrálnom, hogy az általad és its_grandpa által javasolt dizájnelképzelések (megfelelő függőleges szellőzés, az érzékelő teljes leszigetelése stb.) megvalósuljanak.

Bug és debug fia vagyok én

Ha már csinál egy mikrovezérlős mókát, akkor egyszer, de nem egy évben hanem összesen, akkor amikor beállítja a különböző üzemmódok hőfokát a programban, nappali, éjszakai, csak a hálószobák, csak a nappali+konyha, elutaztunk, ilyenek.

menyország -> mennyország, akadáj -> akadály, jótálás -> jótállás, Iphoneal > Iphone-nal, kisuly > kisujj, csővet > csövet

az az elkerülhetetlenül bosszantó jelenséget fogjuk produkálni, amikor az utolsó tizedesjegy billeg két egymás melletti érték között.

Hát, valóban, ennél rosszabbat el sem tudok képzelni. Emlékszem, gyerekkoromban hetekig nem bírtam aludni éjszaka, mert billegett a tizedesjegy.

Ja, nem.

lesz még egy külön szerverszámítógép, ami a routerhez kapcsolódik, és ami tükrözi az adatokat?

Miért, talán anélkül gondoltad megvalósítani a távirányítást? Tehát lesz egy mobil alkalmazás, amivel direktben próbálsz kapcsolódni az éppen alvó esp-hez?

Hát, valóban, ennél rosszabbat el sem tudok képzelni. Emlékszem, gyerekkoromban hetekig nem bírtam aludni éjszaka, mert billegett a tizedesjegy.

Mondjuk, pont erre egyszerű a megoldás: mérek 10 másodpercenként, kiértékelem percenként 6 mérésből és akkor lépek fel egyúttal a wifire. És még azt se lehet mondani, hogy elavult lenne a régi érték.

Miért, talán anélkül gondoltad megvalósítani a távirányítást? Tehát lesz egy mobil alkalmazás, amivel direktben próbálsz kapcsolódni az éppen alvó esp-hez?

A szerverszámítógépet az ESP NOW-wal megúsztam volna, de közvetlen wifi kapcsolattal valóban nem. Egyre inkább úgy néz ki, hogy ez az ötlet marad, de azért lehet, hogy UDP-vel vagy valamilyen más trükkel fogom megoldani, hogy ne kelljen mindig nulláról kezdenem a bejelentkezést.

Bug és debug fia vagyok én

Még egy ötlet a dizájnnal kapcsolatban: az esp-re ragassz egy olyan pici, 1x1cm-es alu hűtőbordát, asszem VGA-kon szokták használni RAM hűtőnek (legutóbb egy számtech boltban kaptam ilyet), a bordák függőlegesen álljanak, ezzel gyorsul a hőleadás és talán a légmozgás is. A hőmérséklet szenzort pedig úgy kellene felszerelni, hogy ne érintkezzen az akril előlappal, mert az is vezetheti a hőt.

Az UDP kapcsolathoz is fel kell csatlakozni a wifire.

Pont ezt akartam írni. Az UDP két réteggel feljebb van a wifi-nél... Tehát a wifi ahhoz is kell.

Alex

Bocsanat, de szerintem egy ilyen projektnel az rohejesebb, hogy ha van pl 6 termosztatod esp alapokon, akkor meg x darabot hozza akarsz adni 'szervernek', es amugy meg nem is ertem ezt a koncepciot
ha mar ugyis wifiznek, akkor miert is nem eleg 1 kozponti egyseg?
vagy most akkor mar nem wifin akarunk kommunikalni az alegysegekkel? vagy elvesztettem a fonalat teljesen(?)

[ Szerkesztve ]

[ Szerkesztve ]

300+ négyzetméteres ház, csupa beton, 15 termosztát.
Legalább 3 router fogja kiszolgálni a ház WiFi igényét, ha nem négy.
Az teljesen kizárt, hogy egy pucér ESP32 ki tudja szolgálni mind a 15 termosztátot, ha egy erős router se tudja lefedni.
Tehát a lefedettségről szól az egész, semmi egyébről.
Az „igazi” wifi sajnos kurva lassú, hogyha ciklikusan fel-és le kell kapcsolódni. Hacsak nincs valami olyan technika, amiről nem tudok.

Bug és debug fia vagyok én

A plexiüveg hővezető képessége 0,26 W/mK, azaz harmada a közismerten jó hőszigetelő üvegnek (0,8 W/mK), és alig rosszabb a guminál (0,16), fánál (0,11–0,15) stb.
Természetesen ettől még szerelhetem a hőmérsékletszenzort úgy, hogy ne érintkezzen az akrillappal, de ezt csak annak az árán tudom megcsinálni, hogy a szenzor így legalább 1 mm-rel bennebb kerül a doboz „mikroklímájába”, ami szerintem rosszabb.

Bug és debug fia vagyok én

Néhány megjegyzés:
"billeg az utolsó tizedes jegy"
Billeg ott néhány tized mindenképp. Most, az asztalon lehet,
hogy tartja tized fok pontossággal az értéket, de a falon biztosan nem fogja. Egy helyiségben mindig van hőveszteség. Ha nem volna, nem kellene fűteni. Így mindenképpen vannak hidegebb felületek: fal, ajtó, ablak, mennyezet, padló, stb. Biztosan van légáramlás is, ami bizony bekavar. Ha elmész a szenzor előtt lesz akkora légáramlás,
hogy pár tizedet biztosan mozdul. Vagy elmegy alatta a kutya, vagy a macska.

Az ESP32 WiFi jele nem éppen erős. Ha routerrel tartja a kapcsolatot, az kiegyenlíti, de egymás között már gyengébb. Hogy is működnek ezek? Hogy megy egy adatcsomag átvitele?
Az adó összekészít egy csomagot, és beleírja a cél címét, ami a MAC cím. Egy borítékba berakja a csomagot, és ráírja a címet.
Aztán ezt a csomagot belekiabálja az éterbe (vagy a madzagra) azzal a logikával, hogy "itt egy levél, kapdossátok el, és akinek a címe van benne az használja, a többi dobja el!" És így tesznek. Ez az alap, minden forgalom alapszintje ez. Erre az ESP-n az ESP-NOW van. Nem kell semmi általános szabályt követni, mert egyedi. Ennél lentebb nem lehet menni, a dolgok lényege miatt. Ilyenkor nem kell se WiFi AP, se semmi. A fogadó ESP-nek persze fogadó állapotban kell lenni.

Magasabb szint, ha IP szinten kommunikálsz. Ebben az esetben mindenképpen a WiFi AP-hoz kell küldeni a csomagot, mert ő tudja, hogy ki van bejelentkezve, azaz ki jogosult, és a bejelentkezetteknek mi az IP címük, és ahhoz milyen MAC cím tartozik, mert az alap továbbra is az, hogy a csomagot MAC cím alapján küldözgetik, de már bele van csomagolva az IP cím is. Ezért neked is bejelentkezve kell lenni az adott hálózatra, közvetlenül nem tudsz állomásra küldeni csomagot.
(A madzagosnál némileg másként megy, mert a "mask" alapján eldöntöd, hogy azon a madzagon lóg-e, amin te is. Ha igen, akkor bekiabálsz a madzagra, hogy helló fiúk, akinek ez az IP címe,
az küldje el nekem a MAC címét, hogy tudjak neki levelet küldeni. Mert ott is MAC cím alapján történik a forgalom. Ha nem egyazon madzagon vagytok a címzettel, akkor küldöd a gateway-nek, aki tudja, hogy melyik kapu a kijárat a világ felé, és arra küldi tovább, sorsára bízva.)
Az IP szinten két módon kommunikálhatsz:
UDP: hasonló az alap szinthez. Beleírod a csomagba az IP-t, és szintén bekiabálod az éterbe, de a router/AP MAC címével.
Ő erre lecsap, kikeresi a címzett IP-hez tartozó MAC-et, és annak elküldi. Vagy saját maga feldolgozza, ha neki szól. Összesen ennyi a forgalom, nincs se visszajelzés, se semmi. Soha nem tudod meg, hogy megérkezett-e hibátlanul a csomag.

TCP: ez a protokoll már tartalmaz visszajelzést is. Ha pl. hibásan érkezett, mert közben más is kornyikált, akkor újraküldést kér, ha meg minden rendben, akkor ezt jelzi vissza. Ez egy picivel több adatforgalom, de biztonságosabb.
Tehát, ha nem ESP-NOW-t akarsz használni, akkor mindenképpen bejelentkezve kell lenni egy WiFi AP-re. Ez nem akkora gond, mert ez a bejelentkezés élve marad egy ideig akkor is, ha nincs forgalom.
Viszont, ha egy másik ESP AP-nak küldesz adatot, akkor bizony fel kell építeni a kapcsolatot. Ez nekem is okozott problémát: netre kapcsolódik egy ESP, WiFi routeren keresztül, ami küldi folyamatosan az adatokat, és valahol máshol szintén WiFi routerhez kapcsolódik a cél állomás ESP AP. Úgy tűnik, hogy talán sikerült lerövidítenem az időt, de ez a projekt egyelőre félre lett téve, majd folytatom. Ha mégse sikerül, akkor átállok UDP-re.
Volt régebben egy másik projekt, ahol egy központi ESP-nek küldözgettek a viágból adatokat, és ő minden bejelentkezettnek tovább küldte. Ott - úgy tűnt - nem volt hosszú késleltetés.

Hát, ezek alapján kell eldöntened, hogy mit akarsz.
ESP-NOW-nál gond a távolság.
UDP-nél, TCP-nél valamivel nagyobb forgalom, több idő, több meleg. UDP-nél egy kicsit kevesebb, mint TCP-nél.

[ Szerkesztve ]

Az amerikaiak $ milliókért fejlesztettek golyóstollat űrbéli használatra. Az oroszok ceruzát használnak. Én meg arduinot.

300+ nm betonházban felejtsd el a Wifis megoldást, ha saját a ház.

Köss be fixen UTP kábelt mindenhova, majd POE kaptál powert, MQTT meg mehet a kommunikáció. Kevesebb lesz vele hosszútávon a gond.
Nem szórod tele a házat pluszban Wifi jellel.

Vagy Nordic chipek hada Bluetooth MESH, vagy 433 MHZ adó vevővel láttam MESH hálót.

Release the Beast....

300+ nm betonházban felejtsd el a Wifis megoldást, ha saját a ház.

Ez a vonat már sajnos elment. Nemhogy lejárt a villanyszerelés, de a festés is megvolt mindenhol. Csak a táp, valamint a relé két kábele vannak a termosztátok falidobozaiban.

Nem beszélve arról, hogy ha már ennyi kínlódtam vele, lehet, hogy ipari termék is lesz belőle valaha, és egy UTP kábeles termosztátot a kutya se fog megvenni, mert nagyon keveseknek van meg hozzá a falban a hálózat.

Bug és debug fia vagyok én

lehet, hogy ipari termék is lesz belőle

Hát akkor szerintem próbáld meg a percenkénti kommunikációt + MQTT vagy más elterjedt smart home protokoll integrációt, mert akkor nem kell külön szervert is csinálnod a rendszerhez, fel lehet pattintani a már esetlegesen meglévő MQTT brókerre. A szabványos dolgokat mindig könnyebb eladni.

Az ESP8266 nem termelne kevesebb hőt? 1 magos CPU, talán kisebb órajel... Ugye azért vetetted el, mert kevés az I/O lába?

Az ESP8266 nem termelne kevesebb hőt? 1 magos CPU, talán kisebb órajel... Ugye azért vetetted el, mert kevés az I/O lába?

Eredetileg valóban azért vetettem el, de azóta többször is átterveztem az egészet, és talán boldogulnék annyi lábbal is. De a neten sehol nincs meggyőző adat arról, hogy az ESP32 többet fogyasztana, ugyanis, amennyivel gyorsabb, annyival korszerűbb is az architektúrája. És – nem utolsósorban – fejlettebbek a power save módjai, ami végső soron a legfontosabb a mi szempontunkból.

[ Szerkesztve ]

Bug és debug fia vagyok én

Értem.

Apropó!
Van ez a WMM Power Save mode, ami a 802.11n-ben biztosan benne van, de lehet, hogy a régebbiekben is.
Ez – ahogyan értettem – arról szól, hogy az AP akkor is fenntartja a kapcsolatot a station-nel, ha az éppen alszik. A station polling intervalluma teljesen független a DTIM-től, akkor ébred fel, amikor akar, és egyszerűen csak lekérdezi, hogy az utolsó ébredés óta van-e „félretéve” számára csomag. Ha igen, lekéri.
Magyarán, nincs szükség új bejelentkezésre minden ébredéskor, a kapcsolat fennmarad akkor is, ha valóban percenként ébresztek és a másodpercekig tartó bejelentkezés helyett villámgyorsan le lehet zavarni a kommunikációt, majd vissza lehet aludni. Mintha az én projektemhez találták volna ki!
Erről a dologról itt olvastam.

A gond az, hogy nem találok Arduino könyvtárat ESP32-höz, ami támogatná ezt a WMM PowerSave lehetőséget, holott teljesen nyilvánvaló, hogy mind az ESP3866, mind az ESP32 támogatja. Tudsz erről valami bővebbet?

[ Szerkesztve ]

Bug és debug fia vagyok én

aryes #14524 Ez jó volt :)

Lehet én hagynám a fenébe az átalakítást hűtőbordával+szigeteléssel.
Megoldható egy NTC és ellenállás osztóval az ADC lábra, 1 % pontosságú NTC 10 darabtól 70 huf, az ellenállás meg fillérek. Szépen megírod a kódot, kompenzálz az ESP chip aktuális hőmérsékletével, átlagolsz, satöbbi.
Egy tizedes pontosság szerintem elég, a gyári termosztátok hőmérséklet mérési pontossága ±0,5°C.

Nem teljesen világos, mi itt az NTC előnye az SHT35-ös modullal szemben. Kifejtenéd?

Bug és debug fia vagyok én

5 perc guglizás után annyit találtam erről, hogy ezt nem is az esp-n kell engedélyezni, hanem a routerben (QoS), és az esp-t hibernációba vinni. De lehet, hogy félreértettem valamit.

Szia!

Ha az ESPNOW-t használod nem kell feljelentkezni a routerre, tehát ha altatod azután sem kell. Igaz így azESP32-k egymással kommunikálnak MAC cím alapján, router nélkül.
Minden "kapcsolód" elküldi az adatait egy központi ESP32-nek, ami aztán tovább feldolgozza.
https://randomnerdtutorials.com-on találsz hozzá mintapéldákat is.
Nagy István

Az tiszta, hogy a routerben engedélyezni kell. De mi történik, miután felébresztem az ESP-t az alvásból? (Amúgy nem hiszem, hogy hibernációról lenne szó, max mélyalvásról, de nekem ide pont a light sleep lenne a jobb.) Arra kellene könyvtár, hogy ilyenkor mit kell csinálnom, hogy megkapjam a csomagot, mit kell válaszolni az AP-nek, hogy elküldje stb.

Bug és debug fia vagyok én

A központi ESP32-Vel van a baj. Ugyanis egy 300+ m²-es csupabeton házban esélytelen, hogy egy ESP32 minden termosztátot lásson. Tehát startból több „központi” ESP32 kell.

Bug és debug fia vagyok én

Még mindig azt mondom, hogy próbáld ki, hogy a percenkénti ébresztés mennyivel viszi el a mérést. Ha kereskedelmi terméket szeretnél csinálni, annak hülyeállónak kell lennie, a legtöbb júzernek az is gondot okoz, ha meg kell változtatni a router default jelszavát, nemhogy átkonfigurálja a routert a WMM Power Save mode bekapcsolásához.

Még mindig azt mondom, hogy próbáld ki, hogy a percenkénti ébresztés mennyivel viszi el a mérést.

Elviszi. A 60 mp-ből 2-3 (de van, mikor 4) másodpercen keresztül teljes teljesítményen pörög!

[ Szerkesztve ]

Bug és debug fia vagyok én

Egy kapcsolóüzemű táp mennyit melegedhet, amikor pár milliampert kell szolgáltatnia az idő nagy részében egy alvó ESP32-nek és egy kis fényerejű, 4 digites kijelzőnek?

Amúgy a táp már biztonsági okokból is egy nedvességálló zselés dobozban lenne, ha nincs PUR-hab. És az se az ördögtől való, hogy a szerelődobozba már eleve 3,3 V érkezzen.

[ Szerkesztve ]

Bug és debug fia vagyok én

its_grandpa #14540-ben:
Nem az SHT35 cseréjére utaltam, hanem arra, hogy mérd az eszközöd hőmérsékletét, ahelyett, hogy hűtőbordát akasztanál rá.

Az ESP32-nek lehet maximalizálni a CPU freq-jét (80 Mhz-ig).
Esetleg megpróbálhatnád a kódodból, bár tovább fog tartani a kommunikáció viszont nem fog pörögni.
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/system/power_management.html