Sziasztok! Nyilván a gondok abból fakadnak, hogy mások a tapasztalataink, más a habitusunk, mások a szempontjaink. Igen - határozott vagyok a saját véleményemet védve, hiszen a már felemlített hibák és tévedések minden rendszer velejárói - akár felismeri az ember - akár nem. Én azt tapasztaltam, hogy ahogy szaporodnak az adatok - elkezd terjengőssé válni a klasszikus master-slav rendszer. Túl sok adat megy folyamatosan a rendszeren. Ez több bajt is hoz hozhat magával:
1.) Belassul a kommunikáció (ez konkrétumon alapul, 3 épületben is okozott problémákat)
2.) Ha egyetlen kulcs információ kimarad - zavar támad a rendszerben
A lényeg, hogy tulajdonképpen el kell gondolkodni: Kell-e nekem ennyi információforgalom? A válasz sokszor: nem. Én egy olyan rendszert "álmodtam", ami hasonlít az emberi vészreakciókhoz. Azaz :
Ha sétálunk, minden rendszer alapállapotban ketyeg. Ha megbotlunk beindul egy folyamat és lekezeli ezt a szükséges módon. Ez megvan a riasztórendszerekben is, hiszen alapvetően eseményvezérelt rendszerek.
Ezt Multimaster módban lehet igazán jól kezelni. De nálam ez még a nem túl távoli jövő. Jelenleg a betonbiztos hardver volt a cél -s úgymond "melléktermékként" készültek csak el a szoftverek, hiszen valahogyan ellenőrízni kell az elképzeléseim helyességét és megvalósíthatóságát. Azaz az általam felépített rendszer nem is rendszer, csak egy képesség, amit többféle módon is fel lehet használni. Egy olyan univerzális célhardver, mint egy PLC, vagy PC, de épületfelügyeleti modulban. Egyetlen célhardver - sok lehetőséggel. Azonban ezt komoly dolog tesztelni. A tesztek során jöttek elő az Achillesz sarkok. De szerintem megérte. A már hivatkozott oldalakat azért linkeltem be más rendszerekről, mert ugyanazt a problémát meg lehet oldani 300 féle eszközzel, de eggyel is - csak más szemlélettel. Nem vitatkozom azon, hogy jó egy olyan rendszer, ami áll egy vezérlőből és sok távvezérelt IO modulból. Csak azzal vitázom, hogy ez életszerű? Megfelel a mai követelményeknek is? Mindenre egyedileg gyártunk valamit? Vagy gyártunk egyfélét, olcsón, tömegben? Nyilván egyetlen buszrendszer is elég. De sok esetben jobb rendszert építhetünk, ha mindenre azt használjuk, amire kitalálták. Ezért került végül 2 kommunikációs panel (cserélhető) a megoldásomba. Így lehetőség van átjáróként is felhasználni. Miért lehet jó ez? Mert például már van egy meglévő gépészeti rendszerünk. Erre a saját portján csatlakozunk és feldolgozva a nekünk szükséges információkat - és megszűrve azokat - használhatjuk fel a saját buszrendszerünkben. Erre számos példa létezik - csak nem ilyen hardverben. Az én megoldásom azért kapta végül a kameleon nevet, mert igyekszik minden platformmal a saját nyelvén kommunikálni. Erre van két RS485(vagy más!) port, USB, TCP/IP egyszerre. Minden csatlakozás, célchip rajta van, azonban rajtunk áll, mit használunk ki belőle. A dobozos megoldás a rendszer terjedését segíti. PLC-re is, PIC-re, Rasberry-re lehet világításvezérlést írni, működni is fog. De a megbízhatósági listán, melyik lenne az első? Ki írná meg a programot? Milyen színvonalon? Sokszor találkoztam profi programozókkal, akiknek a hardver adottságai miatt az ilyen és hasonló - egyszerű feladatokba is beletört a bicskájuk. Miért? Mert programozóként oldották meg a problémát. Nem a user fejével gondolkodva. Mindezt kötött időben, adott bérért. A "dobozos" megoldás lényege, kicsit a PC piac MAC-es elgondolásán alapul. Mindent egy kézből. Igyekeztem a szoftvereket a rossz tapasztalatokat kikerülve - a felhasználók igényeihez igazítani. Így meg lehet kerülni ezt a fajta hibaforrást.

Szinte szóról-szóra ezek voltak az elképzeléseim, amikor letudtam az első próbálkozásokat és rendszer tervezésébe fogtam. Univerzális, szabadon skálázható modulok, user-központú szoftverrel... Ez maga a szakmai álom. De sajnos jött vele az ébredés is. A fejlesztés olyan mérvű erőforrásokat igényelt volna, ami nyomokban sem állt rendelkezésre. Illetve lehetett volna, de csak akkor, ha valamiféle üzleti megtérülés áll mögötte, ami nem feltétlenül a világpiaci betörést jelenti, de legalább 8-10 szomszéd és ismerős vásárlási szándékát. A mások által is ismert körök megfutását követően kiderült, hogy ez nem megy.

Tehát változott a szemlélet. Lesz rendszer, de úgy kell simulnia a meglévő körülményekre és adottságokra, mint egy vizes harisnya egy női lábra. Ezt azért írom le már nem először, mert határozott tapasztalatom, hogy egy ilyen projectnél, ahhoz hogy valóban megvalósulhasson, nem a hardver vagy a szoftver a fő probléma, hanem a fantázia megfékezése a kezdeti terveknél. Furcsán hangzik, de igaz. Számtalan esetről tudok, amikor az újabb és újabb ötletek miatt végül sose lett az egészből semmi. Ezt úgy lehet megoldani, hogy az extráknak nyitva kell hagyni egy csatornát és neki kell állni a legerősebb fókusszal a nem nélkülözhető részeknek.

Ez a fő oka annak, hogy még a buszokat is szétválasztottam. A kritikus funkciók, mint a fűtés és a riasztó, külön-külön buszon mennek, limitált eszközszámmal, kőkemény militáris szemléletű kapcsolati rendszerben. Itt elvetettem a multimasteres elvet, mert az a nézetem, hogy semmi szenzor nem dumálhat bele a dolgokba, amíg nem kérdezik. A hierarchia szigorú. Van a főparancsnok, ami közvetlenül nem irányít semmit, de kiadja a műveleti parancsokat, követi az eseményeket, irányítja a jelentéseket és tartja a kapcsolatot a főparancsnoksággal.
Vannak osztagparancsnokok, amik képesek önállóan is működni az utolsó műveleti alapján, hallgatják a jelentéseket, kiválogatják a nekik szükségeseket és maguk is jelentenek. Ezáltal nincs és nem is lehet dugulás a vonalon és akkor is működni fog (legfeljebb kisebb hatékonysággal), ha egy egér elrágja a kábelt.

A harmadik vonal az, aminél elszabadulhat a fantázia. Itt lehet multimaster, lehetnek slave-ek, futhat a világitásvezérlés, az automata macskaetető és bármilyen céleszköz, amire csak szükség lehet. Természetesen mindennek képesnek kell lennie önállóan is működni. Ez azért fontos, mert az egész rendszer valójában béta verzió és jó darabig még az lesz. Ezzel értelemszerűen az jár, hogy az egyes panelek olykor visszaugranak az asztalra és addig azért a többinek menni kell. Megette a fene az egészet, ha a már átalakított villanykapcsolók nem működnek, mert leállítottam a buszt, amikor pár új ötlet miatt átírom kissé az adatgyűjtő, vagy a koordinátor részt.

Ez az elképzelés azzal az előnnyel jár, hogy az egyes, hasonló funkciójú elemek nagyon hasonlítanak egymásra. Tehát ha nagyjából azonos családba tartozó mikrovezérlőket használunk, akkor az egész kommunikációs, paraméterátadós programrészt csak egyszer kell megírni és simán inkludálható.

Mielőtt a tapasztaltabb szakik nehéz szavakat ejtenének, határozottan leszögezem, hogy ezt az egészet nem nekik írom, hanem azoknak, akik ugyanazokkal a homályos elképzelésekkel épp most indulnának neki, ahogy én indultam pár éve. Esetleg segít megtakarítani pár felesleges kört. 100%-ig hobbielektronika és nevezhetjük akár demo board-nak is, annyi különbséggel, hogy rendesen összerakva akár végleges rendszer is maradhat. Nem konkrét tervet mutatok, azt mindenkinek magának kell megcsinálnia a harisnyaelv miatt, hanem tervezési szempontokat.

Még egy rövid kitérő a felhasznált elekronikáról. Az ember hajlamos elcsábulni a mindenféle szuper technikákkal összefutva, én naponta csorgatom a csorgatnivalót, amikor olvasom az elektronikai hírleveleket az új technikákról, de mégis a pic és a propeller mellett maradtam. Megragadt bennem az egyik regényből egy mondat: "Amit Isten alkotott, abban hiszek, de amit magam alkottam, abban bizonyos vagyok". Tehát elhiszem, hogy az elektronikai ipar istenei csodákat alkotnak, de én magam már csak olyasmiben bízom, aminek minden mikroszekundumnyi időzítéséért és minden bájtjáért magam vállalhatom a felelősséget.

Jóformán azóta foglalkozom picekkel, amióta megjelent az első flash memóriás változat és messze nem osztom azok lekicsinylését, akik pl. a 16F877-es közismerten hihetetlen érzékenysége miatt előítéletekkel élnek. Mindenkit biztosíthatok róla, hogy pl. a 16-os sorozat mára annyira megbízható, hogy bármit meg merek építeni vele. Több száz program és rengeteg, máig működő eszköz után ezt nyugodtan kijelenthetem. 7-8 éve mennek gyakorlatilag megszakítás nélkül olyan kapcsolásaim, amik egy kerti aknában, szivattyúk között, csöpögő párában tanyáznak.

A Propeller-t meg nem kell megvédenem. Csak annyi a problémám vele, hogy évekkel korábban nem fedeztem fel. Jellemzően az az eszköz, ami olyanoknak készült, akik valóban akarnak programozni. Olyan mint pl. szerszámnak a nyomatékkulcs. Csak az használja, akinek valóban szüksége van rá és nem is igen tudja nélkülözni. Nekem pont ez hiányzott jó ideje ahhoz, hogy kerek lehessen a történet.
PC kapcsolatról, webszerverről, telefonos vezérlésről nem tudok mit mondani, arról beszéljen az, aki használja.

Nem akarok vitázni a nézeteimről, nincs is értelme, úgyse változtatok rajtuk. Nem tartom az enyémet mások rendszerénél előbbrevalónak, tehát senki se fogja fel kritikaként a következtetéseimet. Nálam egyszerűen így simult ki a harisnya, másnak meg máshogy. Azért írtam le a dolgot megint ilyen hosszan, hogy csatlakozzam pl. kukori felvetéséhez és szemléltessek egy megközelítést. Rábízom az olvasókra, hogy használhatónak tartják, avagy sem.

Sziasztok,
Technikai jellegű kérdésem volna hozzátok. Nemrég kezdtem a házunk okosítását raspberry alapon. PIC egyenlőre nincs, riasztónál és öntözésnél lesz majd, de egyenlőre még tanulás és tervezés alatt.
Jelenleg hőmérséklet mérés megy 1-wire-n, illetve spot és ledszalag vezérlés, valamint tv, műholdas beltéri, házimozi vezérlés ir-n keresztül.
Van egy motoros redőny Bővebben: Link egy ilyen 433mhz-s rádiós távirányító Bővebben: Link. (természetesen ráprogramozva)
Szétszedtem, egy PIC16F630 van benne.
Az rpi-hez van 433-s adóm és vevőm, illetve trinket ad rpi vesz... (működés teszt miatt...)
Szeretném a redőnyt is az rpi-ről vezérelni, de elakadtam . A jelet nemtudom elkapni, nem is érzékeli a vevő.
A leírás szerint a távirányítót le lehet másolni, így több távirányító vezérelheti a redőnyt. (meglévőn program gomb, hangjelzés, program gomb, hangjelzés, újon program gomb és kész) Gondolom ilyenkor kiad egy egyedi azonosítót amit a motor tárol... A fel, le és stop gombok fix kódok lehetnek... vagy nem tudom
Volt már valakinek ilyennel dolga? Mit tudnátok javasolni? Miért nem látom rpi-n a kiadott jelet?
Előre is köszönöm.

Van lehetőséged kínlódni (ha a redőny nem beszél vissza a távráncigának, akkor még sikerülhet is), de sokkal jobban jársz, ha veszel még egy távot, és a raspi csak a nyomógombokat kezeli rajta...

Szia! Ez lett volna a következő dolog, amit megosztottam volna: Ha intelligens épületet akarsz - vedd mindenből a legbutábbat! Egyszerű redőnymotor 4 kivezetéssel: 0, fel, le, védőföld. Minden eszköz ami saját elektronikával van ellátva - zárt, nem publikus protokollal működik. Rengeteg történetet tudnék mesélni, de elég legyen annyi - ma már én sem a legintelligensebb kazánt venném meg, hanem egy fapadost, ami betonstabil - az elektronikát pedig én csinálnám meg hozzá. Sajnos - amennyivel az ember többet fizet egy ilyen készülékért - az a pénz soha nem jön vissza, de meg sem éri. Egy sima redőnymotor egy tizessel olcsóbb lett volna. Redőnymotorok. 10-12 redőnynél ez már egy igen jó elektronika ára.

Szia!

Ezek a távirányítók nagyon alacsony Baud rate-el működnek 2400-al, vagy még kisebbel, a hatótáv és a biztosabb működés miatt. Nem szoktak tesztbájtot (0xAA) sem küldeni, amivel az okosabb vevők beállíthatják maguknak az adatátviteli sebességet, így megeshet, hogy az rpi nem is fogja értelmes jelként. Sima Usart jelsor, egy ID, néhány fix kód, valami chksum, olcsó vevő és kész.

Érdemesebb a pic Tx lábáról elkapni a jelet egy tárolós szkóppal, vagy egy soros analizátorral. De az talán még egyszerűbb, amit snapscan tanácsolt.

Én is a szkópos megoldást választottam, egy délelőtt alatt megoldódott a problémám, igaz nem a redőnyvezérlés, hanem 433Mhz-es távvezérlős dugaljak kapcsolása. Simán lemásoltam a táv. jeleit, és azt küldöm ki.
Bővebben: Link

Üdv. Én is nagyon régóta tervezgetek egy elég komplex rendszert, de eddig még csak pár prototípus készült, de egyik sem tetszett valami miatt. Most elvileg kigondoltam az ideális megoldást, de lenne egy komoly elvi (és főleg technikai) dilemmám.
Szeretnék több vezérlőt is elhelyezni, vagy a lámpakapcsolóba, vagy a lámpatestbe. (A kapcsolóba jobb lenne.) Viszont nem szeretném átvezetékelni ez miatt a fél házat, de így a kapcsolónál csak fázisom van, a lámpánál meg kikapcsolt állapotban csak nulla. Van valakinek jó megoldása, hogy lehetne így stabil tápot csinálni az elektronikának, ami 3.3V-on úgy 100mA körül vesz fel? Valami ilyesmi megoldás kéne, de ez elvileg csak 1-2mA-re van tervezve, és nem is tűnik túl stabilnak egy mikrokontrollerhez.
Érintésvezérelt dimmer

Sziasztok! Szia Laci!

Éppen most akadtam össze, az általad említett motorral. Építenem kell egy átjárót, ami tanítható.
A lényeg, hogy megoldható amit te akarsz csinálni, simán ellestem egy táv jeleit, arduinóval pedig küldöm ki, és a moci mocorog: Video
Mivel a távvezérlő, és az arduinó is ugyanazt a jeleket küldi ki, így a motornak elég ha egy jelet megtanul. A kód felépítese, hogy van egy hosszú start bit, aztán 40 bit. Ebből ha jól sikerült visszafejtenem, az első 24 bit a távirányító azonosító, a következő 8 bit (több csatornás táv esetén a csatorna azonosító) az utolsó 8 bit pedig a nyomógombok( fel, le, stop, program gomb)

Szia,
Szuper Parkolópályára tettem mert nincs más cucc, mint egy rpi és az általad is használt rf adó, vevő páros. Viszont érdekes, hogy rpivel figyelem a vevőt, megnyomom a távir gombját, semmi nem történik (olyan mint a tiéd, a kicsi). Viszont ha adok az adóval, akkor a vevő veszi a jelet.
Előveszem újra, próbálkozok tovább, mert mennie kell

Szia,
Csak sikerült elkapni valamit, de egyenlőre nem tudom reprodukálni.
Egy kis python script vizsgálja a 22-es gpio portot. Időzítése 0,0005 (lehet ez nem jó)

le
1111110001100001011011000110010000101101101001011011000010110010100101100
fel
111111100100100101011001011000010010110110100101101100001011001011000010
stop
1111111001001010110110010101100100001001011000010110110100100100010011010

majd mintha ismétlődne, de van eltérés néhány bitnél.

Megpróbáltam ugyanazzal az időzítéssel ezt a kódot kiküldeni, de semmi nem történik

Sajnos az elektronika része kicsit magas, tudnál benne segíteni, hogy megértsem, illetve működésre tudjam bírni?

Hát, nem tudom, neked mintha túl sok lenne a bit. Dettó ugyan ezt a smart-home-os motort használom az ipod féle távval, és nekem 40bit az egész kód. De ugye ezt egy gombnyomásra elküldi a táv kb 2-4 szer. Mellékelt képen vannak az adatok, amiket szkóppal kimértem.
Nálad a STOP gombnál például nem látom a kódban sehol a nyomóbomb-hoz tartozó byte-ot, ami: 01010101

Sziasztok! Van egy öntözőrendszerem és ethernettel szeretném ki/be kapcsolni.

Mármint ethernet kábellel?CAT5-el?
Vagy hálózaton keresztül távolról? AZ egészet vagy zonánként?
Vagy mi a kérdés?
Persze gondolom mit szeretnél. Goglizz rá a GSM pager -re. Az kell neked.

Sziasztok!
Led szalag
2 db 12v lámpa
rádió
öntözőrendszer
szivattyú
kerti lámpa
kaputelefon
kamera rendszer
elektromos kapu
időjárás mutató
a felsoroltakat lehet vezérelni, érintőskepernyősen?

Lehet.

Sziasztok!
Hogyan lehetne megoldani hogy , LED szalagot,kerti 12v szivattyút,2 db 12v lámpát internetet ki/be kapcsolni?Ugyan így interneten keresztül egy relét ki/be kapcsolni?

A leggyorsabb megoldás, ha fogsz egy mikrokontrollert, építesz köré hardvert, ami soros vonalon keresztül vezérelve tudja kívánságaidat kapcsolni. Utána beszerzel egy ethernet-soros vonali átalakítót, és azon keresztül rákötöd a routerre.
Ehhez szükséged van programozási ismeretekre.
Alternatív megoldás lehet egy RaspberryPi, arra lehet mindenféle perifériát, így jelfogókat is aggatni.

ÉS nem létezik olyan hogy egy motort lehet bekapcsolni usb keresztül?

Jelfogó már tud kapcsolni motort...
Milyen motor? Tudod, hogy az USB szabvány csak 150mA áramot enged meg?

2 Megoldás létezik.
1 Kitanulod a mikrovezérlő vagy más vezérlő programozását és építesz egy rendszert magadnak, plusz írsz egy honlapot amin keresztül kezeled a rendszert.
2 Keresel valakit aki megcsinálja neked mindezt.
Az első időbe kerül a 2. pénzbe. Lehet választani. (Az első verzióhoz is be kell fektetni pár tizest hogy használható legyen. A másodikhoz már inkább 100 ropi körül gondolkozz.)

Sziasztok!
Ti hogyan oldanátok/oldottátok meg, hogy egy fogyasztót digitálisan és manuálisan is tudjatok kapcsolni? Pl. lámpa. Jó lenne egy SW amiből tudom on/off kapcsolni, úgy hogy az eredeti kapcsolós kapcsolás továbbra is megmaradjon. Mindezt úgy, hogy a SW ismerje a lámpák aktuális állapotát.
A HW megoldásra várok javaslatokat. Nekem 2 megoldás jutott eszembe:
1. Figyelem a kapcsolón a feszt.
2. Figyelem a fogyasztóba folyó áramot.
Viszont ezenkívül még csupa más feladat is adódik.

Manuálisan felkapcsolod , hogy kapcsolod le"digitálisan"? Elveszed a kapcsolótól az áramot? És ha le van kacsolva, akkor hiába adod vissza a kapcsolónak a feszt..
Így is úgyis vezetékezni kell..
Kell egy PLC szerű dolog ami kapcsolja fizikailag a "bármit" egy kimenetén keresztül. Bemenetére meg megy a kapcsoló. És valahogy valamin meg a digitális kommunikáció megy.

Nekem csak az a bajom hogy kell vagy 30-40 IO egy szintre, egy teljesen egyszerű 100nm háznál is. Ezt ipari eszközökből összerakni nem 3 forintos tétel! (úgyhogy kénytelen leszek csinálni célhardwert)

Van egy olyan lehetőség, hogy minden doboz egy slave eszköz lesz a kapcsoló meg csak "dísz" kisfeszt kapcsol egy modulon. A valós kapcsolást pedig egy triac végzi majd. Az elektronika így fogja ismerni az állapotot. Nálunk takarékos és led izzók vannak.
Ellenérv?

Kapcsolónál csak akkor van fesz ha épp nincs felkapcsolva, tehát a nem lesz miről működnie nulla nélkül. Vagy soha nem kapcsolsz fel 100%osan...

Ezt most nem igazán értettem meg. Én úgy gondoltam, hogy a kapcsoló jelezne az MCU-nak, hogy gyújts. Az pedig a következő 0 nál gyújtaná a triakot. A 0 vezeték fixen csatlakozik a fogyasztóhoz a fázist pedig kapcsolná a triak.

Hol van(ak) elhelyezve az eszközök?? (MCU, Triac)

Sehol sincsennek eddig. Úgy gondoltam, hogy a falba szerelt kapcsoló dobozba tenni egy kis elektronikát, ami kapcsol. A falikapcsoló pedig csak az MCU pint húzná vcc-re, vagy gnd re.

Nem teljesen értem mit akarsz, de a standard megoldásokat tudom.
1.) Nem kapcsolót használsz, hanem nyomógombot, és impulzusrelé módban kapcsolsz.
2.) Távvezérlés esetén XOR-t alkalmazol. A fogyasztónak mindegy, hogy helyileg, vagy távvezérelve lett felkapcsolva vagy lekapcsolva. Maximum ezt nem direktben érdemes elkövetned, hanem egy regiszterben, és onnan írod a kimenetre a végeredményt. Így a visszajelzésed is egyszerű, mert csak a regiszter állapotát kell lekérdezned.
Kapcsolóra nincs korrekt megoldás, csak ha alternatív módban kapcsolsz. Akkor azonban a billentyű állapota nem ad visszajelzést arról, ki - vagy bekapcsolt-e az utolsó állapot. Nyomógombnál sincs visszajelzés, ezért távoli fogyasztónál erről is gondoskodni kell (például kültéri világítás).

Meglévő általános vezetékezésnél a kapcsoló szerelvény dobozában nincs nulla, csak fázis meg kapcsolt szál. Magyarul nem biztosított a készülék áramellátása! Innentől remélem érthető a hozzászólásom!
A másik apró gondolat hogy jut el a modulokhoz, a "digitális" jel!!