Fórum Root.cz
Hlavní témata => Server => Téma založeno: Pavouk106 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 ( ;D )? 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).
-
Na to snad existují knihovny, nejjednodušší bude něco jako Bonjour/Zeroconf.
Edit: Necitujte celé názory nad sebou, zhoršuje to čitelnost vlákna.
-
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, ...)
-
A nie je to celkom jedno? Ja by som pouzil SSHFS - predpokladam, ze SSH tam bude bezat tak ci tak, cize je to viac menej zadarmo...
-
Mountovat to jako filesystem mi přijde šílené, pokud jde jen o předání dat.
Předpokládám, že vám tam na každém běží démon. Když na každou stranu přidáte do pythoního kódu http server, který předá ty požadované hodnoty, tak máte hotovo. V Pythonu tak 20-30 řádků. Přidání autentikace a ssl podle libosti. Na internetu mraky tutoriálů.
Pokud to nechcete dělat přes http, tak bych to udělal jako jednorázový skript přes ssh. Naloguje se, přečte hodnoty a zase se odloguje.
-
A nez resit nejake knihovny, tak nemuze jedna aplikace sedet na UDP portu a druha se ji obcas zeptat? Chapu, je to nemoderni, nebezpecne a asi na pet radku v pythonu na kazde strane.
-
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, ...)
Když se vidí, tak jedině TCP. Cokoliv jiného je v tomto případě blbost.
-
Mountovat to jako filesystem mi přijde šílené, pokud jde jen o předání dat.
Také. Tím, že je to oboje Python, tak bych to zabalil pomocí Pickle, poslal soketem a neřešil.
-
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.
-
A nešlo by použít MQTT (https://en.wikipedia.org/wiki/MQTT (https://en.wikipedia.org/wiki/MQTT))? Tj. na RPI s LCD rozjet MQTT broker, treba Mosquitto (https://mosquitto.org/ (https://mosquitto.org/)) a pres nej informace vymenovat?
Vyhody:
- publish+subscribe, kdy se bez problemu muze pripojit i ten SNMP server a hodnoty publikovane od RPI z kotelny si budou vycitat jak RPI s LCD tak i ten SNMP server
- moznost pouziti retain nastaveni, kdy si broker bude pamatovat naposledy publikovane hodnoty a dokaze je dat subscriberum i bez toho, ze by publisher (RPI v kotelne) byl online
- moznost pres to jednoduse sdilet i provozni parametry toho RPI v kotelne (tj. jestli bezi, kolik ma disku, RAM, vytizeni CPU, apod)
- bud uz existuji konektory (pro ten SNMP server), nebo je mozne resit i shell skripty (Mosquitto ma CLI rozhrani)
- muzu pripojovat i dalsi subscribery postavene na dalsich technologiich - podpora MQTT je ted uz ve spouste home automation systemu (treba muj oblibeny Home Assistant https://home-assistant.io/ (https://home-assistant.io/))
-
Používám doma něco podobného (RPI které měří a řídí teploty u psů, pak pár ESP8266 které měří teploty a různé jiné kravinky a RPI v domě jako zobrazovací panel s LCD, který umožňuje ty jednotlivé hodnoty i nastavit). Mám na to vybranou UDP multicast adresu (abych nepoužíval broadcast) a každý měřák (ESP8266 i RPI), kromě nějakého ukládání svých dat do DB posílají každých 5 vteřin balík svých dat na tu UDP multicast adresu. Zobrazovači pak stačí poslouchat a když jsou data, tak aktualizovat (výpadek nevadí). Pokud chci změnit hodnoty, pošlu je na daný přístroj a ten mi potvrdí změnu. Funguje perfektně, mám namixovaný Python, Arduino C a XOJO a žádná komplikace.
Data zároveň zapisuje každé zařízení do DB na Synlogy (pomocí HTTP volání PHP skriptu) a to skript duplikuje na můj veřejný server. Zvenku se pak mohu na údaje podívat na tom věřejném, doma přímo na Synology...
-
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).
-
A nestacilo by uplne hloupe pouzit scp a RPi by si data posilala z cronu jednou za minutu? Jedna minuta neni u regulace kotle zadna doba, kvuli ktere by si clovek mel delat vrasky. Kotel neni jaderny reaktor.
-
JardaP.: Co Ty víš, čím doma topíme ;D 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).
-
JardaP.: Co Ty víš, čím doma topíme ;D
Tak jestli topite na uran, tak stejne musis mit regulator rovnou na reaktoru a nejake RPi v bejvaku mu do regulace nesmi kecat. Pak tam jeste musis mit nekolik zabezpecovacich systemu. Reaktor, kdyz ujede regulace, tak exponencialne ujede, az vybouchne a roztece se.
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.
Proc? Abych videl, ze mi kazdych 10s naroste teplota na kotli o pul stupne, namisto aby to po minute poskocilo o 3? Budes travit cas pred displayem a koukat na cislicka? To te za den omrzi. A jotel je tak pomala regulacni soustava, ze kdybys ty data posilal kazdych 5 minut, porad jeste by se to neposralo.
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, ...).
man sshfs, -o allow_other
Ja bych se spis bal toho, ze mi sshfs spadne, kdyz treba vypadne spojeni, protoze nekdo pustil neodruseny mixer. To abys to hlidal skriptem, shodil a obnovil. U scp je mi jedno, kdyz to obcas neprojde. V nejhorsim po par minutach bez dat vypnu kotel, dokud zase nezacnou chodit. A na displayi v bejvaku hodim chybovou hlasku.
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).
S scp je to urcite jednodusssi na implementaci. S HTTP bych ale nesel do jineho reseni, nez ze obe RPi si budou navzajem vystavovat data jako read only, aby si nejaky hracicka nekratil cas tim, ze mi bude psat do nejakych hodnot. I tak ale je scp bezpecnejsi. Muzes i pouzit klice, jako u ssh. Hezke je na tom take to, ze obe RPi budou na siti skoro neviditelna. Web server pritahuje vic pozornosti, nez ssh bezici na portu 5687. To by mohlo byt zajimave proto, ze kdyz to nekdo hodla rozchodit a nadale to nebude updatovat, tak za tech 30 let to urcite nebude bezpecne. Mozna ani to ssh.
-
asi bych na to taky pouzil mqtt, to ma clovek rozbehany razdva
a pokud by jsi tedy nechtel pouzivat kanon na vrabce a ani jine hotove reseni (zeromq napr) tak udelat proste tcp server-client, to je skutecne na par radku (neco jako https://wiki.python.org/moin/TcpCommunication)
-
Pořád mi přijde ten UDP multicast jednodušší - je též na pár řádek, kotelna prostě bude posílat balíček svých teplot a nezatěžuje ji, jestli poslouchá jen to druhé RPI nebo deset dalších mobilů, tabletů, počítačů, dalších zobrazovačů...
A pro ovládání relé na tom samém portu bude čekat na specifický povel pro sepnutí/rozepnutí (a potvrdí ho vzápětí v balíčku svých dat).
Jediné, co je třeba dělat, je udržovat bind na UDP port a když nebude, tak se prostě nic nepošle (a na druhé straně nic neuslyší) - ale není to o hlídání spojení, navazování nového atd. Prostě opravdu pár bajtů bez overheadu.
(Vzájemně) připojené adresáře mi přijdou nejkomplikovanější na hlídání OK stavu...
-
Pořád mi přijde ten UDP multicast jednodušší - je též na pár řádek
Chtel jsem namitnout ze multicast je proti holemu UDP jeste porad moc slozitej, ale kdyz koukam na priklad, tak ty ctyri radky navic se daji prezit. I kdyz jestli to dobre chapu, tak ten druhy setsockopt se receiveru bude generovat nejake IGMP pakety.
http://stackoverflow.com/questions/603852/multicast-in-python
Samozrejme opakuji, ze pokud ma pouze jeden vysilac a jeden prijimac, tak se muze na multicast vykaslat a bude to mit na par radku. Zkusme ty radky spocitat:
Vysilac:
... socket
... sendto
2 radky
Prijimac:
... socket
... bind
... recv
3 radky
Opravdu tu chce nekdo resit nejake ssh, nfs, http, mqtt, nebo janevimco?
-
Sorry, znovu jsem si precetl puvodni dotaz. On to chce i opacnym smerem.
Tak jeste dva radky: send a recv naopak.
-
Samozřejmě souhlas, unicast UDP je úplně nejjednodušší, ale ta výhoda multicastu je jednak v ladění (při jakémkoliv problému si mohu poslechnout, co si stanice vyměňují bez zásahu do původního SW) a jednak v možnosti přidat jednoduše další stanice (třeba jen ty displeje pro zobrazení) opět bez změny SW a hlavně zatěžováním jedné strany případnými požadavky...
-
Nejprimitivnejsi a dostatecny by me prislo mit ssh klice + scp s rozumnym timeoutem a kontrolou navratove hodnoty.
To scp se muze logovat na spesl uzivatele s adekvatnima pravama (cteni jen toho souboru a zapis nikde), pokud se to cloveku chce resit.
-
A nebo na jednom z nich pustit nějakou db(což se beztak hodí pro statistiky) a šahat do tý db z obou RPi.
-
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.
Tak když trváte na tom SNMP (čemuž úplně nerozumím, mimochodem má to nějaké mibky?) a už ho tam máte, tak to načítejte přes SNMP. Nějaká knihovna pro Python určitě bude, třeba PySNMP.
-
Řešil bych to přes http(s), proč? Web server je na tohle fajn, chceš do budoucna přidat webové rozhraní? Máš už sever, přidáš jen nějaké html... Na tohle konkrétně preferuji bottle framework a taky to tak řeším u sebe. Soubory většinou přenáším webdav...
-
Btw jestli to spinas relatkama tak je rovnou vymen za ssrka, usetris si tim problemy jako speceni kontaktu atp...
-
Panove, KISS. Aby to za par iteraci neskoncilo jako cluster serveru s diskovym polem.
-
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!
-
...Půjdu cestou HTTP a jen read only....
To jo. le pomysli a to, jak ti NSA nasadi do site malware a bude ti sledovat data z kotle a z bejvaku....
-
...Půjdu cestou HTTP a jen read only....
A co když se ten script co bude generovat index.html nějak zasekne?
Na http budou neaktuální data?
-
...Půjdu cestou HTTP a jen read only....
A co když se ten script co bude generovat index.html nějak zasekne?
Na http budou neaktuální data?
a to je problem aby si tam pridal timestamp? a co kdyz by zvolil jeden z 10 jinejch zpusobu a script co by generoval nebo sbiral data se zaseknul? ;)
-
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.
Ještě jednou bych zalobboval za MQTT - fakt silně bych ti to doporučoval.
Není to "kanón na vrabce", je to jeden démon, který ti poběží na jednom RPi a můžeš na něj napojit kolik chceš klientů, sdílet data jakkoli napříč klienty, výpadky ti nevadí, slušná knihovna se sama reconnectne, můžeš sledovat dostupnost klientů (k tomu se používá ta retain zpráva) atd. atd. Provozu brokeru se nemusíš bát - např. mosquitto je nenáročný držák. Nainstaluješ, jedeš, zapomeneš, nikdy už nic neřešíš. Pokud nechceš ACLka, nemusíš ani nic konfigurovat, jenom spustíš a už nikdy na to nehrábneš.
Ale hlavně: je to už dneska dost standard. Možná se ti dneska zdá, že ty dvě RPi jsou definitivní stav na 30 let, ale za dva roky tě napadne, že bys to chtěl ovládat z mobilu. Za tři roky, že bys chtěl data zobrazovat na tabletu pověšených na ledničce a za tři a půl roku se začneš nudit, že to všechno funguje a budeš chtít přidat další sensory a zobrazovat to na displayi za zrcadlem ;)
To sdílení souborů je slepá ulička - teď ti to bude stačit, ale budeš s tím mít problémy (neconnectlo se, nenamountovalo, ...) a do budoucna to nijak nerozšíříš. UDP apod. může být fajn a robustní, ale s ničím to nepropojíš, bude to tvoje "proprietární" řešení a robustnost si musíš pohlídat sám. Zeromq vyloženě nedoporučuju, sexy myšlenka, ale v praxi mě hodně mě zklamalo. Http je v pohodě, ale bude se hůř ladit (nemáš žádnej jeden bod, kde bys mohl snadno sledovat veškerou komunikaci) a pokud bude časem funkcionalita růst, skončíš se špagetovým kódem volání různých API, ve kterým si musíš udržovat pořádek a systém. Budeš si úplně zbytečně lámat hlavu s kravinama ohladně detailů API.
S MQTT máš robustnost, můžeš veškerý provoz krásně sledovat, můžeš to snadno propojit s čímkoli, klient existuje i v javascriptu (pro připojení ti stačí statická html stránka s kouskem JS). A můžeš si na to napojit třeba NodeRed a udělat si během max půl hodiny domácí, soukromý IFTTT - a to se vyplatí! ;)
P.S. mqtt mám docela dost ošahaný, rád ti s tím případně pomůžu. Zaplatíš mně tím, že si proti sob2 zahrajem OpenTTD nebo jinou multiplayerovku podle tvýho výběru ;)
-
Jo, ještě jsem nenapsal, že MQTT je samozřejmě jenom způsob, jak data posílat a "sdílet" v okamžiku, kdy jsou poslaná. Není to databáze.
-
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.
Spinat relatkem stykac neni nic nesystematickeho, to se tak nekdy dela. Ale obvykle ve vetsich kotelnach, nez mas ty doma. Tedy pokud netopis elektrikou, nebo nemas tepelne cerpadlo. 230 V krat 10 A jsou cca 2 kW a takovy elektricky prikon bezny plynovy kotel nema ani s cerpadlama dohromady. Takze tipuju, ze muzes stykac vynechat, protoze nejake rozumne rele takovych 230 V a 8A spinat zvladne.
Jinak to s tou DIN listou jsem nepochopil. Ja mam na DIN liste i to OvocePi i to rele.
-
S tím lobbingem pro MQTT souhlasím. Ošetřování všech možných chybových stavů vlastního řešení bývá opruz plný chyb, navíc se problémy vyskytují postupně, až po čase, v nestandardních situacích, které se špatně simulují a člověka často ani nenapadnou.
Pokud je něco hotové, standardizované a stále vyvíjené, way to go.
-
Teda vy mě ale serete ;D
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ě ;D
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).
-
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ě ;D
Super :)
se mrknu na MQTT, něco si počtu a ještě se tady ozvu.
Koukni na https://www.youtube.com/watch?v=WLIlDGiXpJY dobrej uvod.
-
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!
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...
-
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...
Ale stačí trocha přepětí v kabelech a nevhodný souběh...
Spečený kontakt u relé v patici na DINce je za 60Kč, SSR za pár stovek až tisíc a zbytečně. Nehledě na to, že SSR má další nectnosti - potřebu chlazení, větší rozměry,...
-
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)?
-
Bude tam na vysokoproud (bojler) sepnutí v řádu 2x za den (noční proud), když ten den nebude ohřejvat kotel nebo soláry.
To je mozna zbytecne. Bojler ma prece termostat a tak z elektriky akorat dorovna teplotu podle toho, jak moc to jiz vytopil kotel ci solarni panel. Zalezi na tom, jak moc vam vadi, ze budete mit chladnejsi vodu v pripade, ze to bojler nedotopi nad teplotu z kotle/solaru, pokud mu v tom zabranite odeprenim nocniho proudu. Ale vzhledem k tomu, ze topna voda z kotle nebude 90°C a ze solaru asi take obvykle ne, tak bych tipoval, ze mate velky bojler a jedete na nizsi teplotu. V tom pripade termostat bojleru stejne obvykle nesepne, protoze uz bude vytopeno a vy si usetrite stykace, dratovani a programovani.
No, pokud na tom trvate, tak si tam aspon dejte rucni vypinac. Aby vam jednou neodeslo RPi a vy jste nemusel tyden ohrivat vodu na sporaku.
-
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...
Ale stačí trocha přepětí v kabelech a nevhodný souběh...
Spečený kontakt u relé v patici na DINce je za 60Kč, SSR za pár stovek až tisíc a zbytečně. Nehledě na to, že SSR má další nectnosti - potřebu chlazení, větší rozměry,...
Nesouhlas. Používám toto:
http://www.dx.com/p/solid-state-high-level-4-channel-5v-dc-relay-module-black-blue-435617#.WKxtUhjMzOQ (http://www.dx.com/p/solid-state-high-level-4-channel-5v-dc-relay-module-black-blue-435617#.WKxtUhjMzOQ)
Cena 210 Kč za 4 SSR, pripojeno přímo k rPI v tuto chvíli ca rok. A mám to připojeno jako "pseudo PWM" na topných panelech u psů - topím na 0- 100% s rozlišením 10%.
Udělal jsem si zjednodušení, protože nepotřebuji rychlost (setrvačnost desek), takže hodnota=(procenta/10 - 1) topí vždy když jednotky sekund jsou <=hodnota.
Např. 20% (hodnota = 1) ... topím v 0., 1., 10., 11., 20., 21., 30., 31., 40., 41., 50. a 51. sekundu, v ostatní ne.
Znamená to, že spínám docela často - při jakémkoliv požadovaném výkonu (kromě 0% a 100%) 17280 sepnutí a rozepnutí za den! Relátka by to asi dlouho nedala...
-
Mirek: Na video mrknu, něco počtu a pak dáme OpenTTD. Hraješ to nějak alespoň trochu (víc)?
Dřív jsem to hrával vášnivě, teď už nějakou dobu ne. Ale tebe vyklepnu, to si piš! ;D