ESP-01 + Tasmota + Relé

Közösségi kerekasztal

Szóval kitaláltam, hogy ez milyen jó lesz... Elekromos kapu lábaira relé, azt meg az esp-vel kapcsolgatom, így lesz távirányítva.

Problem #1: A unifire felkapcsolódik az esp, viszont IP-t nem kap. Pontosabban, nem is kér (vagy legalább is nyoma sincs). Egy szutyok tp-link routerre kapcsolódva persze megy.

PEBKAC, nem volt a VLAN taggelve a unifire. :)

Problem #2: Bár egyelőre csak az asztalon LED-ekkel nézem, de bootkor/restartkor villan a led... Tehát minden bootkor/restartkor ki fog nyílni a kapu.

Ez így baromira nem jó.

Ötletek?

  • 1874 megtekintés

( EspOS | 2025. 08. 30., szo – 15:03 )

Szerkesztve: 2025. 08. 30., szo – 15:08

A GPIO0 nem soros port, de csak magas szinten bootol a modul. GPOO0 -|<- schottky felhúzó tranyó.

https://www.esp8266.org/

Nem mondtad, hogy random van boot.

Eleve, nem írtad le a teljes üzleti igényt, és azt sem, hogy most hogy valósítottad meg, meddig jutottál el, és hol a gond. A kollega tippelt egyet, hogy hogy csinálhattad meg (= azaz, ha ő lenne a te helyedben, hogy csinálta volna meg) és arra mondta, hogy az valószínű nem jó.

Fuss neki úgy, hogy az elejéről szépen okosan elmondod, hogy mi az igényed, mit hogyan csináltál eddig, és pontosan hol van az elakadásod. Ezeket az elektronikai cuccokat 75-féleképpen meg lehet valósítani, és szerintem itt senki nem gondolatolvasó, hogy tudja, mire gondolsz.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Leírtam mit szeretnék. A kapnyitón van két érintkező, ami a távirányító két gombjának megfelelő (gyalogos, illetve teljes nyitás). Ezt szeretném egy relével kapcsolni, a relét pedig egy ESP01-gyel vezérelni. Itt van jelenleg a garázsba az asztalon próbapanelen összedugdosva, a kimenetén LED-ekkel. Próbálom kitalálni mi-hogy van, illetve beállítani. Ennyi. Ennél pontosabbat nem tudok, és szerintem nem is szükséges, mert egy faék egyszerű valami.

"Sose a gép a hülye."

De most egy nem létező problémára keresel megoldást.

Jó, oké, felejtsétek el amit eddig írtam, kezdjük előlről.

Ma baromira ráértem, és szeretnék egy ESP-01 két kimenetén LED-et kapcsolgatni. Viszont zavar az, hogy induláskor felvillannak a LED-ek. Hogy csináljam, hogy ne villanjon fel?

"Sose a gép a hülye."

Én csak teszthez mondtam, hogy a programozható felhúzó ellennállások ne tévesszék meg, de ez is hülyeség volt mert a GPIO0, GPIO2 alapból az ESP modulon 10k fel van húzva, egyébként nem bootolna. A versenyző meg azt se mondta hogy speckó optós relé moduljai vannak, akkor nem írkálok ennyit feleslegesen.

https://www.esp8266.org/

( dlaszlo | 2025. 08. 30., szo – 16:15 )

Szerkesztve: 2025. 08. 30., szo – 16:35

Problem #2-re: Biztos, hogy nem jó? 

https://tasmota.github.io/docs/PowerOnState/

PowerOnState Control relay state after powering up the device.
0 / OFF = keep relay(s) OFF after power up
1 / ON = turn relay(s) ON after power up
2 / TOGGLE = toggle relay(s) from last saved state
3 = switch relay(s) to their last saved state (default)
4 = turn relay(s) ON and disable further relay control
5 = after a PulseTime period turn relay(s) ON (acts as inverted PulseTime mode)

Vagy csak boot közben átáll esp-01-gyel?

Egyébként nem teljesen világos. Gyakorlatilag építesz egy eszközt reléből, és esp-01-ből ami mondjuk ugyanazt tudja, mint egy shelly, vagy más hasonló wifi-s relé? Erre a célra egy shelly nem felelne meg? 

De ezt még ettől többféleképpen lehet, milyen relé, hogy vannak összekötve, hogy van beállítva a tasmota? pl a PowerOnState.

Kicsit írj többet légyszi, hogy pontosan mit csinálsz/csináltál.

Megfelelne, de ezek a cuccok vannak itt a fiókban, és egyébként szívesen csinálok inkább sajátot.

Még sehogy nincs összekötve a relé. Ledek vannak a kimeneten. Generic (8) module, GPIO0 -> Relay -> 1, GPIO2 -> Relay -> 2

Nagyjából ennyi. Vagy mire vagy kíváncsi?

"Sose a gép a hülye."

Ok, ha jól értem akkor két kaput akarsz vezérelni, vagy kétféle módon akarod kinyitni a kétszárnyas kaput, egyébként egy GPIO vezérelné.

Nincs ESP-01-em, és nagyon régen játszottam ezekkel, így most egy csomó "ha jól gondolom mondat": :)) csak ötletelésnek szánom, javítsatok ki ahol alapvetően hülyeség, amit írtam:

Jól gondolom, hogy a GPIO0 és a GPIO2 is high értékkel indul, normál boot esetén?

Ha jól gondolom, akkor a GPIO0-n, és a GPIO2-n a HIGH érték csak akkor vált LOW-ba, ha a program elindul, és beállítja a PIN-ekre az OUTPUT módot, és LOW-ra állítja őket? 

Tehát ezeket a LOW értékeket esetleg lehet invertálni, ami már a relét vezérli? (hogy GPIO0 vagy GPIO2 LOW-ra kapcsoljon egy relé)

Szerk: + a tasmotát én első körben hagynám is, hogy ne kavarjon be bootolás után, hanem saját progit töltenék rá fel. (ha működik, utána jöhet a tasmota)

Ha megcsinálom erre is a sajátot, akkor nem lesz tasmota, mert akkor már minek...

Csak kezdeti kísérletezés miatt gondoltam, nem a teljes logika megvalósítására.

A doksi alapján úgy látom, hogy a Tasmota-ban is meg lehet csinálni az inverz logikát:

SwitchModeX és a PulseTime parancsok kellhetnek neked + az beállítható hogy indulás után mi legyen az induló állapot. Így bootolás közben és után végig HIGH marad, amíg meg nem nyomod a gombot: nem lesz felesleges ajtó nyitás. - de ki kell próbálni, hogy a gyakorlatban van-e valami meglepetés. :)

A reléhez érkező jel megfordításra meg hasonlóra gondoltam: https://www.youtube.com/watch?v=8c8NLfAP4oY  

Megfelelne, de ezek a cuccok vannak itt a fiókban

Én a shelly relére szavazok az "ESP01 board + relé" megoldással szemben: védelmek (galvanikus leválasztás, biztonsági távolságok, túláram, túlmelegedés, megfelelő doboz stb...), biztonsági tanúsítványai vannak + nem egy ember által már kipróbált dolog. Míg a DIY ESP-s megoldásnál, több dologra kell figyelni: pl.: hogyan hajtjuk meg a relét (nem a gpio-ról közvetlen mint egy ledet), flyback dióda használata, méretezések, stb... Lehet, hogy ezekkel mind tisztában vagy, jól ismered, de én inkább egy kész megoldást használok. És a shelly sem drága igazából.

( gabrielakos v | 2025. 08. 30., szo – 17:10 )

Egy led villanás korántsem biztos h kapcsol egy relét. 

Én biztos h Shelly 1Plus-sal fogom csinálni.

zászló, zászló, szív

( VincentV | 2025. 08. 31., v – 00:00 )

Szerkesztve: 2025. 08. 31., v – 00:11

ESP-knél normális jelenség bizonyos gpio-k billegése boot közben, itt találsz róla infót, hogy melyek a "safe" gpio-k input vagy output esetén: https://randomnerdtutorials.com/esp8266-pinout-reference-gpios/

ESP8266-01-nél elég szűkösek a lehetőségek, mint ahogy láthatod a táblázatban. Próbáld meg az gpio3-at (RX) és a gpio2-őt. Persze így bukod a serialt, de ez van, ha jól rémlik Tasmoatban állítható/kikapcsolható, így felszabadítható. Két javaslat:

  • Tasmota helyett ESPHome.
  • Amikor fiókba rendelsz ESP-t, akkor ne ezt válaszd, 100Ft-al drágábban kapsz pl. Wemos D1 Minit, az alá én nem mennék.

- Megnézem az ESPHome-ot.

- Ezeket szerintem 5 éve (vagy mégtöbb) rendeltem, valszeg akciós volt, mondván majd jó lesz valamire. :)

szerk.:

- Az RX láb jó, de a GPIO2 is villan bootkor.... Ötlet, hogy esetleg lehetne úgy, hogy az RX (GPIO3) egy "engedélyező" láb, és akkor használható GPIO0, GPIO2, meg a TX is.

- Az ESPHome-ot hogy teszem fel rá? Mert azt nem találom.

"Sose a gép a hülye."

Ötlet, hogy esetleg lehetne úgy, hogy az RX (GPIO3) egy "engedélyező" láb, és akkor használható GPIO0, GPIO2, meg a TX is.

Végre egy jó ötlet, s épp tőled, a kérdezőtől.

Nem szoktam használni kész dolgokat, saját tervezésű mikrokontrolleres cuccban meg azt csinálok, amit akarok. A legtöbb MCU reset hatására befelé forgatja a port lábait, tehát azok lebegnek. Fontos, mert ha MOSFET gate-jét hajtja, akkor határozatlan, bármi lehet. Ezért célszerű lehet vagy felfelé, vagy lefelé húzni a lábat ellenállással, tehát abba az irányba, ami passzív működést, nem beavatkozást okoz a meghajtott hardware-ben.

A láb meghajtása pedig úgy lesz tranzienstől mentes, ha előbb az adatregisztert inicializálod - minek kell a porton lennie majd akkor, ha kimenet lesz a port -, majd csak ezt követően forgatod ki a lábat, azaz teszed azt kimenetté. PIC-ek esetében tehát előbb írod a LAT, s csak utóbb a TRIS regisztereket. Arra is vigyázni kell, hogy ebben az esetben rossz ötlet a portra read modify write típusú utasítást használni - ami például egyetlen bitet állít -, mert a bemenetként meghatározott portlábról beolvasott értéket fogja update-elni az output latch-be, s ha ezt követően azt a portlábat kifelé forgatod, meglepődve tapasztalod, hogy nem az van ott, mint amelyre korábban inicializáltad. Ráadásul ez épp azon portlábakon fog történni, amelyhez az adott utasítással nem nyúltál hozzá. Ezt a szakmát gyakorolva az emberben olykor felmerül a kérdés, hogy „miért nem mentem péknek”. :)
 

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Megcsináltam, mondjuk hogy "működik". A relé nem húz be, de a visszajelző ledje egy kicsit megpislan bootkor.. Igazából nem értem miért. Akkor jelentkezik, amikor tápot kap az egész. Lerajzolom a kapcsolást majd és feltöltöm, hátha valaki meg tudja mondani, de ha így marad, az se baj, az alapvető probléma kiküszöbölve. :)

szerk: voálá: https://v1.imgpaste.net/images/public/1701bbbb-0ec6-4f59-9af3-cfeaa842b…
Szóval a BC182-ket is 22k-val húztam GND-re, azzal kattant, még 10k-val is, így 4,7k-val már nem.

"Sose a gép a hülye."

Én nem teljesen értem ezt az egészet még mindig: nagy szopások, próbálgatások és órák elbaszása után eljutottál oda, hogy 25 °C és 80 rH% páratartalom mellett nem nyitja ki a kaput egy reboot, de ha lehűl az idő vagy nagyobbat villámlik vagy elmegy egy CB rádiós taxis a kapu előtt, akkor arra fogsz hazaérni, hogy nyitva van a kapu.

Oké, megcsináltad, fasza, itt van egy talicska vállveregetés, de biztos erre a kókányolásra van szükséged a kapunyitásnál?

https://iotguru.cloud

+1 a megbízhatóságra. El mernél-e menni otthonról, ha otthon van mondjuk két kutya a kertben, és csak kis lehetőség is van, hogy a kapu véletlen kinyílhat. A DIY megoldás meg lehet jó, csak azokból sokszor csak az 5. verzió után kezd el elég jól működni, aminek nincs valami alapvető problémája.

Neked miért fáj az, hogy érdekel és szeretném megoldani?

Az, hogy érdekel a téma, az nem fáj, sőt, az teljesen jó. Az fáj, hogy nem minden jel szerint nem megoldani szeretnél egy problémát, hanem kókányolni szeretnél arra nem alkalmas eszközökkel, mert az a premissza, hogy mindenáron egy ESP-01 kell legyen az egész kókányhalom alapja, akkor is, ha többszörös pénzből kell köré építeni elektronikát.

Kókányolás, mert magamnak csinálom?

Nem, az, hogy magadnak csinálod, az nem kókányolás. Azért kókányolás, mert nullához konvergál a megbízhatósága, miközben nem érted, miért működik, nem érted, hogyan működik, és amúgy fillérekért lenne rá megfelelő megoldás, ami nem fogja kinyitni a kaput, ha jön egy kósza villám másfél kilométerre és nem fogja kinyírni az ESP-t sem, ha így marad napokig. 

https://iotguru.cloud

De megoldani szeretném, egy bizonyos módszerrel.. Mert érdekel, mert szeretem csinálni. Aztán ha kimaxoltam amit lehet, és nincs általam elfogadható eredmény, akkor majd veszek egy olyat, amivel jó lesz.

Továbbra se értem, miért "kókányhalom", amikor is ennek az ESP-nek van egy adottsága, ezt akarom néhány alkatrésszel megkerülni.

Ha jön egy kósza villám, valszeg bármivel kinyílik a kapu... Vagy épp soha többet. Ez egy elég spéci eset. És amúgy, egyáltalán nem vagyok benne biztos, hogy pl. az aliexpressről rendelt olcsó kész cucc nem viselkedne ugyanígy, vagy nem füstölne el.

"Sose a gép a hülye."

Továbbra se értem, miért "kókányhalom", amikor is ennek az ESP-nek van egy adottsága, ezt akarom néhány alkatrésszel megkerülni.

Mert a megkerülés módszere az maga a kókányhalom.

Próbálgatsz vaktában ellenállásokat, tranzisztorokat, mindenféle méretezés és számolás nélkül (miért nem FET, ha már?); próbálod kikerülni azt, hogy az ESP-01 tervezési célja az volt, hogy Arduino-hoz illesztve AT parancsokkal tudjon Wifi kapcsolatot prezentálni az RX/TX lábakon és a GPIO00 és GPIO02, amit relé vezérlésre próbálsz használni, azok dedikáltan a programozásához kellenek, az ESP-01 tervezési célja szerint nem is használhatóak érdemben, mint GPIO, mert könnyen boot-loop lehet a vége. ESP-01-et használni bármi más célra alapvetően kókányolás. Értem, hogy ez volt a fiókban és kihívás, hogy összeraktad, PoC-nak tökéletes, de minden szempontból kókányolás.

Ha jön egy kósza villám, valszeg bármivel kinyílik a kapu... Vagy épp soha többet. Ez egy elég spéci eset.

Spéci eset, hogy másfél kilométerre becsap egy villám és nyílik a kapud? A tranzisztorhalmazod mennyire érzékeny egy taxis CB rádiójára?

https://iotguru.cloud

Továbbra se értem, miért "kókányhalom"

A terület, ahol alkalmazod, az megbízhatóságot vár el:

Az ESP-01 pl érzékeny a tápra: pl hirtelen nagyobb áramot vesz fel, pl wifi kapcsolódáskor, vagy villám, motorindítás, hálózati zavarok. Biztonság: megfelelő tokozás, optocsatolás, galvanikus leválasztás, IP szabványnak megfelelés, stb... Egyéb: watchdog, gombok pergésmentesítése, lebegő vezetékek (induláskor is, pl ne legyen kicsit felvillanó led, ami jelzi, hogy valami nem oké).

Ez kb olyan, mint hogy egy bizonyos tapasztalat felett egy programozó sem kezd el XML parsert írni, de még CSV parsert sem, mert évek óta tartó projektekben az elérhető library-kat már tízezrek tesztelték, és sok tíz ember fejlesztette, kijavítva mindent. (hülyeség lenne belekezdeni is)

Az a különbség, hogy egy olyan fontos területen, mint egy bezárt kapu, egy kipróbált, tanúsított, ipari megoldást használsz-e, vagy Te csináltál valamit, ami működni látszik elsőre, de az csak a "happy path".

Azért tapsvihar, örömujjongás nem lesz a részemről. Rövidzárban járatod az MCU port meghajtó MOSFET-jét. A BC559-ek emittere fenn van VDD-n, szegény MCU le akarja húzni a GPIO lábát GND-re, de csak VDD - 0.7 V-ig sikerül. Ömlik az áram befelé a tranzisztor bázisába, a MOSFET csatornaellenállása limitálja az áramot, az MCU meg disszipál, végül is van villany Pakson. ;) Tréfát félretéve, tessék a GPIO lábak és a bázisok közé odacsinálni sorba valami néhány kiloohmos ellenállást. 10 k jó is lesz. Ez mindhárom GPIO-ra vonatkozik.

Kimérhetted volna szkóppal, hogyan initeli magát ez az eszköz. Akár azt is lehet, hogy elhagyod a legfelső BC559-et, s a GPIO3-ra a másik kettő emitterét kötöd. Akkor annyi lesz a változás, hogy GPIO3 lebegése és alacsony szintje lesz a tiltás, kis impedanciás magas szintje az engedélyezés. Ebben a megoldásban GPIO3-ra ellenállás nélkül mehetnek az emitterek, de a bázisok elé kell a soros ellenállás.

Ugye, van a relé tekercseivel párhuzamosan dióda, ahol az anód van a meghajtó tranzisztor kollektorára kötve, a katód pedig a tekercs azon végére, ami a tápra megy?
 

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Csak egy kérdés, ha már plusz tranzisztorokat is használtál (tényleg érdekel, még szívesen kísérleteznék is vele, csak sajnos 1000 más dolog is van): Ez az ötletelés valamiért nem működőképes? https://hup.hu/comment/3216897#comment-3216897

Tehát eleve a két PIN bootoláskor magas szinten van, és az elvileg úgy is marad bootolás után, amíg programból át nem állítod. (nem vagyok benne biztos, de így olvastam). És a jelet fordítod meg a relének. - lehet, hogy hülyeség.

Az ESPHome egy keretrendszer, amivel custom firmwareket tudsz buildelni egyszerű yaml leírófileok használatával, csak az lesz benne amit szeretnél, más semmi. Hasonló mint a saját kód, csak előre elkészített komponenseket kapcsolsz össze. Ugyanakkor a yaml-ön belül használhatsz saját C kódot is, ha szükség van rá.

Faék egyszerű:

pip3 install esphome

esphome run kapu.yaml

Ez buildel egy firmwaret a kapu.yaml alapján, majd a végén megkérdezi, hogy mely porton (pl. usbserial) flashelje. Ha már van az eszközön ESPHome, és bekapcsoltad az OTA komponenst, akkor megy IP-n is.

Elképesztő jó találmány amúgy.

A kapu.yaml-höz meg pl. kérd meg valamelyik LLM-et, hogy írjon neked egy példát magyarázattal, és az alapfunkciókkal (platform config az eszközöd alapján, wifi, ota, relékezelés), kb. 20 sor lesz az egész, és egyből képbe fogsz kerülni.

Tényleg egyszerű és jól működik. Viszont a relé itt is pereg indulásnál, úgyhogy ettől függetlenül azzal valamit jó lenne kezdeni:

esphome:
 name: esp01-kapu

esp8266:
 board: esp01_1m

wifi:
 ssid: "iot1"
 password: "xxxxx"
 # Ha nincs Wi-Fi, nem indít AP-t, csak próbálkozik újra
 fast_connect: true

captive_portal:

# Webes felület a böngészőből vezérléshez
web_server:
 port: 80

# Logger engedélyezése
logger:

# API Home Assistant integrációhoz
api:

ota:
 - platform: esphome
   password: "xxxxx"

switch:
 - platform: gpio
   pin: GPIO0
   name: "Gyalogos relé"
   id: gyalogosrele
   inverted: true
   restore_mode: ALWAYS_OFF
   internal: true

 - platform: gpio
   pin: GPIO2
   name: "Teljes nyitás relé"
   id: teljesnyitasrele
   inverted: true
   restore_mode: ALWAYS_OFF
   internal: true

button:
 - platform: template
   name: "Gyalogos relé 0.5s"
   id: gyalogosrele05s
   icon: "mdi:shield-lock-outline"
   on_press:
     - switch.turn_on: gyalogosrele
     - delay: 0.5s
     - switch.turn_off: gyalogosrele

 - platform: template
   name: "Teljes nyitás relé 0.5s"
   id: teljesnyitasrele05s
   icon: "mdi:shield-lock-outline"
   on_press:
     - switch.turn_on: teljesnyitasrele
     - delay: 0.5s
     - switch.turn_off: teljesnyitasrele

"Sose a gép a hülye."

"Ezeket szerintem 5 éve (vagy mégtöbb) rendeltem, valszeg akciós volt, mondván majd jó lesz valamire. :)"

De jó, hogy nemcsak én csinálok ilyen hülyeséget! :)

 

BC 546/556 és hasonló bjt-k nagyon nem kapcsolnak ahogy azt elmondják a tutorialokban. Túl hamar elkezdenek a lineáris tartományban vezetni. 2n3904/2n3906 sokkal jobb. Nemrég szoptam ezzel.

Az arduino-ide nagyon szar. Egy idő után elromlott minden pedig nem változtattam a kódon lényegesen. Tele van áthidaló kóddal, hogy az esp-t úgy lehessen programozni mint egy arduino-t. Váltanom kellett esp-idf-re és azt nagyon jónak találom.

Valóban van a tranzisztoroknak datasheet-je.

Közben látom, hogy ez a drága izének van saját programozó környezete.

Megsértődtél az arduinora.

Csináltam arduino-ide programozással esp8266-ral egy kis házi webszerveres vezérlést és nem volt fasza de működik.

Most buheráltam egy esp32-s kamerás projektet és nem volt fasza. Kis változtatások után elkezdett belassulni és egy idő után nem tudtam a programot se rátölteni (flashelni tranyó!). Azt hittem megpörköltem a modult. Vettem másikat ugyanaz történt.

Kipróbáltam az esp32-idf -et és a halottnak hitt modul beindult. Azóta nem ütköztem olyan hibába amit nem értek és rombolom le a programomat mert nem tudom miért nem megy. Ennyi.

BC 546/556 és hasonló bjt-k nagyon nem kapcsolnak ahogy azt elmondják a tutorialokban. Túl hamar elkezdenek a lineáris tartományban vezetni.

Ezt nem értem. Amit mondasz, az implicit azt jelentené, hogy nagyon kicsi lenne az áramerősítése. A nagyfeszültségű tranzisztorok ilyenek jellemzően. Megnéztem a BC546 katalóguslapját. Jó, elavult, de ezen kívül semmi baja, olyan, mint amilyen egy tranzisztor. Ha kijön telítésből a lineáris, áramgenerátoros tartományba, az csak annyit jelent, hogy az elérni kívánt kollektoráramhoz kicsi a bázisáram. Azaz rosszul van méretezve.

ahogy azt elmondják a tutorialokban

Tisztelem a szakemberek tudását, de azt gondolom, ez a vak vezet világtalant szakkör lehetett. Vagy van olyan információ, amit elhallgatsz előlem.

Esetleg az lehet, hogy a maximális szaturációs kollektor-emitter feszültség 0.6 V, a tipikus 0.09 V - 0.3 V, míg a 2N3904 esetében a maximum 0.3 V. Viszont itt a 0.6 V nem a lineáris tartományt jelenti, bár lehet olyan élethelyzet, ahol ez már sok.

Ha kifejezetten alacsony nyitófeszültség a cél, akkor célszerűbb választás a MOSFET.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Én csak buherálok nem értek hozzá. Nézem a tutorialt leírják, hogy fú de jó 10mA bázisáram vagy mittudomén. Működik. Aztán elkezdi baszni az agyam, hogy minek folyik ott el 10mA miért ne tekerhetném lejjebb. Van elég hFE stb. és mégse csinálja. Legalábbis nem kapcsol úgy ahogy előtte.

Szerk: Nem hagyott nyugodni a dolog és újramértem a múltkori áramkört amin a BC-k nem akartak normálisan kapcsolni és nem tudtam reprodukálni a lassú kapcsolást. Most minden jól működött. Szóval ne vegyetek új tranzisztorokat. :D

( Dwokfur v | 2025. 08. 31., v – 08:12 )

Tudom, hogy nem segít, de nem bírom magamban tartani: boot-loop esetén akkor tárogatni fog a kapu... :-) bocs

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

( johans | 2025. 08. 31., v – 15:14 )

Hasonló van nálam üzemben, csak egy ESP32R4, ami egy egybeintegrált esp32 és 4 darab szárazkontaktos relé. ESPHome alatt van meghajtva. Itt mondjuk a bootolással nincs gond, viszont maga a kapu elektronika csak akkor érzékeli a "gombnyomást", ha a relék 0,3-0,4 másodperc körüli értékig zárva vannak. Nálam ez most 0,5-re van állítva, így stabil. Szóval simán lehet, hogy ami boot közben felvillantja a ledet, az még nem nyitja ki a kaput.

Két fájlból áll, és csak a home assistantos interface van engedélyezve, mert onnan vezérlem. Látszik, hogy

  • az úszókapunak 1 másodperc kell, hogy észrevegye távirányítót
  • a kétszárnyú kapunak és a garázsnak 0,5 másodperc
  • a sima kapu meg egy kicsi kézzel nyitható, annak a mágneses zárja addig van nyitva, amíg zárva van a relé (15 másodperc)

A lényeg, a kapu.yaml: https://pastebin.com/XX61Bu9i

Meg amit majdnem minden ESPHome eszközöm include-ál, a base-yaml: https://pastebin.com/B6BZPR4v

Meg kell még egy secrets.yaml, amiben a wifi ssid, wifi password, hálózati beállítások vannak. Bele lehet mindent rakni 1 fájlba is, de amikor 50+ eszközöd van, akkor így egyszerűbb.

Egyébként a webszervert használni ESP-01-en nem jó ötlet, már ha nem akarod rendszeresen áramtalanítani és újraindítani az eszközt.

https://esphome.io/components/web_server/

A  második mondat:

Please note that enabling this component will take up a lot of memory and may decrease stability, especially on ESP8266.

Csak mert láttam, hogy amit írtál yaml fájlt, abban be volt kapcsolva.

Meg ha nem használod a natív Home Assistant API-t, akkor az api: sort szedd ki, különben 15 percenként rebootol az eszköz. Ha nem használsz Home Assistantot, akkor webes felület helyett mondjuk az MQTT működik. Ja, és ha a wifi nem vált AP-ra sose, akkor feleslegesen foglalja a helyet a captive_portal is, azt is szedd ki a konfigból.

Ezt a webszerveres figyelmeztetést eddig nem is láttam, köszi. Én mindegyikbe szoktam tenni, néha jól jön, hogy mindenféle egyéb tool nélkül rá tudok nézni, hogy él-e, hal-e. Bár vélhetően a Wemos D1 Mini Pro-k miatt nem volt még vele bajom, azokon több a ram.

A "captive_portal:" viszont hasznos tud lenni, múltkor egy félresikerült ota frissítés után nem tudott az egyik csatlakozni a wifire. Bonthattam ki a boardot egy elég szar helyről, miközben nem volt semmi baja, csak a hidden ssid-hez kellett már neki egy opció, ami régebben nem kellett (frissítettem az ESPHome build környezetet).

van egy ble-trackerem egy wemos-sal (oke ez esp32 es nem 8266), esp-idf frameworkkel epp belefer a memoraiba, van webserver, meg portal, meg csomo self-info sensor. aramszunet miatt most rebootolodott 105 nap uptime utan.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

ugy jon ide, hogy az esp32 memoriaja is fullon van (ezert kellett frameworkot valtani, hogy beleferjek a hw-ba), es megis jol megy a webserver is, portal is. 

hany nap utan jelentkezik a stabilitasi gond 8266-on?

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Szerintem annak, hogy a firmware belefér-e a flash memóriába, csak áttételesen van köze ahhoz, hogy a futtatáshoz mennyi RAM szükséges. A 8266-on összesen 160 kB RAM van, az is szegmentált, a mezítlábas ESP32 520 KiB RAM-mal jön.

A 8266-on sem mindig jelentkezett a stabilitási gond, de ahol igen, ott kb. 1 héten belül. A webszerver kikonfigurálása minden esetben megoldotta.

ESP8266 Arduino egy Serial.println("Hello Word)"; után kb 55KB szabad RAM marad. Amit reszelek a 950KB kód boot után marad kb 20KB szabad RAM. Minden bájtért megkűzdök, ha profi lennék C++ ban, szerintem még vagy 10KB lehetne pluszba.

https://www.esp8266.org/

Jogos. Egyébként esszembliben még sokkal hatékonyabb. (női munka, csináljaajókurvaannya)

Soha nem tanultam programozni, ezt most törpöltem ki.

Adott feladathoz belőni:

1. HW képességei / elvárt teljesítmény.

2. Feladat komplexitása.

3. Feladatra fordítható idő

4. Programozó tudása.

----------------------------------------------

Megoldás:

1. Megtalálni a megfelelő nyelvet

2. Megcsinálni.

 

Így kezdődik a kódom:

#include

Adafruit_NeoPixel-master\
APDS-9960_Gesture_Sensor_esp8266_Library-master\
Arduino-Sun-master\
Arduino-Temperature-Control-Library-master\
AsyncElegantOTA-scuba\
AsyncTCP-main\
DHTesp-master\
dimmable-light-main\
EasyDDNS-master\
EMailSender-master\
ErriezDS1302-master\
ErriezDS1307-master\
ErriezDS3231-master\
ESP8266_QRcode-master\
ESP8266Audio-master\
ESP8266Ping-master\
ESPAsyncTCP-2.0.0\
ESPAsyncWebServer-yuboxfixes-0xFEEDC0DE64-cleanup\
ESPFlash-master\
esp-idf-oled-master\
ESPRotary-master\
espsoftwareserial-main\
Grove_4Digital_Display-master\
IRremoteESP8266-master\
LCDCharConverter\
LiquidCrystal_I2C-master\
LiquidCrystal-master\
melody-player-main\
OneWire-master\
pcf8574-main\
rdm6300-master\
rfid-master\
Tachometer-main\
Ticker\
untarArduino-master\                                                     --------------------------------------------KÖSZI TEVE !!!!!!!!!!!!!!!------------------------------------------------------
UPnP_Generic-3.5.0\
WS2812FX-master\

 

Ezzel együtt ~20KB szabad ramom van. A faszom vergődjön a char tömbökkel amikor van sztring. A sztringet nem azért csinálták, hogy ne használja senki. Igen, van amikor kontraproduktív, de nem mindig,

 

Igen, meg lehetne írni gépi kódban is.

https://www.esp8266.org/

Ha picike a mikrokontrollered, még a C sem fog menni, valóban csak az assembly jöhet szóba. Amikor van néhány száz byte, vagy néhány kilobyte programtárad, valamint néhán tíz, legfeljebb néhány száz byte RAM-od, meg mondjuk 8 mélységű stacked, akkor marad az assembly.

Én még 32 bites MCU-t is C-ben programozok. Egyrészt, mert kell a RAM minden másra, mint hogy azt az objektumorientáltság őrületei falják fel. Például az sokkal fontosabb, hogy legen logbufferem, ráadásul kettő is, az egyik soros port felé, a másik USB-n lekérdezhetően.

Stringet nem nehéz C-ben kezelni, a konstansok végére automatikusan odateszi a termináló '\0'-t, nincs dolgod vele. Az, hogy nem az adatszerkezetnek van metódusa, hanem a függvénynek van paramétere, az ilyen régivágású dolog, de nem szégyen az. Függvénypointerek, struktúrák, unionok, pointerek vannak, nagyon flexibilis és hatékony. Nem nagyon támaszkodom külső #include-okra, a típusdeklarációk, az USB stack és a <math.h> az, amit kűlsős dologként használok, meg persze a regiszterek elnevezései, ami a hardware-t írja le, hogy a katalóguslapban megegyező nevekkel tudjak hivatkozni az adott regiszterre.

Szerintem az embedded környezet nem az a világ, ahova mindenféle objektumorientált, meg virtuális gépes - pl. java -, sok memóriát és futásidőt felemésztő nyelveket kellene használni. Persze az is világos, hogy 32 bites MIPS vagy ARM architektúrát ne akarjunk assembly-ben programozni.

Épp egy boot loadert írok, aminek érdekessége, hogy el kell mondani a fordítónak, hova allokálhatja a programot, mi legyen az entry point, külön öröm, hogy a megszakításokat is meg kell oldani valahogy, hiszen az sem maradhat ugyanott, mintha csak letöltenéd egy programozóval a kész firmware-t. Azért ilyen nagy mennyiségű, kívülről berántott cuccnál lehet, hogy már aggódni kezdenék, mennyire vannak általánosan, jól megírva, hogyan tolerálják a boot loader jelenlétét. Minél távolabb vagy a hardware-től, minél nagyobb az absztrakció szintje, annál jobban lehet izgulni, sikeres lesz-e egy ilyen manőver.
 

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Van még valamilyen mikrovezérlős modulod a fiókban? Pl. egy Ardiono mini? https://www.aliexpress.com/w/wholesale-arduino-mini.html?spm=a2g0o.home…

Az ESP-01-nek van soros portja, az Arduino mininek is, ezeket összekötve megoldott a kommunikáció a kettő között, az Arduino mininek meg van egy rakás portlába. :) "Kicsit" megerőszakolása a dolgoknak, jóval egyszerűbb lenne olyan ESP-t használni, aminek van elég lába, ez nem vitás. :)

( Nyosigomboc v | 2025. 09. 03., sze – 20:23 )

Mikrokontrolleres vilagban altalaban ketfele modon kerul fel a program az eszkozre: Van egy "egeto", ami az adott mikrokontrollernek megfelelo - altalaban egyszeru - protokollon keresztul belapatolja a megfelelo biteket a flash megfelelo helyere. Ez volt sokaig az elterjedt. Pl. Atmelnel a reset labat lehuzod, aztan SPI-on parancsokat adsz, amivel le tudod kerdezni az eszkoz azonositoit, mereteit, meg be tudsz egetni megfelelo byte-okat. PIC-nel ott a PICkit es ujabb tarsai, stb.

Aztan kitalaltak, hogy mi lenne, ha a flash - ami addigra mar kelloen nagy lett - egy reszet lerekesztenek. Erre a reszre tennenek egy bootloadert, ami indulaskor elkezd futni, es figyel egy megfelelo jelre. Ha ezt nem eszleli, akkor a szokasos modon atugrik a programjara, es teszi a dolgat. Ha eszleli, akkor atvalt egy masik modba, ahol valamilyen masik protokollon - vagy akar wifin - keresztul fel lehet tolteni a programjat (akar egy uj verzioju, modositott/javitottat is). Igy mukodik az ESP-d, de ilyen az Arduino (pl. a fenti Atmel alapu), vagy az STM32 alapu board-ok is.

Az eszkozodon egy ilyen bootloader fut, piszkalja a LED-eket/GPIO-kat, amit a programod futasakor a kapu nyitasahoz/zarasahoz szeretnel hasznalni. Ez igy nem fog korrekt modon mukodni. Kicsit olyan, mint ha egy PC-rol ugy probalnal valamit vezerelni, hogy a kepernyo megfelelo pixelenek feherre valtasat vizsgalod, de bootkor a "Press F1..." felirat P betuje pont arra a pixelre esik.

Megteheted, hogy teszel melle valamit, amivel TX/RX-en tudsz kommunikalni, esetleg a TX/RX labait atalakitod GPIO-ra - ha tud ilyet es masra nem hasznalja. Hasznalhatsz olyat, aminek a megfelelo labai ki vannak vezetve, az megint jo. Az, hogy idozitesekkel megprobalod a "felvillano pixelt" kiszurni, nem egy stabil megoldas. De ezt a reszet mar leirtak, inkabb csak osszefoglaltam.

A strange game. The only winning move is not to play. How about a nice game of chess?

Nekem már csak az nem világos, egy boot loader miért inzultálja az MCU portját. Én a saját boot loaderem esetében a kommunikációs interface-t és egy logolásra alkalmas - debug miatt jól jön az ilyesmi - soros portot zaklatok fel, de a csillió perifériáját nem inicializálom. Már csak azért is, mert azt szeretném, hogy ha ezzel az MCU-val másik hardware-t tervezek, a boot loader-em azzal is működjön.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Van az ESP8266, ami ez a wifis-mikrokontroller, ha jol emlekszem 32 labbal. Ebben persze van GND, tap, meg effelek, de azert alapvetoen van boven GPIO-ja. Erre epitett a gyarto olyan boardot - ez az ESP-01, aminek nem az a celja, hogy ezt hasznald kozvetlenul mikrokontrollernek, hanem hogy valamilyen kutyunek ezen a boardon keresztul adj Wifi kepesseget AT parancsokkal (alapbol egy ilyen firmware-rel jon). Ennek megfeleloen van 8 laba: GND, VCC (3.3V), RX, TX, Reset, Enable, Flash (GPOI0, firmware frissiteshez kell) es GPIO2 (egyik LED-re van kotve, ugy emlekszem, a wireless kommunikaciot jelzi). Amikor ez megjelent, meg nem volt kiadott devtool, nem is lehetett ratenni sajat programot. Rajottek, hogy egy 32 bites, rakas memoriaval meg flashhel rendelkezo procit onmagaban is lehetne hasznalni, felesleges egy - mondjuk 8 bitesrol - iranyitani. De nem volt rola sok informacio.

Aztan par evre ra megjelent egy nagyon korulmenyes C-s eszkoz (a legtobb doksi kinai), aztan minden mas (pl. Lua, Arduino). Szoval ez a board nem erre van, a kivezetett pinek a hasznalathoz - meg esetleges firmware frissiteshez - vannak, nem arra, hogy masra hasznald. Arra ott lenne egy rakas masik GPIO, ami ezen nincs kivezetve. Vehetsz ESP8266-ot onmagaban, vagy olyan boardot - mar van egy csomo - amin ki vannak vezetve ezek a plusz labak. Alapvetoen ezek lennenek arra, hogy sajat projectet epits ra.

Kicsit olyan, mint ha keszitenel egy PIC-es eszkozt, amin egy csatlakozon ki lennenek vezetve a flasheleshez szukseges pinek, aztan valaki jonne, es az egyik labat raforrasztana a kocsijanak a taviranyitojara.

Ja, ha wifin keresztul akarsz flashelni - nem tudom, ezt pont tudja-e, de elvileg nincs kizarva - akkor a bootloader nem baj, ha a wifit mar kezeli. Esetleg azt a pin-t is, ami a kommunikaciot jelzi, es villog, ha van adat. Ez az utobbi megy az egyik kapunyito gombra.

A strange game. The only winning move is not to play. How about a nice game of chess?

Erre epitett a gyarto olyan boardot - ez az ESP-01

Az ESP-01-et nem az Expressif tervezte, hanem az AI-thinker, kifejezetten Wifi kapcsolatra képes "modem" céljából. Az összes ESP-x board AI-thinker tervezésű, az Expressif nem gyártott board-ot.

Amikor ez megjelent, meg nem volt kiadott devtool, nem is lehetett ratenni sajat programot.

Hogyne lehetett volna, az egész ESP8266 ugyanúgy programozható volt, mindegy, hogy milyen board-ra építették rá, az SDK a chip-el együtt jött ki, ami később jött ki, az az OSS SDK, amit aztán beépítettek az Arduino IDE-be.

Aztan par evre ra megjelent egy nagyon korulmenyes C-s eszkoz (a legtobb doksi kinai), aztan minden mas (pl. Lua, Arduino).

Milyen "pár évre rá"? 2014 elején került ki kereskedelmi forgalomba az ESP8266 chip, az ESP-01 board 2014 augusztusi, az Expressif SDK 2014 márciusban jött ki, az első Arduino SDK 2014 novemberi.

https://iotguru.cloud

Nekem már csak az nem világos, egy boot loader miért inzultálja az MCU portját.

Mert az ESP8266 alapvetően úgy van tervezve, hogy a GPIO00, a GPIO02 és a GPIO15 lábak különböző jelszintjeivel lehet indítani a felprogramozását és a boot folyamatot:

A normál működés az, hogy a GPIO15 low, a GPIO00 és a GPIO02 high szintre van húzva, tehát az összes board-on ez a három láb így van default fel és lehúzva.

Ha UART-on keresztül fel akarod programozni, akkor a GPIO15 low, a GPIO00 low és a GPIO02 high kell legyen.

Ha SDIO-n keresztül akarod beolvasni a programot, akkor a GPIO15 high kell legyen, a GPIO00 és a GPIO02 low kell legyen.

Ezért nehéz bármi másra értelmesen használni ezeket a lábakat.

https://iotguru.cloud

Annyira nem hoz lázba. A Microchip például az MCP23009 esetében csinálja azt, hogy egy analóg feszültségből dekódolja ki magának az eszköz 3 bites címét. Lényegében egy 3 bites AD konverter által adott eredmény a device address.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

DAC-ra? Két ellenállás mindössze, meg legfeljebb egy kondenzátor, és akkor a zavarokra sem lesz érzékeny. DAC akkor kellene, ha a működés során módosítani szeretnéd a címet. Amit viszont nem biztos, hogy lehet, mert mi van, ha az élet elején, reset után mintavételezi, utána nem foglalkozik vele. Ezt amúgy teheti digitális cím esetén is.

Az egész onnan indult, hogy kevés lába van, és azt a keveset is elhasználják csillió féle boot üzemmód beállítására, ami miatt elfogy minden láb.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Minden relativ. Az igaz, hogy az Intel meg AMD prociknal nem ritka a 2000 lab - vagy akar annal is tobb, de szerintem egy mikrokontrollernel a 32 egyaltalan nem keves.

Ha keszitesz egy olyan panelt, amin van egy soklabu FPGA, de csak a vcc, gnd, es egyetlen masik pin van kivezetve, akkor most az FPGA-nak van keves laba, vagy a panelnek?

Az egetest bekapcsolas/tap utan szokas csinalni, ilyenkor a 2 ellenallason keresztul toltodo kondi nem biztos, hogy szerencses. Persze meretezes kerdese, hogy tartsa annyira a feszultseget, amennyire kell, de megis kelloen gyorsan feltoltodjon a bekapcsolas utan. De mar egy fokkal macerasabb, mint fel/lehuzni a megfelelo labakat a megfelelo modhoz. Persze a 8 modszer kicsit soknak tunik, de 4-nel tobber azert ki lehet talalni (pl. wifi, bt esp32 eseten, normal vezetekes egeto, sd kartya, uart).

A strange game. The only winning move is not to play. How about a nice game of chess?

Ha valaki parázik a zavaroktól, ott a kompenzáció lehetősége, azaz két kondenzátor, két ellenállás. Nem kell és nem is lehet halál pontosan. De nem szükséges, mert a két ellenállás, esetleg egy picike, mondjuk 100 pF körüli kondenzátor megteszi. Majdnem biztos vagyok abban, hogy egyszer mintavételez, utána nem érdekli, mi van azon a cím lábon. Belatcheli címet az elején, aztán az van kikapcsolásig.

Nyilván a nyák a kevés lábú, csak akkor meg azt nem értem, miért ilyen vackokat használ valaki. Azt értem, hogy nincs mindenkiben meg a képesség, képzettség a hardware-tervezéshez, de ma már a piacon minden is van, s talán még a nyák színe is szabadon választható. Szinte kizárt, hogy nincs a feladatra alkalmas félkész eszköz.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az egész onnan indult, hogy kevés lába van, és azt a keveset is elhasználják csillió féle boot üzemmód beállítására, ami miatt elfogy minden láb.

Annyira nincs kevés lába az ESP8266 chip-nek, az egy 32 lábú IC, van 16+1 GPIO lába, plusz a szokásos egyéb lábak (tápfeszültség, órajel, reset, enable, etc).

Az ESP-01 board-ra van kevés lába kivezetve, konkrétan az UART RX/TX és a boot mode selector GPIO00 és GPIO02, beleértve, hogy a GPIO02 a LED-re is rá van kötve, mert státusz LED-ként funkciónál.

Az ESP-01 board arra szolgál, hogy soros kapcsolaton át AT parancsokkal Wifi kapcsolatot lehessen létrehozni, majd azon át egyszerű HTTP kéréseket tudjon kiszolgálni; a GPIO02-re kötött LED mutatja a kapcsolat státuszát, a GPIO00 low-ra húzásával pedig fel lehet programozni soros kapcsolaton át. Ezt erre tervezték.

Van egy csomó ESP8266 alapú board, amire kb. az összes láb ki van vezetve, ilyet érdemes használni, ha nem soros kapcsolaton akarunk Wifi kommunikációt.

https://iotguru.cloud

Ha jól értem, akkor egy kapunyitó nyomógombját kell vezérelni, amihez a relé feleslegesen nagy. Megnézném, hogyan van a nyomógomb megvalósítva. Ha például GND-re húzás van, arra akár az MCU port kimenete is alkalmas lehet open drain konfigurációval. Ha a mikrokontrollerünk tápfeszültségénél nagyobb feszültségre húzzák, akkor pedig egy MOSFET. Ha multiplexelt a nyomógomb olvasása, akkor analóg kapcsolót használnék.

Persze, lehet, hogy a készen kapható megoldások közül a relé a legegyszerűbb.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( hnsz2002 v | 2025. 09. 04., cs – 21:16 )

Oké, elengedtem az ESP-01-et. A pici ledvillanás csak megmaradt, akármit csináltam.

Megnéztem tüzetesebben az arduinos fakkot... Van még itt ESP32 C3 meg ESP32 80P is. :D (Nem is emlékeztem ezekre)

Úgyhogy megnézem a C3-at.

"Sose a gép a hülye."

Nos, alapvetően működik tök jól. Hétvégén be is tettem a kapuhoz. Viszont tényleg elég csak egy pöccintés a lábakra, úgyhogy levettem 0.2s-re a relé behúzásának idejét, még ez is bőven sok.

Lefordul a firmware, felteszi (OTA), elindul, megy szépen... Home assistantba bejön az új id-val a két elem (teljesnyitasrele02s,  gyalogosrele02s), onnan is megy, webről is... Majd, egy pár óra múlva visszajön a 0.5s-os változat. Az WTF??? Mintha lenne valami primary meg backup firmware, a primary-ra felteszem a 0.2s-es firmwaret, aztán egyszer csak újraindul a 0.5s-es backuppal.
 

"Sose a gép a hülye."

Attol meg o foglalkozhat a hobbijaval, fejlodhet elektronikabol (lenne hova). A kapu ugy kenyelmes, ha kinyilik. A sportnal meg o donti el, hogy mikor mennyit szeretne.

Egyebkent az is megoldas, ha auto helyett biciklizik - de nem minden elethelyzetben, es nem minden kornyeken jo.

A strange game. The only winning move is not to play. How about a nice game of chess?

Mintha lenne valami primary meg backup firmware, a primary-ra felteszem a 0.2s-es firmwaret, aztán egyszer csak újraindul a 0.5s-es backuppal.

Mert az OTA úgy megy, hogy kettő firmware van egymás mellett, és a bootloader a boot folyamatnál választja azt, ami be van állítva. Amikor OTA frissítés van, akkor üzemszerű esetben a "régi" firmware helyére tölti le azt, ami az "új" firmware és ha sikeres, akkor bejegyzi, hogy a bootloader a következő boot során már azt töltse be. És néha van, hogy a régi indul el, ha valami nem sikerült jól és/vagy valamiért visszateszi az OTA az előző firmware-t.

Ennek három oka van: egyrészt az, hogy vissza tudja állni a régi firmware-re, ha valami nem jó; másrészt nincs hol tárolnia, mint ott, ahol véglegesen lesz; harmadrészt nem tudja felülírni azt a részt, ahonnan éppen fut.

https://iotguru.cloud

Na ezt magyarázza meg valaki: FW: 1MB, FS: 3MB, OTA: ~500kB

Működik, de hova a gecibe teszi az OTA cuccot?

ElegantOTA 3MB FW/1MB FS módban fordítva felrakja a 2MB FW/2MB FS 300kB ElegantOTA example cuccot, ami visszarakja a 950kB 3MB FW/1MB FS cuccomat. AsyncWebServeren kűzdök vele.

https://www.esp8266.org/

Na ezt magyarázza meg valaki: FW: 1MB, FS: 3MB, OTA: ~500kB

Pont ezt írtam le: OTA nélkül 1 MB fér rá, OTA-val csak a fele.

Működik, de hova a gecibe teszi az OTA cuccot?

Az 1MB FW területre két darab ~500 kB OTA firmware fér.

ElegantOTA 3MB FW/1MB FS módban fordítva felrakja a 2MB FW/2MB FS 300kB ElegantOTA example cuccot, ami visszarakja a 950kB 3MB FW/1MB FS cuccomat. AsyncWebServeren kűzdök vele.

Nem ismerem részletesen az ElegantOTA működését, vagy olvass doksit, vagy nyiss ticket-et, ha bug. De sok értelme nincs ezeknek a wrapperek-nek, mert a tényleges OTA-t az ESP csinálja, ezek a cuccok csak pár soros wrapper kódok az eredeti OTA köré.

https://iotguru.cloud

De itt nem az van, hogy nem sikerül a frissítés, és instant a régi indul,m hanem success, ment egy darabig, majd utána valahogy visszaállt a régi.

Lehet ennek ahhoz köze, hogy bent volt az esp32-nél:

  framework:
    type: esp-idf

?

Találtam pár konfigban, illetve talán az esphome run is javasolta, hoyg valami új bináris formátum... Most napközben kikommenteltem, így buildeltem, feltoltam újra OTA-val, azóta jó...
 

"Sose a gép a hülye."

De itt nem az van, hogy nem sikerül a frissítés, és instant a régi indul,m hanem success, ment egy darabig, majd utána valahogy visszaállt a régi.

Attól még ott van az előző firmware is. És van olyan, hogy valamiért az indul, akár azért, mert hibás lett az OTA.

Találtam pár konfigban, illetve talán az esphome run is javasolta, hoyg valami új bináris formátum... Most napközben kikommenteltem, így buildeltem, feltoltam újra OTA-val, azóta jó...

Az ESP-IDF az Espressif saját környezete, ami nem Arduino alapú.

https://iotguru.cloud