Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Pavouk106 10. 12. 2015, 16:47:33
-
Zdravím ve spolek,
chystám se udělat si něco jako "chytrý termostat" za pomoci dvou RPi (připojených do domácí wifi sítě) a Arduina. Výsledek by měl být takový, že v obýváku na dotykovém LCD (480x320, SPI) budu mít výpis různých hodnot (převážně teplot) a budu moct ručně ovládat například spuštění kotle, ohřev vody apod., které budou připojené na druhé RPi v kotelně.
Mám ale velký trabl, hledám vhodný způsob, jak to zobrazovat/ovládat. Ideálně bych chtěl fullscreen aplikaci/GUI, která se spustí při startu RPi. S mými zušenostmi jsem schopný udělat jen webovou stránku (PHP), což je na tuhle věc hnus *blijící smajlík*
Kdysi jsem si na PDA hrál s ForwardPass, což je něco jako Flash, ale s javascriptem (náhled zde (http://images.geekzone.co.nz/images/software/fpform.gif), je to gif "animace", koukněte na celou). Lze si tam graficky rozvrhnout vzhled (přidat políčka, tlačítka, posuvníky, ...) a pak s nimi na pozadí pracovat v JS. Něco takového bych rád přesně pro tuhle věc. Nevíte o něčem podobném v Linuxu? Jazyky neumím, ale jsem schopný se naučit syntaxi a napsat si to v čemkoliv normálním (Python, Perl, C, Javascript, ...)
Druhá věc - kde ta aplikace/GUI vezme hodnoty? Uvažuju nad tím, že všechny hodnoty nasypu na RPi v kotelně skriptem do souboru a v obýváku si to z něj rozparsuju a zobrazím. Stejně tak pro ruční ovládání relé (nasypu do souboru 0 nebo 1 a rozparsuju). Není to blbost?
Souhrn: Hledám aplikaci, kde si rozvrhnu jednoduše GUI a na pozadí si budu moct ovládat jednotlivá pole a tlačítka (WYSIWYG editor se skrtiptováním/kódem na pozadí) a zároveň mi jde o případnou debatu na téma jak tam dostat ty hodnoty.
Předem díky za nápady
-
Jako GUI bych zkusil https://github.com/vurtun/zahnrad , ale chtelo by to alespon nejake minimalni zaklady C a hlavne vedet jaky vykreslovaci backend byste rad pro to dotykove LCD pouzil (to bude zalezet na tom, jak/pres_co dane LCD na RPi pripojite a co dany ovladac v Linuxu zvladne). Zahnrad je agnosticky vuci vykreslovacimu backendu, takze zde omezeni neni. Zbytek je "nepodstatny" (vycitani z cidel je brnkacka a posilani po siti ci kopirovani jakbysmet - to bych klidne resil v shellu a nikoliv v C, abyste si usetril kupu prace, potazmo casu).
-
praveze ten web nie je vobec zle riesenie
okrem ineho to ma vyhodu, ze sa to da spustit aj na mobile alebo pc
-
Janci: Mělo by to určitě i výhody, nicméně je to pro mě "ošklivá" cesta a radši bych vyrobil něco ušitýho na míru přímo na displej. Tu webovou část si klidně udělám výhledově jen tak jako doplněk.
gui_guru: Tak víceméně něco takovýho jsem měl na mysli. Pomocí kódu si vše "nakreslit" a pak to i obsluhovat. čeká mě asi hodně studování a experimentů. Nemáš s tím přímo zkušenosti? C pro mě nebude problém, něco málo jsem kdysi psal (trošku víc než Hello world, ale zase nic extra...), ale nemám absolutně páru, jak to postavit celkově... Potřeboval bych povodit za ruku, dokud mi z toho nevypadne první výstup, od tý doby už to zmáknu. Možná je to ale předčasný, ještě jsem to ani nezkusil... Každopádně díky za tip, zkusím to!
-
Kivy (kivy.org)
Mam na raspi 5" dotykac a cez kiwy urobene gui.
-
To webovy reseni Ti ale vyresi i ten problem s prenosem dat...na RPi u kotle pobezi webserver s obsluznou aplikaci a druhy RPi bude jenom zobrazovaci klient. Vsechno pujde po HTTP, asynchrone volany nejakym ajaxem.
-
Python?
https://wiki.python.org/moin/GuiProgramming
Zenity a bash?
http://www.linuxexpres.cz/praxe/zenity-vlidna-tvar-pro-vase-skripty
Tcl/tck?
-
Santa77 a Markota: Díky za tipy, prostuduju si to všechno a pak vyberu podle obtížnosti zprovoznění :-) Víceméně jde o to, co hledám ;-)
Dzavy: Od toho webu jsem upustil. Ne sice definitivně, ale jako hlavní bych chtěl nějakou polovlastní grafickou nadstavbu nad lokálním kódem (tedy v obýváku). Ten web asi udělám v budoucnu jen pomocí PHP a CSS stylů (zelený/červený tlačítko) a to jen jako "nouzovku" nebo doplnění k tomu klasickýmu GUI. Není v hlavním plánu mít to multiplatformní nebo ovladatelný přes net.
-
python, pygame .....
zni to mozna blbě, ale použij framework pro hry(pygame) + matplotlib na grafy ...
dotyk na displeji neni taky problem ....
-
Janci: Mělo by to určitě i výhody, nicméně je to pro mě "ošklivá" cesta a radši bych vyrobil něco ušitýho na míru přímo na displej. Tu webovou část si klidně udělám výhledově jen tak jako doplněk.
gui_guru: Tak víceméně něco takovýho jsem měl na mysli. Pomocí kódu si vše "nakreslit" a pak to i obsluhovat. čeká mě asi hodně studování a experimentů. Nemáš s tím přímo zkušenosti? C pro mě nebude problém, něco málo jsem kdysi psal (trošku víc než Hello world, ale zase nic extra...), ale nemám absolutně páru, jak to postavit celkově... Potřeboval bych povodit za ruku, dokud mi z toho nevypadne první výstup, od tý doby už to zmáknu. Možná je to ale předčasný, ještě jsem to ani nezkusil... Každopádně díky za tip, zkusím to!
Myslim, ze tech nekolik obsirnych dem a examplu (napr. i jednoduchy graficky file-manager na 800 radku v C!) https://github.com/vurtun/zahnrad/tree/master/demo a https://github.com/vurtun/zahnrad/tree/master/example pro ruzne vykreslovaci backendy jiz asi ukazkovejsi byt nemuzou do chvile, dokud nam neprozradis jaky vykreslovaci backend pro to LCD pripojene pres SPI muzes pouzit (je to neco jako https://github.com/notro/fbtft/wiki ?).
Jinak drzim palce. Pokud na tom LCD jdou jednoduse zprovoznit X11 ci primo OpenGL, tak muzes sahnout i po tom doporucovanem Pythonu (nebo jinem jazyku) s jakoukoliv grafickou nebo herni knihovnou, ale tam se toho priucis mene nez v C a hlavne bude samotne GUI pracnejsi nez v Zahnrad.
-
Na tom displeji normálka jede X server. A je to fbtft driver (či jak to správně nazvat). Pomocí xinit si spustím příkaz jaký chci a ten běží na fullscreen (vyzkoušen xterm). Na týhle úrovni jsem se systémem nikdy nedělal, učím se za chodu (většinou jsem rozbíhal nějakej WM, nikdy jsem nespouštěl přímo něco jen tak na X serveru). Předpokládám, že až zkompiluju demo od zahnrad, spustím ho právě pomocí xinit. Teď čekám na kompilaci SDL2, na RPi všechno chvilku trvá... (demo ho chce, tak mu ho chci dopřát, i když by to šlo nejspíš obejít bez něj)
Ten zahnrad chci zkusit jako první, vypadá to pěkně a něco se přitom naučím. S C-čkem jsem navíc alespoň něco dělal. Jakmile uvidím demo v chodu a zkusím si udělat jednoduchej výpis hodnoty ze souboru, tak uvidím, jestli to je to, co hledám.
Pokud nebude zkusím ten python.
-
http://mojefedora.cz/programovaci-jazyky-a-knihovny-urcene-pro-vyuku-zakladu-pocitacove-grafiky-knihovna-pygame/
Když to stačilo na mobilní telefon (PiPhone), tak termostat musí být triviální :-D
-
Musíš míň hrát a víc se učit programovat!!! :)))
Hele, termostat se dá udělat i úplně na koleni amatérsky, ale pokud do toho jdeš úplně bez znalostí, připrav se, že narazíš na spoustu slepých uliček a celkově ti to bude docela dlouho trvat, než to celý rozchodíš tak, abys byl spokojenej. Dost bych doporučil sledovat přednášky, články a blog Petra Stehlíka, protože to je člověk, kterej je v elektrotechnice amatér, hraje si s tím pro radost a píše postřehy, které se perfektně hodí pro amatéry. Spoustu slepých uliček ti ušetří.
Než s tím začneš, doporučoval bych nepodcenit návrh. Celkově ti s tím neporadím, ale měl bych pár tipů ke zvážení:
1. RPi je dobrý na to, že tam můžeš použít plnotučné technologie, které znáš (jako třeba ten X-server, klasický www server, balíčkovač, python atd.) - tj. můžeš tam rychle rozjet poměrně složité věci. Ale máš tam podstatně složitější software stack a hardware samotný je dělaný primárně pro nízkou cenu. Takže se stabilitou to nemusí být kdovíjaký a jenom těžko na RPi můžeš dosahovat nízké latence (kdybys třeba něco chtěl řídit rychlostí jánevím nad sto kilohertz, už budeš mít asi docela problém). Čili RPi bych rozhodně nepoužil na řízení něčeho, co může způsbit škodu - pokud např. ten kotel nemá nějakou vnitřní logiku, která by ho chránila v situaci, kdy se RPi nějakým způsobem zblázní. Třeba můj kotel má spínání, ale i když bys kontakt trvale sepnul, nebude topit pořád - občas se vypne sám nezávisle na tom, co mu radí ovladač. To si určitě předem ověř.
2. Druhá nevýhoda RPi je (na embedded zařízení) poměrně vysoká spotřeba. Prostě budeš k tomu potřebovat síťový napaječ a tímpádem zásuvku, což může být otravný. Mít doma jedno, dvě RPi je v pohodě, ale deset jich doma mít nechceš.
3. Proto se vyplatí si předem promyslet, jestli ti aspoň na některé části systému nebude stačit menší deska. Nezatracuj Arduino, je to perfektní věc a spoustu věcí zvládne naprosto dostatečně! S trochou snahy ho můžeš provozovat i několik měsíců (až dva roky) na baterku a je parádně levný (nejmenší desky z Číny už někde od šedesáti korun). Jediná nevýhoda ATmega328 (čip majoritního typu Arduina) je, že moc nezvládne šifrování.
4. Hodně zajímavá možnost je taky ESP8266. Brutálně levná a s wifi "zadarmo". Taky ale pozor na stabilitu!
5. Komunikační protokol: silně bych doporučil nevymýšlet nic svýho a použít MQTT. Je to fantastická věc, výborně navržená, jednoduchá, ideální pro mebedded zařízení, ale zároveň nekonečně rozšiřitelná. Pokud by i MQTT bylo z nějakého důvodu moc, použít MQTT-SN, které je speciálně navržené pro sensorové sítě.
6. Linková vrstva: wifi je dobrý, pokud to chceš rozjet rychle a moc se s tím nepárat. Vede ale k větší spotřebě, vyšší ceně (pokud nepoužiješ ESP8266) a můžeš mít problémy s šifrováním. Lepší varianta pro jednodušší nekritický věci (měření teploty apod.) jsou nelicencovaný pásma 433 a 868MHz. Na ně se dá použít buď jednoduchý levný vysílač: http://www.aliexpress.com/item/1Lot-1-pair-2pcs-Best-prices-433Mhz-RF-transmitter-and-receiver-link-kit-for-Arduino/32318951712.html který neumí fakt nic jinýho než vysílat nebo přijímat (a to ještě s velkou chybovostí) nebo inteligentnější nRF24L01 nebo nRF905 které mají zabudovanou docela pokročilou logiku - např. umí (aspoň to nRF24L01, u druhýho si nejsem jistej) samy o sobě rozběhnout MESH síť - t.j. automaticky posílat pakety "jeden přes druhýho, na kterýho vidí" správným směrem. Je to hodně dobrá volba v případě, že chceš mít sensorů víc (např. měřit teplotu v každém pokoji). Hlavně proto, že dosah je trochu horší než u té první, stupidní varianty. Zvlášť u desek bez externí antény, s těma mám zkušenost, že mají dosah spíš jenom přes jednu stěnu, víc jsem uspokojivě nedosáhl. Ten jednoduchý vysílač zase v pohodě propálí celej barák.
7. Řešení UI webem bych vůbec nezatracoval! Web rozhodně nemusí být škaredší než nějaký jednodochý UI toolkit. Spíš bych řekl, že naopak. A máš tam zadarmo dálkový přístup. Pokud použiješ nějaký lokální prográmek s UI toolkitem, stejně časem zjistíš, že bys to chtěl ovládat vzdáleně třeba z práce, a stejně skončíš u webu :) Takže myslím, že než hledat vhodný UI toolkit, možná by se vyplatilo trochu zainvestovat do studia moderních webových technologií (různé ty jQuery, D3 apod.) Jako "terminál" bys pak mohl použít nějaký levný tablet z Ebaye, na kterém by jel jenom prohlížeč.
8. Pokud tohle fakt určitě nechceš, na jednodušší terminál by se mohlo hodit STM32F429, které má zabudovaný dotykový displej. Ale počítej s o hodně větší pracností - budeš si tam muset rozjet nějaký RTOS a grafickou knihovnu. Práce s toolchainem a knihovnami není tak pohodlná jako u Arduina, je to občas trochu porod. Mně osobně, když jsem si s tím trochu hrál, se docela líbila kombinace ChibiOS+uGFX.
...uff, to je román tyvole, už budu radši končit :)
-
6. Linková vrstva
Pro hnidopichy: tady mělo být spíš "linková a fyzická vrstva" :)
-
Ahoj,
já mám doma již 30+ IoT věciček a topení je právě na řadě. Čekám na dodávku nějakých dílů, ale řešil jsem prakticky to samé. Jelikož jsem věděl o začátku, že to budu chtít rozšiřovat, byl pro mne primární podmínkou nějaké unifikovaný interface jednotlivých periferií.
Koncové body (zásuvky, světla, teploměry, akvárium, LCD displeje..) jsem postavil na ESP8266. Proč? Malá spotřeba, malá velikost, embed WiFi a cena 2-5USD, dle modulu (ESP 01, ESP 12E, ESP 08, NodeMCU...). V ESP jsem zvolil LUA firmware, přišlo mi to pohodlnější. Všechna koncová zařízení mají spuštěný webserver a poskytují jednak JSON API pro příjem nastavení/vrácení údajů a primárně pak MQTT client, kterým v běžném režimu komunikují. Ten má oproti API výhodu v trvalém spojení, vyhnul jsem se tak nějakým akce s časovým limitem, prostě když teploměr naměří jinou hodnotu než předchozí, rovnou ji posílá serveru. Navíc díky trvalému spojení na serveru vidím, zda je periferie online a dokáži na rozpadnutí spojení reagovat ihned na obou stranách.
Jako server mi běží vlastní python app na routeru Turris. Pro ovládání jsem zvolil webový interface. Primárním místem je tablet namontovaný na chodbě na zdi, má několik základních rozhranní mezi kterými listuji swipnutím prstem. Má to řadu výhod jak tu už zaznělo. Jednak mám stejné rozhranní i na jiných tabletech, mobilech a nemusím při upgradu upravovat více interface. Jelikož je to umístěné doma, mám ve fullscreen režimu na tabletu google chrome, takže vizualně to poznat nejde, navíc pokud bych chtěl takové ovládání využít někde jinde, existuje spousta kiosk aplikací, které zamknou browser ve FS na dané stránce. Další výhodou je pak přímé spojení pomocí WebSocket, vyhnul jsem se tak časovaným AJAX requestům z minulého desetiletí :)
Momentálně kromě topení pracuji na OTA aktualizacích, nyní, pokud potřebuji změnit kód v periferii, musím k ní dojít s NTB a nahrát novou verzi USBčkem, což je otravné :-)
Každopádně web interface o kerý tu primárně jde využíváme celá rodina již několik měsíců a naprostá spolehlivost. Zatím se nestalo, že by rozhranní na obyč tabletu za cca 2k Kč spadlo, nebo se rozpojilo WebSocket spojení, vše je tedy úplně live a funguje bezvadně. Mezi periferiemi mám i Arduino a Rpi 2, ale to pouze tam, kde ESP nevyhovovalo (analog vstup), nemá to žádný přínos, navíc v případě Rpi je zde i menší spolehlivost, jelikož potenciálních chyb je více a systém mi občas zamrznul :/.
-
Koukám, že Saky došel k prakticky stejným závěrům a technologiím jako já, to potěší :) Drobný poznámky:
primárně pak MQTT client [...] Ten má oproti API výhodu v trvalém spojení
Kdyby náhodou trvalé spojení u MQTT bylo problém (např. pokud chci MCU vypínat kvůli šetření energií a spojení se mi nechce pokaždé rušit a znovu navazovat, takže by mi spadlo samo), dá se použít právě ta verze MQTT-SN, která s "mizením" klientů počítá.
Navíc díky trvalému spojení na serveru vidím, zda je periferie online a dokáži na rozpadnutí spojení reagovat ihned na obou stranách.
Poznámka pro kolegy s MQTT méně zkušené: Na tohle se výborně hodí použít MQTT last will: při startu pošlu na topic /hebla/heblo1/live třeba "1" s nastaveným flagem retained, last will topic nastavím na /hebla/heblo1/live a last will message na "" (prázdná zpráva). Tím mám automaticky zabezpečeno, že na /hebla/+/live dostanu v každém okamžiku seznam hebel, který jsou skutečně živý. Last will mechanismus mi zaručí, že i při nějakém nekorektním odpojení klienta se tam dostane ta správná hodnota (prázdná zpráva).
Prázdná zpráva způsobí, že se retained message na tom daném topicu na brokeru smaže, takže zprávy z /hebla/+/live nemusím vůbec parsovat, stačí mi si z topicu vyparsovat id hebla. A navíc můžu mít i "efemerní hebla" - tj. klienty, kteří použijí náhodně generované ID a jenom na chvilku. Protože se topic /hebla/RANDOM_ID/live po odpojení automaticky smaže, nemusím se bát, že by mi počet topiců na brokeru rostl.
Další výhodou je pak přímé spojení pomocí WebSocket
Velice vřele můžu (nejen) pro programování s WebSockety doporučit Elixirový webový framework www.phoenixframework.org - je naprosto skvělý, brutálně rychlý a s websockety se tam pracuje nádherně (a díky Elixiru/Erlangu je to úplně přirozený, včetně nějakých asynchronních událostí apod.).
Momentálně kromě topení pracuji na OTA aktualizacích
Dobrá připomínka! Na to je taky vhodný myslet, zvlášť pokud počet sensorů roste. Pro Arduino/Atmel existuje několik způsobů - Atmel na to má docela dobře připravený návrh, kód bootloaderu je od vlastního programu úplně oddělený, existují různé bootloadery, já jsem třeba používal TFTP.
-
doporučit Elixirový webový framework
...a když už jsme u toho, měl bych si přihřát polívčičku :)
https://github.com/mprymek/fulight
-
Hraju si teď se zahnradem. Vypadá to celkem obstojně, nicméně RPi má load average 3.5 s demo kódem (kterej jsem navíc z 80% promazal). Má to hodně pomalou odezvu (i na hloupej checkox, kterej navíc nic nedělá, jen se graficky zaškrtne). Vypadá to víceméně tak, jak jsem si představoval, ale chová se to nedobře...
Teď nevím, jestli jít teda do Pygame nebo do toho webu... Web je mi bližší, ale nevím, jestli chci jít cestou AJAXu nebo podobných technologií a bez nich to je zase k ničemu... Jakej prohlížeč byste použili? Mám teď na mysli to, aby se dal spustit v režimu kiosk a ideálně zcela bez adresního řádku, lišt a menu. Aby to jelo prostě totálně čistě fullscreen. A pojede na RPi, tak aby to ten ARM nesežralo :-D
Mirek: Jo, měl bych míň hrát a víc makat :-) Co se kotle a nejhorších scénářů týče, je to všechno navržený, aby to jelo paralelně s kotlem, tedy nekecalo do logiky kotle. Kotel si dál pojede podle svýho (přikládání, bezpečnostní uhašení, zapínání čerpadla, zastavení při přehřátí apod.), ale já mu do toho budu moct bez jeho vědomí sahat (například zastavení přikládání, pokud by náhodou zhasnul nebo ruční přepnutí ohřevu TUV z kotle apod.). Je to navržený tak, aby při chcípnutí RPi všechno jelo, jako by tam žádný RPi nikdy nebylo... Chci to jako doplněk, ne jako náhradu původní logiky ;-)
Wifi jsem zvolil pro úplnou jednoduchost a možnost sahat na to z PC nebo mobilu.
Arduino jsem nezatratil, bude připojený k senzorům a přijímačům a do RPi do dostanu USB kabelem. Je levnější případně oddělat I/O piny na Arduinu než na RPi... :-) RPi navíc v obýváku a kotelně mi energeticky extra nevadí, vzhledem k tomu, co tím získám (teploty v různých místech systému, dobrá ovladatelnost víceméně všeho apod.)
433MHz moduly za 40Kč mam, není to hitparáda (spolehlivost a dosah), ale vzhledem k NRF24L01, který mam taky, je to luxus (dosah). Tyhle kravinky mě zklamaly. Pravda, dal jsem za těch asi 10 kusů všeho cca 250Kč, technicky jsou funkční, ale těžko využitelný. Obzvlášť ne na takovou aplikaci, tady potřebuju jistou spolehlivost...
-
Pokud jde o lišty atd, ve fullscreen nejde browser poznat, akorát samozřejmě horní lišta tabletu, atd..
Nebudu sem cpát obrázky a další, ale pár věcí jsem postoval na jiné forum (jsou tam screeny staršího rozhranní i reálné fotky). Je tam také video, tam jde vidět odezva (mám tam implementovanou syntézu řeči, takže to mluví :D. K té rychlosti, všimněte si, že při kliku na tlačítko, se poše pomocí WS event, server kontaktuje TTS servery, nechá syntetizovat náhodnou odpověď, vrátí to tabletu a ten teprve přehraje...
Takže je tam zpoždění díky requestu na syntézu, jinak je to prakticky nepostřehnutelné.. než pohnu s prstem s buttonku, relé již dávno cvaklo..
Rozhranní vypadá už úplně jinak, je multiobrazovkové, ale princip zůstal :-)
URl: https://www.turris.cz/forum/topic_show.pl?tid=886 (https://www.turris.cz/forum/topic_show.pl?tid=886)
-
Hraju si teď se zahnradem. Vypadá to celkem obstojně, nicméně RPi má load average 3.5 s demo kódem (kterej jsem navíc z 80% promazal). Má to hodně pomalou odezvu (i na hloupej checkox, kterej navíc nic nedělá, jen se graficky zaškrtne). Vypadá to víceméně tak, jak jsem si představoval, ale chová se to nedobře...
Ten load je hodne podezrely (diky tomu to ma tu pomalou odezvu). Ktery vykreslovaci backend jste pouzil? Pokud X11 a vse pocita CPU (tady se hodi kompilovat alespon s -O2; prosim nezapomenout, ze dema Zahnrad se by default kompiluji s -O0) a zaroven mate nastavenou prilis vysokou snimkovou frekvenci a zaroven jste si nevypnul napr. vlozene asserty v Zahnrad, tak bychom se asi dostali na takto nizky vykon (zvlast pokud provozujete RasPi na nizsich uspornejsich frekvencich). Zkusil bych snimkovou frekvenci pro zacatek 25 snimku ve spojeni s OpenGL (ktere je na RasPi akcelerovane) a vypnul asserty v Zahnrad.
-
433MHz moduly za 40Kč mam, není to hitparáda (spolehlivost a dosah), ale vzhledem k NRF24L01, který mam taky, je to luxus (dosah). Tyhle kravinky mě zklamaly. Pravda, dal jsem za těch asi 10 kusů všeho cca 250Kč, technicky jsou funkční, ale těžko využitelný. Obzvlášť ne na takovou aplikaci, tady potřebuju jistou spolehlivost...
U těch NRF mě dosah taky zklamal a jedinej způsob, jak se mi ho podařilo dostat na použitelnou úroveň, je právě ten mesh. U heterodynů je rozumnej dosah hodně otázka softwaru - je potřeba nízká rychlost, krátká zpráva, nějaký checksum, dost opakování a v případě potřeby i potvrzování. S tímhle vším je to pak v pohodě použitelný. Spínám tím zásuvku za pár šupů ze supermarketu (něco takovýhodle http://www.nej-ceny.cz/produkty/original/631429.jpg) přes celej barák. Výhodou je, že na všechny ty potřebný serepetičky, se kterýma to má použitelnej dosah, jsou pro Arduino knihovny.
Ještě se mně hrozně líbila tahle vychytávka: vzít levnou meteostanici taky ze supermarketu a přes 433 si na ni posílal jakýkoli čísla emulací dalšího sensoru :) Zatím jsem neměl čas to vyzkoušet, ale jako nápad mi to přijde parádně vychytralý :)
-
Jo a ještě k tomu browseru v kiosk režimu: mělo by stačit použít Firefox, spouštět ho z nějakýho skriptu, kterej ho při pádu případně restartne, nastavit výchozí stránku na to, co potřebuješ, nainstalovat doplněk https://addons.mozilla.org/cs/firefox/addon/r-kiosk/ a v profilu dát do souboru user.js potřebný volby. Mně zatím stačilo:
user_pref("rkiosk.navbar",false);
user_pref("browser.fullscreen.autohide",true);
user_pref("app.update.enabled",false);
-
URl: https://www.turris.cz/forum/topic_show.pl?tid=886 (https://www.turris.cz/forum/topic_show.pl?tid=886)
Kdyby se ti nelíbil ten ošklivý nabíjecí kabel ze zdi to tabletu, stačí zezadu tabletu nalepit oboustranou lepenkou dva nerezové plíšky, přiletovat je skrz zadní stranu tabletu uvnitř přes shottky diodu na 5V napájení tabletu a na zeď našroubovat malé víčko z hranaté elektro krabice, ve kterém jsou zevnitř zapuštěné neodymové magnety z rozbitého HDD. Jsou poniklované, takže výborně vodí, k nim (jejich plechovým držáčkům) jsou zevnitř přišroubované dráty s 5V (adaptér mám umístěný rovnou v klasické zásuvkové krabici pod tím deklem, do ní zavedeno 220V. Tablet dekl přikryje, takže není vůbec vidět. A když chceš tablet někam vzít, stačí odtrhnout od magnetů, drží až moc. Cvakneš na magnety a za chvíli je dobito.
-
Díky za tip, ten kabel je samo provizorka a budu hledat řešení, jak to udělat estetičtěji :-)))
Za pár týdnů pouštím do malosériové výroby radiátorové hlavice které mají HTTP API + MQTT/websocket klienta, k čemuž kromě jiného nechávám vyrobit kryt, takže jsem zvažoval prototypově i nová záda tabletu s kontakty, na zadní straně, takže zeď by sloužila jako "dokovačka", ale možná to doma vyřeším jak píšete :-) Díky ;)
-
Za pár týdnů pouštím do malosériové výroby radiátorové hlavice které mají HTTP API + MQTT/websocket klienta
Tybrďo, to přesně potřebuju! Můžeš dát víc info?
-
gui_guru: Ten load je podezřelej. Jel jsem to přes X11, CPU bylo vytížený na cca 25% (X 16%, zahnrad 5%, htop 4%), podle iotop se nic nedělo, síťovej provoz nulovej...
Zkouším Pygame, vypadá to na míň problémů a rychlejší zprovoznění (než na důchod :-D ).
-
Tak mám v Pygame rozvrženej layout. Čeká mě ještě spousta věcí, ale je už téměř jasný, že to budu dělat celý v tom, pracuje se s tím skvěle a existuje asi miliarda a půl návodů na skoro všechno.
Díky za tipy
-
gui_guru: Ten load je podezřelej. Jel jsem to přes X11, CPU bylo vytížený na cca 25% (X 16%, zahnrad 5%, htop 4%), podle iotop se nic nedělo, síťovej provoz nulovej...
Zkouším Pygame, vypadá to na míň problémů a rychlejší zprovoznění (než na důchod :-D ).
Tak to je dobre, ze Vam Pygame jede. Jenom ze zvedavosti, ktery vykreslovaci backend pouzivate v Pygame? Myslim, ze default je SDL a to samozrejme pojede jedna basen v porovnani s posilanim hromady low-level primitiv pomoci X11 protokolu ;) Mimochodem kolik CPU si vezme Pygame? To musi byt imho docela dost (je to Python a i s jednoduchymi hrami byvaji nekdy v Pygame problemy na silnych masinach, pokud se pouziva SDL 1.2).
-
gui_guru: Kámo, Ty se mě ptáš na moc věcí :-) Já nemám páru, čím/jak to vykresluju. Spustím si X server, exportuju XAUTHORITY, DISPLAY a pak pustím ten python skript a on mi prostě jede na displeji (takže X11?).
Jedu částečně podle návodu, kterej tu někdo poslal (česky) - tam jsem pochytil základy, kreslení obdélníků apod.; a ta podle návodu na nějakou "hru", kde jsem se naučil psát text a teď odtamtud opisuju tlačítka ;D
Líbí se mi to, protože je kód docela dobře čitelný, syntaxe je v pohodě (už jsem něco někdy psal, takže tohle je sice neobvyklý bez {}, ale dá se to v pohodě), pygame je luxusně jednoduchý a efektivní. Zatím mám jen staticky vypsaný věci na displeji, abych věděl, kde co je a kolik to zabere, interakce ještě není. Dneska večer chci začít tahat hodnoty ze souboru a refresh 1x za sekundu + přidat mačkání tlačítek (zatím jen mačkání a změna červený/zelený, bez interakce na pozadí).
CPU to nežere moc, asi do 20%, ale opakuju - nic to vlastně nedělá. Load average je ale zase 3... (ano, už jsem udělal update FW RPi, tím to tedy není). Uvidíme, jakou to chytne odezvu, až to bude interaktivní.
Když už se mi podruhý ptáš, čím vykresluju, hlodá mi to v hlavě. Asi bych se měl podívat, jak to dělat jinak. Takový OpenGL by nebylo marný (když by to šlo přes GPU).
-
Mám nějaké poznatky, pokud by to někoho zajímalo.
Jak jsem už psal, nadhazuju si po nastartování RPi vlastní X server instanci na kterou pak přímo Pythonem kreslím na fullscreen layout.
Používal jsem zpočátku příkaz pygame.display.update(), ale je to pro mé účely špatné řešení - nemusím neustále překreslovat celý displej, to totiž neskutečně žere prostředky. Ne, že by CPU jelo naplno, ale framerate msíto 50 klesne pod 10 a je nestabilní.
Nakonec používám pro změnu věcí na displeji stejnou funkci, ale na různých místech a s parametrem, který jí říká, jakou část displeje překreslit (obdélník). Takhle překresluju všechny proměnlivé oblasti.
Tlačítka: Nakreslím obdélník, dám do něj text a registruju zda je myš v obdélníku a zda je v tu dobu stisknuté tlačítko (mouse.get_pressed). To ale funguje naprosto nespolehlivě, proto jsem nahradil mouse.get_pressed něčím lepším - eventem MOUSEBUTTONDOWN, který reaguje jen na samotný stisk a nebere v potaz držení.
Těmito způsoby jsem dostal rychlé GUI (50fps, až zbytečně rychlé, žere 20% CPU, nastavil jsem to na 25fps a je to na 13% CPU; připomínám, GUI momentálně jen zobrazuje a překresluje, není ta žádný další kód na získávání a zpracování hodnot) a spolehlivě funkční tlačítka.
Teoreticky jsem s touhle částí prozatím hotov. Ještě mne čeká nakreslení dalšího GUI - teď mám zobrazovací, ještě potřebuju udělat nastavovací.
-
Ahoj, neuvazoval jsi o necem takovem ? Komunikace po UART. Na ebay cca od 360,- a muzes to rovnou pichnout na ESPcko.
https://www.itead.cc/display/nextion.html (https://www.itead.cc/display/nextion.html)
-
Divím se, že to tady ještě nikdo nenavrhnul, ale co takhle po startu spustit QT aplikaci ve full-screen módu ?
Počítám ovšem s tím, že ten display co máš, funguje jako klasický monitor.
-
FxS: Displej funguje jako normální monitor. Původně jsem měl myšlenku na fullscreen aplikaci (v čemkoliv, Qt, GTK, ...), ale šlo mi o nakreslení si vlastního vzhledu. Buď pomocí pozic v kódu (jak to dělám v Pygame) nebo nakreslit ve wysiwyg editoru. Potřeboval bych znalost Qt nebo GTK (nebo něčeho jinýho), ale nemá pro mě cenu se do toho nějak moc ponořit, protože v Pygame to je všechno lehoučký a pochopitelný. Pygame si pak celej displej přivlastní pro sebe, nejede žádnej window manager, jen ten jeden proces.
Ystrem: Nejsem až tak low-level nadšenec. "Umím" s Arduinem, "umím" s RPi, ale neumím jít moc do hloubky. Proto používám tyhle udělátka, kde už je spousta věcí vyřešená (a proto nemám třeba Odroid nebo jinou desku, kde bych potřeboval víc času a/nebo znalostí na rozhejbání).
Teď jsem ve fázi, kdy čtu z Arduina pomocí /dev/ttyUSB0 údaje o teplotě a vlhkosti a zobrazuju je spolu s aktuálním systémovým časem na displeji. Takže je to už funkční, ale momentálně velmi omezeně. Budu kupovat druhý RPi do kotelny, programovat další věci na něm a pak to teprve spojím dohromady. Ještě musím taky dodělat GUI pro nastavení časových plánů (topení a oběhu teplé vody).
-
Čo sa mňa ako strojára týka, tak všetky programy čo používam CATIA, ADAMS a MATLAB tak sú vyvýjané v C++. Mňa vždy zaujímalo ako na takéto niečo zháňajú programátorov, napr. vývoj CATIE
-
K raspberry pi se prodává přímo pro něj dotykový monitorek, tak co řešíš. Si to UI pak naklikej v Qt Creatoru.
Jo a divím se že to vůbec děláš, tolik práce s tím...Taky vždycky přemýšlím co bych si udělal z Arduina, jenže pak si spočtu kolik desítek hodin u toho strávím a zase na to raději rychle zapomenu, protože se to prostě nevyplatí :-\
-
Jo a ještě něco, osobně bych si příště dobře rozmyslel to Raspberry Pi, lepší možná je kouipit si normálně mobil s Androidem, nějaký levný, nebo z bazaru a máš v tom vše: WiFi, Bluetooth, dotykový display, gps, GSM ...a hlavně, všechno to už funguje, ne jak Raspberry Pi, u kterého si prdeš a ono se restartuje. Stačí pak jenom umět Qt knihovnu a můžeš vyvíjet aplikaci jakou chceš. S Arduinem si to můžeš propojit třeba přes to Bluetooth a máš to.
-
Sleduj, třeba tohle položí Raspberry Pi v tvojí realizaci na lopatky: http://mobilni-telefony.heureka.cz/sencor-element-p350/
za 999,- Kč takový krásný počítač, i s Bluetooth :-)
-
Jo a divím se že to vůbec děláš, tolik práce s tím...Taky vždycky přemýšlím co bych si udělal z Arduina, jenže pak si spočtu kolik desítek hodin u toho strávím a zase na to raději rychle zapomenu, protože se to prostě nevyplatí :-\
Takový věci se nedělají proto, že by se vyplatily, ale proto. že to člověka baví a chce se něco novýho naučit.
Jo a ještě něco, osobně bych si příště dobře rozmyslel to Raspberry Pi, lepší možná je kouipit si normálně mobil s Androidem, nějaký levný, nebo z bazaru a máš v tom vše: WiFi, Bluetooth, dotykový display, gps, GSM ...a hlavně, všechno to už funguje, ne jak Raspberry Pi, u kterého si prdeš a ono se restartuje. Stačí pak jenom umět Qt knihovnu a můžeš vyvíjet aplikaci jakou chceš. S Arduinem si to můžeš propojit třeba přes to Bluetooth a máš to.
Na telefon obvykle nedostaneš čistý Linux. Když, tak do chrootu. A to je dost starostí navíc - a úplně zbytečných. Jo, kdyby byl levný telefon se solidním hw, rozumnou dokumentací a otevřenými drivery ke všemu, tak bys měl pravdu. Ale to by pak asi ani RPi neexistovalo :)
-
Zaprvé, ano, někoho to může bavit, může na tom i učit, ok :D
Zadruhé: že na telefon nedostaneš čistý linux, to je ftip ne, no a co? ;D Zadruhé, i ten nejlevnější smartphone má lepší HW než Raspberry Pi ;D zatřetí, dokumentaci nepotřebuješ, když máš Qt -- naco chceš dokumentaci, nepotřebuješ lézt na nějaký low level. Začtvrté, naco potřebuješ otevřené drivery tady k tomu termostatu ;D
A zatřetí: bylo by zajímavé propojit ty dva telefony přes GSM modul (ne přes operátora, normálně vysílat/přijímat * což mi vnuklo skvělý nápad na pokus, docela by mně zajímalo jaký to může mít dosah.
-
Zadruhé: že na telefon nedostaneš čistý linux, to je ftip ne, no a co? ;D
Ne. Zkoušel jsem všelijak přiohýbat jeden levný čínský tablet a nakonec jsem dospěl k tomu, že nemá smysl se s tím trápit.
Zadruhé, i ten nejlevnější smartphone má lepší HW než Raspberry Pi ;D
Tím bych si nebyl jistý.
zatřetí, dokumentaci nepotřebuješ, když máš Qt -- naco chceš dokumentaci, nepotřebuješ lézt na nějaký low level. Začtvrté, naco potřebuješ otevřené drivery tady k tomu termostatu ;D
No na lowlevel potřebuješ jít, když tam chceš doinstalovat něco, co na androidu není. Budeš chtít jánevím třeba mosquitto. Nevím, jestli na android je a když jo, tak jestli se všema featurama. Když zjistíš že ne, půjdeš do chrootu. A seš tam, kdes nechtěl být. V kleci.
A otevřené drivery potřebuješ na to, když zjistíš, že ti vývoj pod androidem z jakýhokoli důvodu nevyhovuje a chtěl bys tam mít normální Xka. Čili potřebuješ driver grafiky. A ten u žádného normálního telefonu nejspíš nemáš.
A zatřetí: bylo by zajímavé propojit ty dva telefony přes GSM modul (ne přes operátora, normálně vysílat/přijímat * což mi vnuklo skvělý nápad na pokus, docela by mně zajímalo jaký to může mít dosah.
To by byl určitě zajímavý pokus, jestli to vůbec jde. Jdi do toho a sepiš výsledky, určitě si to spousta lidí ráda přečte.
-
Jnai ještě se doporučuju podívat, kolik stojí na RPi či arduino: gps, gsm, wifi, dotyk display, bluetooth :) dostanete se na docela slušnou pálku, přitom to vše se dá koupit v jediném smartphonu za 1000,- Kč, bezproblémově spojené dohromady a to ještě s baterkou, mikrofonem a repráčkem, ready to use s Qt :)
-
Jnai ještě se doporučuju podívat, kolik stojí na RPi či arduino: gps, gsm, wifi, dotyk display, bluetooth :)
A GPS a GSM jsou pro ovládání kotle obzvláště potřebné! :)
-
Zadruhé, i ten nejlevnější smartphone má lepší HW než Raspberry Pi ;D
Nějaký tip na telefon s Androidem za 5 USD?
zatřetí, dokumentaci nepotřebuješ, když máš Qt -- naco chceš dokumentaci, nepotřebuješ lézt na nějaký low level.
Pro GPIO se to docela hodí. (Tedy ne že by androidí telefony běžně měly volné GPIO porty.)
A zatřetí: bylo by zajímavé propojit ty dva telefony přes GSM modul (ne přes operátora, normálně vysílat/přijímat * což mi vnuklo skvělý nápad na pokus, docela by mně zajímalo jaký to může mít dosah.
Nějaký tip na telefon s otevřeným ovladačem GSM modulu, protože uzavřené používající RIL bez BTSky komunikovat nedokáží? (Navíc se domnívám, že to nebude legální.)
-
Zadruhé, i ten nejlevnější smartphone má lepší HW než Raspberry Pi ;D
Nějaký tip na telefon s Androidem za 5 USD?
Je to horší: potřebuješ telefon, na který místo Androidu půjde dát normální Linux. Protože Android je prostě ve všech ohledech divný. A to ti výběr velice omezí a mezi nejlevnějšími telefony nic takového určitě nenajdeš. Nejlevnější telefony jsou výrobcem dodaný zastaralý kernel bez dostupných zdrojáků a toolchainu, kde chybí některé funkce (např. není zkompilovaný tun/tap driver, takže nemůžeš takové zařízení připojit bezpečně do VPN) a drivery hardware (displej, síť) jsou pevně svázány s dodaným bloatware, který zabírá všechnu dostupnou paměť, je nestabilní, je v něm STAGEFRIGHT a volá domů a nejde s tím nic dělat.
Oproti tomu Raspberry má jen velmi mírně upravený vanilla kernel, který je navíc trvale dostupný ve skoro nejnovější verzi, až na akceleraci videa je všechno open-source a postupně se to dostává do upstreamu. A userspace na RPi je úplně normální Debian.
A zatřetí: bylo by zajímavé propojit ty dva telefony přes GSM modul (ne přes operátora, normálně vysílat/přijímat * což mi vnuklo skvělý nápad na pokus, docela by mně zajímalo jaký to může mít dosah.
Nějaký tip na telefon s otevřeným ovladačem GSM modulu, protože uzavřené používající RIL bez BTSky komunikovat nedokáží? (Navíc se domnívám, že to nebude legální.)
Legální to není, OsmocomBB podporuje staré (hloupé) Motoroly a OpenMoko, a dosah to má jak horší radiostanice v tomto pásmu. Proč horší? Protože mobil má filtr, aby neslyšel jiné mobily, ale jen BTS (pomáhá to proti zahlcení v místech se špatným signálem), takže komunikace mezi dvěma mobily je utlumena. Filtry lze přemostit, pokud se umí pájet.
Keywords: osmocombb, osmocom trx openbts, osmocom motorola filter replacement
-
Když už jsme u toho, ty umíš v ČR koupit RPi Zero za $5? Měsíc po vydání a úplně to vyšumělo. Farnell ho odstranil z nabídky (a i předtím tam stálo $20, ne $5) a v žádném českém shopu nikdy nebylo.
-
Sten: Tak si koupis rpi zero za 5$, no a co jako. Dělal ty si už vůbec někdy něco s RPi kromě toho, že sis tak maximálně spustil xka a zahrál žížalu? Nevíš kolik stojí ty další věci a zřejmě ani nevíš, kolik času je stojí spRovoznit a udělat si pro to appku. Bys tady jinak tak silácky neplácal.
Pro termostat vyjde jednoznačně nejlíp, časově i finanćně, koupit si smartphone, tečka.
-
Čidla teploty stejně musí být zvlášť, přinejmenším musí být dvě, jedno potřebuješ dát ven, druhé dovnitř, navíc na vhodné místo. Takže tam stejně poběží arduina. Přes bluetooth je spojíš s mobilní aplikací - elegantní řešení. Pro mobil si uděláš appku s ovládáním a výpočtem regulace - nějaký PID člen s vhodným filtrem, pro systémy s dlouhou odezvou, což Regulace teploty v místnosti je. Podle umístění kotelny pak propojíš smartphone přes wifi nebo opět přes bluetooth s zařízením s relátky.
-
České eshopy nemají spoustu produktů, trh je minimální. Samozřejmě Pi Zero je vyprodané globálně. V UK stojí bez doplňků 4 libry (samozřejmě + doprava). Tedy až bude :-)
-
Dělal ty si už vůbec někdy něco s RPi kromě toho, že sis tak maximálně spustil xka a zahrál žížalu? Nevíš kolik stojí ty další věci a zřejmě ani nevíš, kolik času je stojí spRovoznit a udělat si pro to appku. Bys tady jinak tak silácky neplácal.
Na RPi jsem nikdy Xka spuštěná neměl. Dělal jsem na 70 RPi distribuovaný sběr dat z Bluetooth senzorů a jejich posílání na centrální server přes GPRS/3G a mobilní skener Tetrapol sítí (ten se z jiných než technických důvodů v praxi nenasadil). A platí pro to úplně přesně to, co jsem napsal ve svém předchozím komentáři.
Není mi jasné, co myslíš „těmi dalšími věcmi“. V prvním projektu máme externí watchdog kvůli potenciální nestabilitě modemu (nakonec se ukázalo, že není potřeba) a jinak vůbec nic (ještě teda krabičku a zdroj, že jo), ve druhém taky není potřeba nic kromě rádia, modemu a GPS (OK, ušetříš pár stovek za to, že to má smartphone integrované).
Pro termostat vyjde jednoznačně nejlíp, časově i finanćně, koupit si smartphone, tečka.
Ne. Předpokládáš znalost vývoje pro Android. Já zase umím s normálním Linuxem a na smartphone bych se a) musel úplně od nuly naučit dělat aplikace, b) řešit problémy jako autostart, c) řešit absenci GPIO pinů, pokud ten termostat má něco ovládat, d) řešit nulovou bezpečnost a podporu HW (neaktualizovaný kernel, ve kterém není např. driver pro CH341, když bych k tomu chtěl připojit USB sériák, absence ethernetového portu, neustálé volání do googlu! - jistě, můžeš říct, že si na to můžu nainstalovat vlastní CyanogenMod, ale argumentoval jsi časem).
-
Nevím jak smartphone, ale mám pár zkušeností s ultra levnými tablety z aliexpressu (cenově jako ten smartphone) a jejich spolehlivost/životnost je tristní. Provoz 24/7 se stálým dobíjením. Poškození firmwaru (neměl jsem jej zazálohovaný - pokud to vůbec jde celé stáhnout a hlavně pak nahrát), již jsem nesehnal stejný s funkčním nakonfigurovaným driverem na použitý touch controller a to jsem psal všude možně po čínských webech. Pravidelné záseky z přehřátí - buď odštípnout baterku, nebo počkat, až se vybije (je to tablet, tudíž baterie napevno přiletovaná). Jiný se občas (náhodně) rebootne do nějakého základního nastavení, po úplném vybití baterky se jej podařilo nahodit do mé konfigurace.
Je to levné, pro řadu využití super (mám to na zdi jako ovládací panel MPD internetového rádia u zesíku - nic kritického), ale pro vlastní řízení něčeho kritičtějšího bych to nechtěl ani náhodou.
-
zelenáč si vybral správnou přezdívku. Přes jeho argumenty nejede vlak (tak to vidí on).
Tak sem tedy napíšu, proč jsem volil řešení, které nyní provozuju a rozšiřuju.
1. Mám doma RPi, které je k ničemu (doslova)
2. Mám doma haldu Arduin, které jsou k ničemu (na hraní)
3. Mám dlouholeté zkušenosti s Linuxem
4. Mám chuť se naučit něco příbuzného tomu, co už umím
5. Chci bastlit
(6. v době napsání originálního dotazu jsem měl objednané LCD k RPi)
Je tedy jasné, že v tom mám peníze, čas a už nabyté znalosti. Proč bych měl teď přejít na alternativu smartphonu? Nemám důvod.
Ještě se mi celkem zamlouvala myšlenka tabletu nabíjeného přes neodymové magnety a na něm běžící GUI v prohlížeči. Dobrá myšlenka, mě ale trochu vzdálená (ale nemít tou dobou už HW, možná bych se nechal ukecat a šel do toho).
Proč ne nejlevnější mobil tu řekli ostatní. Proč všeobecně ne mobil tu řekli ostatní. Já jen přidám jednu věc - mám RPi B+ (1x 700MHz) a Ty jsi tu argumentoval výkonem... Četl jsi jeden z mých minulých příspěvků? Skript, který obstarává výpis údajů (GUI) si bere do 15% CPU. Na co víc výkonu? Vždyť bych si vystačil i s nižším (ale "tři-osum-šestky" žerou docela dost elektriky, tak jsem je zavrhnul).
Pro srovnání - Android na stejnym HW (1x 700MHz) má load average 7.5 a systém je nepoužitelnej (20 sekund čekat na zobrazení "přijmout/odmítnout hovor", když telefon celou dobu zvoní a nejde ztlumit, je prostě špatně). Samozřejmě se nebavíme o Androidu 4.x, ale o 2.1.
RPi mi dává obrovskou volnost v tom, co můžu dělat. Arduina by nebyly teoreticky potřeba, ale já je použiju jako jednodušší (pro mě) ovládání/sběr než na RPi, jako rozšíření RPi a hlavně - jako ochranu GPIO RPi před mojí blbostí. RPi je trochu dražší než Arduino (čínské).
-
Jj, jasně, beru argumenty, ale stejně je lepši řešení ten smartphone :P
-
A to ve všech směrech krOmě "mám doma rpi a je mi kniče u". Dokonce ta appka kterou uděláš může být univerzální, půjde rozjet na jakékkoliv smartphonu, přes bluetooth si najde čidla teploty.. no prostě nǎdhera ve všech směrech, mohlo by to taky snadno znovupoužít víc lidí.
No ale když chceš bastlit, a ze zdi chceš vidět trčící dráty, a dávat k raspberry Pi faradayovu klec, tak prosím no... :DD
-
zelenáč: dej si tuhle stránku do záložek. Až to bude hotový, dám sem fotku.
-
Sten: Tak si koupis rpi zero za 5$, no a co jako. Dělal ty si už vůbec někdy něco s RPi kromě toho, že sis tak maximálně spustil xka a zahrál žížalu? Nevíš kolik stojí ty další věci a zřejmě ani nevíš, kolik času je stojí spRovoznit a udělat si pro to appku. Bys tady jinak tak silácky neplácal.
Nedělal jsem přímo s RPi, ale s jinými deskami s ARMem a GPIO.
Ze zkušenosti je tak stejně náročné napsat appku v Qt jako v Androidu. Pro měření teploty připojíš DS18B20 za 80 Kč (http://www.gme.cz/ds18b20-p530-067), použiješ hotovou knihovnu (https://github.com/matmunk/DS18B20) a máš to samé, jako když čteš Sensor API na Androidu.
Pro termostat vyjde jednoznačně nejlíp, časově i finanćně, koupit si smartphone, tečka.
Nějaký tip na telefon s tepelným senzorem, který nestojí několik stovek dolarů (aby byl alespoň řádově stejně drahý)? Protože podle CDD (nezbytné pro Google Play) je povolené dodávat tepelný senzor až od Androidu 5.
-
Ještě k tomu, co kolik na RPi stojí:
teplotní čidlo DS18B20 - od 50Kč (nicméně já je nepoužívám, protože viz níže)
DHT22 (teplota + vlhkost) - od 60Kč
relé deska (8x 230V/10A) - 150Kč
3,5" dotykový LCD - 450Kč
RPi - 800Kč
wifi - 250Kč
flash/microSD - 150Kč
Arduino - od 60Kč
dráty, rezistory apod. jsou korunový položky
Nevidím problém...
Celkem za materiál dám tak 3000Kč, pak už jen čas (a ten do toho dávám rád, protože to dělám pro sebe a baví mě to).
-
A co to máš za display že je takový levný? není to jeden z těch pro Arduino, že ne? :D
-
Jo a u profi regulace máš čidlo uvnitř domu i venku, tzn. tam bys musel použít bluetooth asi nejlíp, takže plus bluetooth :D A neboo, dat tam obzčejný Trasmitter/Receiver co je na dx.com za 60, Kč, potom tu teplotu můžeš prostě jen v intervalech vysílat.
-
Ještě k tomu, co kolik na RPi stojí:
teplotní čidlo DS18B20 - od 50Kč (nicméně já je nepoužívám, protože viz níže)
DHT22 (teplota + vlhkost) - od 60Kč
relé deska (8x 230V/10A) - 150Kč
3,5" dotykový LCD - 450Kč
RPi - 800Kč
wifi - 250Kč
flash/microSD - 150Kč
Arduino - od 60Kč
dráty, rezistory apod. jsou korunový položky
Nevidím problém...
Celkem za materiál dám tak 3000Kč, pak už jen čas (a ten do toho dávám rád, protože to dělám pro sebe a baví mě to).
VoCore (http://vocore.io/) (MIPS + flash ROM + WiFi + 2×Ethernet) - 500 Kč
-
VoCore (http://vocore.io/) (MIPS + flash ROM + WiFi + 2×Ethernet) - 500 Kč
Bóže můj... ty jsi fakt panic. :D To ti přeju hodně štěstí s vocore, podle fóra jde vidět, že to má vyloženě stovky fanoušků. Kdoví jestli na tom aspoň ta wifi funguje, nehledě na to, když si k tomu budeš chtít připojit nějaké zařízení a nedejbože ho i ovládat. Pokud teda nebudeš chtít strávit měsíc s implementací něčeho, co ti bude na používané platformě trvat hodinku.
-
Displej jede přes SPI, jedou na něm normálně Xka, tváří se pro systém jako klasickej monitor. Touchscreen je rezistivní, jeden nevim přes co (celý to je prostě píchnutý na RPi GPIO konektor). Instalace zabrala a dvě a půl hodiny. 2:25 jsem stahoval archiv a pět minut trvalo jeho rozbalení na flashku.
VoCore a jiný podobný věci neberu právě kvůli tomu, že máloco na nich bude tak jednoduchý. Potřebuju něco, co (rychle) smontuju a pak se věnuju účelu. Ne něco, co budu půl roku dávat dohromady a pak teprve něco tvořit.
Externí čidlo už pár měsíců mám - ATTiny + DHT22 + 433MHz vysílač (+ li-ion + solár na dobíjení), přijímač mám naprogramovanej a celý to už běží. Co potřebuju teď - koupit druhý RPi a pokračovat v psaní programu(-ů).
-
VoCore (http://vocore.io/) (MIPS + flash ROM + WiFi + 2×Ethernet) - 500 Kč
Bóže můj... ty jsi fakt panic. :D To ti přeju hodně štěstí s vocore, podle fóra jde vidět, že to má vyloženě stovky fanoušků. Kdoví jestli na tom aspoň ta wifi funguje, nehledě na to, když si k tomu budeš chtít připojit nějaké zařízení a nedejbože ho i ovládat. Pokud teda nebudeš chtít strávit měsíc s implementací něčeho, co ti bude na používané platformě trvat hodinku.
A co místo hodnocení z telefonu si to i zkusit? ;) Wi-Fi na tom funguje (i když preferuju ten duální Ethernet s PoE, kde jde na jeden kabel pověsit několik zařízení). Psaní programů pro to je jednoduché — je to Linux/OpenWRT, jde tam nainstalovat Python, Qt a spoustu hotových knihoven. To fórum je prázdné hlavně proto, že vývojářské otázky je lepší řešit na OpenWRT a Stack Overflow.