Két épület között kell a LAN-t átlőnünk – ehhez találtuk meg a Ubiquiti NanoStation 5AC Loco antennáit, amik pont ezt a problémát oldják meg. Először csináltam ilyet, eléggé fogalom nélkül, de gondoltam nem lesz ez túl bonyolult dolog.
Az antennákat csak PoE tápellátással lehet etetni, de azzal semmi baj. Van a házban egy atomerőmű méretű 24 portos Ubiquiti Professional PoE switch és egy UTEPO SF10P-FHM, mindkettőn van szabad port is (a nagy dögön ráadásul PoE+ és PoE++ is), így halál nyugalommal szereltem fel őket.
Kis kezeimmel gyönyörűséges UTP kábeleket krimpeltem, leteszteltem a drótot is és a switchekkel való kapcsolatukat is, megteszteltem a PoE tápátvitelt ahogy illik és minden tökéletesen rendben volt – gondoltam én hülye.
A kis antenna megkapja az UTP kábelt én meg mennék a computer elé konfigurálni, de útközben a PoE switchre nézve azt látom, hogy se a Link se a PoE tápolás led nem aktív. Rámértem az antenna végén levő RJ45 csatin a PoE kapcsolatra, minden rendben volt, a nagy switch portjai meg tudják a Pair A (1, 2+ és 3, 6-) és Pair B (4, 5+ és 7, 😎 PoE tápolást is – akkor meg WTF?
A nagy switch 44-57V, illetve 50-57V DC feszültségen tápol, a kis UTEPO pedig 48-57V DC tartományban – ahogy én azt eddig a PoE tápról tudtam. És itt jön a trükk: a kis NanoStation antennáknak 24V 0.5A DC táp kell, különben nem szólalnak meg.
Ezt úgy tudod elérni, hogy veszel hozzájuk 2*14.70 EUR nettóért 2 db 24V-os PoE injektort. Végignéztem az összes point-to-point átjátszó antennájukat és mindegyiknek ez kell.
Nem mondom, hogy nem viszket a fejem búbja az idegességtől. 48V DC-ből kb. két üveggolyó áráért lehet 24V DC-t készíteni, amit a gyártó simán megtehetne az antennáiban. Vagy mondjuk mellékelhetné a speciális 24V DC-s PoE injektorokat, ahogyan teszi ezt szinte az összes WiFi access pointjánál.
Szűk 3 napom ment el a témára, ledokumentálom gyorsan.
A probléma
A PLC-ben futó szoftvert a PLC-n kívülről is akarjuk utasítgatni.
A megoldás
A kommunikációt network variable használattal oldjuk meg. Ehhez PLC oldalon az kell, hogy engedélyezzük a PLC-ben a hálózati változó támogatást, valamint a benne futó szoftver a hálózati változók tartalmával mókoljon, amit akar.
A “B” oldalon Node-Red-et akartam használni. Node-Redhez létezik egy node-red-contrib-netwar csomag, ezt feltesszük és már huss meg is vagyunk az UDP packet generálással, valahogy így:
Az UDP telegram dokumentációja világosan elmondja, hogy a packet elején levő protocol ID a 3 byte hosszú -S3, ami decimálisban a 2970419 számnak felel meg, amit a netvar-sender node ID mezőjében kell megadnod. Ha ez nincs, a PLC ignorálja a packetet és várhatod, hogy beálljanak a network variabLÉK.
Az utóbbi mondatban leírt felismeréshez nekem szűk két nap kellett, mert elsiklottam a milliónyi manualban / tutorialban afelett, hogy ez az a mező, ami az UDP packet headerét definiálja. Kurt videóját pl. vagy tizenötször kockáztam ki, hogy mi a fenét nézek be – ő pl. itt 4:42-nél állítja át ezt az ID-t egyetlen egy frame alatt:
Pappitoval beszélgettünk reggel. Mutattam neki az új Dyson lámpát:
Csini mi? Dysonék sajna aranyárban mérik – de most nem ez a lényeg, ugorgyunk!
Elkezdjük nézni a “Getting started” videót. Érdemes, nézd meg te is:
Ugye neked is feltűntek az alábbiak:
ahogy kinyitod a dobozt, a fedél feléd eső részén ott van az összeszerelési utasítás, nem kell újabb papírokon keresgélni és biztosan látni fogod – nem megy a kukába a manual anélkül, hogy tudomást vennél róla
a csomagolás segít összeszerelni a lámpát – megtartja függőlegesben a nehéz talpat amíg te rögzíted benne a rudat
a tápkábelt takaró kartonok szakítás nélkül, egyben lehúzhatóak a vezetékekről
ugyanígy tépés nélkül bontható le a lámpatestet védő csomagolás is
…és akkor el is érkeztünk a britek által kreált brutális méretű villásdugóig. Ahogy Pappito mondja:
egy ötös hosszabító akkora mint egy pianínó
Kétségtelenül a briteké a legeslegnagyobb vadállat villásdugó – de nem ok nélkül. Mutatom:
Szóval Tom Scott videójából az alábbiakat tudhatjuk meg a brit dugóról:
a villásdugóban van egy beépített biztosíték
a föld tüske azért hosszabb, mint a többi, mert az nyitja a delejt tartalmazó lyukakat védő reteszt
a fázist továbbító tüskék töve azért műanyag, mert így félig kihúzott dugónál nem férsz hozzá a fázist tartalmazó részhez
a földvezetéket azért hagyjuk hosszabbra a dugóban, mert ha meg is tépjük a kábelt és így leszakad a fázisos ér, a földvezeték szakadhat el utoljára
a fázisvezeték azért barna, mert ilyen színű lesz a gatyád, amikor hozzáérsz, ha áram alatt van 🙂
Végül Tomtól megtudjuk azt is, hogy a tepsi méretű dugóban van azért egy borzalmas tervezési hiba: minden alkalommal tüskékkel felfele esik a talajra és nem annyira jó rálépni. És ebből már gurult is tovább a chat.
Egy csomó cég nekiállt ugyanis a brutál méretű brit dugón mindenféle innovatív megoldásokkal segíteni.
A Mu One pl. elforgatva összehajtja a dugót – viszont a föld tüskéből kispórolják a fémet:
A Flip nevű crowdfunding cucc ugyanezt csinálta – ők másképp hajtogattak, de a fém föld tüske itt is kimaradt:
Az Apple is gondolkodott a problémán és úgy tűnik, anno nekik sikerült megoldani, hogy a dugó összehajtható legyen és a földtüske is megmaradjon fémnek:
Sajnos ez a fajta innovatív szemlélet kihalni látszik az Apple-ből és velük együtt számos más vállalatból is.
A poszt címét adó “can’t innovate anymore my ass!” mondat Phil Schillertől, az Apple marketing igazgatójától származik az Apple 2013 szeptember 8-án tartott keynote-járól, amikor a cég bemutatta az új “kiskuka” Mac Pro-t:
A kis kompakt vadállat tényleg csodálatos szerkezet – leszámítva, hogy
borzasztó a vezetékezése
a mozdításra világítva megjelenő csatlakozó piktogrammok csak parasztvakításnak jók, ugyanis az épp csak a fekete gépház fekete csatlakozóit nem világítja meg
a Thunderbolt 2 csatlakozók instabilak
a 3×2 db Thunderbolt pár párosítása nincs jelölve a csatlakozók helyén
amikor beporosodik, azt csinálja, hogy a ventillátort feltekeri 100%-ra, a CPU órajelét leveszi a minimumra és az Apple Hardware Test a “There may be an issue with the System Management Controller. Reference code: PFM006” szöveggel képes megijeszteni ahelyett, hogy azt mondaná: mi lenne, ha kifújnád belőlem a port, bébi?
Szóval tényleg, hova lett ez a minden részlettel törődés, Apple?
Szerencsére néha jön egy Min-Kyu Choi és megmutatja, hogy hogyan is lehetne másképpen:
Preface: Soha nem szoktam ilyen “vallási” témáról írni, a jelenlegi poszt csak azért születik, mert még sehol nem olvastam a sajátommal egyező véleményt.
A múlt héten az Apple frissítette a MacBook Pro palettát, melyen a legkisebb, 13″-os gépük 2 db, míg a többi 4 db USB C csatlakozót kapott (a 3.5″-os Jack lyuk mellett). Az USB C új szabvány, kevés még az USB C portra direktben rádugható eszköz – a szabvány váltás miatt a korábbi kütyükhöz mind adapterre van szükség, ha azokat az új gépünkkel használnák. Lassan annyi dongle kapható Apple termékekhez, hogy azokkal fontot lehet rajzolni:
image source: @andy23 Twitter
Én jelenleg egy mid-2012-es, első generációs minimal config MacBook Pro-t használok, amin a MagSafe tápcsatlakozón és a 3.5″-es jack lyukon túl 2 db Thunderbolt, 2 db USB 3, 1 db HDMI és egy normál SD kártya bemenet található. Ennek ellenére minden nap az alábbi szettel megyek terepre:
A fenti kép kicsit gonosz, mert a két jobb oldali dongle nélkül is túlélek melóban, azok csak azért vannak velem, mert egy tasakban tartom az összes donglét plusz minden drótot és ezek egyszerre jönnek velem, akár melóba megyek, akár víz alá.
A fotón balról jobbra az alábbi játékszerek láthatóak:
analog VGA – DisplayPort: ez akkor kell, ha olyan meeting roomban akarsz prezentálni, ahol a projektoron csak analog VGA van, illetve a mennyezetről csak azt vezeti ki drót a gépedig (amerre én járok, ott az esetek >70%-a ilyen)
DVI – DisplayPort: arra az esetre, ha (csak) digitális videojelet fogadó DVI port lenne a projektoron, vagy esetleg ilyet tudó monitor van a pool asztalon, mert ugye ha van digitális video in, akkor mégsem vagyunk állatok, hogy analógot használjunk
USB – Ethernet: ha nincs WiFi, vagy van, de az enterprise IT nem ad hozzáférést (bizony, ilyen simán létezik). Ez csak 10/100 mbps, van belőle gigabites Thunderbolt verzió is, de az a containerben hajózik éppen.
USB + Lightning – Lightning: iPadhez, ha tápot is adnál neki meg fotót/videót is töltenél fel rá egyszerre (búvározós szituációban nagyon hasznos tud lenni).
USB – Lightning: ez ugyanarra jó, mint az előző – USB connectiont ad iOS eszközhöz. A végén lógó kék infrás DiveMate Fusion IR nevű bigyó egy gateway az iOS-es DiveMate app és az IR protokollt beszélő búvárcomputerek közé.
Szóval nálam ezekből 3 mindenképpen ott van. Ha most gépet váltanék, mind a három dongle helyett újra lenne szükség, plusz nagy eséllyel beszereznék:
egy HDMI – USB C donglét, hogy ha csak HDMI van terepen, akkor azt tudjam használni
egy USB – USB C donglét, hogy amíg ki nem kopik nálam minden USB, addig tudjam őket használni az új géppel
egy Thunderbolt 1/2 – USB C donglét vagy jobb esetben egy rövid Thunderbolt 1/2 – USB C kábelt, hogy a külső Seagate GoFlex dokkomat se kelljen kidobni
Ha 50 USD / dongle átlagárral számolunk, akkor ez 300 USD plusz költséget jelent.
Nekem nem azzal van problémám, hogy egy szabvány kikopik és az Apple veszi a bátorságot, hogy kidobja. Sokkal inkább az zavar, hogy a leglojálisabb, Pro gépeket használó vásárlóival sem kegyes annyira, hogy az új szabványra való első teljes átálláskor mellékelne egy váltást megkönnyítő dongle packot.
Számoljunk egy kicsit. A cég egy év alatt cirka 2.5 millió notebookot ad el és mondjuk vegyünk másfél éves gépfrissítési ciklust alapul. Tegyük fel, hogy a Pro usernek egyféle régi szabványú video out és egy obsolete USB port hiányzik veszettül.
Ha úgy állnának oda a pódiumra, hogy az új szabvány bevezetésekor ott van az új 1st gen gépek dobozában a 2 extra dongle (ami jelen kalkulációban 2.5 * 1.5 * 2 = 7.5 millió drótot jelent), akkor akár az is lehet, hogy kevésbé lenne keserű a szoftver fejlesztésből élő Apple notebook userek szájíze. Akár akkor is, ha 2 dongle árával megemelnék a termékek árát, annak ellenére, hogy az évi 200+ milliárd USD bevétel lehet, hogy elbírná a ~4 millió Pro user felé gyakorolt gesztust.
PS.: ez a poszt pusztán arról szólt, hogy nem szeretem, hogy a világ legtöbb tech pénzét termelő vállalata nem empatikus a lojális Pro vevőivel szemben. Ezért aztán arról commentben is kár beszélnünk, hogy:
túl kevés az új gépeken a port, úgyhogy még USB C elosztó / docking station / bármi más is kéne
nem tudom hozzádugni az új iPhone 7-et sem az új MacBook Pro-khoz
miért nem fért el legalább egy microSD slot a házban (holott ezért én is ölnék)
miért megy a vékonyítás hiszti ahelyett, hogy még akkut kapnánk
Preface
2012 márciusában lecseréltük a hagyományos kazánt kondenzációsra és ha már lúd legyen kövér alapon telepítettünk mellé 5 m² váklumcsöves napkollektort is a hozzá való köcölékekkel (hőtároló puffer, hőcserélő, frissvíz modul, vezérlés, etc.) egyetemben. A választás némi kutatás után a Vaillant termékére esett.
2016 augusztus közepén egy meleg nyári napon forró etilénglikol szaga áradt a kazánházból. Elég volt egy pillantás a szabályzóra, hogy észrevegyük: a kinti hőség ellenére a kollektorokból egy csepp meleget sem szed le a rendszer. Ráadásul ekkor tűnt csak fel, hogy a baj már 2016 júniusában bekövetkezett, csak akkor nem vettük észre.
Melegcsináló HOWTO
Mielőtt a lényegre térnék, muszáj dióhéjban ideMórickázom, hogy működik a fűtésünk:
Gondolom rájössz magadtól, de azért: a rajzon a zöld az áramlási irányokat jelöli, a piros a meleg közeget, a kék a hideget.
Az 1. napkollektoroktól a 2. szivattyú behúzza a hőszállító etilén-glikolt a 3. hőcserélőbe, aki a glikol melegét beletolja a 4. puffertartályba. Ha a háznak melegre van szüksége, akkor az 5. hőcserélővel a 6. szivattyú csinál a csapvízből meleget, vagy a 7. szivattyú a fűtési körökben levő folyadékokra melegít rá egy kicsit. Az egészhez persze csatlakozik még egy kazán is, de azzal most semmi dolgunk, úgyhogy ezért lehagytam a Mórickáról.
A solar körön a 3. hőcserélő után van egy nyomásmérővel ellátott biztonsági szelep, amiből egy hosszú rézcső megy be egy nyitott puffertartályba. Erre azért van szükség, hogy ha valami hiba folytán a nyomás alatt levő solar kör belső nyomása elérné az 5 bar-t, akkor ez a biztonsági szelep egyszerűen leengedi a glikolt ahelyett, hogy hagyná felrobbanni a csöveket.
Nyomozás v1.0
Az augusztus közepén detektált problémát a szerelő úgy korrigálta, hogy újratöltötte a glikolt a nyomás alatt üzemelő rendszerben. A szakember arra tippelt, hogy valószínűleg hosszabb ideig nem voltunk otthon, így nem volt hőelvétel a pufferből és a termelődött meleget a vezérlés már nem tudta hova rakni, így ennek megfelelően a túlmelegedő glikol nyomása elérte az 5 bar-t, a biztonsági szelep leeresztett és onnantól nem volt ami lehozza a meleget a tetőről.
Ezt el is fogadtam, viszont nagyon nem hagyott nyugodni, hogy a problémáról a rendszer semmiféle módon nem tájékoztat. A dolgot úgy veszed észre, hogy a kinti hőség ellenére azt látod a vezérlő kijelzőin, hogy aznap semmi hőt nem termelt a solar kör, illetve a hosszabb időtartamú kiesés is megfigyelhető egy buta havi bontású oszlopdiagrammon.
Nekem ez kevés. Én tudni akarom, hogy pontosan mi történik a solar körben, illetve elektronikusan akarom detektálni azt, amikor ismét előáll a probléma és erről push notificationt akarok küldeni a fiúknak, akik majd riasztják a szervizest. Persze az igazi az lenne, ha a solar kör nem hibázna, ám mint pár óra telefonálgatás után megtudtam, erre a nyomás alatt levő solar rendszerek nem alkalmasak, csak a mostanában gyártott, önmagukat leereszteni és újratölteni képes kollektoros installációk. A sajátom természetesen ezekkel nem kompatibilis.
Azt találtam ki, hogy a glikolt szállító csőre hőcserélő bemeneténél és a biztonsági szelepnél is teszek fel egy-egy PT-1000-es hőmérőt, 10 percenként mérek velük egyet és a mért értékeket naplózom egy sql táblába. Ezen felül azt gondoltam, hogy talán jó indikátor lesz a meghibásodásra, ha a bizontsági szelepnél mért hőmérséklet elér egy határértéket (70 ℃-ra saccoltam), aminek hatására már küldhetem is a figyelmeztetést a gyerekeknek.
Felszereltem a hőmérőket, beállítottam a homeaut serverben a naplózást, megcsináltam a vizualizáló interfészt, körbeteszteltem szépen mindent és úgy gondoltam kész vagyok, de persze tévedtem.
A következő meghibásodás kb. 2 héttel az előző hiba kijavítása után következett be. Sajnos a biztonsági szelep utáni hőmérséklet teszt nem bizonyult hatásosnak: a cső nem melegedett 45 ℃ fölé. Ennek ellenére a hőmérő naplózás nem bizonyult hiábavalónak – mindjárt meg is mutatom! A biztonsági szelepnél levő hőmérővel most nem foglalkozunk, elég tanulságos lesz a solar kör hőcserélőjének bemeneti hőmérséklete.
Az első grafikonon azt látod, amikor a rendszer normálisan működik két egymást követő, kb. egyformán meleg napon:
Ezen pedig jól látszik, hogy a 2. napon 9:30 tájban pusztul meg ismét a rendszer:
Két egymást követő kb. egyforma napon a normál működést tanulmányozva nagyon jól látszik, hogy mi történik a rendszerben:
6:10: az éjszaka után beindul a solar szivattyú. Az ezt követő 10 percben ~10 ℃-t esik a hőmérséklet, mivel az éjszaka során meghűlt a kollektorban levő glikol és a szivattyú épp ezt a hidegebb folyadékot hozza le a hőcserélőbe.
A kollektor és a hőcserélő közti csőszakasz valamint a padlástér is vastagon szigetelt, ezért abban csak nagyon lassan hűl ki a hőszállító folyadék – ez láthatod az éjféltől kezdődő első szakaszon.
7:20: felkel a nap, a kollektorok elkezdik termelni a meleget.
15:00: a hőtermelés csúcsa, kb. ekkor süti optimális szögben a nap a kollektorokat. Innentől kezdve lassan csökken a glikol hőmérséklete, de még mindig van bőven hőmermelés.
20:00: lemegy a nap, a hőmermelés megszűnik. A hőtároló pufferben már legalább 60 ℃ hőmérsékletű víz van, így az ennél hűvösebb glikolból a hőcserélő már nem vesz el meleget. A görbe simulása egyenletesebbé válik, ami azt is jelzi, hogy a szivattyú már nem keringtet, a csőben levő hőszállító folyadék magától hűl le lassan.
Ha ránézel a 2. ábrára, akkor arról a fentiek alapján a meghibásodás napján (=kék diagram) ugyanígy leolvasható a történet:
9:00: A lassan hűlő glikolt 6:10 helyett 9:00-kor mozdítja meg a keringtető szivattyú. A hőcserélő visszahűlése jóval kevesebb ideig tart, mivel a kollektor ilyenkor már baromi meleg.
9:30: a hőmérséklet ezerrel emelkedik.
9:50: az utolsó mért meleg érték – a nyomás alatt levő csőrendszer itt éri el az 5 bar határértéket, a biztonsági szelep leereszti a glikolt. Innentől már csak a lassú kihűlés marad, mivel nincs hőszállító közeg.
A fentieket megmutattam a szerelőnek, aki a rendszert ismét átnézve arra jutott, hogy a hőcserélő szivattyúja adta meg magát. Én továbbra is azt látom a diagrammokon, hogy az eltelt 2 hétben a szivattyú minden nap 6:10-kor indul, kivéve a meghibásodás napját, amikor 9:00-kor mozdította meg először a folyadékot. Szerintem inkább a vezérléssel nem stimmel valami.
A második hiba után szeptember 5-én a csöveket trisóval átmosták, a hibásnak gondolt szivattyút kicserélték, majd 2 nappal ezután a következőt rajzolta nekem reggelire a log:
A kék vonal megint azt mutatja, hogy a szivattyú egy órával később kapcsol. A vezérlésnek nincs internetkapcsolata, tehát nem tud az időjárásról, mindössze annyit ismer a környezetéből, hogy Magyarországra telepítették és hogy épp mennyi a pontos idő.
Nyomozás v2.0
A fentiek alapján azt feltételezem, hogy a rendszer hamarosan ismét megadja magát. A logok nekem már most is egyértelműek, viszont ettől lehetnének egy picit még precízebbek is, ezért a következő tuningot eszeltem ki:
A biztonsági szelepen levő hőmérő átkerül a hőcserélő kimeneti oldalára, így a két mért értékből jól látszik majd, hogy a puffer felvette-e a tetőről lehozott hőt.
A szivattyú tápellátására párhuzamosan rákötök egy 230 V AC-re kapcsoló relét, aminek a kapcsolt NO lábát odaadom egy digitális bemenetnek a homeaut buszon. Ezzel értesülni fogok arról, hogy mikor indult és mikor állt le a szivattyú.
Ha már tudom, hogy mikor megy a solar szivattyú, akkor elég lesz akkor megmérnem a két hőmérsékletet – illetve egész pontosan mondjuk 30 másodperccel a szivattyú indulása után, hogy biztosan a lehozott hőszállító folyadékot mérjem.
Amióta ern0vel összeraktuk a dataflow alapú homeaut servert, nincs az a probléma, aminek a megoldását ne lenne élvezetes implementálni homeaut oldalon egy kis dataflow script módosítással. Lényegében az egész terjengős posztot azért kellett végigrágnod, hogy meg tudjam mutatni neked, hogy csináltam!-)
A fizikai adatbuszról a fenti probléma megoldásához kétféle adatra van szükségünk: egy digitális bemenetére (amire a keringtető szivattyú tápjával vezérelt 230 V AC-s relét kötöm) és a PT-1000-es hőmérők által mért analóg értékekre. A digitális inputokat 100 msec-enként lekérdezem egyben, úgyhogy az már kész, viszont a házban levő 8 darab PT-1000-es hőmérőt csak 10 percenként kérdeztem le eddig, mert a többit bőven elég ilyen lépesközzel naplózni, a két solar hőmérő naplózását viszont a szivattyú bekapcsolásának kellene vezérelni mostantól. A dolog azért problémás, mert a 8 darab hőmérőből 4-et csak egyszerre tudok lekérdezni a Wago MODBUS interface-en. Szerencsére itt van a kezem alatt a dataflow nevű rágógumi, amit a végtelenségig lehet nyújtani – nézzük meg, hogy hogyan csinálom!
Dataflow gyorstalpaló
Ha tudod, mi az a dataflow, akkor menni fog az is, ami lejjebb következik – ha viszont nem, akkor ern0 barátom eldarálja neked elképesztő sebességgel 10 percben (amiből a második ~5 perc már csak a kérdésekre adott válasz):
ern0 közben feltöltötte youtube-ra a tavalyi hosszabb dataflow meetup videót is – hardcore rajongóknak kötelező ez is:
Megoldunk
Ezek után lássuk, hogy raktam mindezt össze:
Ha inkább a scriptet olvasnád, mint a vizualizált ábrát, az így néz ki (btw a fenti rajzot ern0 kódja generálja graphvizzel a lenti dataflow scriptből :)):
component Main {
implementation {
carpet log {
// create pulsars
p100ms: RTCPulsar
p100ms.freq = 100000
p1s: RTCPulsar
p1s.freq = 1000000
// create 10 min scheduler
p100ms.out >> sched10min.clock
sched10min: Scheduler
sched10min.mask := "schedule={mi=0,10,20,30,40,50 se=0}"
// feed Wago digital poll
p100ms.out >> wdp.digipoll
wdp: WagoPoll
wdp.digibase = 0
wdp.digipollsize = 96
wdp.anabase = 0
wdp.anapollsize = 4
wdp.serout >> s1.in
s1: Serial
s1.device := "wago_ip:502"
s1.out >> di4_1.serin
di4_1: WagoDigiIn
di4_1.base = 48
// feed Wago analog poll
p1s: RTCPulsar
p1s.freq = 1000000
p1s.out >> wap.anapoll
wap: WagoPoll
wap.anabase = 0
wap.anapollsize = 4
wap.serout >> s2.in
// Wago bus
s2: Serial
s2.device := "wago_ip:502"
// split Wago analog input msg
s2.out >> ai1.serin
ai1: WagoAnaIn
ai1.base = 0
ai1.size = 8 // 4 input, 2 byte/input
// store temps in Value components
ai1.out1 >> temp1.setvalue
ai1.out2 >> temp2.setvalue
ai1.out3 >> temp3.setvalue
ai1.out4 >> temp4.setvalue
temp1: Value
temp2: Value
temp3: Value
temp4: Value
// send measured temps to sql loggers from the first 3 thermometers
sched10min.out >> temp1.in
sched10min.out >> temp2.in
sched10min.out >> temp3.in
temp1.out >> sql1_1.in
temp2.out >> sql1_2.in
temp3.out >> sql1_3.in
temp4.out >> sql1_4.in
// define sql loggers for all 4 thermometers
sql1_1: Shell
sql1_1.command := "./log_temp.py r9_nagyhaz_nappali"
sql1_2: Shell
sql1_2.command := "./log_temp.py r9_solar_test"
sql1_3: Shell
sql1_3.command := "./log_temp.py r9_utca"
sql1_4: Shell
sql1_4.command := "./log_temp.py r9_napkollektor"
// di4_1.out1 = solar pump power state change
di4_1.out1 >> change4_1.value
change4_1: Change
change4_1.last = 0
change4_1.zero >> log_solar_pump.in = 0 // log pump OFF state
change4_1.nonzero >> log_solar_pump.in = 1 // log pump ON state
change4_1.nonzero >> d30s_4_1.in // log temp with delay after pump switched on
// log solar pump state
log_solar_pump: Shell
log_solar_pump.command := "./log_di.py r9_solar_pump"
// log thermometer wiuth a 30 sec delay
p100ms.out >> d30s_4_1.clock
d30s_4_1: Delay
d30s_4_1.delay = 300
d30s_4_1.out >> temp4.in // log temp with 30s delay after pump has started
}
}
}
Elmagyarázom a rajzot – a legjobb, ha kinyitod teljes méretben 🙂
Start
Kezdetben azt csináltam, hogy egy 10 perces scheduler (=sched10min) lökdöste meg az analog inputokat pollozó wap komponenst és az abból kiálló ai1 analóg poll értelmező meghívott négy darab, sql insertet elvégző scriptet (sql1_1..sql1_4), akik megcsinálták a naplózást. Ezzel az a baj, hogy a 4. hőmérőt csak akkor akarom naplózni, amikor a szivattyú beindul, a többi meg maradhat 10 percenként.
Flow detection
Első körben detektálni kellett a szivattyú indulását. Ehhez csak a solar vezérlőből a szivattyúnak adott 230 V AC tápra kell párhuzamosan rákötni egy 230 V AC által kapcsolt relét, aminek a másik végébe jön a 24 V DC kimenetünk, akit a buszon a di4_1 modul out1 lábára kötünk.
Nekem akkor kell naplóznom a solar folyadék hőmérsékletét, ha a szivattyú megindul (egész pontosan kicsivel utána), így a di4_1.out1 láb 0-ról 1-re történő állapotváltozása kell, hogy kiváltsa a naplózást. Az állapotváltozás detektálására ott van a change4_1 komponensünk, aminek a zero illetve nonzero lábain csak akkor jelenik meg trigger, ha a bemenetén az előző inputhoz képest más adat jelenik meg.
Logging
Innentől már nincs nehéz dolgunk, csak be kell kötni a change4_1.nonzero kimenetet a d30s_4_1 30 másodpercre állított delay komponensbe, akinek az out kimenetével indíthatjuk a naplózást.
Analog poll
Az analóg input olvasásán is változtatni kellett. Egyrészt a 10 perces kérések helyett másodpercenként kérdezzük le a modult (ezért bökdösi a p1s 1 másodperces Pulsar komponens a wap analóg input poll generátort a korábbi sched10min 10 perces trigger helyett), másrészt az ai1 analóg input választ feldolgozó komponens lábait a közvetlen naplózás helyett a temp1..temp4 Value komponensekbe kötögettem. A temp1..temp4 value komponensek tárolják a mért értékeket, a kimenetük indítja meg a bennük levő érték naplózását, amit az sql1_1..sql1_4 Shell komponensek végeznek el. A temp1..temp4 komponensekből az első hármat a sched10min 10 perces időzítő triggereli, míg a negyediket (amiben a solar folyadék hőmérsékletét tároljuk) a di4_1.out1 komponens kimeneten megjelenő 0->1 érték változás indítja.
Extras
Ha már egyszer detektálom a szivattyú indulását (és leállását is, hiszen a change4_1 komponens mindkét állapotváltozást megadja), akkor ezt is simán lehet naplózni – erre való a change4_1zero és nonzero lábaira kötött log_solar_pump komponens. Innentől a következő hibánál nincs vita, hogy mikor indította el a solar vezérlés a szivattyút.
Szummárium
Hétvégén megcsinálom a hardveres részt is, aztán még készül hozzá egy olyan diagram, ami a solar kör hőmérő által mért értékeket együtt mutatja a keringtető szivattyú állapotváltozásával és onnantól már kellőképpen felvegyverkezve várom a következő hibát.]]>
Tegnap jött szembe az index.hu cikke, amiben bemutatják, hogy hogyan loptak el nemrég egy kulcs nélküli nyitású Porsche Cayenne-t. Többször olvastam már hasonlót és minden egyes esetben az egekbe szökik tőle a vérnyomásom. Ez a poszt egyrészt segít megérteni, hogy miért, másrészt megpróbál egy kis kriptográfiai alapismeretet ültetni a fejedbe.
Egész pontosan attól leszek ideges, hogy látom, ahogy a sokmilliós autókba a gyártók még mindig képtelenek az autólopást valóban ellehetetlenítő technológiát beépíteni. Ha elolvastad az indexes cikket, abból kiderült, hogy a tolvajok lényegében lehallgatják az autó és a kulcs közötti kommunikációt, valamint a netről beszerzik a változó kódot léptető algoritmust és azzal meg egy korábban lehallgatott kulccsal az új kulcsot kiszámolva nyitják ki a kiszemelt járgányt.
Na de ha ez ilyen egyszerű, akkor miért nem lopják el az összes pénzed, amikor online bankolsz? Az interneten küldözgetsz mindenfélét, ott miért ne hallgatódzhatna a tolvaj és miért ne számoltathatná ki a következő e-bank belépésedhez szükséges kulcsot csak úgy, ahogy az indexes cikkben látott autótolvajok csinálták? Hát azért, mert az autógyártókkal ellentétben a bank nem _szarik_ a biztonságra és megfelelő azonosítási technikát használ!
Titkosítsunk
A kocsikulcs és az kocsi közti kommunikáció során a gonosz tolvaj egyrészt hallgatódzik, másrészt hozzáfér a kommunikációt végző protokollhoz (hiszen vette a neten a kínaiaktól egy szoftver formájában). Valahogy azt kell megoldanunk, hogy a tolvaj ne tudjon a kocsi által értelmezhető üzenetet gyártani, illetve amit lehallgat, azt se értse. Erre megoldás az asszimetrikus titkosítás.
Hogy könnyebben értsük a magyarázatot, nevezzük át a résztvevőket: legyen a kocsi Alice, a kocsikulcs Bob, a hallgatódzó tolvaj pedig Eve.
A titkosításhoz kulcsokra lesz szükségünk, mégpedig résztvevőnként két darabra, egy nyilvános és egy privát kulcsra (a két kulcs nem számítható ki egymásból). Ezekkel a kulcsokkal fogjuk az üzeneteket titkosítani, illetve visszafejteni. Matekozás nélkül fogadjuk el, hogy létezik olyan algoritmus, amely az üzenetet úgy kódolja az egyik kulccsal, hogy az ily módon kódolt üzenet csak a másik kulccsal fejthető vissza.
Ha tehát Alice nyilvános kulcsát odaadjuk Bobnak és Bob nyilvános kulcsát Alice-nak, akkor már meg is vagyunk:
Alice Bobnak szánt üzenetét a Bob nyilvános kulcsával kódolja, amit a Bob a saját privát kulcsával dekódol
Bob Alicenak szánt üzenetét Alice nyilvános kulcsával kódolja, amit Alice a saját privát kulcsával dekódol
Így, amennyiben egyik privát kulcs sem kerül Eve kezébe, hiába hallgatja le a kommunikációt, nem tudja dekódolni azt, hiába van a kódoló/dekódoló algoritmus a birtokában (nota bene: egy titkosító algoritmus erejét soha nem jelentheti az, hogy az algoritmus maga mennyire ismert). Mindez lerajzolva:
Forrás: Wikipedia
Hol kapható ez az extra?
Számomra a legmeglepőbb, hogy a fent leírt technológiát kínáló biztonságot egyetlen autógyártó sem kínálja, sem alapáron, sem extraként. Másfélmillióért vehetsz adaptív ledes fényszórókat, fizethetsz felárat azért, hogy az autód beparkoljon helyetted, de hogy asszimetrikus titkosítás védje az ajtózárad, arra valahogy nincs kipipálható opció az extralistán. 3rdparty megoldás szerencsére többféle is van: BLUE16, Cerbeos.]]>
Ha váltasz, az új alkalmazás által kezelt számlá(k)hoz az új mobil alkalmazás gyártja az OTP tokent az új mobilappon belüli használathoz is és a desktop Java applet azonosításához is. A régi app az OTP tokent netkapcsolat nélkül gyártotta, az új mobilappnál viszont kell a tokengyártáshoz az internetkapcsolat. Ez akkor jelenthet problémát, ha külföldön vagy egy desktop gép előtt és nem tudsz netet adni a mobilodnak.
Az alkalmazás csak a magán folyószámlák kezelését támogatja, céges bankszámlákat talán majd jövőre. Ha mindkettővel rendelkezel, akkor a céges számláid authentikációjához marad a korábban is élő token.
Amennyiben több magán folyószámla kezelését akarod megoldani az új mobil alkalmazásban és nem mindegyiknek te vagy az elsődleges tulajdonosa (=család egyéb számlái), úgy ezt csak úgy tudják elvégezni, hogy az aktiváció során a nem általad tulajdonolt számlákat a CIB24 telefonos azonosítóval authentikálod. Ha ez nem megy, akkor a saját számlá(i)d kerülnek bele az új mobilappba egész addig, amíg ezt az authentikációt el nem végzed.
Az új mobilapp aktiválásához szükség lesz a személyid számára és lejárati dátumára, illetve a bank által ismert személyes adataidra.
Hirtelen ennyi. Nekem sajna ez több szempontból nem felel még meg, úgyhogy maradok régi auth token user.]]>
Alfred Google Translate workflow-t, ám a Google egy ideje DDOS attacknak veszi a workflow ismétlődő lekérdezéseit és ez azt eredményezi, hogy viszonylag gyorsan kizár a szolgáltatásból egy teljes napra. Nem volt mese, más fordító megoldás után kellett nézni – így akadtam rá a dict.cc-re.
Innen már csak pár lépés volt Raphael Barondict.cc-hez írt Python kódja, onnan meg Thomas Hirsch Alfredre szabott workflow-ja.
Thomas megoldása sajna bedrótozta a workflowba, hogy az angol->német irányban fordítson, viszont a dict.cc angolról és németről számos más nyelvre képes fordítani, így csak egy picit kellett megpiszkálni a workflowt ahhoz, hogy angol<->magyar és angol<->lengyel irányokban is fordítson:
Újabb forrás->cél nyelv hozzáadásához csak újabb script filtert kell létrehozni:
amiben csak ezeket kell cserélgetned:
A workflow-t szedheted tőlem, vagy a github forkból.]]>