Ha megnyomom a gombot akkor kapcsolja fel- , ha még egyszer akkor kapcsolja le a hozzá rendelt fényforrást.
Azért gondolnám arduino-val vezérelni, mert ilyenkor átkötés nélkül, program kód módosítással meg tudom változtatni, hogy melyik kapcsoló mit kapcsoljon.
Szeretnék un. "pánik" gombot, ami a lakásban mindenhol felkapcsolja a villanyt, és ezeket majd szeretném mobilról is kapcsolgatni. Ez mellett pedig szeretnék előre programozott eseményeket is (mobilról), mint pl Filmnézés (ilyenkor a TV mögötti kis világítás be, Nappali össz. világítás ki és a konyha jelzőfény be), stb...
Ilyenek miatt gondoltam, hogy mikrokontrollerrel kapcsolok...
Vagy ezeket másképp szokták csinálni? Nyitott vagyok ha van jobb ötlet :)
Ja igen, nekem írtad, hogy csak ha az e-építési naplót lezárták utána ügyködhetek.... :)
Ez csak egy kis része az egésznek amit lerajzoltam, szándékozok még áramot, hőmérsékletet, páratartalmat is mérni.
Szeretnék még egy nagy (7") LCD-ta hova kíírom az aktuális fogyasztását a háznak (ez jobban motiválja az embert a fogyasztás csökkentésére, persze ésszerű határokon belül), ezzel együtt logolni fogok mindent egy adatbázisba...
Kapcsolók kérdéskör: megfelelő előkészítés mellett simán lehet, akár 20-30 méterről is kapcsolni valamit (kondenzátor, megfelelő felhúzóellenállás, dióda és meg van oldva).
A kék optocsatolt relé (valójában valószínűleg egy breakout board) lényege pont az, hogy nem kell mögé semmi. A relé másik közkeletű, bár régies elnevezése a jelfogó, sokat elmond a működési elvéről: kis (vezérlő) jelre jelentős áramokat és/vagy feszültséget kapcsol. Izzót triakkal is meg lehet hajtani egyébként. A breakout lényege, hogy van rajta egy galvanikus leválasztás (optocsatoló), jó esetben még a nyák is úgy van kiképezve, hogy a gyenge-és az erősáramű rész elválik egymástól. Az optocsatoló után jön a nagyfeszültségű részt kapcsoló elem, ami nem egymás után értendő (kevés kivételtől eltekintve), hanem önmagában, csereszabatosan: triac, relé, szilárdtest-relé (SSR). Vagy ez, vagy az. Vagy amaz, ugye.
Erre korábban írtam már, nem tudom, hogy neked-e vagy másnak (és hogy itt-e és nem a FB csoportban). Ha a ház új, akkor nagy vonalakban mindent az UTÁN építhetsz be, hogy az e-építési naplót lezárták, előtte nem, mert ha bármi történik, a felelős építésvezetőt veszik elő, és ő egy élet egzisztenciáját kockáztatja. Nem lesz egyszerű érintésvédelmi szempontból kóser rendszert összehozni, mert fizikálisan és elektromosan is szeparálni kell az erős- és gyengeáramú (mikroáramú) részeket egymástól, megfelelő rögzítés, lángvédelem stb. alapértelmezett. Ha megnézel egy "valódi" okos konnektort, az nagyjából ezt tudja. Ha te építed utólag, akkor ami fontos: nulla, védővezető és fázis helyes kötése, minden 230 V-os rész vagy kettős érintésvédelemmel, vagy (végpontoknál) földelve. Tüskesor, hüvelysor felejtős, minden csavarozható vagy gyorsrögzítős sorkapocs legyen, az adatkábelek is. Adatra jó a telefonkábel + UTP csatlakozó, bár ezt az eszközoldalon annyira nem lesz egyszerű megvalósítani (sem a vezérlőpanel, sem a végpontok viszonylatában), bár nem lehetetlen. Én visszacsatolást is betennék (fénymennyiségmérés, árammérés), de ez az én fixa-ideám.
Csináltam egy elvi kapcsolási rajz részletet hogy hogyan is tervezném vezérelni a házamat. Elektronika órám már rég volt, úgyhogy kérlek nézzétek el nekem, ha valamit nem pontosan jelöltem.
Szóval azt szeretném kérdezni, hogy a kapcsoló felől hogyan érdemes kuldeni a jelet az Arduino MEGA-nak, mert gondolom egy egyszerű kapcsoloval egy pár méter után már nem a legstabilabb lenne a kapcsolás.
Másik kérdésem az lenne hogy a kék optocsatolt relé után érdemes e betenni egy másik fajta relét pl finder ssr, stb...
Végül a legfontosabb kérdés, hogy élet- és érintés védelmi szempontból nézve kell e még valami, ha nem csak izzókat hanem konnektorokat is szeretnék vezetelni.
#include <Arduino.h> #include <wdt.h> /* watchdog timer example code.
flashes LED three times quickly on boot up. Then goes thru a loop delaying an additional 250ms on each iteration. The LED is on during each delay. Once the delay is long enough, the WDT will reboot the MCU. */
const int onboardLED = 13;
void setup() {
int k;
// immediately disable watchdog timer so set will not get interrupted
wdt_disable();
// I often do serial i/o at startup to allow the user to make config changes of // various constants. This is often using fgets which will wait for user input. // any such 'slow' activity needs to be completed before enabling the watchdog timer.
// the following forces a pause before enabling WDT. This gives the IDE a chance to // call the bootloader in case something dumb happens during development and the WDT // resets the MCU too quickly. Once the code is solid, remove this.
delay(2L * 1000L);
// enable the watchdog timer. There are a finite number of timeouts allowed (see wdt.h). // Notes I have seen say it is unwise to go below 250ms as you may get the WDT stuck in a // loop rebooting. // The timeouts I'm most likely to use are: // WDTO_1S // WDTO_2S // WDTO_4S // WDTO_8S
wdt_enable(WDTO_4S);
// initialize the digital pin as an output. // Pin 13 has an LED connected on most Arduino boards:
pinMode(onboardLED, OUTPUT);
// at bootup, flash LED 3 times quick so I know the reboot has occurred.
for (k = 1; k <= 3; k = k + 1) { digitalWrite(onboardLED, HIGH); delay(250L); digitalWrite(onboardLED, LOW); delay(250L); } // delay a bit more so it is clear we are done with setup delay(750L); }
void loop() {
int k;
// this loop simply turns the LED on and then waits k*250ms. As k increases, the amount of time // increases. Until finally the watch dog timer doesn't get reset quickly enough. for (k = 1; k<= 10000; k = k + 1) { // at the top of this infinite loop, reset the watchdog timer wdt_reset(); digitalWrite(onboardLED, HIGH); delay(k*250L); digitalWrite(onboardLED, LOW); delay(250L); } }
Nem feltétlen matek, csak nem úgy gondolkodik a számokról, mint mi normál esetben. Ennek a lényege, hogy a törteket nem kerekíti, csak simán levágja a végüket (int típusú változó esetén).
Tegyük fel, hogy a naple változó értéke 10. A tombelem_max értéke így 90. i értéke 0 és 9 között növekszik egyesével, ennek megfelelően a tombelem változó értékei:
1, 1, 1, 4, 9, 16, 25, 36, 49, 64.
A map tehát szegény nem tehet mást, mint egy viszonylag szűk értelmezési tartományt tágít ki, ráadásul úgy, hogy a két vége nem is értelmezhető (a bemeneti oldal eleje 0, a kimenetié 1, a bemenet vége 64 (az elvi 90 helyett), a kimenetié 255). Ezzel a 65 és a 90 közötti tartományt (a teljes értelmezési tartomány majdnem harmadát) elveszted, a feny[9] változó értéke ennek megfelelően soha nem lesz nagyobb, mint 182 (ha jól számoltam), a tombelem fent vázolt problémája miatt pedig az alsó tartományban lesznek nehézségeid.
Én azt csinálnám, hogy a map() parancsot teljes egészében negálnám a történetből. Készítenék egy függvényt, aminek a bemeneti értéke a naple változó. Ezzel számolnék egy mértani sorozat szorzót visszafelé (milyen naple mínusz egyedik elemhez milyen szorzó szükséges ahhoz, hogy az érték a lehető legközelebb legyen 255-höz, de ne legyen több nála. A kezdeti érték 1 lenne, a többi értékek pedig először az 1, majd az előző érték szorzatai végig). A kapott adatokat betölteném a globális feny[] függvénybe (nyilván for ciklussal).
Aztán kicsit durvább és sok kísérletezés kell hozzá, de csinálni lehet egy olyan 255 elemű tömböt, amelyik az egyes értékekhez tartozó optimális pwm (analogWrite) értékeket tartalmazza, és ha végigmész a tömbön egyesével, lineárisnak tűnő fényességnövekedést tapasztalsz. Ha tudod, hogy hány lépésben kell világosítanod, csak azt kell kiszámolnod, hogy melyik elemeket kell lehívnod. Ehhez PROGMEM javasolt, mert bár 255 elem nem túlságosan nagy, és csak byte-ról van szó, a SRAM akkor is szűkösebb erőforrás, mint a flash.
Strukturálási javaslat: a tombelem_max = naple*(naple-1); sort a for() ciklus elé tedd, mert így minden körben lefut, és mivel naple értéke nem változik, ugyanazt a számítást végzed el többször.
For ciklus alatt feltöltött tömbömbe (ha az elemszám alacsony - 10 körüli (10-30 között változik)), akkor az első három indexel ellátott map-al generált szám azonos lesz. Erre van valami matek, vagy csak a nem túl elegáns if-es megoldással lehet megoldani (ahogy a 0-át zárom ki).
for (int i = 0; i < naple; i++) { tombelem = (i*i)-(2*i)+1; if (tombelem < 1) { tombelem = 1; } // i=1-nél jelentkező 0 elkerülése tombelem_max = naple*(naple-1); feny[i] = map (tombelem, 0, tombelem_max, 1, 255);}
Most karácsonyi leszerelés van, úgyhogy csak röviden.
A MOS-FET egy nagy teljesítményű kapcsolónak tekinthető, kb. mint egy relé, csak a működési elve teljesen más. Nem „állít elő” feszültséget. Nem tudom, hogy mit és hol mértél, de az biztos, hogy ami jelforma a FET-be bemegy, a karakterisztikájának megfelelően nagyjából az fog kijönni belőle. Most semmi FET-es kapcsolásom nincs összerakva mérhető formában, de ha lesz és nem felejtem el, akkor pár screenshotot küldök.
Köszi a kimerítő választ :) és bocs hogy csak kódrészletet adtam. Védelmemben annyit, hogy még készül és kicsit töredezett még a kód, bár igyekeztem kommentelni. Egyébként akvárium vezérlés lesz rengeteg beavatkozási lehetőséggel auto/manual módban. Igazán már csak ez a pwm-es játék a fényerővel és a tápadagoló pumpák vezérlése van hátra, meg sok teszt... (meg az amire még csak ez után gondolok).
A változókra természetesen figyeltem, így a legrosszabb esetben sem tudnak túlcsordulni. Egyetlen változóm sem vehet fel elméletben negatív értéket, az idő alapú int változóim (eltelt_percek, vil_be, stb) általában percben (x óra*60 + y perc) vannak meghatározva, vagy néha hasonló módon másodpercben. A "napfel" tényleg byte, értéke 1-59 között lehet, valójában percértékek és futás közben bármikor változtatható nextion HMI-ról. A nap_kep is a nextion felé megy, illetve a utolsó if-return-ben lévő lehatároló érték is a nextiontól jön, ami fölé nem mehet a a led fénye.
Még arra is figyeltem, hogy a változók se akadhassanak össze (pld ne előzhesse meg a kikapcsolás a bekapcsolást), küldjön hibajelet ha a user ilyet produkálna a sok állítgatással.
A progi mega-n fut és a globális változók 64%-ban vannak kihasználva, így még néhány elefér.
A javaslataid kipróbálom természetesen. Ezek szerint valamit elbaltáztam, amikor valós elemszám nélküli tömböt nem sikerült deklarálnom a setup-ban.
A próbálgatások alatt egyszer olyanba már belefutottam, hogy mem hiányra panaszkodva nem engedte indítani a serial monitort, csak reset után. Ez akkor ált elő, mikor folyamatos óravisszaállítás köztben a for alatti tömbfeltöltést próbálgattam. Lehet akkor sikerült feszegetnem a 8kB határait.
fenyfel[i] = map (n, 0, n_max, 1, 255);
fenyero = fenyfel[index];
analogWrite(napfeny, fenyero);
Az analogWrite függvény 255-nél ad 100%-ot. A led 0-100 közötti kitöltési tényezőjét ez az eredmény határozza meg, melyet a MOS-FET állít elő, jelen esetben "0"-12V-ot. Ezt jól megmagyaráztam magamnak, remélem jól okoskodom. :) Jól gondolom, hogy a MOS-FET-en az 1. tényezőhöz sem a 12V 1%-a tartozik, tehát az sem lineáris?
Egyébként a led kitöltési tényezőjének kiszámításához a for ciklusban először részarányosan osztást alkalmaztam, de úgy nagyon gyorsan elérte a látható max fényerőt. Ekkor váltottam négyzetre, de úgy tűnik, hogy ez sem a legmegfelelőbb, így gyúrok rajta kicsit...
Köszi a segítséget. Egyébként két éve egyszer már kóstolgattam ezt a világot, de akkor időhiány miatt gyorsan félretettem. Most, kb. két hónapja újra belemerültem, és elég sok időt rááldoztam az olvasásra, tanulásra. Az ötleteim téren hajlamos vagyok a saját fejem után menni, a járt utakat kerülöm, így sok kis kudarcból nagyobb élmény lesz... Volt olyan nap, hogy kb 12 óra "programozás" eredménye kb. 20 soros működő kódrészlet lett...
A kitöltési tényező egy százalékos (vagy tört százalékos) érték, 0-től 100-ig. 0-nál csak 0 van (egyáltalán nincs magas jelrészlet), 100-nál meg csak 1 van (csak magas jelrészlet van). A legtöbb led láthatóan nem lineáris. Az, hogy mennyire nem az, a pwm alap frekvenciája, a led árama és néhány egyéb paramétere határozza meg (mi az a küszöbfeszültség, amin az elektronok áramlása és így a fénygerjesztés létrejön és ehhez milyen hosszú fel- és lefutási idő tartozik). Másrészt, az emberi szem a fényesség-eltérést nem lineárisan, hanem logaritmikusan érzékeli még azonos fényviszonyok között is, ezért van, hogy néhány érték (pl. a csillagok fényességének meghatározásához használt magnitudó) sem lineáris skála, hanem logaritmikus. (A decibel is az egyébként.)
Általában 20 százalékos kitöltési tényezőig nagyon intenzív a fényesség emelkedése, 20 és 60 között mérsékelt, 60 és 80 között alig észlelhető és a legtöbb sima lednél 80 és 100 százalék között csak ritkán lehet érdemi fényességváltozást észrevenni (sokszor a ledek gyártási eltérései nagyobb fényerődifferenciát produkálnak). De ez szinte ledenként különbözik, nem hogy led típusonként.
Mátrixot/tömböt létrehozhatsz szabadon, előre nem meghatározott elemszámmal, ekkor a konkrét memóriafoglalás akkor történik, amikor a program fut. Ha a szoftvered hibás és/vagy nem számoltál utána, egykönnyen belefuthatsz olyan helyzetbe, hogy a rendelkezésedre álló memóriát egy sima for ciklus teleírja, és onnantól rossz esedben a kontrollernek is harangoztak. Márpedig olyan sok memóriával nem tudsz gazdálkodni, mert a SRAM Uno (és folyamodványai) esetén 2, Mega2560 esetén 8 kB.
A kóddal nekem több bajom is van.
-- nem látom a napfel változó deklarálását és a kezdeti értékét sem, emiatt,
-- az int signed, a byte unsigned, vagyis az int lehet negatív is, a byte nem. Ha a napfel jó esetben byte, akkor is gáz van, mert ha az értéke 181-et meghaladja, akkor az int n= i*i; és az int n_max = napfel * napfel; sorokban máris túlcsordultál. Az n változót nyugodtan definiálhatod globálisként, de lehetőleg valami értelmesebb névvel, mert így kb. fingja sincs az embernek, hogy mi az.
-- az int változó deklarálásra való, loopban, nem parancssor szinten (for ciklusban például) kerülendő a használata, mint minden változót deklaráló parancsnak.
-- a fenyfel[] tömböt a void setup()-ban is feltöltheted, feltéve, ha csak egyszer van rá szükség (ezt mondjuk a fals értékek elkerülése végett egyébként is érdemes megtenni). Ha változik az értéke futáson belül, akkor tedd ki külön függvénybe a feltöltést. Deklaráld globálisként a maximális elemszámra, és úgy töltsd fel, hogy lehetőleg a kiolvasást és a maximális érdemi elemszámot ugyanaz a változó (ez esetben a napfel) határozza meg. Nagy lesz a memóriafoglalásod, de kicsi lesz az esélye, hogy valami csúnyaságba belefutsz. Ha egyébként memóriaigényes a program és nincs változóra már memória (pláne ennyire), akkor csinálhatsz egy külön függvényben minden alkalommal egy számítást arra, hogy éppen mennyi a fenyero ideális értéke (ami egyébként a [napfel - (vil_be - eltelt_percek)] négyzetének map paranccsal való megfelelő redukálásának eredménye. (Gyk.: ha nem fut le túl sűrűn a program fényerőállítási része, akkor a tömb teljes egészében kihagyható és egy viszonylag komplikált számítással helyettesíthető).
-- az
n = map(n, 0, n_max, 1, 255);
így egy kissé erős. Tisztább, ha összehozod a következő sorral:
fenyfel[i] = map (n, 0, n_max, 1, 255);
-- az if-ben a return; számomra teljesen értelmezhetetlen.
Ahogy a kódot sikerült kisilabizálnom, nagyjából az történik, hogy egy tömböt feltöltesz egy gradációs görbe egyes értékeihez, ahol a sorszám az eltelt időt, az érték a világosságot szimbolizálja. A több értékeit ezután az eltelt idő föggvényében kiolvasod és ennek megfelelően hajtod meg a kimeneten lévő lámpát (PWM módszerrel).
Tudni kellene, hogy a napfel értéke milyen gyakorisággal változik (ha változik egyáltalán), illetve azt, hogy mi lehet a maximális értéke (ha byte, akkor 255). A tömböt a program elején deklaráljuk a lehető maximális értékre ( byte fenyfel[napfel]; ), de csak egyszer. index változó ugyanez. A vil_be és az eltelt_percek nevű változók típusát nem lenne ártalom tisztázni, mert ha az időt millis() alapon méred, akkor a byte egykönnyen bajos lehet, de adott esetben még az int is. (A millis() unsigned long típusú változó.) A (fenyertek) nem tudom miért van zárójelben. A va_napfel.setValue(1) sor honnan jön? A nap_kep = 61; pedig a legnagyobb gyönyörűség, amit programozó láthat, mert innentől fingja sincs, hogy a nap_kep mi a pörgettyűs kóchenger, és a 61-ről is csak annyit tudni, hogy a 42-nél pont 19-cel több. Hivatalos elnevezése "mágikus szám".
Dimmelhető 12V led izzót használok, mely már 90-es kitöltési tényező, cirka 10,4V körül full fénnyel világít, utána már látható fényerő emelkedés nincs.
A kitöltést csak 0-100 között használjam 1-255 helyett vagy van egyéb mód is a PWM jel és a led összehangolására? Vagy a ledem sz*r (ebay - adatlap ismeretlen)?
Az áttekintő poszt akár lehetne témaindító is .... tök jó!
Ehhez kapcsolódóan lenne egy kérdésem: a programomban egy olyan tömböt hozok létre, melynek elemszáma csak a loop-ban derül ki (változó adja), így előre nem tudom deklarálni (legalább is nekem úgy nem fordult le). A tömb feltöltését csak meghatározott feltételek esetén akarom végrehajtatni (ne fusson le mindig, csak adott eset teljesülésekor egyszer). Sajnos ez így nem megy, én erre nem találtam megoldást. A tömb feltöltésnek és a deklarálásnak azonos ciklusban kell lennie, másként hibát ad. Van erre megoldás?
A progarmrész egy adott időpontban a megadott időtartamban megadott jelszintig led fényerőt szabályoz. Sajnos csak úgy tudtam megoldani, hogy a kezdő és végső időpont között minden ciklusban lefut a tömb feltöltése is (teljesen felesklegesen).
A teljes kód már bőven 2000 sor fölött van, így csak a kérdéses részt szúrtam be. Ebben a formában működik, szépen teszi a dolgát... A kiperezett sorok szerint szeretném futtani, de akkor(ahogy írtam) a tömb elemei nem lesznek kiolvashatóak. Tud valaki segíteni? Prof?
// napkelte funkció (a világitás bekapcsolása előtt X percig) if ((eltelt_percek >= (vil_be-napfel)) && (eltelt_percek < vil_be)) { byte fenyfel[napfel]; byte index = 0; // if (szamolo == true) { // tömb feltöltése csak egyszer fut le for (int i = 0; i < napfel; i++) { // tömb feltöltése a percben meghatározott elemszámmal int n = i*i; // parabolikus legyen a számok felfutása int n_max = napfel*napfel; n = map(n, 0, n_max, 1, 255); fenyfel[i] = n; // szamolo = false; }
index = napfel-(vil_be-eltelt_percek); fenyero = fenyfel[index]; //hol tart a kiolvasás if (fenyero > (fenyertek)) { fenyero = (fenyertek); return; } //nem megy a szabályozott érték fölé analogWrite(napfeny, fenyero); va_napfel.setValue(1); nap_kep = 61; // } }
A program minimum eltelt időt néz. Tehát egyedül az garantált, hogy egy "task" ennél sűrűbben nem fut. Vagyis ennél a beállított időnél ritkábban fut, amikor legközelebb sor kerül rá. Ha egy másik task 10 másodpercig tököl egy ciklusban, vagy simán delay()-t használ, akkor sem veszi el tőle senki a vezérlést.
A millis() egy rendszerszintű változó. Az értéke az MCU (újra)indulása vagy legutóbbi túlcsordulás (amikor eléri a változótípus asta maximális értéket és 0-ról kezdi újra) óta eltelt időt méri milliszekundumokban (a másodperc egy ezred részének megfelelő időközökben). Lényegében egy számláló, ami ha nem is halál pontosan, de egységes időközönként (milliszekundumonként) növeli eggyel az értékét.
