Příspěvky

526

Odkladiště / Re:Je televizní vysílání přežité?

« kdy: 13. 03. 2017, 14:45:34 »

S konektivitou 8/1Mbit bych u nás na vesnici nechtěl sledovat TV přes internet. Když si vezmu v úvahu, že dalších cca 100 domácností jede z vesnice do internetu po společný bezdrátový lince (takže 8/1 ani nejde garantovat), tak si myslím, že klasický TV vysílání (mluvím o DVB-T/2) tady s námi bude ještě dlouho. Prostě nejde jednoduše odstřihnout a nahradit internetem. Nejsou na to zdaleka všude dostatečný podmínky.

Mimochodem znám i lidi, který jsou rádi za 3/1Mbit. Na druhou stranu znám i lidi, který potřebujou výkonnější router, protože ten jejich stávající 1Gbit prostě neuroutuje.

527

Server / Re:Sdílení dat mezi dvěma RPi

« kdy: 21. 02. 2017, 14:25:45 »

Jen k těm relátkům - pokud tam bude sepnutí v řádu minut a ne jen hodin a více, opravdu bych použil ta SSR. Jedno sepnutí za 10 minut je víc než 50 000/rok...

Bude tam na vysokoproud (bojler) sepnutí v řádu 2x za den (noční proud), když ten den nebude ohřejvat kotel nebo soláry. Vidím to řádově na 100 - 300 sepnutí ročně. Sáhnu po klasickym stykači. Důvod napsal PetrM, je to hlavně jeho cena, která vyváží i případnou výměnu 1x za XY let.

U těch slabých proudů (řádově do 0,5A, je to víceméně jen čerpadlo, větrák a šnek na kotli) bych teoreticky mohl použít klasická malá relé na 230V/10A. To by skrz ně mělo projít v pohodě. Ale asi dám stykače i na tohle. U stykače věřím, že bude fungovat bez problémů.

Do DIN lišty to celý nedám. Rozvaděč mám totiž víceméně plný (vše by se nevešlo) a je zbytečně daleko. Dám do do nový bedny přímo do kotelny.

Mirek: Na video mrknu, něco počtu a pak dáme OpenTTD. Hraješ to nějak alespoň trochu (víc)?

528

Server / Re:Sdílení dat mezi dvěma RPi

« kdy: 21. 02. 2017, 12:04:09 »

Teda vy mě ale serete

Pravda - nabídka na pomoc s MQTT a na oplátku multiplayer OpenTTD zní velmi lákavě, je to jednoznačný win-win scénář. Alespoň pro mě

Vzhledem k tomu, že teď se můj čas a pozornost soustředí na zkompilování jádra pro Toshiba AC100, tak tahle otázka ještě není zcela uzavřená. V době kompilace jádra (cca 58 minut) se mrknu na MQTT, něco si počtu a ještě se tady ozvu.

Pořád je to kanon na vrabce, protože já chci udělat zcela uzavřenej systém, kterej bude nezávislej a neovlivnitelnej čímkoliv zvenku - zde vynecháme odcizení klíčů SSH/wifi, bugy v použitých programech apod., ano? Já to myslím tak, že nepřijde brácha s mobilem v ruce a nezačne mi vrtat do nastavení... Výstupem budou vždy jen readonly data. Jediný zápisy půjde dělat buď přímo na úrovni filesystemu (přes SSH) nebo klikáním na ikonky na displeji nebo vypínačema (v kotelně, mechanický spínače).

Info ke kotelně: Solární ohřev vody (teplota teplé a vracečka), automat kotel na uhlí (větrák + šnek -> ovládání ale jen pro jejich odpojení v případě, že kotel z nějakého důvodu vyhasnul -> to zjistí teplotní čidlo v komínu), teplá voda do topnýho systému + vracečka z topnýho systému, ohřev TV ze soláru nebo z kotle (ovládání ventilu) nebo elektrikou (tady je těch 10A), okruh teplý vody do domu (teplota do domu + vracečka + ovládání čerpadla), teplota ve 250l bojleru nahoře a dole.

Celkem bude v kotelně pokud dobře počítám 8 Dallas čidel a 1x thermocouple (komín) a budu chtít spínat (nebo rozpínat) minimálně 5 věcí.

Na příští zimu chci mít hotový minimálně:
1. ruční zapnutí (na LCD nebo vypínačem přímo v kotelně) ohřevu TV z kotle
2. automatický koloběh TV do domu (aby se čerpadlo spínalo v nějakých intervalech podle teploty vracečky)
3. termostat (RPi v obýváku měří teplotu v bytě a taky venku)
4. ruční zapnutí (na LCD nebo vypínačem v kotelně) ohřevu TV elektrikou

RPi si mezi sebou budou předávat:
z kotelny do obýváku teploty (k zobrazení) a stavy (např. čerpadlo běží)
z obýváku do kotelny topit/netopit a ruční ovládání zmíněných věcí

Předávat se budou jen čísla, ať už teploty nebo 1 a 0 pro různý stavy.

Pokud se něco podělá (chcípne nějaký RPi nebo nějakej skript), tak buď:
v obýváku neuvidím údaje
v kotelně se odpojí relé deska (napájení) a systém se uvede do stavu bez dozoru RPi -> pro tuto možnost bude v kotelně na krabici s RPi vypínač, kterej bude sloužit jako manuální spínač termostatu - totální override všeho "chytrýho" (když nebudu doma, něco se posere a manželka chce mít doma teplo)

Pokud chcete, můžeme to tu převést na obecnější HW debatu o provedení celýho systému. SW stránka věci je víceméně podchycená (až se rozhodnu zda HTTP nebo MQTT).

529

Server / Re:Sdílení dat mezi dvěma RPi

« kdy: 20. 02. 2017, 13:07:30 »

Ještě to hotové nemám, ale rozhodnutý už jsem. Půjdu cestou HTTP a jen read only. Každý RPi si na vlastím písečku vytvoří svoje soubory s datama a vystaví je na HTTP tomu druhýmu RPi.

Všem moc děkuju za podněty a návrhy, cením si jich. Zevšeobecním trochu důvod, proč jsem ty které nevyužil - pracuju s tím, co znám a v čem jsem schopný to udělat za rozumný čas. A to i za situace, kdy to třeba není to nejlepší řešení z některého hlediska.

HTTP pro mě má výhody - vytáhnu mobil, mrknu do prohlížeče a mám data před sebou. To je neocenitelná věc při debugování na dálku. Teď nemyslím debug skriptu, ale debug situace v kotelně... ;-) V kotelně se bude měřit víc věcí a na některé bych nerad čekal (třeba) několik minut, než dostanu novou hodnotu.

SNMP je jen pro zajímavost, jsem statistickej magor. Loguju, co se dá. Kromě samotných systémových logů. Takže teploty, otáčky, využití CPU/RAM, ... a to u všeho, co to umí, kromě Windows PC. S tím tady nikdo nic neuděláte :-)

Relátkama budu spínat, ale přemýšlím trochu o nesystematickym řešení... Že relátkama budu spínat klasický stykače na DIN lištu. Pojede přes to několikrát 230V od 0,2A do 10A.

Ještě jednou díky za vaše názory a nápady!

530

Server / Re:Sdílení dat mezi dvěma RPi

« kdy: 17. 02. 2017, 18:43:06 »

JardaP.: Co Ty víš, čím doma topíme Taky by to bylo řešení, ale raději bych předávál informace častěji, řekněme alespoň 1x 10s. Kdybych to scp dal opakovaně 5x za sebou do bash skriptu s prodlevou 10 sekund a pouštěl jednou za minutu, docílil bych víceméně kýženýho efektu.

Je to lepší než SSHFS, protože u toho je problém s právy (pod čím běží Python skript, jaký uživatel to připojil, ...).

Nicméně si nejsem jistý, jestli to bude lepší/jednodušší/použitelnější, než HTTP server.

Zatím teda přichází v úvahu dvě možnosti: SCP a HTTP. Uvidíme, dnes nebo zítra se na to mrknu trochu víc a jedno z toho rozjedu. Osobně vidím jednodušší to HTTP (pustím server, dám mu documentroot a jedu).

531

Server / Re:Sdílení dat mezi dvěma RPi

« kdy: 17. 02. 2017, 18:28:21 »

Tomas Rollo: MQTT zní dobře. Trochu si myslím, že za současný situace je to teda kanon na vrabce, ale díky za doporučení. Minimálně o tý technologii budu vědět a možná jí využiju jinde. Jinak osobně se příkláním spíš ke dvěma vlastním písečkům (tj. nezávislosti) než k centralizovanýmu řešení (MQTT na jednom stroji, ostatní se mu hlásí)

Jinak retain je defacto nežádoucí, protože by mohlo dojít k nějaký podivný situaci, kdy by si jedna nebo druhá strana myslela něco špatnýho...

Provozní věci RPi bude mít SNMP, ze kterýho sbírám data přes OpenVPN (server je jinde).

JirSoft: Já právě asi nechci jít takovou "obecnou" cestou. Tím, že mám jen dvě zařízení a víc jich nebude (pokud ano, třeba Arduina, tak budou připojný do USB jednoho z těch RPi), tak se mi nechce jít až takhle zeširoka. Ale řešený to máš pěkně ;-) Jinak já to právě taky sbírám na veřejném serveru, ale jen jako log a na čumendu na data. Jinak to má fungovat víceméně realtime - kouknu na LCD a vidim, kolik je venku, jak teplá je voda v bojleru atd. Zpětně to je na serveru spíš kvůli debugování (který momentálně provádim).

532

Server / Re:Sdílení dat mezi dvěma RPi

« kdy: 17. 02. 2017, 13:25:59 »

Na moderní/nemoderní si nehraju, víceméně mi fakt jde jen o to, aby to jelo ;-)

Neběží mi démoni, jen skript s while 1 (no co, dělá to to, co má). Takže komunikace na nějaký systémovější úrovni není.

SSH samozřejmě běží na obojím a běžet bude. Můžu ale klidně nahodit NFS, pokud bude mít výhody. Jde mi hlavně o to, aby se to samo připojilo, kdyby došlo k výpadku na jedné straně.

RPi spadne, tak RPi přestane zobrazovat jeho teploty.
Jakmile RPi najede, tak si RPi samo během startu namountuje složku z RPi.
Já potřebuju, aby RPi nějak detekovalo najetí RPi a postaralo se o mount složky z RPi. Ideálně tak, aby to uměla technologie sama (reconnect).

Je pravda, že navzdory tomu, že se nechci pouštět do sítě v Pythonu, tak HTTP by bylo ideální. Na každym písečku by byly soubory s hodnotama a druhá strana by si je jen pravidelně četla. Kdyby jedna strana vypadla, nic se neděje, prostě nemá hodnoty a po znovunajetí se vše srovná samo. V tomhle případě jsem i ochotnej rozjet webovej server (mimo Python skript).

Jinak já data budu chtít tak jako tak v plaintext souborech - to kvůli tomu SNMP, pohodlně si to z nich vytáhnu. Tím částečně odsuzuju přímý předávání dat mezi skriptama.

533

Server / Re:Sdílení dat mezi dvěma RPi

« kdy: 17. 02. 2017, 10:26:12 »

Teď jsem si o Zeroconf něco přečetl a podle mě to není to, co hledám. Já potřebuju službu na předání dat.

Síť mi teď jede, nastaveno všechno mám, RPi se vidí, a můžou spolu "mluvit". Jde jen o to, jakou službu pro "mluvení" použít (SSHFS, NFS, ...)

534

Server / Sdílení dat mezi dvěma RPi

« kdy: 17. 02. 2017, 09:45:52 »

Ahoj všem,

řeším teď doma takový trabl. Popíšu situaci:

• V obýváku mám RPi s LCD displejem. Zobrazuje vnitřní a vnější teplotu a vlhkost. Je připojené na domácí wifi (DHCP pevná IP).
• V kotelně mám také RPi, které momentálně měří teploty vody a má připojená relé. Je také připojené na domácí wifi (DHCP pevná IP).
• Potřebuji spojit tyhle dvě RPi tak, aby si mezi sebou mohly předávat informace. Z kotelny chci do obýváku dostat teploty a z obýváku potřebuju ručně ovládat relé v kotelně.
• V obýváku zobrazuji na displeji pomocí pygame. Veškeré skripty jsou v Pythonu 2.7
  
• V kotelně zatím nic nezobrazuji, skript na získávání teplot je v Pythonu 2.7, relé zatím neovládám (ale udělám to v Pythonu 2.7)
• Z obou RPi budu přes OpenVPN číst údaje přes SNMP (serverem, který jinak nefiguruje v této situaci).

Moje představa je taková, že si budu předávat údaje pomocí namountování části filesystému, kde budou soubory s údaji v plaintext. V Pythonu si pak otevřu soubor, vytáhnu data a zobrazím je/sepnu relé. V Pythonu také data do souborů budu ukládat.

Chci se vás poptat, jak bych měl podle vás namountovat filesystem na obou RPi.

• Mám udělat na jednom vyhrazenou složku a z druhého se připojit a sypat to vše na jedno místo?
• Nebo mám udělat na každém RPi vlastní složku s daty a namountovat to navzájem (RPi mount složka z RPi a současně na RPi mount složka z RPi)?

Osobně preferuju, ať si každý RPi plácá svoje data na svym písečku a cizí data ať si čte z toho druhýho (tedy možnost 2).

Závisí to na mých preferencích, chápu.
Řekněme, že když mi vypadne spojení, tak RPi s LCD prostě jen nevypíše teploty z kotelny, který kvůli výpadku nevidí. RPi v kotelně při výpadku uvede relé do safemode, tedy do stavu, jako kdyby žádný RPi nebylo.

Další z otázek je nasnadě - jakým způsobem namountovat filesystemy? Udělat si klíč bez hesla a jet přes SSHFS? NFS? Přenášet soubory přes FTP ( )? Zároveň bych potřeboval nějakej failsafe mode - když budu jedno RPi restartovat, tak aby se mi provedl mount automaticky znova (tedy "obnovil" automaticky).

Připomínky ode mne:
Python 2.7 ("stará verze") vyhovuje i do budoucna, protože jakmile to jednou pojede, odmítám na to víc hrabat ("zakonzervuju" to). Netřeba řešit, proč to nepíšu v 3.x. Pravděpodobně nakoupím další SD karty, na které si dám image funkčního řešení, stejně tak koupím i rezervní RPi a LCD. Tohle prostě bude fungovat minimálně dalších 30 let, ideálně 50.
Nechci jít do nějakýho high-level řešení jako třeba ukládat data do MySQL apod.
Nechci v Pythonu řešit síť (třeba předávání dat přímo po síti mezi dvěma skriptama)

Předem díky za názory a podněty.

K obrázku: Červená = obývákový RPi, modrá = kotelnový RPi, černá čára ukazuje očekávaný směr toku dat (zobrazit data z čidel na LCD), přerušovaná čára značí, že to možná někdy bude. Relé na obrázku nejsou, protože ještě nejsou připojená (ještě k nim chybí kus cesty).

535

Software / Re:Hraní her -> Windows ve virtualu

« kdy: 15. 02. 2017, 14:16:06 »

4) Linux a Wine

Provozuju to od dob, kdy jsem přešel na Linux (cca 8 let) a zahraju si parádně.

EDIT: Mimochodem - (nejen) Steam už nabízí docela dost A-čkových her pro Linux, není problém si zahrát přímo v Linuxu.

536

Hardware / Re:Krabice na embedded hardware ?

« kdy: 08. 02. 2017, 20:00:59 »

Nějaký krabice nabízí GME.cz (plast/plech), ale nevím, jestli to je přímo to, co hledáš... Některý z nich mají i díru na displej nebo průchodky, některý jsou vodotěsný (montáž ven, na střechu, ...) apod. Nedal bych za to ruku do ohně, ale věřím, že spoustu krabic nabízí už léta.

(Není to reklama, jen ten krám mám blízko a chodím tam pro malý krabičky na Arduino a elektro součástky. Ještě mám v okolí GES.cz, ale tam jsem nikdy moc nenakupoval, je už pro mě trošičku z ruky, ale vím, že má některý věci levnější - možná i krabičky)

537

Hardware / Re:Sluchátka nehrají potichu

« kdy: 07. 02. 2017, 21:38:16 »

Jak to dopadne... Možnosti jsou tři:
1. Neoprávněná reklamace (70%)
2. Dostaneš nový kus (29%), který bude mít stejnou vadu (100%)
3. Dostaneš peníze (1%)

538

Software / Re:Brute force loupnutí hesla k certifikátu

« kdy: 30. 01. 2017, 12:43:43 »

Jak dlouho čekáte, že to bude trvat? Bavíme se tu (pokud dobře čtu a chápu) o 1000 (tři znaky) - 10000 (čtyři) kombinacích.

539

Hardware / Re:Vykonne PC bez aktivneho chladenia - pre alergika

« kdy: 27. 01. 2017, 13:49:50 »

Pokud by se sehnala základní deska s hodně dobře chlazenou napájecí kaskádou, pak si myslím, že pasivní chlazení i výkonný sestavy není sci-fi.

Když se bedna položí na bok a nechá se otevřená, dá se na PC nějaká masivní věž, nejlépe nevržená pro pasivní chlazení (větší odstupy mezi lamelama) a ta to pravděpodobně udrží na přijatelný mezi.

Na grafiku lze dobastlit něco podobnýho (věž myšlenou původně pro CPU), ale tam už těžko říct, jestli bude stačit, grafiky už jsou kolem 150+W. Napájecí kaskádu grafiky chladit pomocí heatpipe (teplo dostat dál a tam na druhym konci heatpipe lamely - takový chladiče se kdysi dělaly a možná ještě prodávají).

Pasivní zdroje už jsou.

SSD aktivní chlazení nevyžaduje, HDD stačí, aby kolem něj bylo trochu místa na vyzáření tepla. Zbytek by neměl dělat problémy.

Doporučuju server extrahardware.cz, kde docela dobře testujou chladiče CPU (i v pasivním režimu). Minimálně pro inspiraci se to hodí. Možná by se dal oslovit i jeden z redaktorů, kterej testy dělá. Možná by to i sami chtěli otestovat

540

Distribuce / Re:Nelze nainstalovat závislost libc6:i386

« kdy: 26. 01. 2017, 12:41:53 »

Přesně, čistý řešení to nemá. Tiskárna vyžaduje konkrétní libc6-i386 a VirtualBox vyžaduje konkrétní (nebo minimální) libc6. Ovšem obojí chce knihovnu v jiné verzi.

Pokud nejde v Debianu nainstalovat jiná verze slotově, tak nevím, jak to řešit (Debian ani podobná distra nepoužívám).