Az okról nem tudok nyilatkozni, millió egy lehet. Ha a mérés valóban így inkonzisztens, ahogy írod, akkor a néhány héttel ezelőtt részleteiben tárgyalt átlagolós módszer hozhat megoldást, mivel bármely 5 mérés legalacsonyabb és legmagasabb értékét kiejted az átlagból, a maradék viszonylag nagy megbízhatósággal az elvárt eredményt fogja hozni. Persze tesztelni kell, és az sem árt, ha a probléma forrását szünteted meg.
Az arduino.cc fórumán olvasva javasolnak kondenzátorokat az érzékelő kimenete és a föld közé, a kábel mindkét végére (0,1 uF), ezzel a zaj jelentős részét ki tudod szűrni (de nem mindet). Hathatós megoldás lehet még a mérés gyakoriságának csökkentése (akár több másodperces, esetleg egy perces közökkel). Nekem előfordult, hogy fordítva kötöttem be, akkor produkált furcsa méréseket (meg jelentős melegedést is). Üdv,
/* YourDuino Example: Find Address of a DS18B20 Temperature Sensor Cut and paste the address to a text file for later use. V1.1 01/17/2013 Questions: terry@yourduino.com
Connections: DS18B20 Pinout (Left to Right, pins down, flat side toward you) - Left = Ground - Center = Signal (Pin 2): (with 3.3K to 4.7K resistor to +5 or 3.3 ) - Right = +5 or +3.3 V This sketch looks for 1-wire devices and prints their addresses (serial number) to the Serial Monitor in a format that is useful in Arduino sketches. Based on example at: http://www.hacktronics.com/Tutorials/arduino-1-wire-address-finder.html */
A boolean-re ott a pont. A többit köszönöm, most nem van agyam felfogni ezeket. :-( A bajom az, hogy mennyire viszi el a hétköznapi földi halandó gondolkodását az, hogy össze-vissza kavarják a fejükben a dolgokat?
Ilyenkor, hogy is mondjam, akadok ki kissé, hogy milyen végtelenül következetlen az Arduino keretrendszer. És ilyenkor nem tudom eldönteni, hogy ez most bug vagy feature!?
És persze, nem nehéz átlátni a különböző változótípusok közötti átjárhatóságot, csak egy nulla szintű kezdő számára nem biztos, hogy helyes iránymutatás az, hogy "olvass és értelmezz valamit bináris módon, amit egy 16 bites decimálisan értelmezett térben tárolsz". A leírást köszönöm mindenesetre!
Alapvetően a fő kérdés az, hogy a buttonState miért int és miért nem bool?
A debugnak ez a szintje a circuits.io-n nálam már kiakaszt mindent. A rendes szimulációnál is kihullik a hajam néha, de ha belehasítanék egy ilyenbe, akkor megállna, mint a bot.
Hát pont ilyen ötletekre vadászok, mint ez a világítós.
Az a baj, hogy ezt egy közepesnél kevésbé szarabb rosszabb lépcsőházi automata tudja, ha van benne szervízüzemmód. És nem vagyok benne biztos, hogy drágább, mint az Arduinós megoldás bedobozolva, relével, stb.
A millis() overflow megoldást viszont tanulmányozom, köszi.
Igen, igazatok van. Valóban rosszul tettem fel a kérdést. Mentségemre szolgáljon hogy hulla fáradt voltam és még csak nem is értek hozzá :D Köszönöm mindenkinek a segítségeket. Próbálom memorizálni őket és ha legközelebb bármi bajom van akkor használni. Vargham, a te verziódat raktam össze(bár egyenlőre még csak próbapanelen). Tökéletesen működik, köszönöm!
A lámpa időzítős funkció közbeni lekapcsolására nincs szükség. Ez egy kinti lámpa lesz, ha valaki kimegy akkor megnyomja a gombot, a lámpa meg majd lekapcsol. Így működik a régi is. De ha valamit kell csinálni kint ami időigényesebb akkor bajos mindig nyomkodni a gombot, ezzel ez ki lesz küszöbölve.
A szimulátornak három hatalmas baja van: egyrészt roppant rendszerigényes (szerver és kliens oldalon is), másrészt nem real time, hanem lassúcska, harmadrészt nincs debug lehetőség egyáltalán.
Feltöltve találtam benne több hibát is, ezek egy része elég amatőr (hozzárendelés == sima = helyett). A maradékot még jó 20 percig debugoltam Serial Monitorral. Az if-ek egymásután és a bool-ok állítgatása kihozott olyan korrelációkat, amelyekből a bool-ok olyan kombinációja jött ki, amit nem vizsgáltam, emiatt végtelen ciklusba került. Az ok az egyszerűsítés: "ha B feltételt vizsgálom, tudom, hogy A feltétel mindenképp igaz, tehát akár ki is hagyhatom a vizsgálatból". No, ez marhára nem lett igaz, mert lett olyan eset, hogy B feltétel igaz volt ugyan, de az A feltétel egy korábbi vizsgálat eredménye képpen már nem teljesült. Már majdnem beleírtam egy újabb bool-t, de rájöttem. :-D Egyébként tényleg jó feladat.
Én időközben megírtam, most ellenőrzöm. millis() overflow figyeléssel. Egyedül watchdog nincs benne. Meg delay() egy szál se. Dezájnolva 99 sor és csak két mágikus szám van benne. 3 define (pinek), 5 boolean, 5 unsigned long, mind globális, bár csak egy függvény (void loop() ) van.
És asszem életemben először az ellenőrzött 'kész' program compile error nélkül futott le. #jonapomvan
De én kíváncsi lettem volna, hogy az eredeti kérdező hogyan fogalmazza meg a kérdést. Már csak azért is, mert rengeteget segít, ahogyan precízen megkonstruálja a kérdést.
Szóval a nem működik, mi a baja az nem kérdés.
Az a tapasztalatom, hogy egy precízen feltett kérdésre sokkal többen és sokkal pontosabban válaszolnak. Az szintén tapasztalat, hogy egy kérdés precíz megfogalmazása közben 10-ből 9 alkalommal meg is válaszolom magamnak, és nem kell fórumokon kérdezősködni. Egyszerűen a probléma logikus végig gondolása segít.
Tényleg jó feladat. A mellékelt kód viszont nagyon nem egészen ezt csinálja.
Sorban a gondok: 1. LED nincs kimenetként deklarálva. 2. A nyomógombot érdemes aktív LOW-két használni: pinMode(kapcsolo, INPUT); aztán digitalWrite(kapcsolo, HIGH); Ez a belső pull-up ellenállást bekapcsolja, így a bemenet folyamatosan (kis áramon) magas jelszinten lesz. Ha lemegy 0-ra (ilyenkor a kapcsoló másik felét a földre kell kötni), akkor van gombnyomás. Üzembiztosabb és kevésbé zajérzékeny. 3. Változók. Ez így nem jó. Forrás olvasásra. Itt: data types. A lényeg, hogy bár most még annyira nagy galibát nem okoz, komplexebb programok simán elhasalhatnak rajta, hogy nem következetesen vannak használva a különböző változótípusok. Az int numerikus változó, ennek nincs TRUE és FALSE vagy HIGH és LOW értéke, bár az igaz, hogy az IDE vizsgálatoknál értékelheti úgy, mintha lenne, de a hozzárendelés ebben a formában gondokat okozhat. 4. 20 mp-es delay nagyon nem szerencsés. Mi van, ha ez idő alatt le akarod kapcsolni a lámpát? (Megoldás a blink without delay példában az Arduino tudástárban [lásd fent].) 5. Az első vizsgálatban látható 1 és 4 mp-es kivárások közül az 1 mp-esnek van értelme (bár te 2 mp-et írtál), a 4 mp-nek viszont semmi. 6. Semmi nem vizsgálja a második (bekapcsolt állapotban lévő lámpa kikapcsolására adott utasítást).
