3,3 kevés lesz, 4-4,2-vel próbálkoznék. Meg lehet, hogy kell párezer µF kondenzátor is az áramlökések lefedésére - annakidején C45 telefonnak kellett, hogy tudjon hívást indítani, lehet, hogy a wifi is csinál nagyobb áramlökéseket.

Nem egészen értem, tablet nem kerül pénzbe?

Köszönöm István!
Akkor hagyhatom tötlőn évekig?
A töltőnek nem lesz semmi baja?

Azt mondták nyisak új témát. Ott azt írták hogy hagyhtom töltőn.
(Kínából már 10K megvan)

Hagyhatod töltőn, akkor ha elmegy az áram legalább nem áll meg a vezérlés, bár áram híján a végrehajtás igen.

Engem igazán az érdekelne hogy milyen hardvereket meg szoftvereket használnál?

Szerintem egy tablet architektúrája nem igazán arra való, hogy sok-sok hardvert ráaggass. Jobban járnál egy Raspberry alapú megoldással.

Nem valószínű, mert amikor nem töltődik az akku, akkor kisebb a terhelés is rajta, kevésbé melegszik, az meg pozitívan hat az élettartamra. Ha meg véletlen megdöglik, veszel egy másikat vagy akár szerzel valakitől, aki kukázta a telefonját

A töltőnek nem lesz baja, de az akksi így viszonylag gyorsan tönkre fog menni. Ha már vezérelsz mindenfélét a tablettel, plusz egy opció: hetente egyszer lemeríti pl. 15 %-ig az akkut, majd visszakapcsolja maga alá a töltést.

WiWo,Teamviewer,tennék rá pár zenét, chrome
tablet
Nem használnám midnig, van hogy hónapokat nem vagyok otthon.(Ilyenkor a mini pc használom)
dc-dc konverterrel megoldható?

Tiszteletem!

Most találtam rá erre a topikra. Szeretnék egy OpenHAB- Pi alapú lakásautomatizálást építeni először csak a garázsban, hogy ne akasszam ki a családot
A garázs radiátora külön szabályozható. Indulásként egy termosztátot építek aminek 868MHz-en kellene kommunikálni a Pi-vel.
Minden jó tanácsot szívesen fogadok.
abalazs írta, hogy ilyennel foglalkozik és a MYSensors használhatónak bizonyult. Most ezt tanulmányozom.

Üdv:

FF.

szia

kíváncsiságból én is nézegettem már, de elakadtam az installálásnál.
Milyen hardwert tervezel használni hozzá?
Én első körben piface bővítőt, az bent van a támogatott hw-ek között.

Most csinálok egy termosztátot (ATMega328P, 2*16 LCD, Li-ion akku, DS18B20, DS 3231, RF69, RFM69-868MHz). Kell még hozzá egy 868MHz gateway.
Ha ez már megy akkor - ha jól értettem - a határ a csillagos ég.

Sziasztok! Frissen regisztráltam, én is a házvezérlés témakörben tájékozódom. A jelenlegi setup:
- RPi B+, node.js, express, mongoDB, alakul a VPN, responsive UI tabletre, telefonra, PC-re
- GPIO vezérlés szépen megy, relét tud kezelni ahogy kell, következne az RF, redőnymotor, garázskapu, stb.

A probléma:
433MHz-es adó és vevő pár, bekötve ahogyan kell, wiringpi, 433Utils telepítve, LED az adat lábakhoz hogy látszódjon a forgalom.

./codesend 111111-ra a ./RFSniffer vesz, de értelmetlen és random adatot. Bárki foglalkozott már ezzel?

Röviden ennyi, persze ha bárki tud segíteni, írom a részleteket is csak addig nem akartam egy fél oldalt pötyögni telefonról

Előre is köszönök minden segítséget!
Johny

Ha nem akarsz pötyögni - olvass vissza. Ezek a PI-k PC-k lehet szépíteni a dolgot, de oprendszer fut rajtuk ennek minden nyűgével. Én másképpen tenném fel a kérdéseimet: Rámernéd-e bízni az életed egy PC-re? Mondjuk egy liftvezérlésben? Én nem. A célhardver sokkal biztonságosabb. Nem beszélve a zavarokról, amikből van bőven. Épp a napokban olvastam - talán a "ki mit épített" topikban egy Arduino alapú kazánvezérlőről, ami lefagy, ha elindul egy szivattyú. Na ezekkel kell szembenézni egy 3V körüli táplálású rendszerrel. Hatalmas zavarok - rossz jel/zaj viszony, bemeneti zavarok, táplálási problémák. Ha nem hiszel nekem, állíts össze egy tesztáramkört asztalon. Tegyél mellé egy 12V-os relét nyomógombról úgy, hogy a relének csak graetzel adsz tápot - azaz szűretlenül. működtesd nyomógombról a relét úgy, hogy az érintkezői egy motort kapcsolnak. Ha nem fagy le - ügyes vagy. Továbbléphetsz a következő szintre. Tudom, hogy csábító a sok toolkit és segédprogram, meg a mobilos appok. De nem árt egy kis hardverismeret is.

Szia! Köszönöm a választ, most már rendes billentyűzetről. Értem, mire célzol, természetesen nem Paksot szeretném vezérelni, így az otthonomban is vannak tabu témák. Pont a kazán, hőcserélő és egyebek azok, amikre nem szabadítom rá a Pi-t.
A többit tesztnek, kihívásnak tekintem, szeretnék építeni valamit aminek talán van egy kis haszna is, még ha alkalomadtán újraindítást igényel akkor is. Hőmérő-szenzor, páraérzékelés, redőny és garázs, pár lámpa és kaputelefon.
Természetesen hiszek neked, nem szükséges tesztelnem hozzá A HW és SW környezet természetesen olyan, amit mindig lehet tanulni és fejleszteni, talán valójában ez a célom, nem pedig a mindent-vivő okosház. Arra ott a Control4 és társai, ebben is egyetértünk.

Ha az eredeti kérdésemben is tudsz segíteni, azért is hálás lennék. A fentiekről bővebben:

RX / TX

WiringPi

433Utils

A küldött és fogadott adat köszönőviszonyban sincs egymással, "1111" sorozatos küldésére "207, 31, 943" satöbbi adat érkezik. Távírányitó sniffelésére pedig semmi sem történik. Hullámhossz alapján antennát is adtam hozzájuk, a helyzet változatlan.

Johny

Szia,
Bocsánat, nem olvastam vissza minden hozzászólást, így lehet hogy már próbáltad, de:
Én saját fejlesztésű RF transciever-es dolgokat úgy szoktam éleszteni, hogy először kihagyom az RF modulokat. Közvetlenül összekötöm a végeszközök adó-vevő-re menő "digitális" lábait, így lehet szűkíteni a problémakört. Ha így minden jó, akkor RF problémád van, zajos környezet, rossz antenna, stb. Ha így sem megy, akkor pedig a protokoll nem stimmel -> szoftveres hiba.

Szia! Áss mélyebbre. Én készítettem már saját protokollt és igyekeztem publikusakat is felhasználni. Ha egy állandó karaktersorozatra nem állandó válasz jön, ott a dekódolás a ludas, vagy a kódoló személy nem tudja pontosan mit küldött. Van pár szöveges alapú segédprogram ami segít értelmezni a kódolást és a dekódolást. Ilyen például a Hterm nevű terminál program. Érdemes a hardvereden beállítani a 11111111-t például és dekódernek a hterm-et. Sok kérdésedre azonnal választ kapsz. Egyrészt minden távirat bitekből áll. Ezeknek van fel és lefutó éle is. Nem mindegy mikor indítod, mikor állítod le a jelfolyamot. Nem mindegy, mit használsz startra, milyen karaktert és milyen karakterkódolást. Ha az alapok összejöttek - könnyebben megtalálod a hibát is. Nem árt RF-nél utánanézni valami CRC-nek is, mert torzulhat az adat. Először az is sokat segít, ha két Htermet egymással szembe tudsz fordítani. Akár soros, akár USB porton. Sok kérdésedre ott lesz a válasz. A Hterm jósága abban is megmutatkozik, hogy ugyanazt a karaktersort a végtelenségig képes küldeni, akár hex, akár dec, akár bin formában és meg is tudja jeleníteni többféleképpen. Így minden hibát könnyebb kiszűrni.

Nálam ezért van rendes PLC az összes vezérlési feladatra,(fűtés, redőnyök, világítás) a PI meg csak megjelenítésre szolgál.3 éve folyamatosan megy a rendszerem, a PLC egyszer sem állt le(!) A PI az egy éve van üzemben, csak VNC viewert futtat, de ezalatt kétszer előfordult hogy lefagyott, újra kellett indítani.

Nálam az említett teszttől a PhoenixContact nLC 055 is kifagy. A saját vezérlésem (hardver) már nem. Amúgy teljesen jó a gondolat. A vas tegye a dolgát, a SCADA meg ha lefagy - nagy ügy.

Nyilván PLC-k között is akad silány minőségű, ezért írtam, hogy "rendes".
Egyetértünk, a megjelenítés másodlagos.A legfontosabb funkcióknak meg be kell építeni kézi működtetést, huzalozott kapcsolóval, szerintem.

Szia!
RF moduloknál nem lehet csak 1111-et küldeni azt Manchesteri kódolással kellene, ami azért kell mert a folyamatos H szinttől a kondik telítődhetnek az rf modulban és ez okozza a hibás adatokat, így viszont folyamatosan van hl átmenet, ezáltal ez a hiba kiküszöbölhető. Kipróbálni nagyon egyszerű. A 2 rf modult minden nélkül kösd tápra, az adó bemenetére adj H szintet és figyeld meg mi lesz a vevő kimenetén HHLLL kb.

Csak kiegészítésül. Bármilyen közegben történik egy adatátvitel, akár vezetéken (kábelen), akár rádiós eszközön, vonali kódolást kell alkalmazni. Persze rövid vezetékek esetén elhagyható, de nagy adatsebesség esetén még akár berendezésen belül is szükség lehet rá.

Én nagyon ajánlom a CAN buszt. Nagyon zavar védett. Saját szakmámból adódóan tudom mondani pl használjuk szélturbinában. Saját beépített CRC, újraküldés, hiba detektálás stb stb.

Ez tény, nem véletlenül találták ki, és nem véletlenül használják a járműtechnikában is. Egy villanymozdonyban aztán van zavar bőven. Ezesetben a működési protokollba eleve beépítették a használat körülményeinek megfelelő vonali kódolást.

Azért valami okból kifolyólag 120 métert a turbinában optikai szálon megy az adat. Na jó házban ez egy kicsit túlzás. De úgy gondolom hogy ezekkel a bohockodós RS485-ökkel ellentétben az itteni amatőr környezetben is méltatlanul elhanyagolt dolog.
Én éppen a fűtés okosítását csinálom, és már csak egy paraszthajszál választ el attól hogy a CAN I/O expandereket szét tudjam szórni a házban.
Onnantól kánaán!

Egyébként nem PLC-zek, bár most ahogy olvastam a fórumokat az OMRON ZEN elkezdett érdekelni.
STM32F4xx-el hajtom őket.

Az optikai szál használatának is meg van az oka, leginkább az elektromos elválasztás. Nem tudom pontosan milyen magas a szerkezet a puszta közepén, de tuti ki van téve az elektrosztatikus feltöltődésnek, a villámlátogatásnak, az igen komoly kiépített villámvédelmi rendszer ellenére.
Mondjuk, egy lakóházban valóban túlzásnak tűnik, de meg lehet gondolni. De akkor is szükséges minimál vonali kódolás, pl. NRZ+CRC, vagy ilyesmi.

Hát igen. A CAN csak az OSI első két rétegét definiálja. Ami fölötte van az már protokoll pl PeliCAN, vagy CanOpen. De az én esetemben pl az MCP25050 nevű CAN I/O expander meg is határozza hogy hogy kell hozzá szólni. Nem nagy ügy 8 adatbyte-ba minden belefér. Utasítás, + adat, előtte meg a cím úgye adott a CAN Frame álltal.

Én is haladgatok a ház automatizálással, ugye a kis CP1L 14 IOját 3 perc alatt kinőttem. Közbe rengeteg időt vett el egy fűrészporos égőfej, és hozzá szükséges kiegészítők legyártása, igaz valódi vezérlése is csak most készül.
Eleinte én is valami IO expanderen gondolkodtam, de 100+ IO pont még azokkal sem olcsó. De most véletlenül megtalált egy filléreért egy kövület, Omron CS1G plc, 128 IO ponttal. De ehhez is kelleni fog bővítés, ami majd a melléképületeket fogja kezelni.
Ami mostmár égető probléma: egy halom DS18B20 illesztése a plc-hez, mert addig nem tudom a kis CP1L-t felszabadítani, illetve hadrendbe állítani a dinót.

Mennyiért vesztegetnek egy ilyet? Elég nagy darabnak tűnik.
Én ARM-okat progizok BareMetal meg PIC-eket ASM-be. Nekem ez a PLC a lusta ember cuccának tűnik. De amikor a DirecDrive turbinában megláttam a Siemens Simatic S7-et akkor elgondolkoztam.

Ahogyan a többiek is írták, a rádiók nem szeretik a folyamatos jelszintet. Ha kisebb távolságra akarsz jelet átvinni (10-20 m) , javaslom az rfm70 vagy hasonló modulok használatát. Nem túl drágák, cserébe a beadott adatot nyugtázással továbbítják . mondjuk a vályog falat már nem igazán szereti, de biztosan van ilyen modulból jobb is.

Így van, gyorsan, kisebb erőfeszítéssel lehet vele jó eredményt elérni.
Viszont jóval drágább, főleg ha spec. modulok is kellenek.

Én láttam pár éve a melóhelyen egy felrobbant fém kapcsolószekrényt, amiben egy S7-315 PLC volt, berakták az alkoholos tisztítószert a kapcsolószekrénybe úgy hogy nem volt rajta a kupak.Lerepült az egyik ajtó meg elégtek a kábelek, újra kellett huzalozni.A PLC az run-ban szépen futott tovább.