2016. december 1., csütörtök

Titkos Project 2. - Tápegység

Végre megérkezett a pici tápegység a LED-ekhez (és persze a project többi részéhez):


2016. november 19., szombat

Titkos Project 2.

A hét elején elkövetett panelek közül kettő a második titkos projectem-hez tartozik (volt első is: https://hackaday.io/project/7424-secret-project)
Ez ESP8266-on alapul:


Ahogy láthatod az ESP-07-et választottam hozzá, ami ott hányódott az alkatrészes dobozomban.
Megpróbáltam feléleszteni a processzor panelt:


Először feltöltöttem az arduino flash példaprogramot rá (ez megmondja a flash valódi méretét is). "Mőködött", de...
...az eredmény méretes bukta volt:


Az ESP-07-es modulokat az ESP8266 időszak hajnalán vettem, hogy játszak velük. Meg sem néztem a flash méretét akkoriban. 512K van benne (mint az ESP-01-ben). Az ESP-01-ben kicseréletm a flasht, de ezen van egy fém kupak. Ezért nem éri meg küzdeni vele.
Szerencsére van egy pár ESP-12E is itthon. Lefutottam a műhelybe:


Sokkal jobb:


És gyorsan rendeltem egy pár ESP-07S-t és ESP-12F-et.

2016. november 15., kedd

Elektronika - Újabb cuccok folyt...

A szombati panelek így állnak ma:


Lassan, nem ártana írnom is a dolgokról, nem csak fotózgatnom. :-)

2016. november 14., hétfő

Media Player

Most könnyes szemmel (egy túrót) elbúcsúzom, a Raspi/OSMC párostól.
Mától a Pine64/Android/Kodi cucc veszi át a helyét:


Okok: Gigabit Ethernet, Mali 400 - Ezekkel a Raspi 3 sem tud mit kezdeni.

Jó, jó tudom. Még valami dobozt kerítenem kell neki.

2016. november 12., szombat

Elektronika - Újabb cuccok készülnek

Dolgozom ezerrel:


Pofáraesés Windows Server 2016 módra

Ezt olvasom:

"Windows Server 2016 Install Windows Server 2016 and choose the Desktop Experience installation option. If a computer is running Windows Server 2016 Core mode and you want to install Exchange 2016 on it, you'll need to reinstall the operating system and choose the Desktop Experience installation option."

Ez most komoly?
Eddig a Core-t lehetett konvertálni: https://blogs.technet.microsoft.com/john_taylor/2013/01/08/converting-from-server-2012-core-install-to-full-gui/

Még jó, hogy nem is terveztem, hogy core-t telepítek az Exchange alá.

2016. november 11., péntek

Hogyan nyírjunk ki egy Exchange DAG-ot...

...annélkül, hogy akár az Exchange, akár a DNS, akár az AD konfighoz hozzányúlnánk?
Na? Valaki?
Nincs ötlet?
Pedig egyszerű:
Rakjunk fel a hálózatra egy OpenWRT alapú Wi-Fi AP-t.
Te hülye vagy, ettől meg miért döglene meg?
?
Mert csak. Megdöglik az, csak figyelj:
Az OpenWRT AP-n jó gazda módjára kikapcsoljuk a DHCP-t mert ugye nem kell.
És ennyi, de...
IPv6? Rémlik valami?
Nem?
Az OpenWRT mint jó és modern cucc rendelkezik IPv6-al.
Vajon válaszol-e az IPv6-os kérésekre? Hát persze.
Vajon hiredeti-e magát mint DNS szerver IPv6-on?
Jól látod!
Vajon az Exchange DAG Node kér-e magának címet, DNS-t IPv6-on?
Bizony, hogy kér.
És melyik lesz az elsődleges DNS szervere? A statikusan beállított IPv4-es, vagy a dinamikusan felszedett IPv6-os?
Bingó!
És vajon az OpenWRT DNS-e tud-e a másik subnet-en lévő, gyanútlanul IPv4-ező DAG node-ról?
Hát persze, hogy nem.
Vajon van-e DAG replikáció, ha a node-ok nem tudják feloldani egymás címét?

2016. október 14., péntek

ESP-01 műtét

Mostanában ESP8266 alapú projecteken dolgozom. Az első pillanattól kezdve meg akartam oldani a web-en keresztüli firmware upgrade-jét (OTA). A terv, hogy a böngészőből fel lehessen tölteni a fájlt az SPIFFS fájlrendszerbe (kész). Ott ellenőrizni lehessen az integritását (folyamatban). Ezek után fel lehessen upgrade-elni (kész). Ez a folyamat magától értetődően azt igényli, hogy a flash mérete legalább kétszerese legyen a bináris kódnak.
Az első működő projectem ~280K bináris lett. Ez azt jelenti, hogy az ESP-01 modul 512K flash-e nem elég.
Körülnéztem, hogy tudom-e növelni ezt. Ezt blog bejegyzést találtam:
http://tech.scargill.net/32mb-esp01/
Tetszik a flash chip cseréjének ötlete, de van néhány gondom a megvalósítással:


Úgy döntöttem, hogy keresek 150mil széles 4MByte (32Mbit) flash IC-t megbízható forrásból.
Megtaláltam. Ez a  Cypress (Spansion) S25FL132K0XMFI041 a TME-től: http://www.tme.eu/en/details/s25fl132k0xmfi041/fram-memories-integrated-circuits/cypress/
Ez többbe kerül ($0.75 darabja), de megbízhatónak tűnik és nincs lábhajlítgatás.
A csomag megjött a TME-től, így tegnap este megvolt az első műtét:


Az eredeti 512K Winbond chip-es a bal oldalon, a Spansion 4M chip-es a jobb oldalon.
Ha elindíjuk az Arduino IDE-t van benne egy CheckFlashConfig nevű példa amivel ellenőrizni lehet a flash méretét:


Az eredmény a soros monitoron látható.
Műtét előtt:

Műtét után:


Még náhány modul vár az operációra. :-)

2016. szeptember 26., hétfő

Hyper-V - logikai bukfenc

Eléggé régen használok Hyper-V-t mindenfelé.
Érdekes pofonba futottam bele.
A hétvégén hosszas, teljes áramszünet volt. A szüntementesek nyomokban sem bírnak ki ennyit, tehát mindent kikapcsolt a kolléga.
A visszaállás után hívott, hogy működnek ugyan a dolgok, de valami nem gömbölyű. A Hyper-V management gépről működik a Hyper-V manager, de a saját notebookjáról nem. Ez pedig eddig jó volt.
Ma hosszas szenvedés után rájöttem az okra:
Az ugyebár jó ideje megengedett, hogy virtualizáljuk a Domain Controllert, és a Hyper-V (még a cluster is) elinduljon DC nélkül.
A védelem érdekében ugyebár a Hyper-V hoston NEM KAPCSOLJUK KI a tűzfalat, csak beengedjük rajta ami kell (RDP, Ping, SMB)
Tehát a gép elindul.
Nincs DC, tehát a hálókártya melyik profilba kerül? A publicba
Mi a WinRM public profil alapbeállítása? lokális háló (máshonnan nem enged be)
Ki ellenőrzi, hogy megérkezett a DC tehát hálózati profilt kellene váltani? SENKI!!!

2016. július 23., szombat

Multiméter rémálom

Vettem egy 6.5 digites asztali multimétert az eBay-en még 2014 decemberében. Egy Schlumberger Solartron 7061-est:


Úgy éreztem, hogy jó ötlet.
Nem volt az.
A probléma gyökere a hiányzó mérőkábel. Kérdezheted, hogy mi a probléma vele. Bemegyek a boltba és veszek valami olcsó kínai mérőkábelt, vagy elköltök egy kissebb vagyont egy Fluke vagy Keysight kábelkészletre és megvagyok.
Sajnos ez nem ilyen egyszerű. A Schlumberger valami fura csatlakozót használt a szokásos banándugó helyett.
Ezt itt:


Azt mondhatod: Márpedig ilyen állat nincs. De van. Ott van a multiméterem elején.
Először is, megpróbáltam mérőkábelt szerezni a neten, az eBay-en, stb. Minden kísérletem kudarcba fulladt.
Ezután megpróbáltam kideríteni, hogy egyáltalán milyen csatlakozó ez. Valami internetes forrásban azt találtam, hogy ez mini XLR.
Vettem ebből párat:

Nem volt jó.
Következő próbálkozás: elolvasva különböző fórumbejegyzéseket megtaláltam a korrekt típust:
Fischer Connectors S 104 A053-130+
Körülnéztem, az egyetlen hely ahol találtam ilyet, egy számomra ismeretlen amerikai cég volt, HATVANÖT dollárért. Ezeknek elment az esze? Ez csak egy csatlakozó, könyörgöm!
Ezen felül még fizethetek szállítást, meg vámot. Nincs az az isten!
Rendben, menjünk tovább.
Felmentem az Alibabá-ra, majd később az Aliexpress-re, ahol találtam egy céget, amely gyártja ennek a Fischer Connectors termékvonalnak a klónját, de nem ezt a pontos lábkiosztást.
Írtam nekik, hogy tudnak-e ilyet csinálni:



Azt gondolom, nem hibás feltételezés a részemről, hogy sosem fognak ilyet gyértani nekem.
Ezen a ponton feladtam egy időre...

...az év elején felírtam a listámra mint megoldandó feladatot.
Visszamentem az amerikai oldalra ahol eredetileg megtaláltam. Náluk már nem volt készleten. :-(

Következő próbálkozás:
Írtam egy levelet a gyártónak, hogy vehetnék-e tőlük közvetlenül.
Átirányítottak a magyar forgalmazóhoz.
Néhány levélváltással megállapodtunk az árban.
A végén elfelejtettem válaszolni az utolsó kérdésre a számlázással kapcsolatban.
Néhány hónappal később újra eszembe jutott, de nem volt túl sok kedvem egy magyarázkodó levelet írni. Tehát elengedtem.

Utolsó próbálkozás:
A nyaralásom első napján (kb. 3 hete) jött egy hírlevél a Farnell-től, amelyben hírül adtátk, hogy felvették a Fischer Connectors termékeit a portfóliójukba.
Azonnal rákerestem, és IGEN, van náluk raktáron.
Amint hazaértünk, megrendeltem, megérkezett:



Mostmár csak csinálmon kell egy banán aljzatokkal ellátott dobozt, mérőzsinórt, akármit, hogy használni tudjam.

U.I.: Kérem valaki mondja meg, hogy ki az az idióta, aki szigeteletlen fém mérőcsatlakozót tervez egy nagyfeszültségre is használható multiméterre????

2016. április 14., csütörtök

Mesék a házautomatizálásról - ModulMánia

Ahogy tovább gondolkodtam, egyértelművé vált, hogy egy moduláris rendszert akarok csinálni. Valami hátlap egyenméretű modulokkal, a szenzorok, beavatkozó szervek, mikrovezérlő és a tápellátás különálló modulokon lesz.

Ennél még tovább mentem. Megterveztem a dobozt, a hátlapot és a modul méreteit. A modulok 5x5cm-es panelen kerülnek megvalósításra. Miért? Mert ez a méret olcsón (10$/10db) rendelhető a Kínai NYÁK üzemekből.



A tervezett modul csatlakozó tartalmaz egy SPI-t, egy I2C-t és nyolc GPIO-t. Ez 17 érintkező együtt a két tápsínnel (3.3V és 5V). A 17 érintkezős 0.1" osztású egysoros tüskesor elfér a panel 5cm-es élén.

A rendszerhez kitaláltam jó néhány modult, amiket meg akarok valósítani. A lista nem teljes és a modulok még változhatnak:
  • Relé - Egy csatornás relé modul
  • RCR - Az ugrókódos távirányító vevőjének a modulja
  • Hálózati érzékelő - A hálózati feszültség meglétének ellenőrzése, ezt terveztem a kapcsolókhoz
  • Hőmérséklet/páratartalom - AM2302 alapú modul (a szenzor maga, kívül is, belül is elhelyezhető)
  • Esp01 - ESP-01 alapú "agy" a modul kapcsolható két GPIO és egy I2C között
  • Esp07/12 + pcf8574 - ESP-07 vagy ESP-12 alapú modul I2C bővítővel
  • Esp12e/f - Kérdőjeles. Ez akkor hozható létre, ha a belső flash memória SPI portja könnyedén megosztható külső SPI eszközökkel - tesztelés szükséges
  • Arduino + nrl24l01+ - MySensors.org szenzor "agy"
  • Tápegység - 5V/3.3V képes táp, egy HLK-PM01 és egy 3.3V LDO vagy buck konverter alapon
  • Nrl24l01+ - Nordic kommunikációs modul - elsősorban a Beaglebone-hoz készül, hogy MySensors.org átjátszó lehessen belőle
  • Barométer
  • Busz bővítő
  • Teljesítmény mérő - Áramváltó alapú
  • Teljesítmény mérő - Hall elemes
  • Teljesítmény mérő - Digitális mérőóra impulzus számláló
  • Gázóra Hall szenzor
  • SSR Modul
  • GPIO Modul - Izolált I/O Modul, esetleg DC/DC konverterrel együtt.
Továbbá készül 4, 6, és 8 modulos hátlap. A hátlaphoz lesz egy plusz csatlakozó ami lehetővé teszi, hogy az egészet egy BeagleBone CAPE-hez csatlakoztassuk. Ez azt jelenti, hogy a moduláris rendszert a BBG alapú OpenHAB központhoz is fogom tudni használni.

Egy 3D nyomtatható, parametrikus doboz is készül.

Néhány panel terve már elkészült. Ugyan meg lehet rendelni a Kínai gyártótól, ugyanakkor minden terv idáig egyoldalas, ami lehetővé teszi, a könnyű házi gyártást.
A tervek nagyja (nem mind) kizárólag furatszerelt alkatrészeket használ, ami könnyebbé teszi az életet.

És így fog kinézni a modul és doboza. Első OpenSCAD-es animációm!


2016. április 12., kedd

Mesék a házautomatizálásról - Hálózati feszültség érzékelő

Nem, nem akarom a hálózati feszültséget mérni (még).
A garázsvilágítást akarom átalakítani, a lehető legkisebb átalakítással.
Mit jelent ez?
A lámpát két kapcsoló kapcsolja (egy a garázsban, egy a házban a garázs ajtaja mellett) van, alternatív konfigurációban. Meg akarom tartani annak a lehetőségét, hogy a lámpa változatlanul kapcsolható legyen a kapcsolókról. Nem vagyok villanyszerelő, nem igazán akarok hozzányúlni a kapcsolókhoz és a falban menő kábelekhez (amúgy is sok piszokkal járó munka). Szerencsére a lámpa mellett van folyamatos tápellátás is (nem csak ami a kapcsolókról jön)
A terv az, hogy a beavatkozó szervet rákötöm a folyamatos tápforrásra és érzékelem, hogy a kapcsolók be, vagy ki vannak kapcsolva. Ezt a jelet arra használom, hogy átkapcsoljam a lámpát és nem az aktuális státusza határozza meg a lámpa állapotát. Amikor átkapcsolom valamelyik kapcsolót (be -> ki, ki-> be), változik a lámpa státusza.
Az érzékeléshez szükségem van valami elektronikára. A hálózat, nem gyerekjáték, a megfelelő leválasztás kritikus.
A lehető legegyszerűbb áramkört szeretném megvalósítani:
Egy kapacitív tápegység (két kondi, két ellenállás, egy dióda és egy zener), ehhez jön még egy optocsatoló. Az egész lehet, vagy 300Ft.
It a rajz:

2016. április 11., hétfő

Mesék a házautomatizálásról - A fűtés csatlakoztatása

Ahogy korábban már említettem, van egy rakás Conrad (ELV) FHT80B termosztátom, rádióvezérelt radiátorszelepekkel, és van egy CUL v3.2-es eszközöm. Most megpróbálom ezeket az OpenHAB-hoz kötni.
Mielőtt nekiláttam ennek a projectnek felraktam azt a CUL firmware-t amit az OpenHAB-hoz javasoltak, innen:
http://culfw.de/culfw.html
Az összeköttetésről itt találhatók információk:
https://github.com/openhab/openhab/wiki/FS20-Binding
https://github.com/openhab/openhab/wiki/CUL-Binding

Rakjuk össze a "binding"-ot:
1. Másoljuk be a szükséges addon-okat a /opt/openhab/addons mappába:
org.openhab.io.transport.cul-1.8.1.jar
org.openhab.binding.fht-1.8.1.jar
Ha van más FS20-as eszközöd a fűtésvezérlésen felül akkor még erre is szükséged lehet:
org.openhab.binding.fs20-1.8.1.jar

2. Szerkeszd meg a konfigurációs állományt /opt/openhab/configurations/openhab.cfg. Add hozzá a végéhez ezeket:
fht:device=serial:/dev/ttyACM0
fht:baudrate=38400
fht:parity=0
fht:housecode=XXXX
A housecode szabadon választott. Egy négyjegyű hexadecimális szám. És feltétlenül szükséges. Ha nem adod meg, a kommunikáció nem fog elindulni, és erről egy büdös hangot sem szól, logol. Hibát csak akkor látsz a logban, ha debuc módba kapcsolod.
Ez a kód a CUL eszköz kódja lesz és semmi köze az FHT80b kódjaihoz. Továbbá, ha azt akarod, hogy a dolog működjön, bizonyosodj meg róla, hogy az FHT80b "CEnt" beállítása "nA"-ra van kapcsolva.

3. Akkor most létre kell hozni, néhány item-et az items fájlban az FHT80B-hez. Valahogy így:
Number fhtRoom1Desired "Desired-Temp. [%.1f °C]" { fht="housecode=552D;datapoint=DESIRED_TEMP" }
Number fhtRoom1Measured "Measured Temp. [%.1f °C]" { fht="housecode=552D;datapoint=MEASURED_TEMP" }
Number fhtRoom1Valve "Valve [%.1f %%]" { fht="housecode=552D;address=00;datapoint=VALVE" }
Switch fhtRoom1Battery "Battery [%s]" { fht="housecode=552D;datapoint=BATTERY" }
Contact fhtRoom1Window "Window [MAP(en.map):%s]" { fht="housecode=52FB;address=7B;datapoint=WINDOW" }
A housecode a fenti példában az FHT80B eszközé. Ki tudod olvasni az FHT80B-ből. A code1 az első, a code2 a második része. Az olvasott kódókat át kell alakítani hexára.

4. Most el kell helyezni az olvasott értékeket a sitemap-on:
Frame label="Heating"
{
 Setpoint item=fhtRoom1Desired minValue=6 maxValue=30 step=0.5 
 Text item=fhtRoom1Measured
 Text item=fhtRoom1Valve 
 Text item=fhtRoom1Battery
 Text item=fhtRoom1Window
}
Az eredmény valami ilyesmi:
Még egy megjegyzés: Légy türelmes. Az adatok begyűjtése lassú. Néhány adat, csak akkor fog megérkezni amikor változik. Tehát eltarthat jó néhány percig, akár órákig is amíg megkapod az adataid.

2016. április 10., vasárnap

Javítás: HP 3478A

A fóliakondenzátorok öngyógyulnak, mint tudjuk:
Igen, látom:

A HP 3478A multiméter RIFA hálózati szűrőkondenzátora

Mesék a házautomatizálásról - Lámpakapcsolgatás

Menjünk tovább. Ez csak egy kis kopipaszta programozás.
A kódot innen szedtem:
http://iot-playground.com/blog/2-uncategorised/40-esp8266-wifi-relay-switch-arduino-ide

Lecseréltem az SSID-t és a jelszót, rákötöttem egy 150 ohmos ellenállást, meg az első LED-et amit az alkatrészes dobozban találtam az ESP8266 megfelelő lábára. Letöltöttem a kódot, elindítottam a soros monitort a Visual Studio-ban:

Ha kapcsolódom a webszerverhez egy böngészőből, be és ki tudom kapcsolni a LED-et.

Akkor most integráljuk az OpenHAB-ba.
Nem csináltam mást, mint módosítottam a korábbi rule-okat. Először, csak hozzáadtam a http hívásokat a korábbi szabályokhoz, de ez nem volt kielégítő. A távirányítóról tudtam vezérelni a LED-et, de a böngészőből nem. Tehát kicsit jobban hozzányúltam.

Íme az eredmény:
import org.openhab.core.library.types.*
import org.openhab.core.persistence.*
import org.openhab.model.script.actions.*

rule "GarageLightRemote"
when
    Item KeeLoq_Remote_B changed from CLOSED to OPEN
then
    if(Garage_Light.state == ON)
    {
        sendCommand(Garage_Light, OFF)
    }
    else
    {
        sendCommand(Garage_Light, ON)
    }
end

rule "GarageLightOffAction"
when
    Item Garage_Light changed from ON to OFF
then
        sendHttpGetRequest("http://10.1.2.129/gpio/0")
end

rule "GarageLightOffAction"
when
    Item Garage_Light changed from OFF to ON
then
        sendHttpGetRequest("http://10.1.2.129/gpio/1") 
end
És az áramkör:

2016. április 9., szombat

Mesék a házautomatizálásról - ESP8266, Arduino, Visual Studio

Nem vagyok nagy barátja az Arduino ökoszisztémának. A hulladék fejlesztőkörnyezet, a normális debugger hiánya távol tartott tőle.
A másik oldalon, be kell vallanom, sokat fejlődött az utolsó találkozásunk óta, és egyre megkerülhetetlenebbnek tűnik.
Az OpenHAB rendszeremhez szükségem van távoli szenzorokra, beavatkozó szervekre. Nagyrészüket építeni (és nem venni) akarom. Körülnézve két könnyen használható megoldást találtam:
  • ESP8266 alapú WiFi modulok
  • MySensors.org NRF24L01+ és Arduino alapú mesh hálózat
Mindkettőt ki akarom próbálni. Miután nem igazán van arduino-m (van pár a szekrényben, de különböző gyártóktól, különböző nyűgökkel, és nem igazán illenek ebbe a projectbe), tehát az ESP8266-tal akarok először játszani.
Azt olvastam, hogy a LUA értelmező nem igazán jó nagyobb projektekhez, így eleve az Arduino környezetet választottam. Egyenlőre csak tanulom, tehát nem tudom, hova vezet.
Az első célom, hogy képes legyek GPIO-t kapcsolgatni az ESP8266-on HTTP REST API-n keresztül.
Ahogy feljebb, már jeleztem, kellően útálom az Arduino IDE-t. Korábban különböző problémákba futottam vele amikor a 3D nyomtató Marlin firmware-ét próbáltam konfigurálni. Később megtaláltam, hogy a megbízható Visual Studio-t (amit napi szinten használok a munkámban, különböző projectekhez) is használhatom, ezzel a kiegészítéssel:
http://www.visualmicro.com/
a feladatra.
Rakjuk össze a környezetet:

1. Telepítsük fel az Arduino IDE-t. Innen tölthető le: https://www.arduino.cc/download_handler.php?f=/arduino-1.6.8-windows.exe

2. Telepítsük fel a Visual Studio 2015-öt. Én a Professional kivitelt használom, de az ingyenes is megfelel. Innen tölthető le: https://go.microsoft.com/fwlink/?LinkId=615448&clcid=0x409
Bizonyosodjunk meg róla, hgy a C++ komponens telepítésre került.

3. Indítsuk el a Visual Studio-t. Menjünk a Tools/Extensions and Updates menübe. Válasszuk ki az Online pontot a baloldali panelen. Keressünk rá az Arduino-ra
Töltsük le az Arduino IDE for Visual Studio komponenes-t


Telepítsük fel és az utasításoknak megfelelően, indítsuk újra a gépet.

4. Az újraindítás után megjelenik az Arduino konfigurációja. Be kell állítanunk az Arduino IDE elérési útját és a az ESP8266 Board Manager URL-t:
http://arduino.esp8266.com/stable/package_esp8266com_index.json


Nyomjuk meg az OK gombot.

5. A menüsoron az Arduino board választó mellett kattintsunk a nagyító ikonra. Válasszuk ki a Manage Boards fület.
Nyissuk ki az ESP8266 pontot és jelöljük meg a 2.1.0-ás verziót.
A felugró ablakban nyomjunk OK-t a telepítéshez



Ezen a ponton egy kenmény hibába futottam. A gépem tartományi tag. A dolgaimat mezei felhasználóként futtatom, ami csökkentett jogokat jelent (természetesen van admin felhasználóm, de csak akkor használom, ha szükség van rá). Úgy tűnik, hogy a telepítő hibás. A profilkönyvtáram nevében van egy pont. A telepítő ezt átkonvertálta aláhúzásra bizonyos helyeken, és egy Access Denied hibát dobott - mert ugye a könyvtár nem létezett és létre sem tudta hozni.

Tehát létrehoztam a könyvtárat adminként, és adtam magamnak jogot rá. Ezután a telepítő lefutott, de az első fordításnál hibát kaptam. A hibaüzenet teljesen használhatatlannak bizonyult. Jó néhány próbálkozás, Process Monitorozás (Micosoft, korábban Sysinternals eszköz), bemásoltam a helyükre az aláhúzásos profil temp könyvtárában felejtett dolgokat. Mostmár működik, sok óra elvesztegetve.

6. Próbáljuk ki
Gyors tesztet akartam, tehát, csak létrehoztam egy demo projectet, a blink-et a Visual Studio listájáról.



Miután kiválasztottam a megfelelő board-ot (esetemben a NodeMCU v0.9-et) és soros portot, feltöltöttem a kódot és elkezdett működni.

Úgy tűnik az ESP8266 környezet kész egy bonyolultabb feladatra.

2016. április 6., szerda

Mesék a házautomatizálásról - Távirányító integráció

Ahhoz, hogy az ugrókódos távirányító működni tudjon az OpenHAB-bal, az első dolog, hogy a GPIO binding-ot engedélyezni kell. Egy egészen használható dokumentációt találunk az OpenHAB wikiben:

https://github.com/openhab/openhab/wiki/GPIO-Binding

Nagyjából azt követtem el, amit a doksi írt, de némi módosítés szükséges volt.

1. Telepítsük fel a natív JNA library-t:
apt-get install libjna-java

2. Módosítsuk a /opt/openhab/start.sh-t
Adjuk hozzá a java parancssori paraméterek listájához:
-Djna.boot.library.path=/usr/lib/jni

3. Módosítsuk a /etc/init.d/openhab fájlt.

Adjuk hozzá a DAEMON_ARGS paraméterek listájához:
-Djna.boot.library.path=/usr/lib/jni

és adjuk hozzá a GPIO unexport parancsokat a daemon leállási feladatokhoz:



4. A korábban letöltött distribution-1.8.1-addons.zip-ből (része az OpenHAB letöltéseknek) csomagoljuk ki a következő fájlokat:
     org.openhab.io.gpio
     org.openhab.binding.gpio

A /opt/openhab/addons könyvtárba

5. Indítsuk újra az OpenHAB-ot:

/etc/init.d/openhab restart

Mostmár az OpenHAB kész a GPIO kezelésére. Kell némi konfiguráció módosítás, hogy használni tudjuk.

6. Addjuk hozzá a szükséges elemeket.

A GPIO bemenetek Contact-okkal reprezentálhatóak az OpenHAB-ban. Tehát adjuk hozzá a  /opt/openhab/configurations/items könyvtár valamelyik fájljához (Én itt már kidobtam a demo konfigurációt, tehát nálam ez a saját házam item listája) a következőket:

Contact KeeLoq_Remote_A "Remote A [MAP(en.map:%s]" (<ID of your Group>, Windows) { gpio="pin:66"}
Contact KeeLoq_Remote_B "Remote B [MAP(en.map:%s]" (<ID of your Group>, Windows) { gpio="pin:67"}
Contact KeeLoq_Remote_C "Remote C [MAP(en.map:%s]" (<ID of your Group>, Windows) { gpio="pin:69"}
Contact KeeLoq_Remote_D "Remote D [MAP(en.map:%s]" (<ID of your Group>, Windows) { gpio="pin:68"}

Ha minden rendben van a következőt fogjuk látni:



És, ha megnyomjuk a távirányító valamelyik gombját a, a closed felirat open-re vált, majd vissza, ha elengedjük a gombot.

7. A világításhoz, ez nem lesz elég
Arra van szükségünk, hogy megtartsuk a státuszt, ahogy az be és kikapcsol.
Tehát, hozzádunk még egy Switch-et az items fájlhoz:

Switch Garage_Light "Garage Light" (<ID of your Group>, Lights)

Ez csak egy egyszerű kapcsoló, tehát, ha távirányítóról akarjuk vezérelni, még egy szabályt is létre kell hozni. Ezt a /opt/openhab/configurations/rules mappában lévő rules fájl szerkesztésével oldhatjuk meg:

rule "GarageLightToggle"
    when
        Item KeeLoq_Remote_B changed from CLOSED to OPEN
    then
        if(Garage_Light.state == ON)
        {
            sendCommand(Garage_Light, OFF)
        }
        else
        {
            sendCommand(Garage_Light, ON)
        }
end

Ezek után, ha megnyomjuk a B gombot a távirányítón, be és ki fogja kapcsolni a fenti switch elemet.
Ez még nincs hatással a fizikai lámpára. Ahhoz még gyártanom/vennem kell valami beavatkozó szervet.

2016. április 5., kedd

Postás

A postásunk a cégnél egy idióta.
 Ezt eddig is tudtam, de ma kiverte a biztosítékot.
Az egy dolog, hogy rugalmatlan. Az egy másik, hogy ha van egy csomag amit nem kell aláírni (ne tévedjünk, Kínai e-bay-es pár grammos cuccról beszélek), és van egy másik amit alá kell írni, akkor lazán lenn hagyja a portán a nem aláírós darabot és feljön az emeletre az aláíróssal.
A kommunikációja katasztrófa.
Ember!!! Én az ügyfél vagyok, te meg a szolgáltató. Az, hogy te a hivatal vagy én meg az alatvaló, 27 éve elmúlt!!! Ha én (általános alany, a polgárt értsd rajta) nem rendelek vackokat Kínából, nem adok fel levelet, nem veszek igénybe postai szolgáltatásokat akkor neked nem lesz munkád, pénzed. Fogd már fel!!!
Na szóval. Ma fel jött az emeletre (tudom mert rálátok a folyosóra), itt kószált, be nem csöngetett. Azt hittem nem hozzánk jött. Majd távozott.
Már rutinos vagyok, gondoltam valamit lerakott a portán. Hát le...
Csomagot is, meg CSOMAG ÉRTESÍTŐT.
Hát, hogy az a jó büdös...
Azért mert képtelen becsöngetni, kopogni, füstjeleket eresztgetni, vagy mit tudom én, holnap mehetek be a "nyolcablakvandeörüljhaegyetkinyitunk" postára.
Ha szólok, akkor most kirugják, vagy valaki elmagyarázza neki, hogy mi a dolga?
Kicseszni nem akarok vele, csak megkapni a cuccaim. Kézbe. LEGALÁBB AKKOR AMIKOR ITT VAGYOK!!!

2016. április 4., hétfő

Összevissza gondolatok - Akku monitor

Jött ma egy hírlevél a Maximtól.
Benne ez az új termék:
https://www.maximintegrated.com/en/products/power/battery-management/MAX17201.html

MAX17201, MAX17205, MAX17211, MAX17215: Functional Diagram

Akku monitor SHA-256-al. Lehetővé teszi a gyártóknak, hogy kizárják az utángyártott akkumulátorokat.
Ok, ezt a gyártók szeretik, mert szerintük:
- Biztosítani tudjuk, hogy a termék a gyártói specifikáció szerint működjön, hosszú távon.
Szerintem:
- Biztosítani tudjuk, az alapító tengerparti házát, a Ferrari-ját, a marketing/management vízfej költségeit.

Ez részemről eléggé ellenséges hozzáállás, de nézzünk egy példát:
Vettem egy Fluke PM6685-ös frekvenciamérőt. A szerkezet 1998-ban volt új. Az új ára sok ezer dollár lehetett (sajnos nem találtam meg az eredeti MSRP-t). Így 18 év után biztonsággal lejárt minden gyártói támogatás. A szerkezet akkumulátorról is működőképes. Az akku természetesen döglött benne (miután fel is puffadt, a műanyag tartóját is eltörte).
Volt benne két 6V/3Ah zselés aksi. Elmentem a Lomex-be vettem két újat, megragasztottam a tartót és működik.

Ugyanilyen kvalitású műszer ma:
A fenti chip az akkumulátorpackban.
Tíz évvel később (nem 18-cal): A műszert még az használja aki eredetileg megvette. Ilyesminek nem 3 év az elévülése mint egy notebooknak. Aksi döglött, támogatás lejárt, a tulaj kénytelen az egészet kidobni, mert még eladni sem tudja.

2016. március 30., szerda

Mesék a házautomatizálásról - Ugrókódos távirányító

[2016.04.16]: Amikor írtam ezt a cikket, nem vettem észre, hogy a cape manager slots fájlja a régi helyre mutat. Javítva.

Ha az autódban ülsz és be akarsz jutni a garázsodba, tudom, hogy nem divatos, de a leg kényelmesebb eszköz a kulcskarikádon lógó kicsi távirányító (valami az autoba integrált cucc jobb és divatosabb lenne, talán csinálok valami ilyesmit később).

Ahhoz, hogy távirányítani tudjam az OpenHAB-ot és rajta keresztül a garázskaput/világítást, vettem egy ilyen ugrókódos távirányítót az aliexpressen:

http://www.aliexpress.com/item/RF-Rolling-Code-Decoding-Receiver-Module-2-Transmitters-DC-5V-4CH-TTL-Output-Learning-Momentary-Toggle/32295201884.html



A tervem az, hogy a garázsvilágítás, a garázskapu és még néhány (miután két gombja marad, pontosan kettő) dolog távirányítására használom.
Először is felraktam egy breadboard-ra, bekapcsoltam, hogy kipróbáljam, működik-e.
Az első próbálkozásra tökéletesen működött, kitalálni, melyik csatorna melyik gombhoz tartozik, gyerekjáték volt.
Az egyetlen probléma a cuccal, hogy 5V-os logikai kimenetei vannak, én a BeagleBone Green-hez akarom kötni, aminek a GPIO portjai nem tolerálják az 5V-ot.
Úgy döntöttem, hogy a világ legyegyszerűbb szintillesztőjét fogom használni hozzá. Egy ellenállásosztót. Egy 39K-s és egy 68K-s ellenállás megoldoja a kérdést, multiméteren mérve.

A következő rész, a BeagleBone GPIO felkonfigurálása. Az OpenHAB a Linux GPIO Sysfs interfészt használja, ami nagyon egyszerű (https://www.kernel.org/doc/Documentation/gpio/sysfs.txt).

Először megpróbáltam adatot olvasni parancssorból. A vevő egy csatornáját rákötöttem a BBG 60-as GPIO (P9, 12-es érintkező) portra.

A konzolon a következő parancsokat szükséges kiadni:

echo '60' > /sys/class/gpio/export
echo 'in' > /sys/class/gpio/gpio60/direction

Ezek után az érték, ezzel a paranccsal olvasható:

cat /sys/class/gpio/gpio60/value

A parancsok jól működtek, de akár megnyomtam a gombot akár nem, mindíg 1-est kaptam vissza.

Megmérve a bemenetet, 1.6V-ot kaptam akkor is amikor a vevő kimenetén 0V volt. Ez azt jelenti, hogy a BBG bemenet tápra van húzva.

Ebből adódóan két lehetőségem maradt:

1. Kikapcsolom a felhúzó ellenállást valahogy
2. Az ellenállások helyett valami aktív szintillesztőt használok.

Az elsőt választottam.
Körülnézve tisztán kiderült, hogy a felhúzó ellenállás vezérlése nem része a Linux GPIO csomagnak. Sokat olvasva kiderült, hogy a BBG Cape Manager Overlay-eket használ ennek megoldására. Ez a múltban (korábbi kernel verziók) hol volt, hol nem volt. A 4.1.x-esre amit én használok, viszont már része a mainline kernelnek.

Itt van némi olvasnivaló:

https://github.com/jadonk/validation-scripts/blob/master/test-capemgr/README.md
http://www.thing-printer.com/cape-manager-is-back-baby/
http://www.valvers.com/embedded-linux/beaglebone-black/step04-gpio/

Az overlay repository (tanulhatsz belőle, de nem szükséeges ennek a feladatnak a megoldásához):
https://github.com/RobertCNelson/bb.org-overlays

A leghasználhatóbb dolog amit találtam ez a tool volt:

http://kilobaser.com/blog/2014-07-28-beaglebone-black-devicetreeoverlay-generator

Ez képes a szükséges overlayt előűllítani.

Tehát a 60-as GPIO felhúzóellenállásának a kikapcsolásához a következőkre van szükség::

1. Mentsük el a következő fájlt a /lib/firmware könyvtárba bspm_p9_12_2f-00A0.dts néven:


/*
 * This is a template-generated file from BoneScript
 */

/dts-v1/;
/plugin/;

/{
    compatible = "ti,beaglebone", "ti,beaglebone-black";
    part_number = "BS_PINMODE_P9_12_0x2f";

    exclusive-use =
        "P9.12",
        "gpio1_28";

    fragment@0 {
        target = <&am33xx_pinmux>;
        __overlay__ {
            bs_pinmode_P9_12_0x2f: pinmux_bs_pinmode_P9_12_0x2f {
                pinctrl-single,pins = <0x078 0x2f>;
            };
        };
    };

    fragment@1 {
        target = <&ocp>;
        __overlay__ {
            bs_pinmode_P9_12_0x2f_pinmux {
                compatible = "bone-pinmux-helper";
                status = "okay";
                pinctrl-names = "default";
                pinctrl-0 = <&bs_pinmode_P9_12_0x2f>;
            };
        };
    };
};

2. Fordítsuk le:
dtc -O dtb -o /lib/firmware/bspm_P9_12_2f-00A0.dtbo -b 0 -@ /lib/firmware/bspm_P9_12_2f-00A0.dts

3. Töltsük be:
echo bspm_P9_12_2f > /sys/devices/bone_capemgr.?/slots
echo bspm_P9_12_2f > /sys/devices/platform/bone_capemgr/slots

Ezután a felhúzóellenállás megszűnt létezni. A távirányító státusza olvasható lett.

Rendben, ez most működik egy csatornára, de mi van néggyel? Tudok négy overlay-t generálni, de hogyan kombinálom egy fájlba? Elég kevés infót találtam, mindaddig amíg rá nem akadtam erre az Adafruit dokumentációra:

https://learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree/device-tree-overlays

A doksi alapján sikeresen kombináltam a négy generált overlay-t. Végülis a P8 7-10 lábait használtam.

Az overlay (suf_keeloq-00A0.dts):

/*
 * SUF - 4-Channel Keyloq receiver cape
 */

/dts-v1/;
/plugin/;

/{
    compatible = "ti,beaglebone", "ti,beaglebone-black";
    part_number = "SUF-KEELOQ";

    exclusive-use =
        "P8.7",
        "P8.8",
        "P8.9",
        "P8.10",
        "mmc1_sdcd",
        "gpio2_3",
        "gpio2_5",
        "gpio2_4";

    fragment@0 {
        target = <&am33xx_pinmux>;
        __overlay__ {
            suf_keeloq_pins: pinmux_suf_keeloq_pins {
                pinctrl-single,pins = <
0x090 0x2f
0x094 0x2f
0x09c 0x2f
0x098 0x2f
>;
            };
        };
    };
    fragment@1 {
        target = <&ocp>;
        __overlay__ {
            suf_keeloq_pinmux {
                compatible = "bone-pinmux-helper";
                status = "okay";
                pinctrl-names = "default";
                pinctrl-0 = <&suf_keeloq_pins>;
            };
        };
    };
};

fordítás és betöltés:
dtc -O dtb -o /lib/firmware/suf_keeloq-00A0.dtbo -b 0 -@ /lib/firmware/suf_keeloq-00A0.dts 
echo suf_keeloq > /sys/devices/bone_capemgr.?/slots
echo suf_keeloq > /sys/devices/platform/bone_capemgr/slots

Ez már működik, csak jó lenne valahogy boot időben betölteni.
Ahhoz, hogy ezt elérjük, hozzá kell adnunk a /boot/uEnv.txt fájlhoz:

cape_enable=bone_capemgr.enable_partno=suf_keeloq

Következik: Integráció az OpenHAB-bal

SharePoint Sync - Sokadszor

Drága Microsoft!

Ezt egy picit már unom. Szerencsére cégesen megszabadultunk a SharePoint Sync-től. Kemény pénzért előfizettünk a DropBox-ra.
Én még próbálkozom, hogy a saját MAPS előfizetésemnél megoldjam ezt a kérdést. Kezdem feladni, ez egy használhatatlan bénázás.
Ma megint megpróbáltam szinkronizálni. A gépem, friss Windows 10, az összes frissítéssel, rajta az utolsó O365-ös Office az utolsó frissítéssel. A szinkronizálandó könyvtár az O365-ös SharePoint-ban.
Az eredmény:


És amikor ezen nagynehezen átvergődtem:


A szóban forgó könyvtár egy megemészthetetlen méretű, teljes 2.35GB-os valami.

Már nem vagyok mérges. Talán kicsit szomorú, már nem tudom, hogy sírjak, vagy nevessek.
Csak baráti jó tanács: Lassan itt lenne az ideje, ezt a bénázást befejezni.

Aláírás:
Gömöri Zoltán
EX-MVP, EX-MCITP, EX-MCSE

2016. március 28., hétfő

Mesék a házautomatizálásról - OpenHAB telepítés

Akkor itt most felrakom az OpenHAB-ot mint központi házvezérlőt.
Az OpenHAB egy java alapú rendszer, tehát telőször is szükségünk van egy Oracle Java-ra. Ahhoz, hogy ezt felrakjuk hozzá kell adnunk a PPA repository-ját.
Melleseleg: Tudom, hogy a sudo vudu alapvetően fontos, a biztonsághoz. Magam részéről a saját Windowsos gépemet egyszerű felhasználóként használom XP óta, amikor az UAC még tervként sem létezett.
De amikor valamit összerakok, akár Windows-on akár Linux-on és amit csinálok az tisztán adminisztratív dolog, azt adminként csinálom. Tehát az első dolog amit csinálok a linuxon, amikor jó néhány dolgot telepítenem kell, ezzel kezdem:

sudo su

Ezért a továbbiakban nem fogok minden sor elejére sudo-t írni.

1. Adjuk hozzá a dpkg-hez az Oracle Java PPA repository-ját és rakjuk fel:

apt-get install software-properties-common
add-apt-repository ppa:webupd8team/java apt-get update apt-get install oracle-java8-installe 

2. Töltsük le az OpenHAB fájljait. Ezekre lesz szükségünk:

3. Csomagoljuk ki a fájlokat és gyártsunk konfigurációt

mkdir /opt/openhab
unzip distribution-1.8.1-runtime.zip -d /opt/openhab/
unzip distribution-1.8.1-demo.zip -d /opt/openhab/
cp /opt/openhab/openhab_default.cfg /opt/openhab/openhab.cfg

4. Miután még mindíg sudo módban vagyunk el is indíthatjuk az OpenHAB-ot, hogy ellenőrizzük a funkcionalitását:

/opt/openhab/start.sh

Némi várakozás után megnézhetjük az eredményt egy böngészőben:

http://<ip cím>:8080/openhab.app?sitemap=demo


Rendben. A szerverünk működik, de még nem végeztünk. Itt áljunk meg egy pillanatra.

Először: talán észrevetted, hogy nem csináltam specifikus felhasználót az openhab-hoz. Ennek oka van.

Az Ubuntut nem beágyazott rendszerekhez tervezték. Ezért, nincs arra beépített megoldás (vagy én nem tudok róla), hogy a mezei felghasználó hozzáférjen a hardver GPIO portokhoz (ha te tudsz erre egyszerű megoldást, kérlek, ne tartsd meg magadnak). A következő részekben, használni akarom a GPIO-t. Ezek alapján az OpenHAB a root nevében fog futni.

Másodszor: Szükségünk van egy megoldásra, hogy az OpenHAB daemon-ként fusson. Tehát...

5. Töltsük le a daemon scriptet innen:

https://github.com/openhab/openhab/wiki/Samples-Tricks#how-to-configure-openhab-to-start-automatically-on-linux

Mentsük el az /etc/init.d mappába openhab néven.
Állítsuk be:

chmod a+x /etc/init.d/openhab
update-rc.d openhab defaults

Szerkesszük meg a kedvenc szövegszerkeszőnkkel. Valószínüleg csak a RUN_AS bejegyzést kell openhab-ról root-ra állítani.
Indítsuk el:

/etc/init.d/openhab start

Most újra ellenőrizheted a böngészőben, hogy megy-e, és a /var/log/openhab.log-ban nézhetjük meg, hogy van-e hiba.

2016. március 26., szombat

Mesék a házautomatizálásról - Irány a komfortzónám

Ok, kezdjük el:

Nem vagyok egy Linux guru. A piacon rengeteg különböző disztribució létezik, de nekem, csak az Ubuntuval és a Debiannal van némi tapasztalatom. Továbbá általában nem használok semmilyen linux GUI-t.
Tehát amikor belekezdek egy Linux alapú projectbe, az azt jelenti, hogy felrakok egy Ubuntut.
Miután úgy döntöttem, hogy ezt a projectet BeagleBone Green-re építem, fel kell raknom rá egy 14.14 LTS-t.
Az alap információ itt található: http://elinux.org/BeagleBoardUbuntu

1. Le kell tölteni a kész image-et innen: https://rcn-ee.com/rootfs/2016-02-11/flasher/BBB-eMMC-flasher-ubuntu-14.04.3-console-armhf-2016-02-11-2gb.img.xz
(ma a 16.04 már létezik, de én maradok a régebbinél, mert az stabilabbnak tűnik). Le kell tölteni továbbá az image író eszközt (Win32DiskImager):
És szükségünk van egy minimum 2GB-os uSD kártyára is.

2. Csomagoljuk ki az image-et egy mappába a gépen. A 7-Zip pl. alkalmas a feladatra. Telepítsük fel a Win32DiskImagert.

3. Írjuk ki az image tartalmát a uSD kártyára


4. Amikor az írás kész, rakjuk át a kártyát a Beaglebone-ba. Nyomjuk meg és tartsuk lenyomva a boot select gombot (a uSD foglalathoz legközelebb lévő gomb) miközben tápellátást adunk a panelnek. Egy rövid indulási fázis után a LEDek Knight Rider-est fognak játszani (Hmm, mindenki tudja még, hogy mi az a Knight Rider?). Várjuk meg amíg befejezi és az összes LED bekapcsol.

5 Dugjuk fel az eszközt az Ethernet hálózatra. Ha ki tudjuk deríteni a DHCP által adott címet, akkot a 6-8 pont opcionális. Csak indítsuk újra a panelt, a tápellátásának ki és bekapcsolásával.

6. Telepítsük fel a panel PC meghajtóját. A Windows meghajtó itt található:
64 bit: http://beagleboard.org/static/beaglebone/latest/Drivers/Windows/BONE_D64.exe
32 bit: http://beagleboard.org/static/beaglebone/latest/Drivers/Windows/BONE_DRV.exe
Ez NEM egy soros port emulátor, amint azt várnánk, hanem egy virtuális ethernet meghajtó. Egy SSH terminálra (pl. PuTTY) lesz szükségünk a csatlakozáshoz.

7. Csatlakoztassuk a BeagleBone-t a PC-hez. Ha már hozzá volt kötve, csak húzzuk ki az USB kábelt és dugjuk vissza. Amikor kihúztuk, vegyük ki a uSD kártyát is. A továbbiakban nem lesz rá szükségünk.
8. Ha lefuttatjuk az ipconfig-ot a gépen, egy új ethernet interface tűnik fel:


A címe 192.168.7.1. A Beaglebone a 192.168.7.2-es címen található. Csatlakozzunk az SSH terminálunkkal hozzá.

9. Ha nem használtuk az USB/Ethernetet a csatlakozáshoz, csak csatlakozzunk a DHCP-től kapott címmel. Az alapértelmezett felhasználó/jelszó páros: ubuntu/temppwd
Ha statikus címre van szükségünk, csak szerkesszük meg az /etc/network/interfaces fájlt.

10. Ha ellenőrizzük a DNS beállításainkat, azok valószínüleg nem működnek. A /etc/resov.conf szerkesztése nem oldja meg a problémát, miután a következő újraindításnál felülírásra kerül.
Szerkesszük meg a /etc/resolvconf/interface-order fájlt és rakjuk az eth* bejegyzést a lista tetejére. Ez korrgálja a DNS beállításokat.

11. Indítsuk újra a szerkezetet.

12. Telepítsük fel a frissítéseket:

apt-get update
apt-get upgrade

2016. március 25., péntek

Mesék a házautomatizálásról - Miért?

Miért ne?
Azóta tervezem ezt mióta elköltöztünk 2009-ben. Akartam valami ház automatizálást rögtön a kezdetektől. Van egy barátom aki mélyen benne van a KNX rendszerekben. Azt mondta, hogy a költség a ház kb. 10%-a. Nem akartam ennyit kifizetni, így egyszerűen dobtam az ötletet.
Természetesen az automatizálás megjelent a házban itt-ott, de integráció nélkül.
Volt néhány kísérletem az automatizálásra, de nem mentem ennél tovább.
Csak a gyűjtemény kedvéért:
- Vettem egy pár Conrad FHT80B termosztátot és a kapcsolódó szelepeket. Ezek működnek a házban ma, de "szigeteket" képeznek.
- Vettem és telepítettem egy páratartalom érzékelőt és kapcsolót (része a Conrad FS20 rendszernek) a páramentesítőhöz (a beépített vezérlő használhatatlannak bizonyult)
- Vettem egy számítógép interfészt és egy kód monitort az FS20 rendszerhez. Az interfész változatlanul a dobozában van. A kód monitort (vagy hívjuk debuggernek) használtam párszor
- Vettem egy CUL v3.2-t az FS20 rendszer vezérlésére, de ez is az egyik alkatrész dobozomban kallódott mostanáig.
- Terveztem és építettem egy pár hőmérőt, amit arra szántam, hogy egy későbbi termosztát project alapját képezze, aminek neki se kezdtem.
Ahogy látod máig semmi kb. sem történt.
Miért most?
Ahogy haladok az elektronikai projectjeimmel, néhány dolog felkeltette a párom érdeklődését. Ebből pedig született egy kérés.
A garázsban nem látunk semmit, ha nincs felkapcsolva a lámpa, de nem tudod kikapcsolni, miután beültél az autoba. Az eredmény: Ha lusta vagyok (ami néha megesik), a lámpa felkapcsolva marad.
Ezt meg kéne oldani.
Az egy egyszerű megoldás lenne, hogy lecseréljük a kapcsolót egy nyomógombra, hozzáteszünk egy időzítőt, de...
Én össze akarok hozni egy ház automatizálási rendszert. Ez egy jó kiindulópont. Tehát az egyszerű megoldás helyett, miért ne építsünk valami nagyot?

2016. február 8., hétfő

Leválasztótrafó

Az ok amiért elkezdtem dolgozni (a változatlanul befejezetlen) CNC Motor meghajtó projectemen, két ügyhöz köthető:
Amikor lecseréltem a 230W-os marómotort egy 400W-osra és az alulméretezett lineáris vackot egy 600W-os kapcsolóüzemű tápra, az utóbbi egyszerűen felrobbant, a védődióda hiánya miatt (az én hibám)
Amikor meg akartam javítani a fenti tápegységet, elkövettem egy második hibát. Elfelejtettem, hogy minden hálózatra kötött oszcilloszkóp le van földelve. Második nagy bumm, és a javítható tápegység véglegesen kimúlt.
Tehát elkezdtem dolgozni a CNC motor meghajtó projectemen és mellékesen megállapítottam, hogy mindenképp szükségem van egy leválasztótrafóra, hogy elkerüljem a hasonló baleseteket.
Rendeltem, vettem jónéhány alkatrészt hozzá - egy toroid trafót, dobozt, kapcsolókat, csatlakozókat és egy többfunkciós panelmétert, ami feszültséget, áramot, teljesítményt, meddő teljesítményt és cos fi-t is mér.
Az összes alkatrész ott vergődött a műhelyben, miután semmi kedvem sem volt, kivágni, kifúrni a szükséges lyukakat kézzel. Arra vártam, hogy befejezzem a CNC-t és elvégezze helyettem ezt a munkát.
Egy pár hete azon gondolkoztam, hogy tápegységeket kellene tesztelnem a házautomatizálási projectemhez. Ahogy elkészült a műterhelés, a leválasztó transzformátor is szükséges eszköznek tűnt.
Ma jobb helyzetben vagyok. A CNC-m ugyan továbbra sem működik, ellenben a 3D nyomtatómmal. Thehát, mi történik, ha lecserélem az aluminium elő- és hátlapot műanyagra, ahogy a műterhelés projectnél tettem.
Megtörtént.
Itt az eredmény:


2016. február 1., hétfő

Műterhelés

A következő nagy dolog amin dolgozni szeretnék a házvezérlés projectem (de csak miután befejeztem néhány aktuálisan futó dolgot mint a build szirénát).
Létezik jól bevált központi management - az OpenHAB. Vezérelni a dolgokat bárhonnan, szintén nem probléma (Webes, iOS-es, Androidos applikációk léteznek hozzá).
Távoli szenzorokat és beavatkozó szerveket építeni manapság szintén könnyű. Rengeteg ilyet lehet találni az interneten olyan olcsó IoT platformra alapozva, mint az ESP8266 modul. Ehhez szenzorokat, reléket, SSR-t illeszteni triviális. Megoldani a tápellátását a távoli szerkezeteknek, sokkal trükkösebb feladat, még akkor is, ha az elektromos hálózat rendelkezésre áll. A projectem elsődleges célja az energiamegtakarítás. Sok energia elpazarlása arra, hogy bizonyos eszközök fogyasztását mérjem, nagyon rossz ötlet.
Tehát mielőtt belekezdek a projectbe, szeretném megtalálni az elektromos hálózatra kötött szenzorok tápellátásának a leghatékonyabb módját (a hálózati táplálás nélküli szenzorok ügye egy külön kérdés, elemes táplálás, alternatív energiák, stb. - ezekkel később akarok foglalkozni). Egy rakás különböző tápegység felépítés létezik erre a célra. A követelmények:
- Annyira hatékony legyen, amennyire csak lehetséges
- Tudjun 200-250mA-t produkálni 3.3V-on (esetleg 5V-on) (az ESP8266 energiafogyasztása: http://bbs.espressif.com/viewtopic.php?t=133)
- Amennyire csak lehetséges, olcsó legyen (egy nagy adagot kell építenem belőle, tehát számít a költség)
- A hálózattól izolált működés nem követelmény. A hatékonyság sokkal fontosabb.
Ebben a pillanatban nem akarok végigmenni a lehetséges megoldásokon (Rezisztív, Kapacitív, Lineáris, leválasztott és nem leválasztott kapcsolóüzemű, stb.). Venni/építeni akarok néhány típust és tesztelni.
Ahhoz, hogy össze tudjam hasonlítani ezeket, feltétlenül szükségem van egy állandó áramú műterhelésre.
Először körülnéztem a különböző fórumokon, hogy megfelelőt találjak. Alapvetően kétféle eszközben gondolkoztam:
1. Valami olcsó darab, ami használható kis áramokhoz, és nem fáj félrerakni, ha veszek valami komolyabbat, ha szükségem van professzionális megoldásra.
2. Egy professzionális darab, amit később más projectekhez is tudok használni.
Az első kategóriában nem találtam semmit. Körülnéztem az ebay, aliexpress, tindie környékén, de amiket találtam, nem voltak alkalmasak a feladatra, vagy nem estek az első kategóriába.
A második kategóriában a Maynuo M971x szériát találtam:

Egész jókat írnak róla a neten, ugyanakkor a jelenlegi igényeim nem indokolnak egy $400-600 kiadást (model függően, szállítással, vámmal ennyire jön ki).
Tehát az a döntés, hogy építek egyet.
Az előbb azt írtam, hogy nem találtam megfelelő olcsó darabot. Ez igaz a már megépített modelekre, ugyanakkor a másik oldalon, találtam olyat amire építhetek. A re:load 2-t az Arachnid Labs-tól. http://www.arachnidlabs.com/blog/2013/02/05/introducing-re-load/
Ha van ilyen, akkor miért nem vettem meg?
Mert teljesen más követelményekhez tervezték. Az kisáramú működés, és a perciziós szabályozás nem volt követelmény, ugyanakkor a telepes táplálás igen.
Az én tervem:
- független, hálózati táplálás (ez esetben egy váltóáramú fali adaptert használtam - egy őskövület Draytek routerből maradt)
- belső 12V egyenáramú táp (a magasabb feszültségnek több oka van: műveleti erősítő választás, opcionális hűtőventilátor, normál gate feszültségű MOSFET használata, stb.)
- Lecserélem az áram mérésre használt ellenállást jóval nagyobb értékre (1 ohm). Ez javítja a jel/zaj arányt. A másik oldalom 2V feszültésgesés-t kapunk 2A terhelésnél, de 3.3V alatt nem akarom használni
- Changed the current feedback resistor to a much higher value. This decrease the noise and the OpAmp offset problems. On the other side I get 2V voltage drop at 2A load, and I don't want to use this for anything bellow 3.3V.
- Lecseréltem a MOSFET-et egy olcsó n csatornás darabra (olyanra amit a fiókban találtam)
- Megteremtettem a műveleti erősítő offset kompenzálásának a lehetőségét (egy 0.6V-os negatív táppal és némi trimmerpotencióméterrel)
- Hozzáadtam méréshatárváltást (0-200mA, 0-2A)
- Lecseréltem az egyfordulatú potenciómétert egy 10 fordulatúra.
Itt a végleges kapcsolási rajz:


BreadBoard-on megépítve:


A nyák terv:


Egy fémdobozt választottam a készülékhez, de nem akartam egy rakás lyukat fúrni az előlapra (a hátlap más kérdés, azon csak egy lyuk van), tehát terveztem egy 3D nyomtatható darabot.
Itt van az eredmény. Teljesen összeszerelve (minusz a teteje), bemérve, működik: