Durva cache-t, de hogyan?

Web, mail, IRC, IM, hálózatok

Egy nagyon kis erőforrású - mikrokontrolleren futó - webszerver kiszolgálását szeretném felgyorsítani a lehető legjobban. Az elavult böngészők támogatása nem cél, de a mobiltelefonról történő csatlakozást biztosítani kell.Két irányban tudok elindulni:
1 - Minimalizálom az elküldött tartalmat, azaz a statikus tartalmakat gzip-el tömörítve küldöm el.
2 - Megkérem a klienst, hogy csak a dinamikus tartalmakat kérje le újra, így a képeket, statikus fájlokat csak egyszer töltené le.
Sajnos egyik irányban sem sikerült lépnem.
1 - Ha minden statikus tartalmat gzip-el tömörítek, és a "Content-Encoding: gzip" header-t küldöm el a válaszban, akkor a mobil default safari böngészője nem képes értelmezni a választ. Emiatt a tömörített küldés kiesik. Vagy van valamilyen más header, amivel jelezni tudom a kliens felé, hogy tömörítve küldöm az adatot? Tudom, hogy a kérelemben elküldi a kliens, hogy képes-e értelmezni a tömörített adatot, de a kérelem header értelmezése, és a különböző esetek kezelése is erőforrást igényel. Olyan megoldást keresek, ami minimalizálja a szerver erőforrásigényét.
2 - A statikus tartalmak mellé elküldöm a "Cache-Control: max-age=300, public" header-t, mégis a böngésző minden oldalfrissítésnél újra és újra lekéri az összes képet. Pedig ezt a header-t írják mindenhol. Tudtok olyan header-t ajánlani, aminek a hatására a mobil böngésző csak nagyon ritkán, vagy akár soha sem kéri le újra az erőforrást?

  • 3634 megtekintés

( persicsb | 2017. 09. 18., h – 10:28 )

Miben kis erőforráső a kontroller? CPU teljesítményben? RAM-ban. Ez a két dolog egymásra ortogonális.

"Minimalizálom az elküldött tartalmat, azaz a statikus tartalmakat gzip-el tömörítve küldöm el."
gzip tömörítés az a memória/sávszélesség problémát oldja meg, CPU teljesítmény kárára. Azaz ha a CPU teljesítmény a szűk keresztmetszet, ezzel rontasz a teljesítményen.

"2 - Megkérem a klienst, hogy csak a dinamikus tartalmakat kérje le újra, így a képeket, statikus fájlokat csak egyszer töltené le."
Ez sima HTTP cache headerekkel megoldható.

"Vagy van valamilyen más header, amivel jelezni tudom a kliens felé, hogy tömörítve küldöm az adatot?"
A Content-Encoding: gzip az önmagában nem elég. Csak akkor használhatod, hogy a kliens a kérésben jelezte, hogy be tudja azt fogadni. A kérésben lévő Accept-Encoding header tartalmazza, hogy milyen forráskódolást támogat a kliens, lehet, hogy gzip-et nem, de deflate-t igen. " de a kérelem header értelmezése, és a különböző esetek kezelése is erőforrást igényel." Már pedig ha nem támogatja a gzip-et a kliens, akkor hiába küldesz neki gzipet. Fel KELL dolgoznod az Accept-Encoding headert.

"A statikus tartalmak mellé elküldöm a "Cache-Control: max-age=300, public""
5 perc nem igazán érdekes cache-control max-age érték. Adj meg jóval nagyobbat.

A statikus tartalmakat kiszervezheted teljesen külön kiszolgálóra is.

Másrészt: a HTTP az egy nagy erőforrás-igényű protokoll, szöveget kell parzolni állandóan hozzá. Ez drága dolog.
Mit akarsz pontosan megcsinálni? Mindenképpen HTTP és web kell neked?

A kontroller egy ESP8266. Leginkább a CPU gyenge, de a memória sem sok.

Ezek szerint a deflate más, mint a gzip. Ez jó hír! Megpróbálom zlib-bel és deflate tömörítéssel, hátha azt támogatják a gyakori mobil böngészők! Még meg kell találnom, mivel tudok linux alatt zlib tömöríteni, de ez jó ötlet!
Mellesleg a tömörítés nem igényel CPU erőforrást, ha egyféle, mivel eleve tömörítve tárolom a fájlokat. Ezért is lenne nehéz figyelni az Accept-Encoding headert. A fájlok minden változatának tárolása pedig már nem férne el a tárterületen. Persze, ha a cache működne, akkor nem lenne akkora baj, hogy nem tömörítve megy az adat.

Az 5 perc csak a tesztelés miatt 5 perc. Ha működne felemelném. De az 5 perc sem működik.

Egy mobilról vezérelhető termosztát a végcél. Ehhez legegyszerűbb vezérlőfelület a web. Persze, ha pure html, semmi csicsa, akkor nincsenek erőforrás problémák, de szeretnék szépet. Js, css, képek, design.

A statikus tartalmakat, mint CSS, JS, elhelyezheted egy másik kiszolgálón, ahonnan letölti az adatokat a böngésző, a termosztát mikrovezérlője pedig csak a dinamikus tartalmakat állítja elő.

Még egyszerűbb lenne, ha az egész CSS/JS/HTML file-okat egy külön szerveren helyeznéd el, ahonnan a böngésző letölti, a termosztát pedig csak a dinamikus tartalmakat szolgálja ki, akár websocketen, akár máshogy. Minek azt tárolni a termosztáton, amit amúgy máshol is tárolhatsz?

Használj E-Taget a Cache-Control mellé.
Amúgy tudnál mutatni egy teljes HTTP header-halmazt, amit a kontroller előállít?
Még az is lehet, hogy nincs jól beállítva az időzóna, ezért aztán hiába 5 perc a cache értéke, azt látja a böngésző, hogy már rég lejárt a cache érvényessége.

Több webszerverrel is próbálkoztam. A mostani a következő headereket küldi vissza: 


Cache-Control: public, max-age=600
Content-Encoding: gzip
Content-Length: 545
Content-Type: image/svg+xml

Sajnos ez a server statikus tartalomhoz csak statikus header-t tud társítani, bár nem tudom, szükség lenne-e másra is.

Közben kiderült, hogy ez a webszerver rosszul küldte vissza a tömörített adatokat. Ezt kijavítva látszik, hogy a mobil böngésző is fogadja a gzip tömörített tartalmat, így az 1-es ponton pipa.

A szerverem nem tud dinamikus header-t generál a statikus tartalomhoz.
Jelenleg még egy oldalból áll a felület, így csak a frissítéssel tudom tesztelni.
Összesítve akkor a jó cache beállításhoz a következő header-ök használhatóak: Cache-Control, Expire, E-Tag, Date.
Ezekből - ha jól tudom - az E-Tag egy kontroll összeg a tartalom változásának ellenőrzéséhez, tehát minden esetben a szerverhez kell fordulni, hogy értelmezni lehessen. Az én szerverem nem tud 304-es választ generálni, csak 200-ast, így ez jelen esetben nem segít.
Frissítésre a többi fejléc sincs hatással, tehát ezen fejlécek mellett a frissítés mindenképpen újratölti az oldalt.
A tartalom tömörített küldését jelezhetem a Content-Encoding fejléccel.
Van még lehetőségem, vagy ennyivel tudok gazdálkodni?

A jó cache-hez a Cache-Control és a Date elegendő, vagy az Expires és a Date. (Ha van mind a kettő, akkor a Cache-Control a nyerő). A Date nem feltétlen szükséges, de akkor némely kliens esetleg nem cache-el.

Az ETag az már szerveroldali, ahogy írod is. Szerver oldalon még van a Last-Modified használata is, de szerintem a kliens oldali döntéshez nem nagyon van más lehetőséged, csak a fentiek.

Szerk.: az Expires nagyobb eséllyel működik Date nélkül is, de hát azt is dinamikusan kell generálni.

Mikrokontrollerre minek web/js/css? fogadjon plaintextben parancsot paraméterekkel, aztán az eredményt tolja ki szintén plaintextbe/csv-be. A kliensgép(ek)re meg megírni a csilivili szoftvert, ahol nem muszály takarékoskodni az erőforrásokkal.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

"Ehhez legegyszerűbb vezérlőfelület a web"

Van egy raklapnyi fw (en egyiket sem ismerem :D), amivel weblapot mobil appa lehet takolni, az uj ertekeket lekerheted AJAXszal. A juzer ugysem fogja akarni bongeszobol megnyitni az oldalt, telepiti az appot azt keccsokolom. En ebbe az iranyba indulnek el.

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám

Ebben az esetben is kell egy webszerver a mikrokontrollerre, csak még egy app is mellé. Ráadásul innentől kezdve minden telefon oprendszerre külön app kell, vagy biztosítani kell internetkapcsolatot.
Összességében nekem ez egy összetettebb útnak tűnik. De persze az app mindenképp elegánsabb lenne, mint egy webcím.

Igen, teljesen igazad van. A mobil app nagyon hasznos, és biztos, hogy az erőforrásigényt minimalizálni lehet vele a mikrokontroller felé.
Cserébe többletmunka van a másik oldalon.
Ha a mikrokontroller el tudná látni a saját konfigurálását, számomra az lenne a legmegnyugtatóbb. Akkor a későbbiekben szabadon bővíthetem a funkcionalitást, nem kell mindig új appot generáltatni, nem kell figyelnem, hogy a kliens megfelelő app verzióval csatlakozik-e. Így először ezt az utat szeretném végigjárni.

Olyan dolgokat akarsz megcsinálni egy mikrokontrollerrel, amire nem való.

A legjobb megoldás a következő lenne szerintem:
- a mikrokontroller csatlakozik egy meglévő hálózatra, és nem ő maga az AP, amire csatlakozni kell. Szép is lenne, ha csak amiatt, mert nekem a termosztátot ellenőriznem kéne, WiFi-t kéne váltanom a telefonon, a laptopon stb.
- a mikrokontroller periodikusan, vagy kérésre elküldi a mért adatokat egy adatfeldolgozóhoz. Nem feladata egy ilyen eszköznek weboldalakat kiszolgálnia, csak adatot szolgáltat, amiből a megfelelő eszközök kiszolgálják a weboldalakat.
- a mikrokontroller a megfelelően azonosított felektől megkapja a parancsokat, hogy mit csináljon és végrehajtja azokat.

( st3v3 v | 2017. 09. 18., h – 10:37 )

[troll]
nem épp kifinomult cache-re lenne szükséged a "durva" helyett? :)
//troll logging off.

( gabrielakos v | 2017. 09. 18., h – 10:48 )

Tegyél elé egy proxy-t.
--
Gábriel Ákos

( Mcsiv v | 2017. 09. 18., h – 19:01 )

szerintem debugolj. Mind a gzip-nek, mind a cache-control -nak működnie kellene

// Happy debugging, suckers
#define true (rand() > 10)

( STP | 2017. 09. 18., h – 21:43 )

Ne küldj képet.
Használj táblázatot, SVG-t, oszt jó napot.
Kispolákkal sem tudsz 50 fős csoportot vinni Madridba egyszerre.

( ReLuXa | 2017. 09. 18., h – 22:47 )

Én mondjuk optimalizálnék arra is, hogy minél kevesebb file legyen összesen. Valami single page weblapot raknék össze mondjuk angular2 alapon és vhol láttam, hogy van olyan toolchain, ami képes csak a szükséges dolgokat egy js fileba összerakni. Ezt gzippelném és raknám fel az SPIFFS-re. Ha jól tudom, az ESP8266-nál limitált, hogy hány socketet tud egyszerre nyitvatartani, szoval lehetőség szerint az összes assetet szintén vhogy begyógyítanám egy css-be.

( vl v | 2017. 09. 19., k – 06:42 )

A problémád lényege, hogy olyan eszközt akarsz a célodra használni, amire az nem alkalmas.

A megoldás pedig ennek a kiküszöbölése: tegyél elé egy készüléket, ami alkalmas a browser kiszolgálására, a mikrokontrollert meg arra használd, amire való: a minimálisan szükséges információ biztosítására (az elé rakott készüléken futó sw számára).

Hosszabban: egy normális browser kiszolgálására sok-sok MB-ban mérhető RAM kell. Mondjuk egy 128MB RAM-mal ellátott szappantartó (pl. OpenWRT-s wifi router) alatt nem is próbálkoznék, de egy RPi vagy valamelyik combosabb haverja már GB nagyságrendben tartalmaz memóriát. Egy mikrokontrollernek ennyi sosem lesz. A mikrokontroller arra tökéletesen elég, hogy egy szál TCP kapcsolaton meg lehessen tőle kérdezni mondjuk másodpercenként egyszer pár adatot, ami néhány KB-ban elfér (vagy még jobb, ha magától küldi el az adatokat a "gazdájának"). A szappantartón futó webszervertől aztán sok 100KB-os HTML oldalak formájában, képekkel-sallangokkal, körítéssel, akár 42 párhuzamos sessionben is kérdezgethetik a kliensek, az már bírni fogja a strapát.

Igen, tudom, hogy nem alkalmas erre az eszköz, éppen ezért érdekel. Mennyit lehet ebből az eszközből kihozni, mi a határ, és mi az, amibe már belebukom.
A kérdésem is arra vonatkozik, hogy hogyan tudom elérni, hogy minimális erőforrást kelljen csak kiszolgálnia, hisz többre nem igazán alkalmas.

Szerintem megkaptad a választ. Ha mindenképp ragaszkodsz az AP-s történethez, akkor vegyél egy pi zero w-t, az szolgálja ki a webserver forgalmat, a mikróval és beszélgessen soros porton, vagy i2c, spi, whatever protokollon keresztül.

Nem nagy költség (szállítással 5000 Ft alatt kézhez kapod, a havi fogyasztása lesz talán 100 Ft), kell még mellé egy levetett usb táp, egy levetett uSD kártya, tuti találsz kallódót. Felteszel rá egy linuxot, arra gyorsan egy l*mp stack-et (apache helyett inkább nginx vagy lighty), megoldod a (bocs) soros kommunikációt a két eszköz között, sztennyi.

Ha végignézed a válaszokat, a többsége nem a feltett kérdésre válasz.
Van néhány hasznos tanács, hogy hogyan tudom gyorsítani a kiszolgálást, de hogy hogyan tudom elérni a tartós kliensoldali cache használatot, arra nem jöttem rá.
A probléma megoldása szerintem más esetekben is hasznos lehet. Szeretném tudni, hogy hogyan irányíthatom a kliens oldali cache-t.
De többen arról próbáltok meggyőzni, hogy más rendszert építsek. Ez nekem nem válasz arra, hogy ezt a rendszert hogyan optimalizálja. Akkor sem, ha igazatok van, és van jobb rendszer.

Mellesleg a rpi doboza és ennek a doboza között ég és föld a különbség.
Mindenféle külön tápegységek és egyéb kiegészítők összegányolásával már próbálkoztam, működik, de ronda. Ez egy szép, kompakt, vállalható, lakásba is gond nélkül elhelyezhető egység. Nekem ez is szempont. Fogyasztani ez sem fogyaszt többet. (<1W)

Jelenleg már elfogadható sebességgel szolgálja ki a weboldalakat, bár még lehetne gyorsítani.
Továbbra is várom azokat a válaszokat, amik arról szólnak, hogy hogyan tudom tartós cache-re bírni a mobil klienseket.
Azóta az is kiderült, pontosítva a feladatot, hogy a webszerver statikus fájlokhoz csak statikus headereket tud csatolni, így például elég nehéz lenne valamilyen aktuális időpont alapú header értéket visszaadnom.

"Továbbra is várom azokat a válaszokat, amik arról szólnak, hogy hogyan tudom tartós cache-re bírni a mobil klienseket. "
10 perc neked tartós cache?

Az általad adott headerek (https://hup.hu/node/155399?comments_per_page=9999#comment-2141516 ) alapján:
Ha ez HTTP/1.0, akkor ne csodálkozz. A szabvány (https://tools.ietf.org/html/rfc2616#page-108 ) szerint:
Note that HTTP/1.0 caches might not implement Cache-Control and might only implement Pragma: no-cache (see section 14.32).

HTTP/1.1 vagy HTTP/1.0 a protokoll?

Ezt másként látjuk, de hát ettől szép a világ.
Egyébként én élvezek az erőforrások határán járni. Szerintem sokkal tanulságosabb, mint például apache alá betenni egy php kódot. Én legalábbis ebből a bűvészkedésből már eddig is sokat tanultam.
Szerintem egy ilyen feladatot lehet fikázni, vagy kihívásnak tekinteni. Ha pedig véletlenül még sikerül is megcsinálni, az meg csak hab a tortán! :)

Ha valós alternatívát látnék, persze az is érdekelne, de az elhangzottak közül egyedül az esp32 volt valóban alternatíva, de összességében az is bukott. Az, hogy valaki szerint valami jól hangzik, az nem alternatíva. A konkrét igényeket kívülről úgysem látjátok, én meg nem nem akartam ebbe az irányban elmenni. Gondoltam, keselni sokkal többen keselnek, mint ahányan mikrovezérlőket használnak.
Főleg úgy fura a sok alternatíva ajánlás, hogy már látszik, ezzel a hardverrel is megoldható a feladat. Van benne elég erőforrás, csak ügyesen kell tudni használni.

Én sem értem a fikázókat.
Ha egy termosztátot kell vezérelni, akkor miért ne lenne jó, ha annak a hardverére (is) kerül a web kiszolgáló, ha egyszer elbírja? Miért lenne az jobb, hogy van még egy hardver, plusz kommunikációval, plusz hibalehetőségekkel, ...?

Természetesen, ha több termosztát (vagy más egység) van, akkor már jobb lehet egy külön kézbe fogni a vezérlést.

( pepelopez | 2017. 09. 19., k – 07:09 )

Nem tudom melyik webszervert használod rajta de általában max 2 kapcsolatot tud kezelni. Nálam így néz ki pl egy index html:

https://pastebin.com/p24bixPY

egymás után tölti be az oldal alkatrészeit

De jobban jársz ha mqtt-vel értesíted ki a klienseket, de ehhez is kell egy mqtt broker

Igen, ezt megtapasztaltam. A webszerverek zöme még kettőt se nagyon kezelt. A többit meg várakoztatta, és ezekből néhány meg is szakadt. A rosszabb az, hogy amikor elkezdett kiszolgálni egy kérelmet, néha azt is megszakította. Szerintem ennek egyik oka az SPIFF lassúsága, de ezt nem teszteltem.
Próbáltam az asyncron webszervert is arduino magra, mert ez azt állította párhuzamos kiszolgálásra képes. Állításnak mondjuk jó volt, de a gyakorlat nem hozott lényegi javulást.
Míg nem az esp-open-rtos webszerverét ki nem próbáltam! Mint az álom! Gondolom leginkább az RTOS-nak köszönhetően. Jelenleg 11 darab 1-2kb-os erőforrásból áll az oldalam, de gyakorlatilag zökkenőmentesen tölti be. Legalábbis firebuggal figyelve a letöltést, szinte párhuzamosan szolgál ki vagy 8 kérelmet. Érezhetően gyorsabb a kiszolgálás ezzel a webszerverrel, és egyszer sem szakadnak meg a letöltések. El sem timeotol egyik sem. Persze, még így is lehet 1-2 másodperc, mire lejön az oldal és minden képe, de ez már emészthető kategória. Ráadásul gzip-elt tartalommal már 1 másodperc alá is beszorítható. Ha mindezt még egy jó cache kezeléssel is el tudnám látni, akkor egy-egy eseményre már tényleg csak egy-egy kérelem kiszolgálása maradna, és egészen használható környezetté válna.

( uid_6201 v | 2017. 09. 19., k – 11:10 )

Esetleg erősebb erőforrásra lehet váltani: ESP8266 --> ESP32
https://www.cnx-software.com/wp-content/uploads/2016/03/ESP8266_vs_ESP3…

Illetve a webet milyen nyelven programoztad benne? Sokat lehet erőforrásban nyerni, ha C-ben dolgozol.

Webről: minél nagyobb része egyetlen fájlos, statikus, gzip tömörítve tárolt legyen. Statikus képecske is ugyanebbe a HTML fájlba mehet base64-ben. Lásd: http://www.bigfastblog.com/embed-base64-encoded-images-inline-in-html
Ezt az egyetlen fájlt simán ki kell lökni a böngészőnek az oldal megnyitásakor.

Az adatokat pedig periodikus AJAX kérheti, de csak az adatokat és azt is erőforrástakarékos módon generálva és egyben kilökve. Ezt a böngészőben futó AJAX javascriptje a megfelelő mezőbe behelyettesíti, illetve a böngészőben futó javascript az adatokból akár rajzolni is tud. Lásd: HTML5 canvas.

Jelenleg is ESP8266 vezérli a termosztátot, de még csak nagyon primitíven. Ezt újítom most fel. Ilyen csipem van pár, később másra is használni szeretném, ezért most meg akarom ismerni a lehetőségeit és korlátait. Ráadásul 6 dollárért dobozzal, táppal, relével egybeöntve esztétikus kivitelben... Egyelőre nem váltanék másik csipre.
Luával kezdtem, de most már c-ben generálódik a weboldal.
A base64-től tartok, mert az meg a méretét növeli, bár gz-vel talán már nem vészes. Ezt át fogom gondolni a design és kódolás újratervezésénél.
Egyelőre a cache-t akarom beállítani a lehető legjobbra.

r40.gif --> 2154 byte
r40.gif.base64 --> 2910 byte ... ez van beágyazva a HTML-be
r40.gif.base64.gz --> 2253 byte - valójában a HTML-be rakva a HTML-lel együtt lesz összetömörítve

Ellenben egyetlen lekérés és egyetlen fájl kiszolgálás hárul az ESP8266-ra.
De nézzük nagyobb fájlméretre, mi történik ha a HTML-be ágyaznánk és gzip-elnénk?

predikaloszek.jpg 231628
predikaloszek.jpg.base64 312904
predikaloszek.jpg.base64.gz 237155

Ez sem jelentősen nagyobb méretű gzip-elve. Ellenben meghálálhatja a kisteljesítményű elektronika, hogy egyetlen lekérés + egyetlen válasszal megvan a statikus rész kiszolgálása a sok apró párhuzamos lekérés és sok válasz helyett.

Köszönöm. Ez így igaz. Csak annyit veszítek a beágyazott képekkel, hogy jó keselés esetén a képek csak egyszer mennek le a klienshez, és onnantól az egy oldal, amit letölt az sokkal kisebb.
Jelenleg ott tartok, hogy egészen jó sebességgel tudok kiszolgálni már fájlokat, bár a jó keselést még mindig nem sikerült megtalálnom.
1-2 kb-ot élvezhető sebességgel ad vissza, 10-20kb felett azért már zötyög. Lehet, hogy a beágyazást nem a html-be tesztem, hanem a css-be. Így keselve nem töltődnek újra, és mégis csak egy kapcsolat a 9 helyett.

"Jelenleg is ESP8266 vezérli a termosztátot, de még csak nagyon primitíven."

Ehhez miért kell webszerver? Fordítsd meg a dolgot, legyen önállóan üzemképes a vezérlés, kérje el időnként a kívánt állapotot és az ehhez szükséges mérési adatokat és döntsön ennek megfelelően. Ne egy buta perifériád legyen, hanem egy önállóan döntésképes okos perifériád.

Nem is ertem a kerdest. Amikor mar egy huto is "okos", beepitett ap-val es mobilalkalmazassal jon (hello LG).
Akkor egy termosztattol miert varna el az ember kevesebbet?

Mondjuk en szemely szerint 3x is meggondolnam, hogy netre engedjem ki az ementali sajtot....

Meg a francnak van kedve security fixeket telepiteni 10 ev mulva a hutojere.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Ezek szerint nem ugyanazt értjük "okos" alatt. Nekem a termosztát nem attól okos, hogy fut rajta egy webszerver vagy egy MQTT kliens, amin keresztül tudom vezérelni, hanem attól okos, hogy önállóan képes a feladatát ellátni és ehhez nem kell rá webszerver vagy MQTT kliens, nincs központja.

egyre gondolunk, csak felhivtam a figyelmedet egy trendre, ami szerintem elharapodzott (pl okos huto).

De beszeltem mar napkollektoros ceggel is, aki szerint az internetrol konfiguralhato napkollektor azert jo a felhasznalonak ( havi dijon kivul ;),
hogy problema eseten a szerviznek nem kell a helyszinre mennie...
En erre csak annyit mondtam nekik, hogy amihez nem kell csavarhuzo, azt szoftveres bugnak hivjak errefele...;)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Az okos termosztát természetesen önállóan kapcsolgatja a program szerint a fűtést.
De felprogramozni, vagy a programban váltani kell tudni, és ehhez felület kell.
Minden termosztáton kell lennie olyan funkciónak, hogy bár most 20 fokra fűt a program, mégis emelje meg 22-re. Ehhez kell valamilyen felület.
Vagy hardveres, gombokkal, tekerőkkel, helyi kis képernyővel, vagy egy weboldal. (Vagy app, vagy bármi más, de kezelni kell tudni.)

"Az okos termosztát természetesen önállóan kapcsolgatja a program szerint a fűtést."

Ez eddig oké.

"De felprogramozni, vagy a programban váltani kell tudni, és ehhez felület kell."

Ezt kérje el valahonnan, mint kliens vagy kapja meg, mint szerver, de pár bájtos machine-to-machine protokollon.

"Minden termosztáton kell lennie olyan funkciónak, hogy bár most 20 fokra fűt a program, mégis emelje meg 22-re. Ehhez kell valamilyen felület."

De ennek nem a termosztáton kellene lennie. Semmi keresnivalója a termosztáton, az egy végrehajtó egység, függetlenül attól, hogy buta vagy okos.

A te esetedben lenne egy termosztat (itt: esp8266), es lenne egy erintokepernyo egyseg, amiben lenne egy eleg eros sbc, ami kepes weboldal kiszolgalasara (pl. raspberry pi+7" erintokepernyoje).

Itt pedig arrol van szo, hogy dobjuk ki a kepernyot es legyen a mobiltelefon a kepernyo.
Csak a webszerver feladatat igy at kell tenni az esp8266-ra.
Vagy hozzunk ki egy mobilalkalmazast es akkor a webszerver feladatat (gui megjelenitese) a mobilalkalmazas veszi at.

Szerintem mind a harom megkozelites jarhato, a legolcsobb (fejlesztesi munkaoraban is), hogyha az esp8266 a webszerver is.

A legdragabb a raspi. Ott az erintokepernyo 16k, doboz hozza 13k, raspi 9k, kiegeszitok 5k.

A legkevesbe uzembiztos, hogyha a webszervert is az esp8266 adja.

De ettol mindegyik ut jarhato. Imho

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Az üzembiztonság egy külön kérdés.
Jelenleg a fűtést egy ESP8266 kapcsolaja, és a routeremen fut a weboldal valamint a vezérlő daemon is, úgy, hogy szintén a router méri a hőmérsékletet.
És még így is külön rutin van az ESP-n, hogy ha lehal vagy elszáll a wifi kapcsolat, akkor indítsa újra magát, és külön rutin megy a routeren is, hogyha az újraindítási kereten túl elérhetetlen a termosztát, akkor riasszon. Az ESP kb kéthetente indítja magát újra, a router pedig 2-3 havonat riaszt.
De ebben a konfigurációban én kötöttem össze a külön tápegységet, relét, és ESP csipet. Elektronikai szakemberek szerint a bizonytalanság oka, hogy nincsenek megfelelő csatoló kondenzátoraim, meg ki tudja még mi.
Látszik, hogy nem vagyok elektronikai műszerész.
Hogy ez az egyberobbantott doboz, ahol gyárilag kötötték össze az egységeket mennyivel lesz stabilabb, az már jó kérdés. Lehet, hogy ezen fog elbukni az ESP8266, de eddig el kellene jutnom. A fejlesztés közben annyit már megtapasztaltam, hogy a lefagyások oka gyakran nem az ESP-ben van.

( harlequin | 2017. 09. 21., cs – 10:16 )

Képeket, statikus adatokat áttolnám egy külső szerverre, esetleg egy erősen cache-elt proxyval együtt, a mikrokontroller tényleg csak azt szolgálja ki, amit muszáj.

Ki a felhobe! :)

Es akkor eljutottunk oda,
hogy megfagysz otthon, mert nem toltodik be a png a cdn-bol, igy nem tudsz a "futest be" ikonra kattintani.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

aha, volt nekünk egy ilyen remote vezérelhető konnektorunk, amin a nyolc lukat 8 iframe jelképezte, ebből szerencsétől függően 1-3 töltött be egyszerre, a többiből semmi nem látszott. Ráadásul valami y kötéses kábelek voltak benne, és fel volt írva, hogy ez melyik vas melyik felét viszi le, vidám volt. Főleg úgy, hogy átadáskor nem regélték el, hogy hogy a francba is van, és hogy kell értelmezni alatta a feliratokat, vakartunk a fejünket, hogy ez most mi.

( khiraly | 2017. 09. 21., cs – 11:01 )

En hasznalnek valami javascript libraryt
single page apphoz.
Igy oldalvaltasok nincsenek, az elso
oldalletoltes utan mar csak par
byteos jsonok vandorolnak.

A react 35kb, de a preact csak 3.5kb tomoritve. Az ide eleg is lehet.

Itt egy mini demo oldal:
https://awaw00.github.io/preact-mobx-starter/

Meg van egy ilyen oldal is, ahol lemerheted, hogy mi mennyi:
https://bundlephobia.com/result?p=preact@8.2.5

A kis kepekhez meg hasznalhatsz css stripe-ot. Azaz fogod az osszes kepet es egy hosszu szalagot csinalsz belole (pl:32x960pixel), es css-bol eltolod es mindig az aktualis reszletet jelenited meg.

Ez igy konkretan 3 lekeres:
html+css (inline)
preact js
1db .png

De utana a tobbit kerheted preact-on keresztul.

Pl. a fontot is, hogyha egyedi betutipust akarsz (dizajn miatt jol jon).
Abbol is generalsz egy kozepeuropai reszhalmazt, hogy az ekezetek jok legyenek.
A google font oldalan kivalaszthatod es akkor azt toltod le, majd gzippeled.

Tudsz ui routert is betenni, hogyha tul nagyra none ki magat.
Es akkor kiteheted mobilon asztalra a direkt linket egy-egy beallitashoz.

Szerintem egy esp-nek egy felhasznalot ki kell tudnia szolgalnia.

Blogolj majd a vegeredmenyrol.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( carlcolt | 2017. 09. 21., cs – 12:59 )

1 - Ha minden statikus tartalmat gzip-el tömörítek, és a "Content-Encoding: gzip" header-t küldöm el a válaszban, akkor a mobil default safari böngészője nem képes értelmezni a választ. Emiatt a tömörített küldés kiesik. Vagy van valamilyen más header, amivel jelezni tudom a kliens felé, hogy tömörítve küldöm az adatot? Tudom, hogy a kérelemben elküldi a kliens, hogy képes-e értelmezni a tömörített adatot, de a kérelem header értelmezése, és a különböző esetek kezelése is erőforrást igényel. Olyan megoldást keresek, ami minimalizálja a szerver erőforrásigényét.

nginx, gzip-re van blacklist milyen user agentekre ne kuldjon gzipet (eloredefinialt)
Raadasul az nginx-nel tervezesi szempont volt, hogy minden OS-nel a megirt async es multithread libeket a legoptimalisabban hasznalja. (kiveve Windows, ott csak 1 thread fut lol)

2 - A statikus tartalmak mellé elküldöm a "Cache-Control: max-age=300, public" header-t, mégis a böngésző minden oldalfrissítésnél újra és újra lekéri az összes képet. Pedig ezt a header-t írják mindenhol. Tudtok olyan header-t ajánlani, aminek a hatására a mobil böngésző csak nagyon ritkán, vagy akár soha sem kéri le újra az erőforrást?

?v=getHash() a fajlnev utan a htmlbe (.css .png, etc.). Frissiteskor (pl. deploy) ujrakalkulalod. Vagy kevesebb requestbol is meguszhatod: img src="generateBase64()"