Hlavní navigace

Vlákno názorů k článku Senzory Martina Malého: Jakou používáte cloudovou platformu pro IoT? od Petr M - A k těm čmoudovým službám, byl jsem donucen...

  • Článek je starý, nové názory již nelze přidávat.
  • 21. 6. 2017 19:32

    Petr M (neregistrovaný)

    A k těm čmoudovým službám, byl jsem donucen kvůli pár projektům ty nesmysly používat, včetně Azure a AWS.

    Ale na rovinu, u IoT jsou jejich schopnosti omezený na tak 0.5% aplikací, jinak je to jenom mirroring dat, schovaných někde za devíti NATy a devíti firewally.

    Když není potřeba dynamický škálování za běhu, klidně to dá obyč VPSka. A potřeba škálování za běhu znamená skoro vždycky, že je něco blbě.

    Třeba dálkový odečet měřidel. Mějme 300 000 měřidel v terénu, načítá se jich 1000 denně s periodou 30 dní. Celou tu dobu čmoud spí a jenom sype data do databáze. Přepočet dat a vygenerování faktury trvá řekněme 100s na jedno jádru.
    - Blbě navrženo: měsíc se nic nepočítá, pak se spustí dávka, která musí být za 30 minut zpracovaná, tj. přepočítání 1000 faktur za minutu a výpujčka 1600 jader.
    - Dobře navrženo: Data dojdou s periodou 864s. Tzn. mezi dvojicí měření se stihnou přijatý data přechroupat 8.5x. Peak se nekoná, zvládne to jeden virtuál s jedním jádrem + dost velká storage na výsledky. Fakturační období 30 dní, ale nemusí začínat prvního. Počítání průběžně, každý den se přepošle hotová část k tisku nebo do mailu. Prachy chodí průběžně a ne nárazově, není potřeba škálování, při výpadku na 7/8 času (tj. 21h denně) se stihnou data v pohodě zpracovat, pokud nedojde k jejich ztrátě.

  • 21. 6. 2017 19:16

    Petr M (neregistrovaný)

    Já nehájím svou pravdu, ale svoje názory. Mám VŠ v oboru, státnicoval jsem z návrhu IO. Živím se vývojem embedded věcí od roku 2002 a bylo tam hodně věcí z dnešní kategorie "IoT" - jenom se to jmenovalo jinak. Věř, že hodně věcí je z praxe a hodně tvrdě získaný zkušenosti a ne trolling. Nebráním se zkušenostem jiných, klidně přehodnotím svůj názor, ale musí to být něčím podložený. Nemám nic osobního proti Malýmu, snažím se být slušný a emotivní reakce z podložených faktů dělají ostatní, ne já.

    Co má Malý v profilu? Tohle: "Sleduje, popularizuje a učí moderní webové technologie (HTML5 a podobné). Popularizuje nové nástroje a elektroniku, provozuje weby, sleduje dění na internetu, píše o něm a komentuje ho." Takže nadšenec, který se živí něčím jiným a jenom kafrá o tom, co někde vyčetl a z rozhledny praxe se rozhlíží možná ze druhýho schodu. Je to na stejné úrovni, jako kdybych se já pokusil psát do měsíčníku o psychiatrii a ignoroval zpětnou vazbu od těch, co se tím živí.

    Když se jako profesionál zmíním, že je někdo mimo, jsem špatný. Když amatér maluje narůžovo proces vývoje a uvedení výrobku do praxe, když to nikdy nedělal, je z něho božstvo a všem může spadnout sanice. Čímpak to asi je?

  • 21. 6. 2017 8:24

    Petr M (neregistrovaný)

    "Jakou používáte cloudovou platformu pro IoT?"

    Žádnou, je to zbytečná komplikace, protože:
    0) Pokud věc nemusí být připojená, nepřipojuje se.
    1) WiFi je pro IoT v praxi nepoužitelná. Složitá konfigurace (zadej heslo k WiFi pomocí jedné ledky a dvou tlačítek), velká spotřeba,... Kde je napájecí kabel, tam se po něm dají rovnou poslat data.
    2) Zařízení jde rozdělit na dva typy, s malým datovým provozem (např. 500 znaků v paketu, který jde 1x za minutu) a s velkým datovým tokem (interkom, kamera,...). První skupinu je jednodušší a levnější řešit jinak (CC01, 485, CAN,..) A tam je pro připojení do čmoudu potřeba bridge. A proč by lokální data nemohl agregovat přímo stroj, co zajišťuje překlad?
    3) U rychlejších zařízení je sice možnost přístupu na net, ale není důvod tahat data ze sítě a pak zase dovnitř, když lokálně je to spolehlivější a s menší latencí.
    4) Automatizace musí jet i při výpadku netu. Tzn. minimálně dvoje nezávislý připojení, nebo lokální zpracování dat. To samý platí pro kamery zabezpečovačky, musí nahrávat, i když má ISP a čmoud výpadek.
    5) Při hobby použití (o který se autor opírá v článku) asi nejde o komunikaci zařízení v pěti státech, kde by se vyplatil centrální server na síti nebo podobná blbina.
    6) Při profi zařízení je potřeba zahrnout do ceny produktu nejenom marže, výrobní cenu a vývoj, ale pokud použiju čmoud, musí se zahrnout i jeho používání za dobu životnosti. Tzn. měsíční poplatek, bez kterýho to odstřihnu (naštvaní zákazníci), započítání nějaké doby provozu do nákladů (co jsem to pro zákazníka posledně počítal, vycházelo to na pět let na cca 30% koncové ceny a tam může dost bojovat konkurence), nebo holt na ovládacím panelu zobrazovat reklamy na dámský vložky.
    7) Je tady možnost komunikace po IPv6, pokud se má spolupracovat globálně. Funguje to i skrz tunely.
    8) Rozjet web server na lokální krabičce je celkem triviální věc, front end je stejný jako na tom čmoudu. Tak proč řešit registrace a výpadky...
    9) Čmoud je možná v pohodě, pokud to člověk nasadí ve městě po optice, ale ba vesnici se sdílenou WiFi má akorát ostudu a ne kšeft.

    Svět není takový, jak se jeví webařovi, co rozblikal LEDku na Sranduinu a honí machry, co všechno dokáže.

  • 23. 6. 2017 21:46

    Petr M (neregistrovaný)

    Jojo, energomonitor, to jsi pěkně smečoval. Málo co je trefnější příklad.

    Hračka, která se připojí na přívod do baráku a dává info o spotřebě, dělá statistiky,... Teoreticky. V praxi ještě nikdo fyziku neoblbnul. Jde o dva vzorečky:

    E = integrál P podle t
    P = U*I*cos(fi)

    Začneme tím druhým. Kdo by se zdržoval měřením napětí (U)? Dle datasheetu "nastavitelná převodní konstanta - 190, 195, 200, 205, 210, 215, 220, 225, 230, 235, 240, 245, 250 V". Fajn, pokud by se napětí drželo stabilní. Pokud je dlouhý vedení k trafačce, soused má přímotopy a FV panely, bude lítat. Počítejme normou daný +/-10%, tj. 207 - 253V. Pokud mám odporovou zátěž, třeba bojler 2kW, je to při nominálních 230V proud 8.7A a odpor 26.4 Ohmu. A výsledek bude vypadat asi takto:
    207V/26.4Ohmu=7­.84A, 7.84A(změřeno) *230V(nastave­no)=1803W (displej), skutečnost 207*7.84=1622W (chyba "měření" +181W)
    253V/26.4Ohmu=9­.58A, 9.58A*230V=2203.4W, skutečnost 2423.7W (chyba "měření" -220.3W)
    To vše při cos(fi)=1 a 0% toleranci měření proudu... Fikaně neuvádí tolerance "měření", ale jenom rozlišení. Není divu, měřidlem s tolerancí řádově v desítkách % bych se taky nechlubil.

    No, proud (I) to snad nějak měří. Nebudem řešit jak a podíváme se na účiník. To je číslo v intervalu <0,1>. Ten se získá z fázovýho úhlu mezi napětím a proudem, když se změří čas mezi tím, kdy projde nulou proud a kdy nulou projde napětí. Oh wait, napětí neměříme, nevíme, kdy prošlo nulou. Ale na tom přece nezáleží, jestli výkon násobíme 0.9 nebo 0.1, prostě tam dáme něco z náhodnýho generátoru. Numero jako numero, že. Nebo natvrdo jedničku, zdánlivý výkon lamám musí stačit.

    No a teď tu "přesnou hodnotu" zpracujeme. Naštěstí víme jak, je k dispozici konektivita do čmoudu, a tak nemusíme ukládat do lokální FLASH stav akumulátoru, kde se sčítají vzorky, aby se to pak dalo stáhnout po sériovce/BT/USB/ftp v CSVčku a otevřít ve spreadsheetu. Ne, to je trapný, středověký řešení. My použijeme AWS, Docker, MQTT, HiveMQ, PostgereSQL, InfluxDB, Python, Django, Coffeescript a Chirp... A možnost exportu do CSV implementujeme jako fíčuru v čmoudu. No to čubrníte, že...

    A hejl, kterýmu jsme to prodali, bude happy jak dva grepy, protože z toho polezou cool grafy a čísla, kterým nerozumí. A nic s tím nenadělá, protože o elektrice ví jenom to, že kope. Ale určitě je o super, protože je to na tabletu a data jsou v čmoudu. Kdyby tomu rozuměl, tak si to totiž v životě nekoupí.
    Dokud je dost hejlů a prodává se, všechno funguje. Jak dojdou hlupáci, pardon zákazníci, nebude z čeho platit AWS. Buďto se firma prodá a nový majitel po půl roce zjistí, o co go a vypne čmoud, nebo vypnou servery hned, jak dojdou prachy. A v obou případech hejlům doma zbudou cihly.

    Jo, to je ten pokrok... Nezáleží na tom, že je to nesmysl, hlavně že se dá oblbnout někdo, kdo tomu nerozumí a zaplatí. Když to krachne, vybleje se jiná konina, však on to někdo koupí.

  • 21. 6. 2017 16:24

    honza (neregistrovaný)

    Zkrátím to, nebudu se rozepisovat ke všem bodům.

    Diskuze jsou dnes zamořené trolly, co hájí svoji pravdu, postují ji pod každý článek a nejsou ochotni připustit jiný názor. Pročítání diskuzí často svádí k boji s těmito trolly, což je boj nekonečný. Důkazem budiž i to, že máte potřebu svou pravdu hlásat pod prakticky každým článkem Martina Malého.

    Z tohoto lze pochopit, že nejen Martin Malý, ale mnozí autoři článků odmítají číst komentáře. Je to pro ně v 99 % ztráta času a to jedno procento prospěchu jim nestojí za těch zbylých devadesát devět.

    Dále už nebudu pokračovat, jen se krátce provokativně zeptám: používáte cloud, nebo máte všechno on-premise? Máte doma svůj vlastní mail server, a nebo používáte Gmail, Hotmail, Seznam nebo některou jinou mailovou službu, která je ve skutečnosti cloudem? (i když vznikla ještě předtím, než se buzzword cloud objevil)

  • 21. 6. 2017 15:21

    Petr M (neregistrovaný)

    Ad 0) Největší chyba, kterou může člověk udělat, je opakovat svou chybu. To se většinou stane, pokud si chybu neuvědomí. A pokud upozornění na chybu ignoruje, nemusí si ji uvědomit nikdy. Takže pokud nečte reakce na svoje články, tak je ... (každý si doplní dle vlastního vychování).
    Ad 1) Neříkám, že to nejde technicky, říkám, že je to většinou nevhodná technologie.
    Ad 2) NFC čip něco stojí. Vývoj konfigurační aplikace něco stojí. Když bude někdo dělat konfigurační appku týden (160h po 250Kč), přidá NFC čip (řekněme 50,- včetně antény) a jeho podporu ve firmware (160h) při sérii 1000ks, je to 130Kč navíc na kuse jenom na to, aby ho člověk připojil. Navíc je to další rozhraní, co se musí ve výrobě testovat a snižuje celkovou spolehlivost řešení. Zase, že to jde technicky neznamená, že je to dobrý nápad.
    Ad 3) Protože stávající infrastruktura je nevyhovující? Pokud není velký tok dat, je plno lepších technologií - namátkově BLE, ZigBee, ZWave, RF komunikace s pomocí CC01,... Proč? Protože WiFi moc žere, procesor si moc nepospí (beacony), je tam režie na udržování spojení, latence roste exponenciálně s počtem zařízení v síti, nutnost implementovat protokoly navíc (ISMP, DHCP,...) atd.
    Ad 4) Čmoud je standardně používaný synonymum pro cloud. Navíc líp vystihuje, co se s data ma může kdykoliv stát. Nevím, co je na tom k nepochopení.
    Ad 5) Tak ty má být v principu vždycky. Ale frikulín potřebuje, aby stav termostatu odešel do čmoudu, tam ho něco přechroupalo a kotel si stáhl ze serveru, že se má zapnout. To je špatně, ale je to kůůůl řečení podle poloboha Malýho.
    Ad 6) Taky doma nemám server. Mám routrer s Linuxem. Průměrná zátěž při routování 0,53% CPU, využití RAM 12%. V tom už je zahrnutý web server pro administraci a Cortex A má přímo crypto engine v sobě. Proč nevyužít stávající řešení?
    Ad 7) O peakách nemluv, s tím si bývalý zaměstnavatel v čmoudu trhnul pěknou ostudu. Servery to daly, konektivita do datacentra ne. A když došly vypočítaný náklady na posílení konektivty od provozovatele čmoudu, zodpovědný manager byl týden psychicky v pr... Dva měsíce jsme řešili, jak ten peak zmenšit, přitom při přímým spojením po IPv6 by žádný peak ani nebyl. Vlastně by tam pakstačil jeden virtuál s mirrorem firmware, kam by se jednou týdně krám zeptal na aktuální FW. Takže - jaká aplikace potřebuje za běhu škálovat výkon?
    Ad 8) Jenomže spolehlivost není o AWS, ale i o cestě k AWS.
    Když si něco rozběhnu doma a chci mrknout z mobilu, je to o domácím zařízení, ISP, peeringu, mobilním operátorovi. Dokážeš to udělat spolehlivěj s čmoudem? Nahradit některý z těch článků spolehlivějším? Má tem čmoud garantovaných 100% spolehlivosti, nebo je to jenom pár devítek? A co cesta peering-datacentrum a iniciativní bagrista?
    Ad 9) Pokrok = rovnák na ohybák? (nedostatek IP adres vyřešíme NATem a ne tlakem na zavedení IPv6, neviditelnost krabičky serverem s veřejnou IP adresou, firewal prostřelíme VPNkem místo standardizace jeho nastavení,...)
    Kdyby řešili příčinu, proč to nejde, místo odrbávek a by to budilo zdání, že to jde, tak nemáme datacentra na to, aby mirrorovaly po 1kB dat z milionů krabiček a řešily, kdo k nim může a kdo ne. Nemáme takovou závislost na dodavateli, že když se rozhodne a cvakne vypínačem, máš doma nepoužitelnou cihlu. Prostě by se člověk připojil ke své krabičce z appky a hotovo...

  • 21. 6. 2017 14:06

    honza (neregistrovaný)

    0) Martin Malý je známý tím, že komentáře pod svými články zásadně nečte. A když čtu tenhle komentář výše, stejně jako jiné od Petra M, řekl bych, že dobře dělá.
    1) WiFi pro IoT je možná nepoužitelná, ale navzdory tomu používaná. Kolega ajťák kupoval manželce novou pračku a (jeho) zásadním parametrem bylo, aby měla WiFinu. Proč? Protože takové pračky v prodeji, to stačí. To je samozřejmě extrémní příklad a budu souhlasit, že moc praktického použití Wi-Fi v pračce nemá, ale třeba Energomonitor pro své IoT používá Wi-Fi. Tak jen příklad, že takové věci běžně jsou a používají se.
    2) Konfiguraci připojení k Wi-FI lze řešit různými způsoby. Například NFC čip a aplikace pro mobil, v níž zadám SSID a heslo a pak to "pípnu" dovnitř do krabičky.
    3) Pokud je v místě napájecí kabel, pak sice jdou data posílat i přes něj, ale proč vlastně? Proč budovat další technologickou infrastrukturu a nevyužít tu (Wi-Fi), která v místě už je?
    4) Nálepkování je báječná vlastnost ukazující na jedincovu psychiku. To, že někdo bude záměrně psát čmoud namísto cloud má o autorovi komentáře mnohem větší vypovídací hodnotu než všechny věcné argumenty dohromady,
    5) Jsou případy, kdy automatizace nepotřebuje neustálé připojení k netu. Připojení k netu nemusí být kritické pro aplikaci. Funkce na netu mohou řešit záležitosti, na kterých nestojí a nepadá okamžitá funkcionalita automatizace.
    6) I při hobby použití může být cloud zajímavý. Přestože to nepoběží v pěti státech najednou. Ne každý má zapotřebí doma provozovat server běžící 24/7
    7) Profi zařízení může ve skutečnosti na použití cloudu uspořit a být pro koncového zákazníka levnější než on-premise. Například on-premise zařízení je nutno škálovat na peakový provoz, zatímco v cloudu si lze kupovat výkon podle okamžité potřeby (samozřejmě automatizovaně). Takže když výkon nepotřebuji, neplatím ho. Nehledě na to, že výkon lze sdílet s jinými zákazníky, což výrazně snižuje jeho cenu.
    8) Budu odvážný, ale vsadím se, že např. Amazon AWS bude mít mnohem menší množství výpadků než jakékoliv on-premise řešení v Česku, nejen v IoT, ale vůbec. Totéž bude platit také pro zálohování — nikdo v této zemi nebude mít tak robustní on-premise zálohování jako Amazon AWS.
    9) Ještěže řada firem neřeší proč to nejde, ale jak to půjde. Díky tomu tady máme pokrok.

  • 23. 6. 2017 12:12

    muf (neregistrovaný)

    Sice to nebyla otázka na mě, ale ano, mám vlastní server se všemi potřebnými službami.
    Pokud mně bude cosi nabízet vaše firma a vyžadovat při tom cloud třetí strany, pomyslím si cosi... a zakázku nedostane.
    Chápu, že můj domácí server nemusí být běžný. Ovšem vůbec nechápu, když si někdo hraje na firemního profesionála a přitom mu firma funguje jako domácí uživatel Franta Lebeda...

  • 21. 6. 2017 20:35

    honza (neregistrovaný)

    Malého soudíte z jednoho odstavce a nic více o něm nevíte. Protože ho sleduji již velmi dlouho (>10 let), tak vím, že to není čistý webař, ale naopak, má asi blíže k hardwaru než k softwaru, mimochodem dělal i nějaký hardware v Energomonitoru. Rozhodně se hardwarem živil v několika společnostech a není to jen nadšenec, jak se mylně domníváte. A taky dělá novinařinu. Akorát se na naší scéně asi nejvíce ze všeho proslavil jako autor bloguje.cz, tak ho veřejnost bere hlavně jako webaře.

    Holt se lidé ocitají v jiných situacích a mají různé přístupy. Váš přístup funguje pro vás, Malého přístup funguje pro něho a jiné lidi. Malého přístup asi není pro řešení 300 tisíc měřidel v terénu, ale na velké množství řešení je to "good enough". A to je ten smysl. Kdybyste na začátku osmdesátých let navrhovali počítače, pak by Malý navrhl ZX 81 a vy byste navrhl PC XT. Každé má jiný přístup, každé má své publikum.

    Jinak nebudu souhlasit s posledním odstavcem. Řekněme, že nemůžeme data měřit průběžně, ale bude to s periodou. Bude peak v měření, který neovlivníme, na který musíme být připraveni. Budeme vědět, kdy peak přijde (např. jednou za měsíc a bude trvat den nebo dva, abychom byli konkrétní, tak kolem desátého, když lidé dostanou výplatu), a jindy to dělá velmi málo. Pak se bude velmi hodit to, že si v cloudu můžeme zakoupit výkon jen když ho potřebujeme; a naopak, když ho nepotřebujeme, tak ho neplatíme.

  • 25. 6. 2017 16:55

    akoze (neregistrovaný)

    ano, produkt sa predava a zakaznik je spokojny s cool instatnym reportom v prehliadaci. dnesny svet je divny, peniaze maju aj ludia ktori nerozumeju ako to funguje ale chcu to mat.

  • 26. 6. 2017 10:54

    honza (neregistrovaný)

    Když se na argument (Malý se v minulosti živil hardwarem, například u firmy X) odpoví něčím zdánlivě souvisejícím, ale ve skutečnosti naprosto nesouvisejícím (princip výrobku od firmy X je špatně), je to zřejmý argumentační klam. Souvislost mezi prvním tvrzením a druhým není absolutně žádná. Už nikomu nenamlouvejte, že nejste troll, lepší důkaz jste nemohl předložit.

    (à propos si nepamatuji, že bychom kdy spolu hráli počítačové hry, takže nechápu, kde jste přišel na tu drzost mi tykat)

Upozorníme vás na články, které by vám neměly uniknout (maximálně 2x týdně).