- Xiaomi 13T és 13T Pro - nincs tétlenkedés
- DIGI Mobil
- Yettel topik
- 15 éves az első androidos Samsung telefon
- Redmi Note 12 Pro - nem tolták túl
- Mobil flották
- Redmi Note 10 Pro - majdnem minden stimmel
- Android alkalmazások - szoftver kibeszélő topik
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Itt az első kép a 2024-es Nokia 3210-ről
Hirdetés
-
Toyota Corolla Touring Sport 2.0 teszt és az autóipar
lo Némi autóipari kitekintés után egy középkategóriás autót mutatok be, ami az észszerűség műhelyében készül.
-
Premier előzetesen a Gray Zone Warfare
gp A mai naptól hivatalosan is elrajtol a játék korai kiadása PC-n.
-
Samsung Univerzum: Így ismerhető meg a Galaxy AI bármilyen telefonon
ma A Try Galaxy webalkalmazás kontrollált környezetben mutatja meg, mit tud a One UI 6.1-es rendszer és a mesterséges intelligencia.
-
Mobilarena
Arduino hardverrel és szoftverrel foglakozó téma. Minden mikrovezérlő ami arduinoval programozható, és minden arduino program, board, és hardverrel kapcsolatos kérdések helye.
Új hozzászólás Aktív témák
-
kesztió
aktív tag
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
-
kesztió
aktív tag
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
-
its_grandpa
tag
válasz kesztió #14502 üzenetére
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. -
-
kesztió
aktív tag
válasz its_grandpa #14503 üzenetére
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
-
kesztió
aktív tag
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
-
kesztió
aktív tag
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
-
nagyúr
válasz kesztió #14506 üzenetére
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 ]
-
kesztió
aktív tag
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
-
kesztió
aktív tag
-
Janos250
őstag
válasz kesztió #14507 üzenetére
"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.
-
kesztió
aktív tag
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
-
JulianSinulf
senior tag
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. -
-
nagyúr
válasz JulianSinulf #14516 üzenetére
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.
-
nagyúr
válasz kesztió #14515 üzenetére
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? -
kesztió
aktív tag
„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
-
kesztió
aktív tag
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
-
gyapo11
őstag
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
-
nagyúr
válasz kesztió #14520 üzenetére
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?
-
-
kesztió
aktív tag
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
-
nagyúr
válasz kesztió #14520 üzenetére
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.
-
dew28
aktív tag
válasz kesztió #14520 üzenetére
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 ]
-
kesztió
aktív tag
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
-
kesztió
aktív tag
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
-
Janos250
őstag
válasz kesztió #14531 üzenetére
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.
-
Tankblock
aktív tag
válasz kesztió #14531 üzenetére
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....
-
kesztió
aktív tag
válasz Tankblock #14534 üzenetére
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
-
nagyúr
válasz kesztió #14535 üzenetére
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?
-
kesztió
aktív tag
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
-
kesztió
aktív tag
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
-
its_grandpa
tag
válasz kesztió #14539 üzenetére
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. -
kesztió
aktív tag
válasz its_grandpa #14540 üzenetére
Nem teljesen világos, mi itt az NTC előnye az SHT35-ös modullal szemben. Kifejtenéd?
Bug és debug fia vagyok én
-
onagyi
csendes tag
válasz kesztió #14510 üzenetére
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 -
kesztió
aktív tag
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
-
nagyúr
válasz kesztió #14545 üzenetére
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.
-
dew28
aktív tag
Igazabol, amennyiben kereskedelmi termek lesz belole, akkor eleve rossz az irany, bar elkepzelem, ahogy benne van a manualban:
"Amennyiben 50mm-nel kisebb melysegu dobozod van, fogj egy dobozmarot, es hajra. Kovetkezo lepeskent johet a PUR hab."
nem lehet ignoralni az tapegyseg okozta hot. ilyen forman pedig az ESP fogyasztasa gyakorlatilag mellekszal[ Szerkesztve ]
-
kesztió
aktív tag
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
tag
válasz kesztió #14548 üzenetére
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