A nagy otthonautomatizalos topik

Eleg sok forumbejegyzest es topikot lattam elszorva, gondoltam egy helyen talan jobb lesz ha irunk, atlathatobb...

Hozzászólások

Frissen be is irom az aktualis helyzetet:
Raspberry Pi-re Homebridge telepitve, ez szolgal ki jelenleg 2 db helyisegnek a mereset (wemos d1 mini + dht11 shield), es a konyhapult led szalagos vilagitasat is belegyogyitottam (wemos d1 mini + relay shield).
Idaig teljesen profin mukodik, a dh11 kornyeken voltak bugok, ezeket sikerult fixelni es igy stabil.
Mukodik a hey siri turn on the light is :)))
A kozeljovoben meg masik 2 helyisegbe is bekerul 1-1 mero, illetve terven van a teljes vilagitas lecserelese is okositottra (Belkin Wemo), termeszetesen mindent a homebridge szolgal ki. :)

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

Nalam philips hue cuccok vannak, igy ott csak annyi kell, hogy minden bekapcsolt allapotban legyen. A fali kapcsolok helyett pedig felszereltem a philips hue dimmer "kapcsoloit", igy minden megmaradt kezzel kapcsolhatonak is es lehetett mindenen okositani is egy kicsit (pl. a bejarati ajto melletti kapcsolonal a hosszan nyomott lekapcsologomb minden mas lampat lekapcsol a lakasban, de ugyonezt csinalja a haloszobaban felszerelt kapcsolo is, a furdoben pedig tobbszori megnyomasra mas es mas szinek/fenybeallitasok kozott lehet valogatni).

---
Apple iMac 27"
áéíóöőúüű

A Philips Hue csaladnal a fenyforrasok tartalmazzak az okositast, igy a lakasban minden foglalatba csavart kortet kicsereltem 1-1 Philips Hue kortere. A lakas nagy reszen szines kortek vannak, de ahol ennek nincs ertelme, oda csak allithato fenyereju melegfeher korte kerult. A kortek 802.15.4 (Zigbee) radioval tartjak a kapcsolatot a Philips Hue Bridge fantazianevet viselo dobozzal. Minden korte onalloan repeaterkent is mukodik, igy a lakas kb legtavolabbi pontja is eleri a kozpontot. A fali dobozokban wagoval kotottem ossze a kapcsolovezetekeket (de mar kiserletezem azzal, hogy elferjen a Philips Hue Dimmer switch mogott egy billenokapcsolo is) es erre helyeztem fel a Philips Hue Dimmert, amin 4 nyomogomb talalhato.

---
Apple iMac 27"
áéíóöőúüű

GU10-hez nem kell trafó.
De ha már csinálod akkor ne a sima GU10 halogént rakjad bele.
Lehet kapni GU10 dimmelhető LED-et is.
Arra figyelj, hogy nem minden LED dimmelhető.
Van rajta egy kis ábra egy dimm jezés áthúzva. Ha ezt látod akkor nem az.

pch
--
http://www.buster.hu "A" számlázó
--

Megrendeltem en is most a starter kitet + 2 extra egot, meg a wemo tetszett ezen kivul, de a philips-et megbizhatobbnak velem.

A hue dimmerrel lehet beallitani olyat pl, hogy minden egot lekapcsoljon, stb?

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

Amit sehol nem talaltam, azok ezek az "extra" dolgok.

Alapbol fogd fel a dimmert ugy, hogy 4db gomb. Van a philipsnek egy developer kozossege: https://www.developers.meethue.com ahol regisztracio utan el fogsz erni egy http hivasokkal operalo apit. Minden egyes kapcsolo (pl hue dimmer switch) "sensor" tipusu eszkozkent fog bekerulni a bridgere. Minden szenzor tipusu eszkoznek vannak eventjei, pl a Hue Dimmer Switch eseteben "buttonevent" amihez tartozik egy ertek, ami a Hue Dimmer eseteben a gombokhoz rendre az 1000/2000/3000/4000 erteket rendeli. (van pl gomb ismetles, 1001/2001/3001/4001, meg meg nehany mas dolog).

A rendszerben keszithetsz egyeni szenzorokat, amik tarolnak egyeni ertekeket (pl. kulso homerseklet, vagy gomblenyomas szamlalo vagy barmi mas). Keszithetsz "rule"ok-at, amik bizonyos felteletek teljesulese eseten vegrehajtanak egy akciot.

Tehat minden egyes gomb esemenyre kell kesziteni egy rule-t, amiben felsorolod a felteteleket es a vegrehajtando akciokat.

En osszehangoltam az osszes lampat ugy, hogy a bekapcsologomb elso megnyomasara szemre azonos fenyerovel induljnak el az eltero helysegekben a lampak, majd pl ismetelt megnyomasra ez a konfiguracio valtozzon. (pl. bejarati ajto 1. nyomas 40%, a wc-ben csak 20%, mig a nappaliban, ahol 3 kortenek van foglalat, csak az 1ik korte kapcsol be 70%-on).

Megcsinaltam azt is, hogy a nappali es a haloszoba es a bejarati ajtonal levo kapcsolo hosszu kikapcsologomb nyomasra kikapcsoljon minden mas vilagitast is a lakasban. A nappali es a haloszoba ajto mellett van a furdoszoba kapcsoloja (a furdon kivul, tehat karnyujtasnyira mielott bemegyek ezekbe a szobakba), ezert oda beallitottam, hogy ha azt nyomom hosszan kikapcsolasra, akkor mindent lekapcsol kiveve a nappalit es a haloszobat (ennek pl. az az ertelme, hogy ha a konyhaban/folyoson/kamraban egve maradt a lampa, akkor ha megyek be a nappaliba, ezeket onnan is le tudom kapcsolni).

Szoval a lehetosegek tarhaza szinte vegtelen. Pl. ha van homerod, ami vagy szinten ZHA vagy ZLL (mert a bridgere fel lehet leptetni 3. gyarto ZLL vagy ZHA eszkozeit is) akkor meg lehet csinalni hogy a falra felrakott nagyon modern absztrakt kepet megvilagito lampa esoben/hidegben zold szinu, melegben meg piros fennyel vilagitson es tegye mindezt teljesen automatan.

Szerk: Amit kifelejtettem. A dimmert habar forgalmazza a Philips europaban is, nem segiti meg a felhelyezeset az itteni dolgokra. Ehhez terveztem egy 3D nyomtathato adaptert, es azzal szereltem fel a falra: http://www.thingiverse.com/thing:1997705 .

Amire elsore nem gondoltam, hogy vakfedel helyett, jobb lenne, ha alatta megmaradhatna a kapcsolo mehanika is. Gyorsan vettem egy esfora kapcsolot, de a jelenlegi terv kb 1-2 mm hianyaban nem teszi lehetove, hogy a kapcsolo kenyelmesen elferjen alatta. (persze lehet, hogy ha sniccerrel levagok a kapcsolobol, vagy smirglivel reszelek egy kicsit a kapcsolo muanyagbol lehet, hogy elfer, de ezt meg nem neztem meg. Nagyon vastagabbra nem akarom, meg ujranyomtatni sem szeretnem a dolgokat).

Egyebkent pl a WC-be es a Konyhahoz olyan muanyagot nyomtattam, ami sotetben vilagit, igy segit megtalalni a kapcsolot sotetben: https://twitter.com/czokie/status/819833620483493889

---
Apple iMac 27"
áéíóöőúüű

Ha majd vasarolod a szines korteket, mindenkeppen a 3. generaciosakat (richer colors cimkeju) celszeru venni, mert a tobbiben nincs jo zold es ciankek szin. A feher fennyel sem a reginel sem az ujnal nincs semmilyen problema. Kapcsolobol pedig mostanaban ajanlom a Mentavill uzleteket, mert ott a kapcsolo es az E27-es foglalatu fixen melegfeher szinhomersekletu, de dimmelheto korte 7 ezer forint koruli aron volt decemberben. Az edigitalon pedig nem irjak sehol, de mar novemberben is az uj, richer coloros korteket arultak.

---
Apple iMac 27"
áéíóöőúüű

Van esetleg screenshotod erről a Homebridge-ről?
A Raspberry egyébként másra is kell, vagy csak a "központosítás" miatt van a rendszeredben? Mert a Wemos D1 Mini önmagában is alkalmas DHT11 kezelésére és relé vezérlésre, nem? A webszerverén keresztül lehet állítgatni, kapcsolgatni, nézegetni a mért eredményt.

Szerk.: Hogyan kommunikálnak az eszközök?

A homebridge egy reteg az erzekelok, lampak, stb es az apple ios homekit alkalmazas koze, hogy kompatibilisek legyenek.
Magat az erzekelok leolvasasat, vagy a lampa kapcsolgatasat lehet siman http-n keresztul is persze, ez egy keretrendszer ami korbefogja oket.

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

És írni is fogsz róla? :)).... Szerk (Lekéstem :) )

Nálam az otthoni szerveren fut több minden amit ide lehetne sorolni, kérdés kinek mi tartozik bele az otthonautomatizalos topikba.

Home-assistant
ZoneMinder
Kodi
Torrent letöltés automatizálás -film, sorozat- (persze fizetve érte becsületesen)

Leginkább zwave eszközök lesznek majd a későbbiekben és Ip kamera

1 db Raspberry Pi 2 a nappaliban: mosquitto broker, és néhány saját okosotthon vezérlő szkript, ez a rendszer agya. GPIOk nincsenek használva rajta. ezen kívül egy transmission kliens + USB-s külső vinyó.

van több NodeMCU v1 board (esp8266) szerte a lakásban ill. az udvaron, ezek végzik az operatív műveleteket. a firmware Arduino IDEben írva. a GPIO-k vegyesen be- (jelenleg csak nyomógombok) és kimenet (relé modul: világítás, kapunyitó motor kontakt) vannak felhasználva. MQTT protokollon kommunikálja le a vezérlési üzeneteket a RPivel.

a rpi-n futó okosotthon vezérlő backendhez tartozik még egy reszponzív webes felület (lehessen udvari lámpát kapcsolni + kaput nyitni telefonról a kocsiból). a pi a rádugott PC hangfalon be tudja mondani, hogy mi lett le/felkapcsolva, vagy minek mi az állapota, emellett webrádiót is tud szolgáltatni, ami ugyaninnét kapcsolható.

kimondottan a biztonság részével még nem volt időm foglalkozni, majd az érettségi meg az ebből adódó káosz után talán...

az MQTT broker természetesen csak a LAN-on belül elérhető, két wifi - két külön alhálózat van itthon, a "vendég" (de persze jelszavas) wifi alhálója az interneten és a privát LANon lévő raspberry 80-as portján kívül mást nem ér el.

saját fejlesztés, néhol spagettikód :-) több modulból áll, python-ban vannak írva. amint elfogadható állapotba kerül, tervezem publikálni az egészet.

az egyik a webes felületről érkező be/kikapcsolási parancsokat dolgozza fel

van egy másik, ami az ESP-ktől 5 másodpercenként érkező heartbeat (GPIO-k állapota, uptime, wifi rssi) üzeneteket figyeli, az állapotadatokat kirakja egy fájlba, amit a webes felület (php) dolgoz fel és jelenít meg. ha 10 mp. elteltével sem érkezett heartbeat üzenet az adott modultól, úgy az UI inaktívnak titulálja.

van még több kisebb másik, webrádió be- és kikapcsolgatáshoz, TTS-hez, stb.

Jól hangzik. Érdekelne, bármilyen is a kód. :)
Az ESP-k hogyan küldik az adatot? HTTP POST, JSON, valami más?
A sűrű írás nem fekteti meg azt SD kártyát a RPi-ban? Én létrehoztam egy néhány kB-os RAMdisk-et, oda írkálom egy hasonló projektnél a hőmérőkből 750ms-onként kiolvasott adatot.

Ez engem is érdekelne. Most egy Rpi-re csatlakozik egy ds18b20 és egy dht22. Ezektől rögzítek 5 percenként adatokat egy RRD adatbázisba. 10 percenként kigyűjti egy highcharts megjelenítéshez az adatokat.
Kíváncsi lennék meddig bírja majd, a kártya már vagy 3 éve megy benne. Ha valakinek van tapasztalata, megoszthatná.

--
Lenovo Z580, LMDE 2 & Xfce

En pl azert nem hasznalom oket, mert a legtobb megprobal tul altalanos lenni, es olyan eseteket/eszkozoket tamogatni, amire semmi szuksegem, cserebe viszont legalabb nagyok es lassuak.
Ha en irom magamnak, azt fogja tudni amire szuksegem van, es en is tanulok kozben. Ami szamomra nem utolso dolog ;)

https://home-assistant.io
Próbáld ki és utána itelkezz. Semmi sallang nincs benne ha nem akarod.
Magad szerkeszted a konfigot is.
Néhány példa segítség miatt, te is mgoszthatod a sajátodat is https://home-assistant.io/cookbook/

Ez meg néhány sablon

https://home-assistant.io/components/#all

jó dolgok ezek, a home-assistant-ot néztem, sok dolgot ismer.

De.

Számomra a legfontosabb szempont az üzembiztonság. Pl. nem nagyon szeretném, ha a RPI, amin fut a home assistant pont akkor darálná le az SD kártyát, amikor épp külföldön vagyok. De a filesystem crash bármikor megtörténhet egy SD kártya esetén... vagy egy sima áramingadozás vagy egy vaku villantás... legbiztosabb módja az egésznek, ha readonly módban van egy bekonfigurált watchdog-gal.

Viszont akkor már kicsit bonyolódik, pl. a beállítások tárolása... én személy szerint inkább tárolnám a beállításokat valahol egy spéci partición (binárisan, nem használva semmi filerendszert) az sd kártyán vagy egy i2c-s eepromban. És ezeket már nehezebb összehozni egy ilyen szoftverrel.

Az, hogy égve marad a nappaliban a világítás, a kutyát nem érdekel. de pl. a fűtés vezérlése nem vicc. nagyon nem vicc, ha szoftverhiba miatt bekapcsolva marad a kazán napokig.

És akkor ott tartunk, hogy bizonyos dolgokat jobb ha rábízunk egy arduino-ra, mint egy ilyen bonyolult rendszerre.

sub, nalam is tervben van hasonlo.

Nekem is folyamatban van egy ilyen "okos otthon" szerű rendszer.

Alapvetően modulosra terveztem:
- A központi vezérlést RPi-vel gondoltam
- Az RPi-hez i2c keresztül több RS485 busz illesztők kerülnének (1 modul 4db RS485-öt támogat)
- Az RS485-ös buszokra vagy 1-1 vagy több felfűzött modul kerülne az alábbiak közül:

- 4 bemenetet és 4 relés kimenetet tartalmazó modul (pl.: elektromos redőny vezérlés)
- 12db relét vezérlő modul (központi világítás vezérléshez)
- 12db FET-es 24V-os kimenet, 2db SSR és 2db normál relé, 3 bement és 1 buszos hőmérőket vezérlő modul (radiátoros és/vagy padlófűtéshez)
- termosztát modul LCD kijelzővel, gombokkal (hőmérséklet beállításhoz), 4db bemenet és 4db kimenettel, szintén buszos hőmérőkkel (DS18B20; pl.: levegő és padló), infra távirányitó vevővel és hangjelzéssel (pl.: ébresztés funkció vagy csengő) illetve páratartalom szenzor
- riasztó szerű modul, 8db analóg ADC bemenettel (NO/NC/EOL/DEOL stb)

- tervezek még egyszerű POE és mikrofon illesztés RPi-hez (ez még nincs meg) ami egyrész kezelő felületet, kaputelefont és házi intercom-ot is szolgáltatna egy-két szobába

A modulok nagyrésze megvan (még a termosztát firmware-n kell fejleszteni), a modulokhoz minden helységbe riasztó kábelt húztam be (táp+RS485). A világítást némi + kábellel egy központi helyre vezetékeltem. A közoponti fűtéshez meg a csövek mellé rakatta le kábelt (thermo motoros szelepmozgatóhoz: 24V-os sacc/kb 3 perc alatt nyit/zár)
A modulok alapvetően buták, csak azt csinálják ami a központi vezérlő mond (M-S): elküldik a bemenetek állapotát és úgy állítják a kimeneteket amilyen parancsot kapnak.

Csak a fejlesztéssel lassan haladok, mert mindig valami fontosabb :(

rpit semmiképp. játékszer, nem valo ilyenre.
a beaglebonebol nemhiába van ipari változat olyan hőmérséklettartománnyal, nekem azon megy a tesztüzem(sima van nekem, nem ipari).

http://dev2.hu/gumiszoba/bb1.jpg

csináltunk hozzá CAPE-et, rs845, rs232, optoleválaszott DI, mcp23017, w1, dht11, pwm, 4 AI pt1000re. pl csináltam kernel modult impulzusos átfolyásmérőre, device treevel, mindennel.

------------------------
Jézus reset téged

RPi-re egy az egyben én sem mernék rábízni ilyen feladatot.

Úgy terveztem, hogy minden modult, ha nem kap parancsot, akkor a watchdog reset-elje. Így ha bármi gond van (kábel, buszmeghajtó vagy vezérlő) és nem poll-ozza senki, akkor alaphelyzetbe áll, vagyis minden kimenetét lekapcsolja.

Ha a központ nem látja a modult, akkor meg el tudja venni tőle a tápot, ezzel újraindítnai, ha ez sem sikerül akkor meg véglegesen (itt majd meg kell nézni mi lett).

A központi részen is két vezérlő lesz, az egyik aktív a másik meg tartalék. Akármilyen okból meghal az aktív eszköz, akkor átveszi a helyét a tartalék. A tartalék persze ethernet-en szinkronba tartja magát az aktív eszközről.

Én úgy gondolom minden funkciót legalább duplázni kell. Ezt vagy fizikailag: pl. 2db vezérlő vagy vagy logikailag pl. 2 különböző eszközzel is le lehet kapcsolni a fűtést/világítást.

Olyat mondjatok nekem, hogy kapcsolo, ami ajto becsukott allapotat kepes erzekelni, ajtokeretre applikalva.

Az a bibi, hogy ehhez kell AC 220V aljzat.Az ESP -nek DC 5Volt kell tudtommal.
Nem vagyok még túl okos ebben, de biztos van olyan átalakító, ami egy DC 12Voltos elemet lekonvertál 5Voltra, és akkor esetleg elmenne 12Voltos A23 elemről https://p1.akcdn.net/full/399784970.duracell-mn21-lrv08-a23-12v-elem-10pp040006.jpg is.
Tudtok ebben segíteni ?

Hoppá !!
Most hogy kicsit utána néztem , látom , hogy a NodeMCU megtáplálható 20 Voltig a VIN -lábon keresztül...
Akkor tárgytalan a kérdésem.

Mivel ezek kb. 50-55 mAh-ás elemek, így ha 100%-os hatásfokkal konvertálod alacsonyabb feszültségre, akkor sem mégy vele sokra. Arra tippelek, hogy egy ilyen felhasználásnál maximum a modem-sleep üzemmódot használhatod. Olyankor viszont kb. 15 mA az áramfelvétel. De még light-sleep módban is legalább 0,5 mA az áramfelvétel. Ekkor is maximum 1-2 hetet bírna ki az eszköz egy elemmel.
(https://www.losant.com/blog/making-the-esp8266-low-powered-with-deep-sl…)

Még egyszer átgondolva a dolgot: Ha reed relével egy reset impulzust generálsz az RST lábra (pl. monostabil multivibrátorral), akkor akár deep-sleep módban is lehet a modul. És akkor – talán – 1-2 hónapot is kibír az eszköz, attól függően, hogy milyen gyakran van nyitogatva az ajtó. Ebben az esetben egy 18650-es, ~3000 mAh-ás akkumulátorral már elfogadható ideig működne egy feltöltéssel.

Rákötöd az RST lábra az ajtónyitás érzékelőt és voila... :)

A 12 órát is meg tudod oldani, rádió és modemet kikapcsolva küldöd deep-sleep állapotba, maximális időre, amiből felébred, kiolvassa az RTS memóriába tett számlálót és elalszik újra, ha még van mit aludnia. Aztán ha azt olvassa ki az RTS-ből, hogy full felébredhet, akkor az utolsó maradék deep-sleep után már rádióval és modemmel ébred.

Vannak trükkök, amivel jól lehet gazdálkodni az akkuval. A saját deep-sleep azért jó, mert akkor az RTS memóriába le tudsz tenni plusz információkat (például a WiFi kapcsolat paramétereit és akkor meg tudsz úszni egy teljes SSID scan időt ébredés után, sokkal gyorsabban kapcsolódik és ezáltal sokkal tovább húzza akkuról).

Ha jól olvasta egy fórumon, akkor a ESP.deepSleep(0) esetén akkor ébred fel, ha a RST -lábra GND érkezik, mondjuk egy gombbal, vagy reed reléról.
Így akármeddig alvásban marad, ha fel nem ébresztik. Ekkor elvégzi a dolgát (ajtónyitásnál elküldi a Wifin keresztül, hogy 'Ajtót kinyitották'), aztán visszamegy deep sleep-be)

Ha jól értettem.

Ebben az esetben igen.

Ha viszont megadod, hogy mennyi idő legyen a deep-sleep, akkor a megadott időben a GPIO16 lábat le fogja húzni GND-re. Ha ezt összekötöd az RST lábbal, akkor önmagától fel fog ébredni. Mindez rajtad múlik.

Én javaslom, hogy időnként ébredjen fel és jelentkezzen be, közölje minimum a tápfeszültségét, különben nem fogod észrevenni, hogy azért nem ébredt fel hetek óta, mert senki nem jött be vagy azért, mert lemerült vagy azért, mert megdöglött.

A WEMOS önmagát ébreszti, tápot ad a szenzoroknak, leolvassa a mért értékeket, elküldi azok és visszaalszik:
https://iotguru.live/measurement/4a984bc0-00cd-11e7-832f-2b6139351b1b/v…

Egyébként az RST lábon fel tudod ébreszteni, tehát ha van valami esemény és azzal le tudod húzni az RST lábat GND-re, akkor bármikor fel tudod ébreszteni az ESP-t.

Apam regen (nagy belmagassagu hazban) az ajto felso reszere szerelt egy rudat, ami egy mikrokapcsolot nyomott be. Ennel nem sok egyszerubb van. (max. megengedett feszultsegre es aramra persze figyelni kell)
Ehhez hasonloan szoktak megcsinalni a hutokben a vilagitas kapcsolojat is, csak ott tipikusan az ajto belso oldala nyomja be a kapcsolot.

A riasztosok pedig az ajtoba be szoktak furni egy magnest, a masik oldalon pedig egy (bonto) reed relevel figyelik. Ezt eleg jol el lehet rejteni, ami esztetikailag elonyos (plusz biztonsagi szempontbol is). Riasztos boltban beszerezheto.

--
A strange game. The only winning move is not to play. How about a nice game of chess? - Wargames

Levegőminőség mérésére vannak szenzorok és technikák? Nem feltétlen (csak) a szénmonoxidra gondolok, hanem inkább egy helység levegőjének elhasználtságát mérném (ha lehet). Nem nagyon kutattam még utána.

Az MQ sorozatban van mindenfele gazdetektor 2-3 USD kornyeken. Kicsit tobbert szallo por erzekelot is kapsz.
Ha "levego elhasznaltsagot" akarsz merni, akkor a CO2 az erdekes, arra nem tudok ennyire olcso erzekelot. (van arra is, kb. 10x aron)

--
A strange game. The only winning move is not to play. How about a nice game of chess? - Wargames

Ha mar indult ez a topic, nekem is lenne egy kerdesem.

Van egy Colibri 11 tipusu 2 szalas termosztatom, ami ugy fest, hogy eloregedett es pontatlannal valt. 19 fokra van kb allitva, es megis bekapcsol a futes, holott a helysegben kb 22-23 fok van. Amiket olvastam rola, azok alapjan ennel joval pontosabb kellene legyen. A homersekletet egy RPi2-re kotott DHT22 szenzorral merem.
Ha mar cserelem, jo lenne kicsit okositani is rajta :}. Ahogy nezem a leirasat, ez egy sima rele, ami ki-be kapcsol a homerseklet fuggvenyeben. Ha ez igaz, akkor egy a RPI2-rol vezerelt relevel helyettesitheto lenne.
Van valakinek erre vonatkozoan valami tapasztalata, esetleg kesz javaslata/megoldasa?

Elore is koszonom.

Sic Transit Gloria Mundi

Én egy Siemens S7 200 212 CPU szereztem be az eBay-ről (24 DI 22 DQ)

Fűtés és klímaszabályozást csináltam belőle, az érzékelők és a mágnesszelepek is szabványos ipari jelszinteket adnak ki magukból illetve fogadnak. Bemeneti jelek a hőmérséklet szenzorok, és ablaknyitás értékelők. Kimeneti jelek a mágnesszelepek, kazán kapcsoló, szivattyú, és klíma kapcsoló. A fűtést kapcsolgatás távolról egy ESP8266-al (kimenetet egy optocsatolón kötöttem a bemenetre) történik. Igazából egy Logo is bőven elég lehet a feladathoz, de ez volt jóáron ezzel a rengeteg digitális be és kimenettel. Egy S71200 vagy 1500-hoz ha megveszem a bővítőmodult, az már horrorisztikus árban lenne, valamint amikor megvettem ezt a CPU-t akkor még bontva nem is nagyon volt vaterán, ebayen ilyesmi. Így az egész ipari megoldás, gyakorlatilag egy rPi+GPIO árából megvolt. A CPU is 230V-os, így még külön táp sem kell neki. A szelepekre, szenzorokra is elköltöttem egy halom pénzt: http://www.futesuzlethaz.hu/shop/667-motoros-szelepek-gombcsapok, de azt egy rPi vezérlő esetén megvettem volna. Azt azért hozzáteszem, hogy aki nem jártas PLC programozásban, annak jobb valami Arduinos cucc. Nekem a PLC jobban kézreáll. Amúgy lehet kapni elég jó áron Siemens vonalon S5 vagy S7 200-at vagy régebbi Omron cuccokat is, amik világvégéig is megbízhatóan tudnak működni. Itt van pl.: http://www.jofogas.hu/pest/Siemens_S7_200_plc_60636877.htm?first=1

Valami megjelenites nincs hozza? Egy jo kis TD200? :}

Par evet dolgoztam S7-200 tipusu PLC-vel, ugyhogy ha oda jutok, hogy valami komolyabb szabalyozasra lesz szuksegem biztosan PLC vonalon indulok el, de azert a Siemens S5 az lehet, hogy kicsit tul hardcore lenne :}

Sic Transit Gloria Mundi

Tulsagosan nem erdekelt a dolog, csak mondta Robi amikor vettem a relay shieldet tole, hogy ovatosan, mert nem 110% quality a tervezes :(
Ha felhivod tavir Robit, biztos szivesen elmondja :)
---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

Ahja, majd utánanézek. Van leválasztott shield is, majd azt is üzembe állítom. :)

Egyelőre még a szobákat építem, ha az kész, akkor jön a fenti projekt... de csak praktikus dolgokat szeretnék, halálcsillagot nem akarok építeni, mint ahogy olvasom egyeseknek a terveit. :)

Erről van szó?

  • https://ae01.alicdn.com/kf/HTB1oAJJOpXXXXXCXXXXq6xXFXXXY/Relay-Shield-V…
  • Nézve a NYÁK rajzolatát, nem sokat gondolkodott, aki tervezte. Ugyan a relé érintkezői és a kivezetések közt két kimart csík is van, ami arra utal, hogy látta már, hogy ilyesmit szoktak csinálni, de nem tudta, minek. A törpefeszültségű résztől a potenciálisan 230V-on lévő vezetősávokat úgy negyed milliméterre tette.

    Semmiképp ne használd 230V-ról! Bár nem írja, hogy megteheted, de azt sem, hogy tilos. Márpedig a relére rá van írva, hogy 230V, és aki nincs képben, szerintem simán ráköti.
    (Én ilyen 230V-os shieldet nem lennék hajlandó tervezni, mert az alatta lévő elektronikától nem tudok biztonságos szigetelési távolságot garantálni, lévén az a jó ég tudja milyen lehet még.)

    Ja, ilyesmi... a NYÁK-ot annyira nem néztem, a rajta lévő relével még nem volt gondom... :)

    230VAC-ra ilyet használok: http://www.ebay.com/itm/131754538057

    Ez optikailag leválasztott, illetve a relé törpefeszültségű részéhez külön tápot lehet adni, így teljesen külön van az erősáramú rész, az optocsatoló vezérelt oldalán a törpefeszültségű rész és az optocsatoló vezérlő oldalán a gyengeáramú rész.

    Ezeket a releket en semmi kritikus es igazabol nagyfogyasztasu dolgokhoz nem hasznalom - ugyanaz a 8 csatornas rele kapcsolja nalam 6 csatornan a padlofutes 3W fogyasztasu csapnyitogatoit. Szinten ilyen rele kapcsol nehany keringetoszivattyut. Ezek nem nagy fogyasztok es pont nem erdekes hogy porognek kapcsolaskor. Vannak olyan alkalmazasok mikre ezek pont tokeletesen megfelelenek es egyeb moka overkill lenne. Ha meg athuz akkor elszall a $5-os nodemcu amibol ugyis tartok tartalekban vagy 6-8-at... Fogyoalkatresz :)

    Ezt találtam WeMos D1 Mini relay-re keresve, gondolom, mind ugyanilyen :)

    A 8 csatornást mutattad valahol, viszont a nyákot csak most néztem meg, itt egy kép róla:

  • https://www.sunfounder.com/media/catalog/product/cache/1/image/1800x/04…
  • Ez nagyságrendekkel tisztességesebb munka, legalább a törpefeszültség leválasztása tekintetében. Az már más kérdés, hogy a relé érintkezők forrasztási pontjai nagyon közel vannak a vezetősávokhoz, lehetett volna szebben vezetni, illetve a vezetősávok közt rést kialakítani.
    Ezzel sem szívesen kapcsolnék olyant, amit meg lehet/kell fogni, ha pont a szomszéd relén van 230V.

    Az ember általában nem kapcsol olyat, amit meg lehet fogni... de meglepően sok ilyen tervezés van. Van olyan LED driver, amiben például nincs a 230VAC felől leválasztás, egy maroknyi diszkrét alkatrész van benne, aztán mégis forgalmazzák. Az, hogy mi mennyire van közel, az relatív, ha szétszednél egy szép fehér dobozos gyári eszközt, abban is lenne kritizálni való, nem attól lesz biztonságos, hogy nem szedted szét. :)

    sub
    (kis otthont is lehet automatizálni)

    Sub

    ~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~
    Fedora 25

    +sub
    Egy ideje nálam is folyamatban van, bár eddig csak a szórakoztató eszközök okosításáig jutottam, világítás még nincs benne (de a tervek hogy miből, az már megvan;))
    Amire eddig jutottam:
    - Hangvezérlés (google voice alapon, így tud magyarul, ez pedig asszonynak, látogatóknak is kézenfekvőbb mint az angol)
    - Audio (házimozi erősítő ki/be, hangerő + spotify vezérlése)
    - Video (TV ki/be, hangerő, csatorna váltás, kodi vezérlése)

    // Happy debugging, suckers
    #define true (rand() > 10)

    Régóta gondolkodom én is otthon automatizáláson, garázs-, tolókapu nyitás, helységek hőmérséklet követés, stb. Ami egy ideje komolyan foglalkoztat, hogy a meglévő risztórendszerem úgy alakítom át, hogy a meglévő mozgás- és füstérzékelőket, sziréna, stb meghagyva a jelenlegi központot lecserélem egy okosabb megoldásra. Elektronikához keveset értek így nem nagyon tudom hogyan lehetne illeszteni a meglevő szenzorokat egy RPi vagy hasonló alapú eszközhöz. Van valami öttletetek, hogy milyen bus-os ( 1wire, i2c) megoldással lehetne figyelni az érzékelőket? A software oldali megoldás még nem eldöntött, nézelődöm az opensource home automation rendszerek közt, egyelőre nem találtam olyat ami minden elvárásom teljesítené.

    Ehhez valamennyire azért kell elektonikai ismeret. ADC-t érdemes használni, pl.: valamilyen I2C vagy SPI buszost. Ezek általában több csatornásak (van ami csak 2, de van pl. 8 is).

    Analog rendszerek úgy működnek, hogy az érzékelőbe (mozgásérzékelő) kerül 1 (EOL) vagy 2 (DEOL) ellenállas (értéke központonként változik, emlékeim szerint pl.: bentel 10k, DSC 5,6k). Attól függően, hogy milyen esemény történik (pl.: riasztás, szabotázs) más-más jelszintet fog mérni a központ. A másik megoldás az szokott lenni, hogy egy vezetékre két érzékelőt kötnek ellenállásokkal így a jelszint megmutatja a központnak melyik érzékelő jelzett.

    RPi oldalán folyamatosan mérni kell az ADC-n keresztül a bemeneteket és az így kapott érték megmutatja épp mi történik az adott csatornára kötött érzékelővel.

    Itt van egy példa egy 8 csatornás ADC használatára (a potméter helyére kerülhetne pl. egy EOL/DEOL-os érzékelő):
    http://www.lediouris.net/RaspberryPI/ADC/monitor-12v.html

    Itt egy EOL/DEOL bekötésről egy kis leírás:
    http://users.atw.hu/ketvillbt/epitoipari_portal_biztonsagtechnika_dsc_z…

    Szóval nem triviális a megvalósítás és szükséges hozzá valamennyi elektronikai ismeret is.

    Ezen túl vannak busz rendszerű eszközök is, itt meg magát a protokolt kell implementálni az RPi oldalán, de itt is szükség lesz valamilyen illesztő áramkörre.

    (rejtett feliratkozás)
    Próbáltatok már redőnyt vezérelni? Ebben a hónapban költözöm a saját lakásomba, utána nekiesek az automatizálásnak én is. Világítás terén Philips Hue, de a redőnyöket hogyan lehetne automatizálni? A TV és a PS4 bekapcsolásával már kisérletezem, bár ez a vacak Samsung alváskor a hálózatról is leszakad, így bekapcsolni csak infrán lehet vagy HDMI-n.
    Vezérlést RPi-n gondolom, nem izgat, hogy nem ipari felhasználásra készült, végülis a lakásom sem egy gyártelep. A jelenlegi LAN-on is egy RPi osztja az IP-t DHCP-n, azon túl, hogy az áramszünetet nem szereti, nincs vele semmi baj.
    Vezérlőnek egy RPi v3 + 7" RPi Touch Display + Smarti Touch ház lesz használva, csak valami korrektül kinéző kezelőprogramot kellene találni rá. (ha magam írom a programot, hamarabb jár le a lakáshitel, minthogy elkészüljön a vezérlő GUI)

    Ave, Saabi.

    Redőny vezérlése címszóval mit szeretnél? Csak annyit, hogy este leengedje, reggel megfelhúzza? Vagy fényerő szabályozást? Esetleg kombinálni a dolgot, és ha érzékeli a rendszer, hogy aktiválták a riasztót (elmegy otthonról mindenki), akkor leereszti az összes redőnyt? Ez utóbbi földszinti lakásnál, kertes háznál hasznos tud lenni betörésvédelem szempontjából, pláne ha alumínium redőnyöd van.

    A motoros redőnynél "kézi" vezérlés esetén annyi történik, hogy van le meg fel irányod, illetve 2 végállás kapcsolód. A távirányítón megnyomod az egyiket és abba az irányba jellemzően addig megy, amig vagy a végállás kapcsoló meg nem fogja vagy a távirányítón meg nem nyomod az ellenkező irányt, mert akkor az adott pozícióban megáll. Esetleg addig mozog a redőny, amíg nyomod a gombot. Ez utóbbi baromi idegesítő tud lenni, ugyanis a motoros redőny lényegesen lassabban mozog, mintha kézzel húzod vagy ereszted.
    Én mondjuk olyan vezérléssel nem találkoztam még, ami fényerő szabályozásra az adott helyiségben rendesen működött volna. Mindig mindegyik szar volt, ha kicsit napsütés érte az érzékelőt, akkor pánikszerűen éjszakai sötétséget csinált az adott helyiségben, és kézzel mindig bele kellett nyúlni.

    Az a része érdekel, hogy nyomógombok helyett hogyan lehetne mikrovezérlővel vezérelni. A többi extrát majd megoldja a lakásvezérlés - OpenHAB, Home Assistant, akármi - a lényeg, hogy nem a falra akarok kapcsolókat. Azt tudom, hogy vannak úgynevezett csőmotorok, amelyeket a redőny tengelyébe kell beszerelni, így nem a jelenlegi gurtnit kell huzigálni valamilyen csörlővel, de ezekről a motorokról ennél többet nem tudok. Amit láttam, ott volt a falon két kapcsoló, azokkal lehetett felhúzni és leengedni, de én nem akarok kapcsolókat nyomogatni, legyen az szépen távvezérelt.
    Utána már megoldom, hogy pl. ha filmet akarok nézni, akkor ezt jelzem a lakásvezérlésnek - mondjuk szóban - az pedig bekapcsolja a TV-t és napszaktól függően leengedi a redőnyt vagy halványítja a világítást.

    Ave, Saabi.

    Ha a redonyeid motorosak akkor mar nyert ugyed van. A fali kapcsolo moge beepitesz kis modulokat (Zwave pl) ami kimondottan redonyvezersere vannak es beallitod oket a neked tetszo Openhab, Home assistant stb-be.) Ha nem motorosak akkor eloszor ott kell kezdeni hogy aramot vinni oda, redonymotort beszerelni -a tobbi intezi ujra a modul vagy akar relezhetsz is mondjuk egy NodeMCU-val.

    Van infrás távirányító is, csak az drágább. Ahol kevésbé szépen oldják meg ott egy szerelődobozt akasztanak kívülről a falra a redőnytokjának a közelébe, és abban van a vezérlés, ami a csőmotornak adja a parancsot, hogy mit és meddig csináljon. Illetve innen van legáztatva az áram a csőmotornak. A csőmotor egy végtelenül ostoba szerkezet, egy villanymotor, ami képes két irányba forogni attól függően, hogy hogy kapja az áramot. Semmiféle "intelligenciával" nem rendelkezik.
    Mondjuk nem tudom a csőmotorok árát nézted-e már. Lehet, hogy dobsz egy hátast tőle, sajnos nem olcsó dolog. Persze ebből is van occó. Az meg annyit is ér. Ezeknél a motoroknál nem árt figyelembe venni, hogy télen a mínusz 10-20 fokot is bírnia kell, nyáron meg a redőnytokban simán lehet 50-60 fok is, és a redőnyt akkor is le kell tudnia engedni vagy fel kell tudnia húzni. Ezeket az üzemi körülményeket az olcsóbb, gagyi csőmotorok huzamosabb ideig nem bírják.
    Illetve az sem mellékes körülmény, hogy a redőnyben műanyag vagy fém tengely van (erre tekeredik fel a redőnyléc, amikor fel van húzva, illetve ez tartja az egész redőny súlyát, ami egy nagyobb ablak vagy ajtó esetében komoly kilókat jelent). A csőmotorhoz kell a fém tengely, mert a műanyagot úgy eltekeri (deformálja, néha el is töri), mint a sz@rt. Viszont a redőnyőnyösök a profit maximalizálása érdekében előszeretettel használnak már vagy jó 10-15 éve éve műanyag tengelyt és tárcsát (erre tekeri fel a gurtnit a redőny, ha kézi mozgatású). Ha a redőnyös korábban asztalos volt, akkor belefuthatsz fa tengelybe is, ami szintén cserés, mert az tömör, nem tudod a csőmotort belerakni. Szóval mielőtt belevágsz, érdemes a redőnyt átnézni belülről, hogy mi van benne. A fém tengely egy horganyzott nyolcszög keresztmetszetű cső szokott lenni, rengeteg kicsi lyukkal, ami arra szolgál, hogy az utolsó redőnylécet beleakasszák fémkampókkal.

    A vezérlésre szerintem rá lehet kötni egy mikrovezérlőt, hogy épp melyik irányt bökje meg a csőmotor vezérlésén. De ehhez a részéhez már nem igazán értek.

    Köszönöm a választ, sokmindenre rávilágított. Például, hogy bár tavaly nyáron szerelték fel a redőnyt, jó eséllyel cseréltethetem ki az egészet. Mivel a ház mellett futó vasút felújításának keretében cserélték a nyilászárókat a vasútra néző lakásokon és redőnyt az kapott, akinek korábban is volt, gyanítom, hogy nem a legdrágább redőnyt szerelték be. Nem lepne meg, ha műanyag tengelyes lenne. Ha már cserélek, akkor meg nyilván olyat kellene venni, ami már eleve motorizált. Nem lesz olcsó, de a luxus sosem az.
    Tehát ezeknek a motoroknak eleve van valamilyen vezérlése, nem a 230-at kapják meg direktben. Ez azért megnyugtató. Akkor most elkezdem túrni a netet egy redőnyöst keresve, aki elintézi a redőnycserét. Mondjuk nem sietős, van más költenivaló is a lakásban.

    Ave, Saabi.

    Egy-két megjegyzés:

    A motoros rendszerhez műanyag helyett aluminium rendőnyt szoktak javasolni. Egyrészt halkabb, másrészt nehezebben akad el, ráadásul itt lehet feltolás gátlót berakni. Persze ez még mindig csak redőny nem rács.

    Egy tipp: létezik redőny + szúnyogháló. Ekkor a szúnyoghálót redőnyhöz hasonlóan fel-le lehet húzni a rendőnnyel egybeépített sínben és tokban (a tok ekkor néhány cm-el nagyobb. Ez azért lehet hasznos, hogy télen ha nincs szúnyog fel lehet húzni és valamivel világosabb lesz az ablak + nem kell fel/le szerelni.

    Maga a csőmotor az 230-ról működik. Ebből előfordul 3 vezetékes, de szerintem 4 vezetékest érdemes választani (a védő föld is ki van vezetve). A vezérlése faék egyszerűségű: egy vezeték nulla, ami fixen be van kötve. A másik kettő meg a fel és a le irány. Ezekhez lehet kapni távirányítós rendszert kapni, ekkor a vevő elektronikája fogja kapcsolni az áramot a rendőnymotorra.

    Az ultimate megoldás valóban az alu redőny. Az jobb hő- és hangszigetelő is, ami vasút mellett nem mellékes szempont. Viszont a műanyag és az alu redőny ára között van egy nagyságrendi különbség. Az árakra már nem emlékszem, mikor aktívan csináltuk, akkor kb. háromszoros ára volt,mint a műanyagnak.
    Mondjuk az biztos, hogy ha egyszer eljutok odáig, hogy redőnyt kell csinálni, akkor alu redőny lesz. A németeknél pl. magát a fogalmat sem ismerik, hogy mi az a műanyag redőny. :)

    Nana, vigyázzunk! a "semmiféle intelligenciával nem rendelkezik" egy elég merész kijelentés.
    következöt javaslom: a kiszemelt csömotorok adatlapját alaposan meg kell vizsgálni, és megnézni, mekkora az a szivárgó áram(leak current), amit még elbír. Illetve azt is meg szokták adni, hogy szabad-e félvezetökkel a motort irányítani. Az elektromos végkapcsolókkal rendelkezöket álltalában nem szabad (de ettöl függetlenül müködhetnek!). Ennek oka, hogy a felsö és alsó poziciókat úgy tudod beállítani, hogy a fel és le gombokat nyomod meg egyszerre -> ez által aktiválod a programozási móduszt. Ha viszont a félvezetöböl mindig szivárog egy pár mili vagy mikro amper, az állandóan bekapcsolhatja a programozási funkciót. Azt is meg kell nézni, mennyi a minimális idö a fel és le parancs között, aminek el kell telnie. Az ilyen digitális végkapcsolóval ellátott csömotorokat simán lehet relékkel meghajtani. Ajánlott az egymást kölcsönösen kizáró bekötés, hogy véletlenül se legyen a fel és le irány egyszerre meghajtva, pl. programozási hiba miatt (akár tüzveszélyes is lehet különben!).
    [a somfy motorokról egyébként csak rosszat hallotam....]

    Továbbá létezik már buszrendszer az árnyékolókhoz is: SMI (Standard motor interface), ez egy 5 polusú kábel ha jól emlékszem (L,N,PE,I+,I-), gyártótól függöen, akár 16 motort is rá lehet kötni.
    Elönyei:
    - csak egy kábelt kell végigvinni és nem csillagban bekötni az összeset a központba
    - van benne egy encoder, ami pontosan megmondja, milyen pozicióban van az árnyékoló. Reluxáknál akár a pontos dölésszöget is be lehet állítani vele, ami akkor hasznos, ha egész éves árnyékolást tervezünk és a nap helyzetét is figyelembe vesszük
    Hátrányai:
    - drágábbak a motorok
    - drágább az irányítás, DIY-ben nehezebb kivitelezni

    Programozásnál egyébként figyeljünk oda, hogy nagyobb számban csömotorokat min. néhány ezred mp-s különbséggel indítsuk. Ezáltal a bekapcsolásnál kissebb lesz a csúcsáram, amit a kismegszakítók fognak megköszönni... :)
    --------
    HOWTO: Zentyal+Zarafa+Setup+Outlook+Thunderbird+mobilephone sync

    Én első körben a multimédiás egységeket szeretném egy gyeplő alá fogni!
    Kezdetnek mondjuk a TV és a Set Top Box ki-be kapcsolását szeretném hálózatról megvalósítani.
    Erre már létezik ez a megoldás.

    Viszont én több eszköz vezérlésére szeretnék saját appot írni majd.
    És itt jön a kérdés. Van valami API, vagy parancs küldési lehetőség a STB-nak, amivel megmondom neki, hogy kapcsolja be magát, vagy a TV-t?
    Valószinű van, ha a fenti app megtudja tenni, csak ez az egyszeri fejlesztőknek is elérhető vajon? Tudok erről valamit?

    A rendszer lelki nálam is egy R.Pi lenne, ami egy webes felületen szolgáltatná az UI a rá csatlakozó eszközöknek. Ahol pl megnyomom a gombot, hogy TV BR, akkor küld egy parancsot hálón az STB-nek, hogy kapcsolja be a TV-t. Ez gondolom HDMI CEC-t használ, ami igazából nekem mindegy, mert én az STB-t akarom kontrollálni, ami a TV-t kontrollálja :)

    És ennek a webes felületébe bele is lehet nyúlni?
    Mert idővel nem csak multimédiára használnám, hanem más dolgok irányítására is. És az lenen a cél, hogy egy appból lehessen mindent vezérelni. Ha akarom akkor telefonról, tabról, vagy asztali PC-ről.

    És pont ezért akarok egyedi felületet fejleszteni, mert az pont azt fogja tudni ami nekem kell.

    Van ra modul kb 500+ eszkozre jo esellyel csak betolod a modult a konfigba es orulsz. Olyan szinten hogy a presence detection pl annyi hogy platform: icloud, password, username es mar tolja is a csalad iphonejainak a helyzetet. 4 sorbol megvan. Pl egyedul presence detectionre van vagy 35 modulja a tomato firmware-tol az Ubiquity AP-n keresztul az owntrackig. Igazabol asszem meg csak a raketakilovore nem irtak hozza modult, ambar egyik-masik nem tul nagy funkcionalitassal bir, de egyszeru modositani. Sikerelment nagyon gyorsan lehet vele elerni, aztan komplexebb dolgokhoz mar kell kis belenyulas... de altalanos dolgokra es ha nem valami nagyon egzotikus komponensekkel dolgozol alapbol benne van ami kell.
    A web interface modositasa... Azt hiszem ahhoz is irtak mar par frontendet es a CSS meg mindig modosithato.
    A sajat fejlesztessel en ugy vagyok, hogy ha nem muszaj nem talalom fel ujra a kereket, es az idomet inkabb arra forditom hogy a letezot okositsam vagy csinositsam...

    Csak figyelmezteteskent: a Mosquito MQTT broker RPI-n kb 2 orat fordul - de ez egy meccses kor. Adnak a HA-hoz egy uj image-t ami "elmeletileg" mindent felheggeszt ra - kiveve ha a RASPI ugye wifin-n van mert a dolog nincs igazabol beleegetve hanem egy sor scriptet futtat le ami a netrol huzza be a csomagokat - 1x! Amikor legeloszor beinditod az imaget. En persze wifi-re hagytam a RPI-t es mire belottem a WPA supplicantot meg mindent csak neztem hogy ez most akkor miert is dedikalt image - hol van rola a cucc? Nem volt halozata elso indulaskor a draganak - utana meg mar ugy volt vele minek az? Ugy hogy kezzel cimbasztam fel ra akkor ujra mindent... Nem nagy dolog csak tudjal rola :)
    Jah es konfigtol fuggoen a HA indulasa/ujraindulasa akar percekbe is telhet de utana ha felallt akkor mar nagyon responsiv a felulete.

    A Google Home mintájára a hangvezérlés home made megoldásban nagyon elrugaszkodott ötlet? (Hé lakás, engedd le a nappaliban a redőnyt vagy Hé lakás, kapcsold be a TV-t a nappaliban, stb.) Nyilván a google specifikus funkciók kihagyásával gondoltam a hangvezérlésre.

    Fentebb írtam, nálam így működik.
    Amit én használtam
    - snowboy (hotword detection)
    - google speech api (speech to text, tud magyarul)
    - raspberry pi 2
    - jó minőségű mikrofon (nálam egy ps3 eye szolgáltatja ezt, mivel 4 minőségi mikrofonja van, line array-ban elhelyezve így lehetőség van echo/noise cancellation -ra és beamforming-ra)

    A google speech api ingyenes reggel nem elérhető (mindenképpen meg kell adni hozzá bankkártyát, stb), viszont az ingyenes keretet eddig még nem sikerült túllépni (havi 60 perc recognition ingyenes, felette $0.006 15 sec-enként)

    Össze lehet barkácsolni shell scriptből is, viszont ha van némi c/c++ tudás, akkor a speech api grpc protokollját ajánlom (én is ezt használom).
    Így az egész (hangkártya olvasása / hot word detection / speech recognition) zökkenőmentesen és azonnal megy, ráadásként a grpc on the fly felismerést is támogat.

    // Happy debugging, suckers
    #define true (rand() > 10)

    Én inkább a gyári cuccok felé veszem az irányt.
    Az elko-ep-el jó a kapcsolatom így (Bár ez bujtatott reklám lesz) az ő eszközei fognak a számításba jönni.

    pch
    --
    http://www.buster.hu "A" számlázó
    --

    Azert a gyari cuccokkal az a gondom hogy az integralasuk eleg nehezkes es sok esetben nem is mindig lehetseges.
    A buli ott kezdodik ha minden beszel mindennel - Hangfelismeres: "Alexa tell Home to start Star Wars on livingroom kodi and set movie scene"
    Az eredmeny: bekapcsol a TV kivalasztja a HDMI source-t, a kodi elinditja a filmet es a lampak kialszanak a nappaliban. Aztan ha csengetnek a kapunal akkor a kodi lepause-ol es picture-in picture-ben feljon a kapucsengo kamera kepe. Ezt tudomasom szerint nem sok gyari cucc csinalja meg mert nem beszelnek a kodi-val pl.

    Nalam fhem csinalja ezt (A Home-Assistant bar jo de nem tud eleget a kodi-val es a TV-immel). A kapcsoloim ZWave, a futes HomeMatic, meg egy rakat ESP8266 relevezerlesre a padlofuteshez, kazanautomatika, garazskapu stb. )

    Tudom hogy nehezkesebb es tobb a munka kezzel osszerakni de semmi gyari cuccot nem talaltam ami normalisan integralhato lenne mas eszkozokkel mint a sajatjai ami nekem nagyon keves.

    Ezt tudja :)
    IMM szerverbe megy minden.
    Lehet vezetékes/vezeték nélküli.
    Tudja a képátlövést (egyik helységből a másikba) szinkron lejátszást, kaputelefonkor pause és kép kirak etc.
    Amit nem tud az a hangvezérlés.

    http://www.elkoep.hu/termekek/audiovideo/videozona/videozonaimm-server/

    pch
    --
    http://www.buster.hu "A" számlázó
    --

    Ilyet esetleg már próbált valaki?
    Elsősorban az érdekelne, hogy egy Home Assistant-al lehet-e kapcsolgatni. Mert ha igen, akkor veszek egy tucatot! :)

    Fyi
    A neten bongeszve, en talaltam homekit megvalositast esp-re, erdemes utanakeresni ha meg nem nezted.

    Ui: asszem ez https://github.com/HomeACcessoryKid/ESP8266-HomeKit/blob/master/README…
    ---------------------------------------------------
    Hell is empty and all the devils are here.
    -- Wm. Shakespeare, "The Tempest"

    Kiprobaltam, par dolgot modositani kellett benne, de mukodonek tunik. Energiagazdalkodas nincs, a 200mAh akkut, amirol a homeroim mennek kb 2-3 ora alatt leszivja ebben az allapotaban, de kiindulasi alapnak mindenesetre egyszerubb, mint a teljes stacket magamnak implementalni.

    ---
    Apple iMac 27"
    áéíóöőúüű

    Egye fene, veszek kettőt próbálgatni. ha bejön, akkor erre építkezem a dolgok kapcsolgatásával kapcsolatban :)

    Már csak egy valamire lennék kiváncsi: Vajon ha a manual switch-el kapcsolom be, akkor szoftveresen ki is tudom kapcsolni? Illetve fordítva: ha progival kapcsolom be, akkor a kis gombjával ki?
    A logika azt diktálja, hogy igen. Jó lenne, mert akkor megoldható lenne a manuális és szoftveres kapcsolgatás is, ha a kis gombot kivezetem pl. egy pillenő kapcsolóra.

    Alapvetően igen, de ha például egy villanymotort vezérelsz, az azt jelenti, hogy ismert bemenetre lesz egy ismert kimeneted, nincs szabályozási visszacsatolásod. Ettől még lehetnek érzékelőid, amelyek a villanymotor állapotát figyelik és hibát jeleznek, ha valami baj van.

    Tipikus példa az, hogy felkapcsolod a világítást: van visszacsatolásod, hogy világít-e, de azt nem a szabályzásra használod, hanem arra, hogy a hibát észleld és elhárítsd.

    Elvi síkon választható el a két fogalom. Szabályozás során a kimeneti jelből hibajelképzés után a bemeneten előállítanak beavatkozójelet, míg vezérlésnél nincs ez a klasszikus "jelvisszacsatolás". Vezérlésnél modellek és algoritmusok számítják ki a vezérlőjelet a bemenetre kötött jelek (érzékelők) alapján. A szabályozás "olcsó és lassú", a vezérlés "drága és gyors". A feladat határozza meg hogy mire van szükség. Pl. egy helyiség hőszabályozása tipikusan szabályozási feladat, míg egy eszterga vagy robot működtetése tipikusan vezérlési feladat. A vezérlés nem azt jelenti hogy a szervomotoroknak ne lenne rezolvere, útadója stb.

    En nem ertek az elmeletehez - kb 20 eve hallgattam utoljara vezerlestechnikat de eppen eleget buzeraltam ezeket az dolgokat a gyakorlatban hogy tudjam visszajelzes nelkul ezek az eszkozok fellabu oriasok.
    Tegyuk fel, hogy a vezerlesem ujraindult - (uj configot toltok be, mittomenmi) - honnan fogja akkor tudni a programom hogy milyen allapotban van az a kapcsolo ami a vendegszobaban van? Vagy pedig felkapcsolom a lampat a tab-rol, a kutya pedig pont ott kezdi el keresni a teniszlabdajat az asztal alatt es megboki a kapcsolot(fizikailag). Honnan tudja akkor a rackszekrenyben ulo vezerlesem, hogy a lampa kikapcsolt?
    Gyakran ugy van ez megoldva pont ezekkel az ESP8266-okkal hogy MQTT protokollt hasznalnak. Az eszkoz kuld az allapotarol egy publish-t egy MQTT topikba ("lakas/vendegszoba/lampa/allapot") pl hogy "status:on" - idealis esetben a RETAIN: TRUE flaggal, hogy a keson ebredo vezerlok is tudjanak rola. MQTT-t hasznalva az eszkoz publikal a fenti topikba es fel van iratkozva pl a lakas/vendegszoba/lampa/vezerles topikra es ha azon erkezik egy "switch: on" uzenet akkor atbillenti kapcsolot es visszabublikal, hogy "status:on". Ebbol 2 dolgot tudok: Az eszkoz allapotat es annak megfeleloen szinezem a gombokat a front-enden illetve tudom hogy a parancs vegrehajtodott. Igazabol jo ha az eszkoz mondjuk 5-10 mp-enkent kuld egy publish-t igy ha ezek elmaradnak akkor tudok rola, hogy van valahol valami kutyum ami szeretetre vagyik...
    MQTT-t hasznalva igazabol nem is csak egy vezerles lehet - nalam pl 3 vagy 4 megy parhuzamosan (fhem, home assistant, Home Bridge a SIRI-nek es HA bridge az emulalt Philips HUE-nak az Alexa miatt.) Ilyen modon barmikor barmelyik eszkozom kepes vezerelni azt a kapcsolot es az osszes vezerlologikam ertesul a valtozasokrol. Ha nincs visszajelzesem csak egy "toggle" ahogy te irod, akkor az egesz rendszer borul es nem is kell hozza mas csak egy kutya meg egy teniszlabda. Arrol nem is beszelve hogy fogalmam sincs rola, hogy ha leesik a keszulek a halorol akkor igazabol a pusztaba kiabalom a "toggle" parancsomat.
    Persze mindig oda lehet ballagni es be lehet kukkantani, hogy eg-e a lampa csak abban mi a buli?

    Az enyém ma érkezett meg. NodeMCU került rá. MQTT-vel jól működik. Innen már csak némi kézügyesség a Home Assistant alá berakni.

    A rajta levő kis kapcsolóval is lehet kapcsolgatni a relét, de messziről látszik, hogy nem napi használatra tervezték. Néha prellezik. Ha rendszeresen használni akarod, akkor célszerű kicserélni egy jobbra/tartósabbra. Ezt viszont még a tüskesor beforrasztása előtt tedd meg, mert utána már sokkal nehezebb lesz hozzáférni.

    Nekem ma jött meg. Most nagyon próbálkozni vele nincs időm, de a gyári appal kipróbálnám, csak egy apró gondba ütköztem.
    Vajon mindegy-e neki, hogy az imputnál melyikre kötöm a + és - -t? Konnektorból próbálnám ki egy kis asztali lámpával, de a fene tudja a konnektorban melyik a + és -.
    Két lehetőség van ugye ha rosszul kötöm be: tönkremegy, vagy nem is fog működni.

    „de a fene tudja a konnektorban melyik a + és -”

    Ez könnyű. Egyik sem. Az egyik a fázis (L) a másik a nulla (N). :-) A Sonoffban a nulla megszakítás nélkül megy tovább, a fázis van megszakítva. Szerezz be egy fázisceruzát, és nem lesz többé ilyen gondod. Egyébként a rákötött eszköz működése szempontjából mindegy melyiket hova kötöd. A konnektorban a kék a nulla, a sárga-zöld a védőföld, és a barna vagy fekete a fázis

    Jah, az a gond, hogy nincs fáziskeresőm, de holnap veszek egyet.
    Konnektor nem játszik, mert szürke kábel van mindenhol a falban. Elég régen épített hálózat van itt.

    Addig kipróbálom úgy, hogy nem kötök rá fogyasztót. Ha a fázis helyére a nulla kerül, akkor egyszerűen nem fog működni. Megcserélem, utána jónak kell lennie. És ha jó, akkor jöhet rá a fogyasztó is.

    Mivel ez a modul a váltóáramot vár a bemenetén (nálunk 230 V), és azt kapcsolja tovább, így két lehetőséged van:
    - A LED-et közvetlenül rákötöd. No comment.
    - A LED tápegységét kötöd rá, és akkor működni fog.

    Persze elvileg kisebb feszültséget is kapcsolhatna. Azonban a bemenetére kötött jelből állítja elő a 3,3 V-os tápfeszültséget a saját működéséhez, és a specifikáció szerint legalább 90 V-nak kell lennie a bemeneten. Azt pedig a LED-ek többsége nem szereti. :-)

    Te hogy töltöttél rá firmware-t?
    Én platformIO-val próbáltam, de ezt írja:

    Auto-detected: /dev/ttyUSB0
    Uploading .pioenvs/sonoff/firmware.bin
    error: cannot access /dev/ttyUSB0

    error: espcomm_open failed
    error: espcomm_upload_mem failed
    *** [upload] Error 255

    Elvileg a sonoff flash módban van. Legalább is ha csak simán rádugom a FTDI-re, akkor villog a LED. Ha úgy dugom rá, hogy közben nyomom a gombját pár másodpercig, akkor nem villog.
    Bár erről nem találtam sehol egyértelmű utalást, hogy mi jelzi a flash módot.

    dmesg szerint jó a kapcsolat az FTDI-vel:
    usb 3-1: new full-speed USB device number 15 using uhci_hcd
    ftdi_sio 3-1:1.0: FTDI USB Serial Device converter detected
    usb 3-1: Detected FT232RL
    usb 3-1: FTDI USB Serial Device converter now attached to ttyUSB0

    Korábban én is a Platformio-t használtam. Viszont – szerintem – az egy Arduino IDE helyettesítő, a NodeMCU firmware-t és a lua-t nem támogatja. Így az esptool-lal töltöm fel a firmware-t (https://nodemcu-build.com -ról), illetve utána a fájlokat az esplorer-rel.

    A sonoff esetében, meg kell nyomni a nyomógombot, és utána rádugni az usb portra. Ekkor nem villog, és ilyenkor van flash módban. Én azt tapasztaltam, hogy 57600 baud-dal lehet feltölteni a firmware-t:

    
    python2.7 "$ESPTOOLDIR/esptool.py" --baud 57600 --port /dev/ttyUSB0 write_flash -fm dio 0x00000 image_a_nodemcu-build.com-ról
    

    Kiegészítés:
    De arra is van lehetőség, hogy a platformioval, a „hagyományos” C/C++ megközelítéssel programozd: https://www.losant.com/blog/getting-started-with-platformio-esp8266-nod…
    Ekkor nincs firmware, nincs lua.

    Kipróbáltam a Te féle megoldásodat is, de kb ugyanaz a hiba az esptool.py esetében is:
    serial.serialutil.SerialException: [Errno 5] could not open port /dev/ttyUSB0: [Errno 5] Input/output error: '/dev/ttyUSB0'

    Jó lenne tudni hol a hiba:
    A gép és az FTDI között, vagy az FTDI és a sonoff között.

    Vajon ha az FTDI és a sonoff között van baj, akkor is ezt az USB hibát dobja?

    UPDATE:
    Haladás van. Forrasztásnál lehetett gond. Kellene már vennem egy normális pákát...
    Újraforrasztottam, most a esptool feltölti... majdnem.

    Connecting....
    Auto-detected Flash size: 8m
    Running Cesanta flasher stub...
    Flash params set to 0x0220
    Writing 413696 @ 0x0... 412672 (99 %)
    A fatal error occurred: Timed out waiting for packet header

    Most ezután simán az FTDI-re dugva a sonoff-ot, nem is villog a LED, gondolom nyekk a régi frimwarenek, és az újnak is ami nem ment fel rendesen :)

    Nálam kicsi másként néz ki az esptool kimenete:

    
    esptool.py v2.0-beta1
    Connecting....
    Detecting chip type... ESP8266
    Uploading stub...
    Running stub...
    Stub running...
    Attaching SPI flash...
    Configuring flash size...
    Auto-detected Flash size: 1MB
    Flash params set to 0x0220
    Compressed 588000 bytes to 379359...
    Wrote 588000 bytes (379359 compressed) at 0x00000000 in 66.8 seconds (effective 70.4 kbit/s)...
    Hash of data verified.
    
    Leaving...
    Hard resetting...
    

    Noh, ezzel már nekem is lefutott!

    esptool.py v2.0-beta2
    Connecting....
    Detecting chip type... ESP8266
    Uploading stub...
    Running stub...
    Stub running...
    Attaching SPI flash...
    Configuring flash size...
    Auto-detected Flash size: 1MB
    Flash params set to 0x0220
    Compressed 412016 bytes to 264934...
    Wrote 412016 bytes (264934 compressed) at 0x00000000 in 46.5 seconds (effective 70.9 kbit/s)...
    Hash of data verified.

    Leaving...
    Hard resetting...

    Ki kellene próbálni, hogy jó lett-e...
    A LED halott marad ezzel a frimwarel, vagy ad valami visszajelzést, hogy jó-e, nem jó-e valami?
    Ha hagyom a 3v3-on, akkor is be kellene bootolnia igaz?
    És látnom kellene a wifik között mint a gyári frimware esetében?

    Esetleg feltudnád dobni valahova a Te frimware buildedet? Tennék egy próbát azzal is :)

    Most már van egy firmware a Sonoff-on, ami tartalmazza a lua interpretert, és azokat a library-ket, amiket bejelöltél a nodemcu-buil.com-on. Mivel a lednek nem mondta senki, hogy villogjon, így nem villog. :-) Ha raksz rá egy init.lua nevű fájlt, akkor bootnál végrehajtja az abban levő dolgokat.

    A firmware felrakása után (amin már túl vagy) az ESPlorer nevű programmal tudod a *.lua fájlokat feltenni, illetve futtatni, és egyéb műveleteket végezni. Az ESPlorerben 115200 baudot kell beállítani a kommunikációhoz.

    A Sonoff kezeléséhez a https://github.com/Red5d/sonoff-mqtt címen levő kódból indultam ki. A futtatásához a nodemcu-buil.comon a bit,file,gpio,mqtt,net,node,tmr,uart,wifi,tls modulokat kell bejelölni, illetve én a TLS/SSL támogatást is bejelöltem. Bár szerintem a bit modul nincs használatban, de ebben tévedhetek.

    Mivel nekem kicsit kuszának tűnt a kód, így egy kicsit átszerveztem, és egyszerűsítettem, bár csak annyira, hogy áttekinthetőbb legyen. Így még nem akarom kirakni a githubra, majd ha egy kicsit még pofoztam rajta.

    Amit én használok:
    - firmware: https://drive.google.com/open?id=0B6vL_WRWA3LwSEFtRkYwTjBZV0k
    - init.lua: https://drive.google.com/open?id=0B6vL_WRWA3LweXN0dmNxemRhSjg
    - sonoff.lua: https://drive.google.com/open?id=0B6vL_WRWA3LwSllsRGVGMk9jSjA

    A Home Assistant mqtt protokollon keresztül tudja majd kapcsolni a jelfogót. Maga a kód ennél többet tud, ha Te magad abajgatod egy mqtt brokeren keresztül. Tömören:

    Default NAME=sonoff

    #### Commands (received)
    * Turn relay power on: topic="sonoffctl/NAME", msg="on"
    * Turn relay power off: topic="sonoffctl/NAME", msg="off"
    * Query state: topic="sonoffctl/NAME", msg="state"
    * Change device name from sonoff to kitchen: topic="sonoffctl/sonoff", msg="name kitchen"
    * OTA update: topic="sonoffctl/NAME", msg=ota
    * List connected devices: topic="sonoffctl", msg="list" (topic sonoffctl without NAME!)

    #### Published messages
    * Device connected: topic="sonoff", msg="NAME VERSION connected"
    * Answer to list command: topic="sonoff", msg="NAME VERSION here"
    * Answer to state command: topic="sonoff/NAME", msg="on" or "off"
    * Answer to turn on, off commands: topic="sonoff/NAME", msg="on" or "off"

    Kiegészítés:
    A sonoff.lua elejét szerkeszteni kell a saját környezetednek megfelelően. Az első sort az OTA update miatt nem szabad módosítani. A HTTP fejléc eldobásához van rá szükség.

    Igazából a Tasmota féle frimwaret feltettem most a az esptool-al és már villogott is a LED.
    4 gyors gombnyomásra AP módra vált. Ekkor lehet hozzá csatlakozni és egy webes felületen beállítani a saját wifi elérést.
    Beállítottam és már csatlakozott is hozzá. A webes fellületéről itt már tudom kapcsolgatni, konfigurálgatni => teljes a szabadság :)

    Most már jöhet a Home Assistanttal való összehozás :)

    És ha ez is jó, akkor a másik kapcsoló frimwarejét is lecserélem.

    Van itthon egy DTH11 hő/pára mérő szenzorom. Lehet ezt is majd ráhackelem. Ahogy látom a Tasmota frimware configjában, egy klikkel lehet aktiválni ezt is benne!

    Köszi a segítséget, most már a neheze megvan szerintem :)

    És a Home Assistant is működik!
    Egy régi elfekvőben lévő RPi 1-re került. Nem hinném, hogy kiemelkedő teljesítményű HW kellene ez alá. :)
    A H.A. saját MQTT brokerével remekül működik is a sonoff az immáron új frimware-el.

    Most hogy a szoftverrel így előrehaladtam, jöhet újra az elektronika...

    Én már elkényelmesedtem és megszögeltem, hogy a szerveren keressék és ha van újabb, akkor a szerverről töltsék le az új firmware-t az ESP cuccaim... eléggé stabilan működik, van egy példány az asztalon, amin játszok, ha pedig stabil a kód, akkor megy a frissítés... nincs kedvem begyűjteni tíz kis eszközt, frissíteni a programját és visszatenni a helyére... :)

    Ezt ismertem, de (mint fentebb már írtam) én a lua nyelvet választottam. Ott azért egy kicsit más a történet. A firmware az, ami tartalmazza a lua interpretert, és a library-ket. Azt hittem arra is van valamilyen megoldásod. A *.lua fájlok frissítése az megy, de a firmware frissítésével még nem találkoztam.

    Egy darab relé van benne, működés szempontjából teljesen mindegy, hogy hova kötöd a nullát és a fázist... életvédelmi szempontból jobb, ha a fázist szakítja meg a relé, mert akkor lekapcsolt állapotban nincs feszültség alatt a kapcsolt berendezés, illetve vannak olyan elektromos cuccok, amelyek nem szeretik, ha a nulla van megszakítva és kapják a fázist folyamatosan.

    De ki tudod próbálni "szárazon" is, hallani fogod, ahogy kattog a relé benne...

    Noh, én fel is tuningoltam az enyémet.
    Firmware csere után kapott egy DHT11 hő és páratartalom mérő szenzort és a kis kapcsolója egy kivezetést, amit rá lehet kötni nyomógombra, billenő kapcsolóra... Lényeg, hogy nem a saját kis gombját kell koptatni, ha manuálisan kell kapcsolgatni.

    Kis konfigurálás a Home Assistanon és már kapcsolható is, illetve mutatja szépen a hő és páratartalom értéket is :)

    Kép 1 Kép 2 Kép 3

    En is a billenokapcsolos kapcsolasra gondoltam, mar csak azert is, mert igy valtokapcsolot is meg lehet valositani vele, ami nekem a lepcsofeljaroban kenyelmes lenne. Csak kellene talalni esztetikus billenokapcsolot.

    Szerk.: Megvalosithato elvileg ugy, hogy rakotod gpio-ra + a foldre a kapcsolot(tehat nem a 220-ra), beallitod a gpio-t switch tipusra a Tasmota firmware-ben, es utana az allapotvaltozast figyeli Low->Float->Low es akkor kapcsolja a lampat.
    Egy sima fali kapcsoloval Sonoff Basic-el es rajta egy gpioval kiprobalva mukodott a dolog, tehat nem kell billanokapcsolo hozza, hogyha csak a villanyt akarod vezerelni vele es mondjuk valtokapcsolast szeretnel.

    Ebbol a cuccbol is bevasaroltam, es kapcsolgatom Home-Bridge + Siri-vel, illetve szinten homebridge-el MQTT-n kiolvasom a szepen rakotott DHT22 adatait. Hibatlanul mukodik, es a kis ejjeli lampat is kapcsolja. (lehet automatizalni is nyilvan, ha arra vagyik az ember.
    Amit viszont most vettem, az a falikapcsolo kimondottan jo cucc.
    Raflash-eltem a Sonoff-Tasmota firmwaret, elso buildet kezzel forditottam, beletettem a beallitasaimat, a tobbinel a githubrol szedtem le a release-elt binarist, es azt toltam fel OTA upgrade-el.
    Picit macerasabb itt firmware flash mode-ba kapcsolni az eszkozt, mint a sima switch-nel, merthogy itt a GPIO 0-t kell a GND-re kotni amikor raadod az aramot, es nincs hozza kulon gomb, de egy jumper kabellel gond nelkul megoldhato. Elony, ha az embernek 3 keze van.

    Szerencsere minden mas firmware upgrade-nel mar nem kell szarakodni, mert az OTA is jol mukodik.
    Ehhez viszont fontos, hogy betartsuk az elso flashelesnel a leirast ( nem 8266-os chip hanem 8285 van benne)

    Egyetlen hiban vele, hogy ha egy ujjal probalom megbokni a touch feluletet, akkor nem mindig erzekeli, ugyhogy raszoktam arra, hogy tenyerrel kapcsolom, ha kezzel kell. Igy 100%-os a hit rate.

    A tapod rendben van?
    Telefonnal es kinai toltovel tapasztaltam ilyen touch felulet furcsasagot.
    Ugye a kapacitiv erzekeles ugy mukodik (vagy ugy is mukodhet, nemtom hivatalosan hogy csinaljak, uC-knel ez a megszokott), hogy felemelik a feluletre kotott megfelelo pint egy ellenallason keresztul, es ha lassabban emelkedik fel, mint szokott, akkor az azert van, mert epp tapizod. Sajnos az instabil (zajos) tapfesz ezt teljesen hazavagja.

    --
    A strange game. The only winning move is not to play. How about a nice game of chess? - Wargames

    No, tesztelés alatt van a cucc, most épp 10 méternyi (72 wattnyi) LED szalagot hajt meg PWM vezérléssel. A tényleges meghajtást egy logic level FET végzi, kézzel tapintható melegedés nélkül. A mérések szerint a LED szalagot viszont nem elég öt méterenként megtáplálni, fél voltot veszít méterenként, szóval az eredeti terveim szerint két vastagabb vezetéket viszek majd a szalag mellett és méterenként megtáplálom, hogy ebből ne legyen sok veszteség, most azért melegszik a LED szalag is a rajta átfolyó áram miatt... :)

    Hőkamerával azért jól látszik, hogy van valamennyi melegedés a kötődobozban (35°C maximum), de nem vészes és ennek a fő oka maga az ESP8266, illetve a DC-DC tápegység, ami a bejövő 9-35 voltos feszültségből készít 5 voltot az elektronikának, amiből aztán az ESP8266 3,3 voltot farag magának. Szóval van valamennyi veszteség... :)

    A LED szalag vezérlése közben azért szépen gyűjtögeti az adatokat is és továbbítja azokat a szerverre. Szóval lassan beépíthető lesz a helyére az első egység, még egy kicsit okosítanom kell, de már magától lekapcsolja a LED szalagot, ha nem érzékel mozgást adott ideig... :)

    Előzmények, képek és bővebben: https://www.facebook.com/groups/barkacsklub/permalink/268402690270219/

    Azért PWM, hogy tudjon ilyet, szóval fokozatosan változik a fényereje... sőt, a mozgásérzékelővel olyan viszonyban van, hogy az utolsó mozgás után x idővel 75 százalékra veszi a fényerőt, ha pedig nem történik erre mozgás újabb x ideig, akkor lekapcsolja a világítást... :)

    Itt van egy videó egy korábbi tesztről: https://www.facebook.com/groups/barkacsklub/permalink/238271149950040/?…

    ...tud NTP szinkront is, szóval a későbbiekben azt is beleteszem, hogy ha éjjel bizonyos ideig le van kapcsolva minden világítás, akkor felkapcsolva sokkal lassabban világosodik ki és csak 10-15 százalékos fényerőig, hogy ne vakítson el, ha megyek brunyálni... :D

    Mert? Különféle helyiségekbe különféle sűrűségű és teljesítményű LED szalag fog kerülni.

    A 7,2 watt / méteres szalag a nappaliba kerül majd, ami 36 négyzetméter, 24 méter a kerülete és öt méteres belmagasságú. Oda kell a fény, most van 5 * 50 W + 4 * 100 W... :)

    Jöjjön egy kis Home Assistant konfigurálás! :)
    Adott egy mélynyomó, amire egy számítógép és a TV van kötve. Tehát mindkettő ezen szólal meg.
    Azt szeretném elérni, ha a gép, vagy a TV be van kapcsolva, akkor kapcsolja be a mélynyomót. Ha egyik sincs bekapcsolva, akkor kapcsolja ki.
    Nos, ez majdnem működik is. A gond az, hogy ha bármelyik készüléket kikapcsolom, akkor kikapcsolja a mélynyomót, amit csak akkor kellene ha mindkettő ki van kapcsolva.

    Így néz ki a konfig ezen része jelenleg:

    - alias: Subw OFF 
      trigger:
        platform: state
        entity_id: switch.pc, switch.hdmi_0
        to: 'off'
      action:
        service: homeassistant.turn_off
        entity_id: switch.sonoff_subw
    

    Van tippetek, hogy kellene átírni, hogy csak akkor kapcsolja ki, ha mindkettő entity státusza off?
    A bekapcsolás oké, mert mindkét eszköz üld egy bekapcsolás parancsot, ami nem gond akkor sem ha már be van kapcsolva, de a kikapcsolás már így nem oké :)

    UPDATE:
    Rájöttem!
    Egy csoportba kell tenni az eszközöket és úgy vizsgálni az állapotot:

    subwoofer_use_devices:
      name: subwoofer_use_devices
      entities:
        - switch.pc
        - switch.hdmi_0
    
      - alias: Subw OFF 
        trigger:
          platform: state
          entity_id: group.subwoofer_use_devices
          to: 'off'
    ...

    A héten, kb. a semmiből létrehoztam az alapját a mi kis okos otthonunknak :)
    A rendszer lelke egy régi Raspberry Pi, ami eddig csak a fiókban volt. Most végre lett funkciója!
    Ez működtet egy 4 csatornás relé modult és MQTT protokolon kommunikál két sonoff kapcsolóval, hőmérő szenzorral, HDMI-n keresztül pedig a TV-vel, LAN-on gépt PC-vel, és egyben nyomtató szerver is a hálózaton.
    Figyeli az asztali PC-k állapotát (be vannak-e kapcsolva), illetve Wake on LAN-al be is lehet őket kapcsolni (később a kikapcsolást is megvalósítom.)
    Figyeli asszonyka és az én telefonomat is, vagyis a telefon küldi be GPS és akksi adatokat, így lehet látni a térképen ki hol van, hány százalékon van az akksik töltöttsége.

    Automatizáló még nem sok van. Csak a mélynyomót kapcsolja be, ha az én gépem, vagy a TV be van kapcsolva. Illetve kikapcsolja, ha mindkettő ki van kapcsolva.

    A négy reléből jelenleg kettő van használva. Polc dekoráció világítás kapcsolásához, illetve a hangyafarmom megvilágításához :)

    Most hegesztek egy WiFi-n kommunikáló mozgásérzékelőt, és szintén WiFi-s LED vezérlést, hogy éjszaka ne kelljen botorkálni ha mászkálunk.

    Van egy szekrényem, tele kacatokkal. Itt megüresítettem a felső polcot. Ide került be az egész hóbelevanc. Szerintem teljesen jó helye van ott, bár az éjjel kiszűrődő SMD LED-ek fénye kicsit érdekes :)

    Home assistant: Egy, Kettő

    Miután a sonoff kapcsolók frimwarejét lecseréltem és a Home Assistantal is sikeresen tudtam őket vezérelni, gondoltam jó lenne egy kis éjszakai "menetfény" is, LED szalagok formájában.
    Sonoff-hoz hasonló, olcsó modult kerestem ehhez, amiben szintén cserélhető a frimware és lehetőleg ESP8266 chip alapú.
    Meg is lett a kicsike: Lixada H801

    Tud egy RGB led szalagot és kettő sima LED szalagot vezérelni, mindhárom esetben állítható fényerővel.
    Gyári szoftverre rá sem néztem, egyből alternatívát kerestem. Van pár lehetőség, de a legjobban ez működött és a Home Assistantba is pár sor beilleszteni a kapcsolókat.

    Tip: Flasheléshez a FTDI RX TX lábait a H801 ugyanazon nevű portjaihoz kell kötni nem fordítva, ahogy általában kelleni szokott, illetve a J3 jelzésű jumper kivezetéseket rövidre kell zárni kb 5. másodpercre és úgy ára alá helyezni.

    NodeMCU háznak valakinek van ötlete,amit olcsón meg lehetne úszni?

    Nem tudom, hogy ez mennyire aktuális még, én elkezdtem 3D-ben csinálni egyet, de sajnos még nem tökéletes.
    Nekem a ház úgy van tervezve, hogy beleférjen:
    - egy NodeMCU v0.9
    - egy DHT22 / Dallas DS18B20
    - egy AM312 PIR szenzor
    - egy TEMT6000 fényérzékelő
    - egy RGB LED

    Most az egész kb. akkora, mint egy Macbook Air töltöje (kb. 70x70x30mm).
    egyelőre az usb-ről való megtáplálásával vagyok gondban. Egyelőre micro USB töltőhöz van kötve. Egyelőre powerbankot keresek hozzá, amiről meg lehetne táplálni.

    Akkor úszod meg a legolcsóbban, ha ismerőssel kinyomtattatod. Én néztem pár helyen, mindenhol olyan 20-25 USD-t kérnének a nyomtatásért. Úgyhogy erősen hajlok rá, hogy vegyek egy belépőszintű 3D nyomtatót.

    kültérre kell az ABS szerintem. A PLA biológiailag lebomlik, de azt nem tudom, mennyi idő alatt. Nekem kolléga nyomtatott 3 dobozt tesztre, amit vártam, ahhoz képest meglepően kemény maga az anyag. Mondjuk a nyomtató miatt a felülete nem szép, ezért utólag kell majd vele valamit csinálni. Esetleg szórógitt + festés.

    Tesztelem.
    Egy darab "selejt" kallódik a műszerfalon, belül.
    Egy (három) darab meg a házfalon, házszám formájában.
    Már majdnem két éve vannak ott, eddig bírják.

    A PLA komposztálható, de elég ideig kell elég hőmérsékleten tartani hozzá.

    Aztán ha már I3, meg plexi...

    EUR 189.00, Zollfrei, von Deutschland.
    http://www.ebay.com/itm/272241739631?_trksid=p2055119.m1438.l2649&ssPag…
    Rendes méret, fűthető asztal, én a Geeetech névvel is meg tudnék barátkozni.

    Olvasva a topikot, látva, hogy ki mire jutott, egyre több ötletem támad, hogy én mit és hogyan tudnék a lakásban megoldani. A lakásnak komoly korlátai vannak, mert egy panel lakás, annak minden hátrányával. A családban az egyik kardinális kérdés a helyiségek hőmérséklete, illetve a levegőminőség a lakásban.
    Szerencsére a radiátorokon vannak szelepek, tehát lehet fűtést szabályozni (ez panelban nem triviális dolog). A szelepeket úgyis cserélni kell. Ezért azon gondolkoztam, hogy első körben ezzel kezdenék el foglalkozni. Google-ban, itthon csak a Honeywell HR sorozatot találtam, leginkább HR92-est, mint intelligens radiátor szelepet. De az nem igazán derült ki egyik leírásból sem, hogy tudja, amit szeretnék. Nekem igazából annyi kell(ene), hogy a Home Assistant képes legyen vezérelni, nem kell, hogy a szelep önmagában "okos" legyen, azt a Home Assistant-ra bíznám. Illetve, ami még szeretnék, hogy a kézi szabályzás lehetősége is adott legyen. Ezt úgyse fogjuk szerintem használni, de az asszony gyomra talán jobban beveszi az okosotthont, ha megvan az opció, hogy kézzel is bele lehet nyúlni.

    Van esetleg tapasztalata ezekkel a Honeywell szelepekkel vagy más/jobb ötlete?

    Nekem az a bajom, hogy már a háztartási eszközökben is terjed az érintőgombos felület, pedig sokkal egyszerűbb a mikrót, a tűzhelyet és a sütőt tekerőgombbal beállítani... minimális költség lenne... sőt. De valahogy vadászni kell azt a főzőlapot, ami nem tekerőgombos. Ugyanígy vagyok a világítással: legyen kapcsoló. A radiátoron legyen tekerő. Nem akarom a telefonommal basztatni a házat, a kezemmel akarom basztatni. :)

    Nalam a falon a Philips Hue Dimmer Switchek vannak ez megoldotta a nyomogomb hianya problemat. Viszont radiator szelepekbol nem nagyon talaltam olyat, ami tekeros lenne... A legjobb valami olyan szelep lenne, mint az erositokon a motoros hangero potmeter. Na ilyet eddig nem talaltam, igy a radiatorok maradnak butak.

    ---
    Apple iMac 27"
    áéíóöőúüű

    Pedig en is pont ilyesmit keresek.
    Ami kezzel es telefonrol is tekerheto.
    Igazabol a cel az, hogy kivaltsam a termosztatot sajat okos termosztatra, mivel ugyis minden szobaban merem a homersekletet, igy adja magat a dolog, hogy szobankent a megfelelo homerseklet eleresekor lekapcsoljam az adott radiatort, es ha az utolso is elerte a homersekletet akkor lekapcsoljam a kazant is.

    Sziasztok! Elég sok mindenem okos már idehaza, de most szeretném őket egy rendszer alá rántani, hogy IFTTT-n keresztül vezérelhető legyen. Home-assistant -ban gondolkodom, de már eléggé elakadtam és reménykedem benne, hogy itt vannak tapasztaltabbak a témában. Pénteken jött meg a raspberry pi 3 B és azóta reggeltől estig ezzel kínlódok, mert az útmutatókat tökéletesen teljesítem - szerintem - mégsem sikerül.

    Holnap érkezik meg a Google Home-om is, ami megkoronázná a rendszert, de a Home Assistant nem akarja az IFTTT-t az égnek sem.
    A configuration.yaml file-ba bemásolom ezt:

    ifttt:
    key: "ide az API key az IFTTT maker URL végéről"

    És amikor le kellene tesztelni, egy egyszerű módszerrel, az nem működik, pedig tök egyszerűen le van itt írva: https://home-assistant.io/components/ifttt/

    Leírok minden a nulláról, hogyan csinálom, hátha én hibázok:

    • Hassbian 1.1-et telepítek, mármint a telepítés magától végbemegy a microSD-ről
    • Belépek pi/raspberry un/psw párossal
    • Megváltoztatom a jelszavam: sudo passwd pi
    • Átállítom a lokalizációt BP-re itt: sudo raspi-config
    • Feltelepítem a samba-t: sudo ./hassbian-scripts/install_samba.sh
    • Beírom a már fentebb említett IFTTT részt a configuration.yaml file-ba
    • Tesztelném, de nem megy.

    A válaszokat előre is köszönöm és külön öröm, hogy egy ilyen zárt közösség tagja lehetek ;)

    Szerintem ezt gondold át mégegyszer! Kívül helyezni a döntéshozó intelligenciát a lakáson magával hozza annak veszélyét, hogy megszakadt internetkapcsolat esetén butább lesz az otthon, mint kézzel vezérelve. Értem én, hogy az IFTTT milyen nagyszerű, de mit sem ér, ha nem éred el. Véleményem szerint az okosotthon vezérlésnek akkor is működőképesnek kell lennie, ha minden erőforrástól megszakítják a lakást, tehát legyen backup akkumulátor és a felhőszolgáltatásokat maximum megjelenítésre használja, döntésre semmiképp.

    Ave, Saabi.

    alapvetően +1,de nem írta hogy a döntéshozó van kint. Én is bekötöttem (egyelőre teszt szinten mert a biztonságától égnek áll a hajam), de nem az otthoni cuccok közé ékeltem, hanem a külső triggerek mennek onnan(telefon pozíció, órán hazajelző gomb, stb) valamint a vissza irány egyszerűsítésére, azaz ha otthon történik valami, akkor push notification, logolás google drive-ba, stb.
    IFTTT-t nem a logikája miatt szokás szeretni (az kb nulla van neki) hanem a már beintegrált csillió szolgáltatás elérésének egyszerűsége miatt.

    Note: nem tökéletes. Nagyon nem. Heti 2-5 alkalommal maradnak ki üzenetek és triggerek, azaz ne ez legyen az elsődleges és egyetlen csatorna

    curl -X POST https://maker.ifttt.com/trigger/{event}/with/key/A_TE_KULCSOD

    az {event} nevét persze cseréld ki egy már az ifttt oldalán létrehozott eseményre, és akkor tudod nézni hogy meghívódott-e

    A screenshot-od alapján vsz nem hoztál létre event-et, nincs mit meghívnod. (EventName-nek hívják az event-edet, ami ugyan lehet, ha így állítottad be, de gyanús)

    Kicsit talán off a kérdés, de lehet, hogy mégsem. Ki honnan szerzi be a szükséges eszközöket? Itthonról vagy e-bay-ről?

    Én ott tartok most, hogy el kellene kezdeni megvenni a kapcsolókat, szenzorokat, Pi-t, stb. Kapcsolókat ebay-ről néztem ki, a Pi-t meg hozzá a szenzorokat néztem itthon webshopban, a hőérzékelőért viszont nagyon sokalltam a 2990Ft-ot, így megnéztem ebay-n is. Nem kicsit lepett meg, hogy ebay-n elvileg ugyanaz a DHT22-es szenzor 2.95USD. És valószinüleg nem kamu, mert az eladó 99,4%-os értékeléssel bír, és eladott belőle 13000+ darabot. Aztán néztem a többi szenzort (fény, pára), azoknál is kb. ugyanez a helyzet.

    Kínából rendelni kicsit adócsalás, de kis mennyiségnél elnézik... webshop esetén ugye kell igazolnod a forrást, nem ér rá egy hónapig jönni a cucc bizonytalan érkezéssel, ezért drágább a postaköltség, mert futár hozza értékbiztosítással, plusz rájön a vám, az ÁFA és a munkadíjak, ami sok apró dolog postázásánál nem kevés... szóval teljesen reális a hazai webshop ár is meg a kínai postázós ár is. :)

    Azért írtam, hogy a webshopnak igazolnia kell a beszerzési forrást, csak olyan dolgot adhat el, amit megvett, cég-cég között nincs vámmentes határ... cég-magánszemély (22 EUR) vagy magánszemély-magánszemély között (45 EUR) létezik ilyen. Csodálkoznék, ha mindenki akkurátusan odafigyelne arra, hogy 22 EUR feletti rendelésnél mindenképp kifizesse a vámot és az ÁFÁ-t és nem hagyatkozna arra, hogy a másik oldal mit írt a csomagra (ami ugye jellemzően "gift" vagy "sample")... :)

    A moralizálós része nem igazán érdekel. Ezen már rég túl lendültem, mikor az ebay-n 400Ft-os sütemény kiszúrót próbálták meg nekem eladni 1600Ft-ért (ami amúgy kb. 3-4 használat után eltörik), vagy amikor a 300Ft-os órát 3500Ft-ért akciósnak kiáltják ki, mert amúgy 7000Ft lenne. Nincs azzal bajom, hogy profitot akar csinálni valaki. Csak ha hülyének néznek, azt nem szeretem. Van az az ár, amit hajlandó vagyok kifizetni, hogy ne kelljen várnom 1-1,5 hónapot. De adott esetben a 3-4x szorzó az nem az az ár.
    A topic-ot pedig nem szeretném ebbe a morlaizálós irányba elvinni. ;)

    Most erre majdnem igent mondtam, hogy igen, mindegyik 22 EUR alatti, de pont múlt héten jött egy 30 EUR körüli, nem néztem hogy mi van rajta. Igaz svájci posta hozta, de csájnából, de még áfával is megérte volna.

    Egyébként igen, szinte mindegyikre rá van írva hogy gift, de törekszem arra hogy ha felbontják akkor se húzzanak le 27%-ra.

    Tudnál adni egy linket arra az űrlapra, amelyen be kell jelenteni, hogy a feladó téves adatot írt a küldeményre, és ezért nem vámolták el a csomagot?

    Egy ismerősöm repülővel jött haza Kínából. Kint vett egy telefont, kb. 250 euró értékben. Mivel utasforgalomban (repülővel) 430 euróig vám- és áfamentes az áru, így nem fizetett sem áfát, sem vámot. Már mielőtt kiment volna, meg akarta rendelni a telefont egy kínai webshopból. Azonban megtudta, hogy néhány hétre ki kell utaznia, így nem rendelte meg. De én tudom, hogy ezt a telefont meg akarta rendelni! Azzal, hogy nem rendelte meg, vám és áfabevételtől esett el az ország. Tehát adócsaló. Azt még nem tudom, hogy őt, vagy az őt kiküldő céget jelentsem fel.

    Ilyen szerintem nincs, ha a NAV-nak nem tetszik a számlán vagy értéknyilatkozaton megjelölt összeg akkor mondanak ők egyet. :)

    (2) A vámhatóság a számlán feltüntetett vagy az értéknyilatkozatban szereplő értéket nem köteles elfogadni a vámkiszabás alapjának meghatározásakor, ha az indokolatlanul jelentős mértékben eltér az adatbázisában szereplő átlagos belföldi ártól vagy kétség merül fel a számla valódiságát illetően. Ebben az esetben a fizetendő vám alapjának meghatározásakor az adatbázisában szereplő átlagos belföldi fogyasztói árat, vagy ennek hiányában a vámhatóság rendelkezésére álló egyéb értéket kell figyelembe venni.”

    Forrás

    Bár mivel gondolom határozat születik, így x napon belül fellebbezhetsz, hogy de hát a kínaik rossz összeget írtak rá.

    2 esetben vettem ÁFA határ fölött eddig külföldről, az egyik EU-n belüli volt, az ugye nem játszik. A másik meg most, ez a 30 USD környéki, ahol nem volt rajta gift, other volt bepipálva, értékként pedig 15 USD volt rajta. Bár tömegnek 0,01 kg, ami önmagában vicc, a cucc manual-ja 2x ennyi, az egész cucc bőven fél kiló fölötti.

    Szóval lehet hogy adócsalás, de a valótlanságot nem én írtam rá, és nem is kértem erre az eladót, és csak licitáltam, nyertem és fizettem. A vámon simán áthaladt, ezért sem érzem magam felelősnek, ha kérték volna az áfát kifizettem volna, így is számoltam a licitálásnál, nem rajam múlt hogy nem kérték.

    Maximum annyiban vagyok bűnös, hogy _utólag_ nem kértem az eladótól papírt arról, hogy ő ezt cégként adta el nekem és véletlenül sem magánszemélyként (ott ugye 45 EUR a limit, ez is mekkora fasság már), majd ezzel nem reklamáltam a navnál, hogy fizetnék nektek 2500-at mert balfaszok vagytok.
    Ezért nyilván az én jóanyámat, el is szégyellem magam érte.

    Az összes többi esetben _teljesen_ _legálisan_ úgy veszem a dolgokat, hogy ne csússzak bele az áfahatárba. A törvény erre lehetőséget biztosít, én pedig élek vele.

    Nekem eddig konkrétan 3x volt olyan, hogy megfogták (és teljesen jogosan). Mondjuk ezeknél már eleve beleszámoltam, hogy +27% + kezelési díj. Jött a NAV-os papír, hogy igazoljam az értéket. Elküldtem nekik a kapcsolódó banki kivonatot és az Ebay/Ali order-t pdf-ben. Nemsokkal utána meg jött a határozat, hogy a postásnak átvételkor ennyi és ennyi utánvétet fogok fizetni. A legnagyobb meglepetés az volt, hogy mennyire rugalmasan bonyolították és hogy elfogadták a pdf-eket emailben.

    e-bayről szoktam rendelgetni és lehetőleg csak olyan boltból, ahol ingyenes a szállítás.
    Itthon vagy kiba drága minden, vagy nem is kapható ami kell, vagy kétszer annyi a postaköltség mint maga a cucc ami kéne!
    Külföldről általában egy hónapon belül megjönnek a cuccok. Nem szoktam gyors postát kérni, ráérek :)

    A dht22 inkább páratartalomra jó, hőmérőnek dallas 18b20.
    Az eladó 13k+ eladása az eladóra vonatkozik, nem az adott termékre.
    Ha több darabra van szükséged akkor javaslom hogy több (jó minősítésű) eladótól is rendelj 1-1 darabot, így ha valahol hibás széria van akkor a többi legalább jó lesz. Illetve ha az egyiktől 40 napra érkezik, a többivel tudsz addig dolgozni.
    Pi-t a pimoroni-ról szoktam rendelni, pár nap alatt itt van (EU-n belülről), a szállítási költség 4 gbp. Persze nagyobb értéknél érdemes lehet megfontolni valami komolyabb szállítási módot (tracking, biztosítás, stb.)

    Valakinek van tapasztalata Broadlink eszközökkel Home Assistant rendszeren? Broadlink A1-ből sikerült már kinyernem a hőmérséklet, pára, légminőség, fény és zajszintet. RM2 PRO-ból viszont nem tudom a base64-es kódokat kinyerni. A leírás hozzá nekem túl kínai.

    Szerintem jó cucc, nekem tök megbízható, holott külföldi fórumokon írtak olyat, hogy több 100 celziusz fokot mutat. Nekem megy mellette az RM2 PRO is és abban van hőmérő szintén, nagyjából együtt mozognak 0,1 - 0,5 fok eltérés előfordul a kettő között néha. De az nem sok.

    Nem akartam új szálat nyitni, meg itt nagy az élet, hátha tudtok segíteni.

    Az a gondom, hogy a kutyánk folyton kiszökik a kertünkből, és képtelen vagyok megtalálni a "szökési vektort" :-) Nézegettük a kerítést minden hol, egyszerűen nem tudom elképzelni, hol dobbant a jószág.

    Arra gondoltam, ki kéne tenni valami 1-2-3 kamerát a kertbe és meglesném. Csak ugye:
    1. Mi az, ami kibírja, ha kint felejtem az esőben
    2. Ne kelljen fél naponta feltölteni az akkumulátorokat
    3. Esetleg Wifi-n átküldhetné a napi termést
    4. Vagy otthon összebarkácsolhatom és/vagy ne legyen drága (mégis csak egy kutya után kukkolok, nem a szomszédra vagyok kíváncsi)

    Szóval, ha lenne megoldási javaslatotok, ne fogjátok vissza magatokat!

    Üdv, Cözi

    Az én kutyám anno úgy szökött, hogy valahogy átküzdötte magát a drótkerítés tetején a szomszédhoz (volt vagy 30 centi a marmagassága), és az ő kerítésén keresztül ugrott ki az utcára. Ami mondjuk magasabb volt mint a mienk, de neki ez kellett.
    Évekig nyomoztuk báz, évekig, már egészen megöregedett mire egyszer valaki meglátta.

    Sok sikert a vektorizáláshoz...

    Éééééés megvan! Szerintem a kutyám már túl rutinosnak képzelte magát, nem is nagyon nézett körbe, én meg pont jókor jó helyen, takarásban figyeltem a történetet. Kerítést rendeztem, kutya szomorkodik, most alszik.

    Így nem lett nekem kertfigyelő kamera rendszerem :-)

    Köszönöm, kérem kapcsolja ki :-)

    Én is kisérletezek vele, de még csak az A1-ig jutottam én is, meg az RM-Pro hőmérsékletéig.
    Neked is csak 0 és egy értékeket ad a levegő minőségre az A1?

    Persze, az normális. A 0 az az érték, amikor minden teljesen rendben van. Na én is eddig jutottam, de az RM2 PRO..... pfff tudok vele küldeni jelet egyébként base64-es kódolásút, az működik. Csak nem értek a linuxhoz, így marhára nem tudom végrehajtani a leírás egy részét, hogy hogyan nyerjem ki a base64-es kódokat az appból. Megvannak a file-ok, de nem tudom hogyan és mit kellene futtatni.

    Ez nem megy: https://home-assistant.io/components/switch.broadlink/#using-e-control-…

    Azt hittem az A1 kicsit többet fog tudni, mint az igen/nem. Majd csinálok valami pontosabbat.

    Most megnéztem, hogy hogy működik az infra jel küldés.
    Nálam van egy telepített RM-Bridge az Androidon.
    Ezen az oldalon el tudod érni a tanulás módot és megkapod a kódot is: http://rm-bridge.fun2code.de/rm_manage/code_learning.html

    Ezekre figyelj:
    a) Wait for one second after the light comes on the box until pressing the remote
    b) Hold the more REALLY close to the unit, 3-4 inches worked reliably for me
    c) Only hold the remote button for something like a quarter of a second.

    A küldött kódot ki kell szedni a json-ból és itt tudod base64-re konvertálni: http://tomeko.net/online_tools/hex_to_base64.php?lang=en1

    Ezután nekem ment.

    Ez nagyon jó, de sajnos ezzel csak rádió jeleket tudok lementeni, infrát nem. Vagy én bénázok megint?
    És ezzel nem fogom megtudni a TC2 kapcsolóim kódjait sem. Azokat csak ki kell bányászni eszerint:
    https://home-assistant.io/components/switch.broadlink/#using-e-control-…

    Viszont ez nekem csak a 3-as pontig megy, utána nem tudom mit kell csinálni, nekem ezt szóról szóra szájbarágósan kellene, hogy mikor hova mit írjak. Annyira linux tudatlan vagyok egyelőre, hogy arra nincsenek szavak.

    Szuper és működik is, csak én voltam béna.
    Megtévesztett a Developr Tool / Services-ben lent a "No description is available" szöveg, azt hittem valami nem oké.
    Valamint valóban az Eventet sem töltöttem ki. Köszönöm!

    Azt szeretném, ha Google Home-nak adok utasítást, hogy kapcsolja fel a LED világítást, azt tegye meg. A HA-ben már be van állítva, ott működik is a LED kapcsoló. Van DuckDNS-em, de nem tudom hogy lehet a MAKER-t tökéletesen kitölteni, hogy meghívja a LED kapcsolását. Egyszerűen nem tudok rájönni, hogy mit rontok el:

    http://prntscr.com/ene0p0

    Update: A Google Home-nak kiadott parancs után a log fájlba belekerül a hibás meghívás, tehát elmegy a parancs, csak azt nem jól adom meg a MAKER-ben.

    LOG: 17-03-23 08:00:56 ERROR (MainThread) [homeassistant.core] Invalid service data for switch.turn_on: Entity ID receiver is an invalid entity id for dictionary value @ data['entity_id']. Got 'receiver'

    Update!!!

    Megoldódott

    A google home tud magyarul?
    Jo lenne egy olyan kutyu, ami egyreszt szepen acsorog a lakasban es varja mit akarunk, tobbiek miatt viszont a magyar jo lenne, konyebben megbaratkoznanak ezzel az okosotthon dologgal
    :)

    ---------------------------------------------------
    Hell is empty and all the devils are here.
    -- Wm. Shakespeare, "The Tempest"

    Sziasztok,

    a tavaszi lomtalanítás közben az egyik dobozban találtam egy ilyet. Azon kívül, hogy a leírásában az van, hogy RS232/422 - LAN átalakító, nem igazán találtam infót a felhasználási területre. Gondolom, belptetőrendszerhez, mert a cég honlapján, ahol találtam, ahhoz használatos eszközök vannak. Lehet, hogy a lakás automatizáláshoz is lehetne használni, de lövésem sincs, hogy mire. Van tippje valakinek?

    Raspberry Pi Zero-val kezdtem tavaly nyáron foglalkozni, de aztán váltottam Arduino Uno-ra, jobban kézre állt. Aztán kaptam két Wemos D1 Mini Pro-t egyik ismerősömtől.
    A kötelező LED villogtatás után a 2x16-os karakteres kijelzőt tutujgattam I2C buszon, illetve DHT11-es hőmérséklet szenzor adatait írtam ki rá. Utána jött egy Nokia 3310-es LCD "upgrade".
    Folyamatosan olvasgattam itt a tapasztalatokat.
    Most épp azt találtam ki, hogy a DHT adatait szeretném látni az iPhone-on, HomeKit alapokon. Rögzíteni nem kell az adatokat. Viszont minden tutorial a Home Assistant ajánlja központnak, és bár ugyan van Raspberry a fiókban, én mégiscsak a meglévő negyedik generációs Apple TV-t szeretném használni, de eddig sehol nem találtam rá segítséget.
    A cél az lenne, hogy a D1 Mini felcsatlakozik WiFi-re, egyelőre állandóan bekapcsolva, és mint HomeKit kompatibilis eszköz megjelenjen a hálózaton.
    NodeMCU-t nézegetem, elvileg képes lenne rá, csak időt kellene szánnom rá :)

    --
    Én TUDOM, hogy igazam van. És ha nincs is, akkor is NEKEM van igazam, mert én vagyok az Admin. Ennyi!

    Sziasztok!

    Kis segítséget szeretnék kérni: egy sok ember által használt épületen bejárati ajtó kulcs nélküli nyitását gondolnám megoldani úgy, hogy minden potenciálisan nyitásra jogosult rendelkezik RFiD-csippel felszerelt kártyával.

    Az elvárás a nyitórendszerrel szemben az lenne, hogy 1 ajtó nyitását kellene tudni vezérelni, elvárás, hogy meg lehessen adni, hogy melyik csip jogosult ajtót nyitni, célszerű lenne, ha nyilván lenne tartva, ki, mikor nyitott, mindezt az lenne a legjobb, ha hálózati kapcsolaton keresztül meg lehetne oldani.

    A vezérlőegység az egyik kérésem, mit lenne érdemes használni, a másik, nagyobb kérdésem, hogy ismertek-e olyan zárbetétet, ami normál méretű ajtóba beszerelhető, alkalmas kültéri használatra, és nem kerül egy vagyonba?

    Köszönöm.

    És ha valaki olyan megy be, akinek nem lenne jogosultsága, akkor vajon téged vesznek majd elő? Mert az ilyen "pénzt nem szánunk rá, de igényeink azért vannak" kategóriájú céges feladatoknál általában nem az kerül a bré kellemetlenebb részére aki kitalálja a feladat, hanem aki meg felépíti szarból a várat.

    És szerintem a _céges_ _beléptetőrendszer_ sehogy se fér bene az _otthon_ _automatizás_ topic-ba...

    Köszönöm, de nem céges környezetről beszélgetünk. Éppen arról van szó, hogy kitalálható-e úgy a feladat, hogy egy ajtó ne 6-800 ezer forintos költségből legyen megoldható.

    Hogy a kártyás ajtónyitás automatizálás-e, azt én csak a fenti hozzászólásokat végigolvasva gondoltam.

    És ismétlem, nem céges környezet, hanem magántevékenység, innen az árérzékenység.

    Ha off volt, hát sorry.

    Ha egy kész rendszert szereltetsz fel, akkor a kivitelezőé lesz a felelősség, ha te szereled fel, akkor pedig a tied. Így annak is néz utána, hogy tűz esetén mi az elvárt működés, és ennek megfelelően tervezd meg a rendszert. Persze jó esélyed van rá, hogy sohasem kell bizonygatnod, hogy a rendszer megfelelt minden előírásnak.

    Hacsak nem valami patinás nagynevű céget kéred fel kivitelezőnek, van olyan hogy a magyar piacon reálisan megtalálod és még felelősségre is vonhatod a kivitelezőt? Az építőipar nem az érvényesíthető garanciákról szól sajnos. Mindezt úgy hogy alapvetően full egyetértek azzal amit mondasz

    "egy sok ember által használt épületen bejárati ajtó kulcs nélküli nyitását gondolnám megoldani ... nyilván lenne tartva, ki, mikor nyitott"

    Aha, nem céges, értem.

    Egyébként nem kell 6-800k-ig elmenni, első szembejövő weboldalon összedobálva a dolgokat olyan 100 nettó jött ki a nagyjára, plusz kártyák, kell egy használt pc, és nyilván van még amit kifelejtettem, szóval szerintem olyan 200k. Plusz egy ember aki megtervezi és összerakja, mert olyan apróságokra kell felkészülni mint tűz, füst, áramszünet, stb. Persze ne forduljon elő ilyen, de ha netán a barkácsolt cuccod miatt meghal bent pár ember...

    Sajnos egyelőre csak angolul tud és abból is szigorúan az US angol beállítással működik együtt, lévén még csak az USA-ban kapható hivatalosan. Egyébként a telefonon lévő asszisztens rábírható TASKER-rel, hogy magyarul fogadja a parancsokat, de sajnos a Google Home-nál ez nem működik.

    Sziasztok,

    egész jól haladok, megjött kínából az első Sonoff kapcsoló, a szenzorok, meg a többi még úton. Közben a konfigot csiszolgatom. A Sonoff MQTT-t használ, ebből tervezem megvenni a lámpakapcsolót is (Sonoff Touch), az is MQTT-n keresztül megy. Viszont eléggé elmentem MQTT irányba, ami nem biztos, hogy jó. Az egész rendszert egy itthoni mosquitto broker szolgálja ki, ami ugyanazon a gépen fut, mint a home assistant. Viszont ha ez megáll, akkor a lakás nagy része is lebutul. alapvetően nem is ez a része zavar, mert alapelv, hogy mindennek kell mennie kézi vezérléssel is. Nézdegettem MQQT clustering megoldásokat, de egy része vagy ágyúval verébre esete (fizetős enterprise megoldás) vagy annyi plusz réteget visz bele a dologba (HAProxy, MQTT broker, Redis, Docker), hogy azzal meg hatványozottan nő a meghibásodás esélye. Így erről az irányról letettem, hogy cluster-t csinálok alá. Marad az egynode-os kiépítés, az meg olyan rendelkezésre állást ad, amilyet.
    Most, míg kiépítés alatt van a rendszer, egy régi Intel Atom-os mini-ITX lap viszi az egészet. Relatív keveset fogyaszt (kb. 35-40W) De ez csak olyankor meg, amikor foglalkozok vele.

    Azt viszont nem tudom, hogy a Raspberri Pi mennyire bírja az ilyen jellegű üzemet. Pi3-at terveztem a HA alá, a TV-k "okosításához meg Zero W-ket. Erről milyen tapasztalataitok vannak?

    Én tulajdonképpen ezért vetettem el az MQTT protokollt és maradtam GET kéréseknél, mert az egy lényeges tervezési szempont volt, hogy mindennek autonóm módon működnie kell, amihez nem kell hálózat, akkor is, ha nincs internet kapcsolat és/vagy a helyi központnak kinevezett eszköz éppen nem érhető el... a másik tervezési szempont az volt, hogy nem akarok nagyon okos házat, csak egy kicsit okosabbat... :)

    Ezt nem igazán értem, mi köze az autonómiának ahhoz, hogy egyébként hogyan kommunikálnak egymással az eszközök? Másképp megfogalmazva, egy REST API-s megoldás - erre tippelek a GET kérések miatt - mennyiben biztosít magasabb rendelkezésre állást?
    Amúgy semmi akadálya két RPi üzembeállításának úgy, hogy mindkettőn fut egy mosquitto. Csak a klienseket kell úgy megírni, hogy mindkét brókert használják. Azt persze nem árt lekezelni, hogy mi történjen egymásnak ellentmondó üzenetek esetén, de ki mondta, hogy ez az egész egyszerű?

    Ave, Saabi.

    "Ezt nem igazán értem, mi köze az autonómiának ahhoz, hogy egyébként hogyan kommunikálnak egymással az eszközök? Másképp megfogalmazva, egy REST API-s megoldás - erre tippelek a GET kérések miatt - mennyiben biztosít magasabb rendelkezésre állást?"

    Úgy, hogy egymással tudnak beszélni központ nélkül, akkor is, ha nincs internet kapcsolat vagy közös Wifi kapcsolat, mert point-to-point beszélnek egymással és keresik egymás társaságát... :)

    "Amúgy semmi akadálya két RPi üzembeállításának úgy, hogy mindkettőn fut egy mosquitto. Csak a klienseket kell úgy megírni, hogy mindkét brókert használják. Azt persze nem árt lekezelni, hogy mi történjen egymásnak ellentmondó üzenetek esetén, de ki mondta, hogy ez az egész egyszerű?"

    Ennél lényegesen egyszerűbb, ha az ember eldobja azt a protokollt, amelyik csak nehézségeket és problémákat hoz be a rendszerbe minimális előnyért. De mindenki maga megítéli, hogy a központ(ok) és/vagy az internet kapcsolat kiesése esetén milyen szintű működést vár el a házától.

    A Skynet-től azért eléggé messze van az, hogy a keringtető szivattyút vezérlő kütyü nem egy felhőben lévő szerveren futó MQTT brókeren keresztül kérdezi meg a tőle egy méterre lévő puffertartály hőfokát mérő kütyütől, hogy érdemes-e még keringtetni a vizet, illetve nem a valahova letett RasPi-n futó HomeAutomation mondja meg, hogy kell-e egyáltalán fűteni, hanem meg tudják egymástól kérdezni közvetlenül... :)

    ...szóval az elv alapvetően a KISS filozófia, hogy például a keringtető szivattyú vezérlése el tudja dönteni saját jogon, hogy mikor kell keringtetni a vizet és az összes ehhez szükséges információt be tudja szerezni közvetlenül azoktól az eszközöktől, amelyek ezt meg tudják mondani neki. Nem kell ehhez központi MQTT bróker, nem kell ehhez MQTT cluster. Ugyanez igaz mindenféle egyéb dologra.

    A Skynetnél sem szerepelt az alapelvek között az emberiség leigázása. Soha nem tudhatod, hogy miről sutyorognak a szenzoraid és szivattyúid egymást közt. Pláne olyankor amikor otthon se vagy, ráérnek és unatkoznak. Aztán amikor rájössz a dologra, akkor már futni sem marad időd.

    Továbbra se értem, hogy mitől lesz egyszerűbb, ha behozok a rendszerbe egy csomó (felesleges) technológiát (RabbitMQ, Linux, Docker, stb.) és egy vagy több olyan központot, amelyek nélkül megáll minden... én inkább olyan technológiákat használok, amelyeket out-of-the-box tudnak az eszközök és nem igényel kliens-szerver topológiát. De felőlem mindenki azt csinál, ami akar... :)

    Mindenkinek máshol van az ingerküszöb. :) Én max odáig fogok elmenni, hogy plusz kényelmi funkciók lesznek. Felkapcsolja a villanyt, ha beülök a dolgozóba a gép elé, TV-t kapcsolja ki vagy be, airsoft-tal írtja a galambokat az erkélyen stb.
    De az ajtózár az marad kulcsos. Nem lesz biometrikus hozzáférés-kontroll, se semmi olyan nem lesz, amivel gond lehet, ha "SkyNET" öntudatára ébredne. :D tehát mondjuk letérdel az MQTT bróker és valamit nem tudok kinyit, vagy becsukni, működtetni, vagy használni. Persze mondom ezt most, aztán ki tudja mi lesz 10-20 év múlva. :)
    Mondjuk robotporszívót még mindenképp tervezek, csak aztán nehogy az is megvaduljon. :D

    De visszatérve az eredeti kérdésre: a Raspberry Pi-ok mennyire bírják a 7/24-es üzemet?

    update: Na tessék. Már el is vesztetem a kontrollt az egyik eszköz fölött. Figyelmetlen voltam az egyik Sonoff kapcsoló összerakásánál és letörtem a mikrokapcsolóról a műanyag "gombot". Szóval momentán csak hálózaton vezérelhető, kézzel nem. :) Ez már a vég kezdete? :)

    Ez csak a TH16-ost és a POW verziót érinti, ahogy nézem, a BASIC-et szerencsére nem. Én ezekre max 10%-át kötöm a max terhelésnek. Hősugárzót nemigen fogok rá kötni. De bizonyos nemzet fiairól simán el tudom képzelni, hogy rákötik a 16A-t, mert rá van írva, hogy annyi a maximum.

    Azért a 6A se kevés. Ha a 110V-os szabványt nézem, az is legalább 600W. el nem tudom képzelni, hogy mit köthetnek ezekre. Mondjuk nekem eszembe nem jutna ezekre 1-2A-nél többet rákötni. Kiindulva az ebay-n kapható kínai powerbankokból, amikre simán ráírják, hogy 20-30-50000mAh-s, és közben meg elfér egy normál kabátzsebben.

    Amíg pár, egymással kompatibilis eszközöd van és könnyen össze tudod őket kötni hálózat nélkül is, addig még igazad is lehet.
    Az egyszerűsítés akkor jelentkezik, ha dinamikusan akarod bővíteni a rendszeredet programváltoztatás nélkül; hibakezelést akarsz csinálni, monitorozást; rugalmasra (resilient) akarod csinálni, tehát egy-egy eszköz meghibásodása esetén is működik tovább a rendszered; központilag akarod menedzselni; egyszerű, rövid (pár soros) kódokat akarsz csak írni; ...
    (A Docker egyébként nem szükséges hozzá, azt csak tervként vetette fel, mivel egy RPi több száz (~300) dockeres microservicet is tud futtatni. A minimum igény egy message broker (pl. RabbitMQ) és egy OS (pl. Linux), amin fut.)

    "Az egyszerűsítés akkor jelentkezik, ha dinamikusan akarod bővíteni a rendszeredet programváltoztatás nélkül"

    Nem nagyon látom hasznát ennek... ki tudom szórni az új szoftvert OTA csatornán, de nem igazán változékony a kialakult rendszer... plusz egyébként is hozzá kell nyúlni azokhoz a komponensekhez, amelyeket érint a változás, teljesen mindegy, hogy a kommunikációs protokoll mi volt. Ha dinamikus bővítés előtt egy szelepvezérlő nem ismerte az új üzenetet, akkor varázsütésre a bővítés után se fogja ismerni.

    "A minimum igény egy message broker (pl. RabbitMQ) és egy OS (pl. Linux), amin fut.)"

    Értem én, hogy "csak"... de továbbra is overkill megoldásnak tartom és szerintem nagyrészt plusz üzemeltetési kockázatot jelent, előnyöket nem igazán.

    "rugalmasra (resilient) akarod csinálni, tehát egy-egy eszköz meghibásodása esetén is működik tovább a rendszered"

    Tehát azzal egyszerűsítem és növelem a rendszer rendelkezésre állását, hogy beleteszek egy vagy több SPOF eszközt?

    > Nem nagyon látom hasznát ennek...

    Próbálok egy példát írni.
    Van egy szelepvezérlőd és hőmérséklet mérő szenzor, valamint egy hőmérséklet szabályozó alapján szeretnéd vezérelni.
    Hová tegyük a vezérlő programocskát?
    A megoldásodnál gondolom a szelepvezérlőhöz kerülne, az kérdezné le a hőmérséklet mérő szenzort és a hőmérséklet szabályozót, majd ezen értékek alapján nyitna vagy zárna (vagy nem változtat az állapotán).
    Kevés eszköz, szépen és egyszerűen meg lehet oldani a megoldásoddal!

    Elkezd bonyolódni a helyzet ha újabb szenzorok jönnek. Ha több szenzor alapján akarunk szabályozni, akkor minden esetben amikor új szenzor kerül a rendszerbe, akkor:
    - a szelepvezérlőt erről tájékoztatni kell (pl. a programját módosítani),
    - kezelni kell azt az estet, ha egy vagy több szenzor egy ideig nem válaszol,
    - ha egy szenzor többször sem válaszol, akkor ezt valahogy tudatni kellene a felhasználóval,
    - ha egy szenzor többször sem válaszol, akkor egy idő után már nem is szabad kérdezni (circuit breaker),
    - a szenzorok lekérését lehetőleg párhuzamosan kell megoldani.
    Tehát itt a szenzor vezérlő programja már elkezd bonyolódni.

    Újabb problémák merülnek fel, ha több szelepvezérlő is van. Ilyenkor mindegyik szelepvezérlőben ott lesz a kis programocska. Mindegyik lekéri a szenzorok értékeit, ezzel az a probléma, hogy a szenzor nem tud úgy működni, hogy X másodpercenként mér egyet, majd mély álomba vonul. Neki minden esetben, ha kérdezik, akkor fel kell ébredjen és válaszolnia kell. További probléma lehet, ha a szelepvezérlőknek együtt kell működniük, pl. ha >2 fok az eltérés, akkor 3-nak kell nyitni, ha >1, akkor kettőnek, ha >0, akkor csak egynek. Ennek az algoritmusát és szinkronizációját megint elég bonyolult lehet megoldani.

    Message brokeres megoldásnál a szenzoroknak annyi feladatuk van, hogy X időközönként mérnek, majd publikálják az eredményt, majd mély alvásba vonulhatnak. A hőmérséklet szabályozó esetén, ha változik az érték, akkor egyből publikál, ha nem változik, akkor X időközönként, hasonlóan, mint a szenzorok.
    A szelepvezérlőknek annyi a feladatuk, hogy ha kapnak egy nyitás parancsot, akkor nyitnak, ha zárást, akkor zárnak, illetve esetlegesen ezek is küldhetnek státusz jelentést magukról.
    Tehát az eszközökön nagyon buta kis programocskák futnának, amiket nem nagyon kellene sohasem megváltoztatni.

    Lenne egy kis programocska, ami Y időközönként összegyűjti a szenzorok és hőmérséklet szabályozó értékeit, majd azok alapján nyitás és/vagy zárás parancsokat küldene a szelepvezérlőknek.
    Külön egy egyszerű programocska intézheti a monitorozást, egy másik a hibakezelést, egy harmadik lehet Dashboard, egy negyedik vezérlő panel, ...
    Ezekben az a jó, hogy nagyon egyszerű kis programocskák, egy képernyőre kiférnek, egyetlen helyen tudják intézni az összes service, összes eszköz hibáit, státuszait.
    Egy másik előny, hogy az adatok folyamatosan gyűlnek és amikor akciózni kell, akkor azonnal tud reagálni, nem kell várni semmire.

    > Tehát azzal egyszerűsítem és növelem a rendszer rendelkezésre állását, hogy beleteszek egy vagy több SPOF eszközt?

    A message brokert rakhatod cluster-be is, két három RPi-ra, akkor nincs SPOF. Az egyszerűsítés a kis programocskáknál jelentkezik. Mindegyik csak egy problémát old meg egyszerűen és röviden, valamint az üzleti logikák egy helyen vannak megvalósítva.

    Nem akarok senkit sem rábeszélni semmire, csak arra akarom felhívni a figyelmet, hogy van egy másik út is. Természetesen, mint minden eszköznek, ennek is vannak előnyei, hátrányai. Sajnos ez sem silver bullet! :-)

    "- a szelepvezérlőt erről tájékoztatni kell (pl. a programját módosítani),"

    Mindenképp tájékoztatni kell.

    "- kezelni kell azt az estet, ha egy vagy több szenzor egy ideig nem válaszol,"

    Ezt minden esetben kezelni kell.

    "- ha egy szenzor többször sem válaszol, akkor ezt valahogy tudatni kellene a felhasználóval,"

    Igen. És?

    "- a szenzorok lekérését lehetőleg párhuzamosan kell megoldani."

    Kevés olyan eset van egy ház-automatizálásnál, ahol valódi párhuzamosságra szükség van. Tulajdonképpen nem is nagyon tudok ilyen esetet.

    "Tehát itt a szenzor vezérlő programja már elkezd bonyolódni."

    Miért bonyolódna? Teszi a dolgát, pont úgy, mintha ezt a vezérlő programot egy központi szabályzóban írnád le... sőt, a központ vezérlő programja lesz igazán bonyolult, pedig bőven elég a megfelelő szintre tenni a megfelelő döntéshozatalt.

    "Újabb problémák merülnek fel, ha több szelepvezérlő is van. Ilyenkor mindegyik szelepvezérlőben ott lesz a kis programocska. Mindegyik lekéri a szenzorok értékeit, ezzel az a probléma, hogy a szenzor nem tud úgy működni, hogy X másodpercenként mér egyet, majd mély álomba vonul. Neki minden esetben, ha kérdezik, akkor fel kell ébredjen és válaszolnia kell."

    És? Az előbb még párhuzamosságról álmodoztál, most meg az a baj, hogy nem lehet deep-sleep állapotba küldeni a szenzort? :)

    "Ezekben az a jó, hogy nagyon egyszerű kis programocskák, egy képernyőre kiférnek, egyetlen helyen tudják intézni az összes service, összes eszköz hibáit, státuszait.
    Egy másik előny, hogy az adatok folyamatosan gyűlnek és amikor akciózni kell, akkor azonnal tud reagálni, nem kell várni semmire."

    Most is egyszerű kis programocskák vannak, mindegyik annyit tud, amennyire a feladatához szükség van, kezeli a saját hibáit és státuszait. Azonnal tud reagálni, nem vár semmire.

    "A message brokert rakhatod cluster-be is, két három RPi-ra, akkor nincs SPOF."

    Aha... szóval ott tartunk, hogy legyen _három_ RasPi, rajtuk Linux, azon message broker... mindezt azért, hogy miért is?

    "Az egyszerűsítés a kis programocskáknál jelentkezik. Mindegyik csak egy problémát old meg egyszerűen és röviden, valamint az üzleti logikák egy helyen vannak megvalósítva."

    Ha nincs központ, akkor ez alapból így van... kezdem azt érezni, mint a halász és a menedzser tanmesében: dolgozzak sokat és sokáig azért, ami egyébként már most megvan, ha nem csinálok semmivel se többet...

    > Miért bonyolódna? Teszi a dolgát, pont úgy, mintha ezt a vezérlő programot egy központi szabályzóban írnád le... sőt, a központ vezérlő programja lesz igazán bonyolult, pedig bőven elég a megfelelő szintre tenni a megfelelő döntéshozatalt.

    Az a sejtésem, hogy a lényeget még mindig nem érted, ezért egy utolsó kísérletet teszek.

    A szelepvezérlőnek pontosan elég annyi feladat, hogy ha nyitnia kell, akkor nyit, ha zárnia kell, akkor zár, illetve még státusz (health) információkat közöl magáról.
    Nézzük, ha iderakod a vezérlő programját, akkor mi lesz itt plusz funkció, ami a message broker (továbbiakban MB) esetén a "központi vezérlőben" nincs:
    - a szenzorok kérdezgetése,
    - figyelni a timeoutra,
    - számolni szenzoronként az egymás utáni timeoutokat,
    - amennyiben egy számot meghalad, akkor felhasználó figyelmeztetése,
    - esetleges párhuzamosítás (soros esetén az idők összeadódnak, itt főleg a timeoutok dobhatják meg nagyon),
    - erős függőség van az egyes eszközök között.

    Felhasználó figyelmeztetése esetén az aggályok:
    - mi a francnak kéne, hogy egy szelepvezérlőnek ez legyen a feladata?
    - ha van 10 szelepvezérlőnk, akkor hibás szenzoronként kapunk tíz figyelmeztetést

    Ráadásul ezeket a feladatokat minden egyes vezérlődben meg kell írnod, ha egyből pl. véletlen kihagyod a timeout kezelést, akkor a vezérlőd ott fog várni az idők végezetéig.

    Ami az MB "központi vezérlőjében" van és semmi más:
    - beérkező szenzor adatok és hőmérséklet szabályozó adatok összegzése,
    - időnként, a beérkezett adatok alapján szelepvezérlő üzenetek publikálása.

    Ami még különbség, MB-s esetben egy szenzor több adata alapján dönt, a szelepvezérlős esetben egy szenzor egy adatából dönt, ha több adata alapján akarnánk dönteni, akkor még tovább bonyolódik a programja.

    Szerinted melyik az egyszerűbb?

    Egy darab hibakezelő programocska feladatai:
    - Beérkező státusz (health) adatok összegzése.
    - Ha egy eszköz vagy microservice X ideig nem ad életjelt, akkor hiba üzenet publikálása.

    Az így kiadott hibaüzeneteket pl. egy web-es programocska megjelenítheti, egy másik emailt küldhet, de ugyanúgy fel lehet használni akár a ház szabályozásánál, pl. extrém hibánál egy lámpa villogtatása vagy hangjelzés. Ezek mind egymástól teljesen független kis programocskák, semmilyen függőségben nem állnak egymással.

    Ha több vezérlő eszköznek kell együttműködnie, akkor további problémák vannak:
    - hova kerüljön a "vezérlő" program,
    - hogyan működjenek együtt,
    - itt is erős függőségben lesznek.

    Pl. egy szobában több szelepvezérlő; fűtés és szellőztetés együttműködése; világítás, mozgásérzékelők, multimédia, árnyékolás, ... együttműködése.

    "Az a sejtésem, hogy a lényeget még mindig nem érted, ezért egy utolsó kísérletet teszek."

    Tökéletesen értem a lényeget. Van egy kalapácsod és mindent szögnek nézel. :)

    "A szelepvezérlőnek pontosan elég annyi feladat, hogy ha nyitnia kell, akkor nyit, ha zárnia kell, akkor zár, illetve még státusz (health) információkat közöl magáról."

    Ha mindenképpen bonyolítani akarod az életed, akkor lehet így is... de: vagy egy okos szelepvezérlőd vagy egy buta aktuátorod van. Két külön filozófia.

    "- mi a francnak kéne, hogy egy szelepvezérlőnek ez legyen a feladata?"

    Mert ettől nevezzük okos szelepvezérlőnek és nem egy buta beavatkozó elemnek.

    "- ha van 10 szelepvezérlőnk, akkor hibás szenzoronként kapunk tíz figyelmeztetést"

    És? Ki tudod szűrni viszonylag egyszerűen, hogy mi a baj.

    "Ráadásul ezeket a feladatokat minden egyes vezérlődben meg kell írnod, ha egyből pl. véletlen kihagyod a timeout kezelést, akkor a vezérlőd ott fog várni az idők végezetéig."

    Nem kell megírnom minden egyes vezérlő esetén, ugyanazt a programot tudják futtatni...

    "Ha több vezérlő eszköznek kell együttműködnie, akkor további problémák vannak:"

    Nincsenek további problémák.

    "- hova kerüljön a "vezérlő" program,"

    Ahol a legjobb helye van.

    "- hogyan működjenek együtt,"

    Ahogy és amennyire szükséges.

    "- itt is erős függőségben lesznek."

    Erős függőség akkor van, amikor minden egy helyen van és csak buta aktuátorokkal és buta szenzorokkal dolgozol.

    "Pl. egy szobában több szelepvezérlő; fűtés és szellőztetés együttműködése; világítás, mozgásérzékelők, multimédia, árnyékolás, ... együttműködése."

    Szóval összefoglalva: egy szimpla fűtésszabályozásnál komoly erőforrásokat használó stateful cluster-t kell építeni egy message broker alá minimum duplikált Wifi AP-vel, hogy minden jól és stabilan működjön... vicces, amikor egy (ipari) vezérlés architektúráját echte webes szoftverfejlesztők készítik, akik egy percet nem dolgoztak az vezérlés- és szabályozástechnikában... :)

    ...feltennék egy kérdést: csináltál már fűtésszabályozást valaha? Olyat, amikor konkrétan kazánt, szivattyúkat és szelepeket vezéreltél?

    "Egy olcsón clusterezhető központi vezérlés vagy egy feleslegesen túlbonyolított periféria?"

    Én továbbra se értem azt, hogy mitől lenne feleslegesen túlbonyolítva egy periféria, ha csak azt tudja, ami a működéséhez szükséges, de azt jól.

    Például a keringtető szivattyúnak néha be kell kapcsolnia adott időnként, majd kettő hőmérséklet szenzort kell olvasnia a bekapcsolt állapota alatt és ezekből el tudja dönteni, hogy kell-e még keringtetni a vizet, illetve ha ezek közül valamelyik hosszabb időn át nem érhető el vagy kívül esik az üzemszerű határértékeken a mért érték, akkor szóljon, hogy baj van és térjen át a vészüzemre. Ebben semmi nincs túlbonyolítva, ennyi a dolga és néhány soros program elegendő

    Csináltál már fűtésvezérlést olcsón clusterezhető központi vezérléssel? És teljesen biztos vagy benne, hogy a keringtető szivattyú vezérlését soha nem fogja érinteni az az esemény, hogy a postás kivételesen háromszor csengetett?

    Pedig jol ervel.

    Ha megbizhatoan mukodo rendszert akarsz, akkor a szenzorokat es a vegrehajto elemeket kabelen kotod a vezerlo egysegbe, ami egy arra tervezett dolog, mint pl egy PLC. A PLC-ben fut minden vezerlo algoritmus, amiknek te egy szamitogeprol vagy helyi kijelzon keresztul adod meg a kulonbozo referencia ertekeket. Ez az alap, de, termeszetesen, ezt lehet komplikalni elosztott rendszerekkel. Ekkor tobb PLC vezerli a kulonbozo alrendszereket. Ha adatot kell csereljenek, akkor kommunikalnak egymassal, lehetoleg szinten kabelen Modbus, Industrial Ethernet, vagy egyebb ipari szabvanyt hasznalva. Ez draga, es sok kabelezes kell hozza. Valamint egy hazi automatizalas lehet nem epp annyira kritikus rendszer mint egy ipari gyartosor, eromu, stb. mukodese.
    Ezt a rendszert lehet tobb modon olcsositani, kulonbozo iranyvonalakat kovetve.

    A te iranyvonalad, ha jol ertem, az, hogy a PLC-t egy, pl RPi-n futo rendszerrel helyettesited. Ennek a hatranya, hogy a kozponti rendszer meghibasodik, akkor az egesz rendszered mukodeskeptelenne valik. Igen, a PLC is meghibasodhat, de azert a jellemzo az, hogy evtizedekig mukodnek megbizhatoan. Valljuk be, egy RPi nem epp a megbizhatosag mintakepe. Es az, hogy van akinek evek ota megbizhatoan mukodik, nem teszi megbizhatobba. Nem ipari celokra talaltak ki. Ettol fuggetlenul hazi automatizalasra megfelelhet. Tovabb novelheted a biztonsagot egy cluster kialakitasaval.

    A masik iranyvonal lenyege, hogy megtartjuk a helyi kis vezerloket, amik csak annyit tudnak, hogy egy bizonyos dolgot vezerelnek, viszont azt kepesek tenni mindentol fuggetlenul. Majd ezek fole epitesz egy SCADA szeru rendszert ami menti az adatokat, mutatja az aktualis allapotokat es lehetove teszi kulonbozo referencia ertekek modositasat. Ennek az elonye, hogy, ha megszakad a kapcsolat a felsobb szinttel, a rendszer akkor is mukodik tovabb. Ha bealitottal 22 fokot, akkor tovabbra is tartja a 22 fokot.

    Ha a szenzorok olvasasat kabelezes helyett WiFi-n keresztul akarod megoldani, akkor mindket esetben le kell kezelned, hogyan reagaljon a kommunikacios hibakra a rendszer, igy ez mindket esetben kb ugyanolyan szintu problema. Itt meg annyi, hogy ha egy szenzort tobb vezerlo is kell hasznaljon, hatasos lehet, ha hiba eseten mindegyik jelez. Ugyanis lehet egy olyan problema, hogy az egyik vezerlo valamiert nem tud kommunikalni vele, mig a masik igen. Plussz informacio lehet a hibakereseshez.

    Teljesen altalanositani nem lehet, mert minden helyzet mas, de azert altalanossagban a kovetkezo 2 lehetoseget lehet kivitelezni:
    - 1 darab kozponti vezerlo, amiben implementalsz minden algoritmust
    - tobb onalloan mukodo kisebb vezerlo, amelyeket egy kozponti helyrol parametrizalsz.

    Mindketto mellett lehet pro es kontra erveket felhozni, es persze lehet kombinalni is oket.

    Sic Transit Gloria Mundi

    "Persze, tojást se tojtam még soha, mégsem eszem záptojást."

    Pedig most arról beszélünk, ahogy tojást szeretnél tojni... vagy nálad ez az egész pusztán elvi síkon mozog és tulajdonképpen nem is akarsz automatizálni olyan esszenciális dolgokat, mint a fűtés, de sommás véleményed azért van a dologról?

    > Például a keringtető szivattyúnak néha be kell kapcsolnia adott időnként, majd kettő hőmérséklet szenzort kell olvasnia a bekapcsolt állapota alatt és ezekből el tudja dönteni, hogy kell-e még keringtetni a vizet,

    Ez nem úgy tűnik, hogy sokkal többet tudna, mint az én nagyon buta fűtési rendszerem, aminél van két termosztát, két relé, egy hőmérsékletre kapcsoló szelep és egy relével kapcsoló szelep. Ha a földszinti termosztát jelez, akkor a kazán bekapcsol, keringeti a padlófűtés köreit, ha az emeleti termosztát jelez, akkor kazán bekapcsol és keringeti a az emeleti részen a vizet, a radiátorokon termosztatikus radiátorszelep van.

    Egyébként ezt írtam: Amíg pár, egymással kompatibilis eszközöd van és könnyen össze tudod őket kötni hálózat nélkül is, addig még igazad is lehet.

    Számomra egy okos fűtésvezérlés kb. onnan indulna, hogy van minden fűtött helyiségben 2-5 szenzor (összesen ~20-30), 1-5 szelepvezérlő (összesen ~10-20), 1 darab hőmérséklet szabályozó (összesen ~10). A rendszer működése nyomon követhető, esetleg szabályozható is web-es felületen.

    "Ez nem úgy tűnik, hogy sokkal többet tudna, mint az én nagyon buta fűtési rendszerem, aminél van két termosztát, két relé, egy hőmérsékletre kapcsoló szelep és egy relével kapcsoló szelep."

    Miért kellene többet tudnia? Mi mást vársz el egy keringtető szivattyútól? Attól lesz okos, hogy tud önmagáról, tud önállóan dönteni, tud számára szükséges környezetéről és képes jelezni az állapotát; nem csak egy aktuátor, amely parancsot hajt végre.

    "Számomra egy okos fűtésvezérlés kb. onnan indulna, hogy van minden fűtött helyiségben 2-5 szenzor (összesen ~20-30), 1-5 szelepvezérlő (összesen ~10-20), 1 darab hőmérséklet szabályozó (összesen ~10)."

    Az okos rendszer nem egyenlő a bonyolult rendszerrel. Plusz: ha a fűtéshez ennyi szenzor és beavatkozó rendszer kell, akkor ott alapjaiban van elrontva valami.

    "A rendszer működése nyomon követhető, esetleg szabályozható is web-es felületen."

    Ez meg független attól, hogy milyen a topológia.

    > Mi mást vársz el egy keringtető szivattyútól? Attól lesz okos, hogy tud önmagáról, tud önállóan dönteni, tud számára szükséges környezetéről és képes jelezni az állapotát.

    Én nem az eszközöktől várom el, hogy okosak legyenek, hanem az egész rendszertől. Az egyes eszközöktől azt várom el, hogy legyenek olyan buták (egyszerűek), amennyire csak lehetséges (és ez igaz a microservice-ekre is).

    > Az okos rendszer nem egyenlő a bonyolult rendszerrel. Plusz: ha a fűtéshez ennyi szenzor és beavatkozó rendszer kell, akkor ott alapjaiban van elrontva valami.

    Ha már okos fűtésrendszer, akkor én elvárnám, hogy minden fűtött helyiségben egyedileg tudjam szabályozni a hőmérsékletet, ehhez pedig kell ennyi eszköz. Egyébként a mostani buta fűtésrendszeremnél is a szelepek és a hőmérséklet szabályozók száma az kb. annyi, csak szenzorból van kb. fele annyi.
    Message brokernél egyébként a 2 szenzorosnál nem igazán bonyolultabb az 50 szenzoros.

    "Én nem az eszközöktől várom el, hogy okosak legyenek, hanem az egész rendszertől. Az egyes eszközöktől azt várom el, hogy legyenek olyan buták (egyszerűek), amennyire csak lehetséges (és ez igaz a microservice-ekre is)."

    Ja! De ezt negyven-ötven éve tudja üzembiztosan az irányítás- és szabályozástechnika microservice és message broker nélkül is.

    "Ha már okos fűtésrendszer, akkor én elvárnám, hogy minden fűtött helyiségben egyedileg tudjam szabályozni a hőmérsékletet, ehhez pedig kell ennyi eszköz."

    Helyiségenként 2-5 szenzor? Minek kellene? Ha jól be van állítva a fűtés, akkor nem is kell minden helyiségbe, pláne, ha jól le van szigetelve a ház, akkor teljesen értelmetlenné válik a hőfokok állítgatása, mert hamarabb keveredik a levegő a nyitott ajtón át, mintsem lehűlne az éppen fűtetlen helyiség.

    "Message brokernél egyébként a 2 szenzorosnál nem igazán bonyolultabb az 50 szenzoros."

    Message broker nélkül se igazán bonyolultabb, mert a hálószobai fűtés-alrendszernek teljesen mindegy, hogy milyen színű fény van beállítva a konyhában vagy csengettek-e és az a postás volt vagy a szomszéd, az extra szenzorok kezelését pedig ugyanúgy le kell programozni vagy szabályrendszerbe kell illeszteni mind a két esetben.

    Kérdés újra: Csináltál már fűtésvezérlést olcsón clusterezhető központi vezérléssel? Vagy bármilyen vezérlést ilyen módon?

    A hálózat is point2point, vagy azért SPOF-nak ott egy WiFi router? Mert akkor már majdnem mindegy, mennyi SPOF van a rendszerben. Amúgy egy helyben telepített Mosquitto nem igényel internet kapcsolatot, ezt nem tudom, hogyan került ide.
    Amúgy meg a tápellátás is SPOF, hacsak nem akkumulátorról működnek az eszközeid.

    Ave, Saabi.

    "A hálózat is point2point, vagy azért SPOF-nak ott egy WiFi router?"

    Leírtam: "egymással tudnak beszélni központ nélkül, akkor is, ha nincs internet kapcsolat vagy közös Wifi kapcsolat"

    "Amúgy meg a tápellátás is SPOF, hacsak nem akkumulátorról működnek az eszközeid."

    Központi 12 és 24 voltos akkumulátoros tápellátást kapnak, mert a világítás és a tartalék fűtés szünetmentes ellátásra van tervezve.

    "Amúgy egy helyben telepített Mosquitto nem igényel internet kapcsolatot, ezt nem tudom, hogyan került ide."

    Úgy, hogy "a központ(ok) és/vagy az internet kapcsolat kiesése" volt a téma.

    Te amúgy értően elolvasod, amire reagálsz vagy csak közlési kényszered volt?

    Ha leírom, hogy "egymással tudnak beszélni központ nélkül, akkor is, ha nincs internet kapcsolat vagy közös Wifi kapcsolat" és erre visszakérdezel, hogy "A hálózat is point2point, vagy azért SPOF-nak ott egy WiFi router?", akkor egészen pontosan hol volt hiányos az információ, ami ezt a kérdést indokolta?

    Most első körben csak a világítások és 1-2 apróság, meg a multimédia cuccok vannak rákötve. De minden megy kézzel is, mert ezt eleve úgy is terveztem. De ha az egész nem képes stabilan és megbízhatóan működni, akkor az egész nem több egy relatív költséges hobbinál. És igazából a cél az lenne, hogy ha már érdekel, és élvezem csinálni a családnak haszna is legyen belőle.
    Szóval, ha pár havonta megáll, az belefér. De azt nem akarom, hogy rendszer legyen belőle, hogy nézzem a kijelzően a "Rebooting House! Please wait...."

    Az mit takar, hogy a touch-t macerásabb flash-elni, mint a sima kapcsolókat? Én csak annyit találtam róla, hogy a 8285-ös ugyanaz, mint a 8266-os, csak 1MB Flash van rajta. A firmware, amit az esp8266-osokra felraktam, lefordítva kb. 440kB, szóval még arra is rá kéne férnie.

    Pusztan ennyi a kulonbseg. Attol fuggoen, hogy mivel flash-eled, mast kell beallitani. Pl en arduino ide-t hasznaltam, es ott erdemes a generic esp8285 profilet beallitani.
    De kb ennyi.
    Ha 8266-on hagyod, akkoris felmegy, csak az ota frissites nem fog kesobb mukodni.

    Annyibol macerasabb, hogy mig a sima sonoff-nal eleg a gombot nyomvatartani, it az egyik pint az esp-n kell foldre kotni.

    Amugy a sonoff wikin amit linkeltel, irjak is ezt, ugyhogy nincs gond.

    Akik használnak Alexát, azokhoz lenne egy kérdésem. Az Alexa hangminta alapján képes megkülönböztetni a pl. családtagokat? Gondolok itt arra, hogy mondjuk csak bizonyos embereknek engedelmeskedjen, vicceskedvű barátoknak pl. ne, csak a családnak.
    Illetve mondjuk a hang alapján tudja, hogy ha pl. a gyerek beszél hozzá és azt mondja, hogy "Alexa, kapcsold fel a szobámban a lámpát", akkor Alexa tudja, hogy a "szobámban" a gyerekszobát jelenti a Home Assistant konfigjában. Vagy ez még túl bonyolult az AI-nak?
    Ezt találtam a súgóban, de ez nem az, amire én gondolok.

    A múltkori automatavásárlós balhé - amikor gyerekek rendeltek mindenfélét - arra utal, hogy nem igazán. Vagy utána, amikor a TV-ben lejátszott riportban elhangzó kulcsszó azt azt nézőknél is aktiválta az Alexát. Bár komolyabban nem néztem utána, az is lehet, hogy kacsa az egész.

    Ave, Saabi.

    Próbált már valaki split klímát vezérelni infravörös LED használatával? Eléggé szenvedős, mind a fizikai, mind a logikai protokoll visszafejtése... :)

    Sziasztok,

    Találkozott már valaki az EasyESP-vel? Ha jól értem, akkor ez egy olyan projekt, ami azt tűzte ki célul, hogy olyan firmware-t hozzon létre ESP8266 (és elvileg ESP8285-höz is most már), amivel lehet az eszközöket webes felületen konfigurálni. Github-on eléggé aktívak, ahogy nézem.
    Próbál univerzális lenni, elég sok eszközt/szenzort támogat. Én kíváncsi leszek, hogy mi lesz belőle.

    Én egyelőre egy Arduino alapú akvárium vezérlőt csináltam. Méri, naplózza a környezet+a víz hőfokát, kapcsolja a fűtést+hűtést valamint a világítást.
    Van benne 1 etető üzemmód külön nyomógombbal, ami a pumpát és a szűrést leállítja 15 percre.
    Van még egy 16x2 kijelző a rendszerben ami váltakozva jelenti meg az állapotokat, valamint az időt és a hőfokot.
    A kapcsolási paraméterek beáálíthatók webes környezetben és mentésre kerülnek az eepromba.
    Tervezem az átépítést raspberry alapra is.

    ESP8266-ot lehet wifin keresztül frissíteni? A bootloader gondolom nem támogatja, de létezik hozzá ilyen firmware?

    Nagyon gondolkozok ez meg a raspberry pi zero között. Árban nem olyan nagy a különbség, fogyasztás szinte mindegy, helyben kicsit kisebb az esp viszont a raspberry-n komplett linux fut, számomra közelebb áll.

    Lehet: http://esp8266.github.io/Arduino/versions/2.0.0/doc/ota_updates/ota_upd…

    Arra kell figyelni, hogy ha feltolod soros porton a firmware-t, akkor mindenképp nyomj egy hardveres reset-et is, mert van egy alig dokumentált hibája a keretrendszernek, hogy soros porton felprogramozás után közvetlenül az szoftveres reset - ESP.reset() - nem működik. Egy napot szoptam, mire megtaláltam, hogy miért nem frissül OTA: nem tudott szoftveresen újraindulni.

    RasPi teljesen más dologra jó, mint az ESP... az ESP egy könnyen fejleszthető embedded rendszer, amely deep sleep állapotból képes felébredni ezredmásodperc alatt és gond nélkül tud us pontosságú időzítéseket is; a RasPi inkább egy kicsi és gyenge számítógép opcionális perifériákkal, amely nem igazán alkalmas pontos időzítésekre, teljesen más a használati esetük.

    Igen, ezzel tisztában vagyok, de most nekem nem is kell a precíz időzítés. Ha már ez otthonautomatizálós topic, elsősorban relék húzogatására gondoltam, esetleg egy-két analóg méréssel, kijelző kezeléssel (I2C) meg esetleg pár nyomógombbal.
    Tudom, a RaPiban nincs AD konverter, de az ESP-ben lévő 1 csatorna sem túl sok, így azt valószínűleg úgyis valami külső I2C-s AD konverter használnék, ha kellene.

    Itt szerintem fokozottan igaz, hogy minél egyszerűbb, annál jobb. Erre a feladatra jobban jársz egy ESP-vel, mint egy Pi-vel. Oké, hogy a Pi-n komplett linux fut, ami közelebb állhozzád, viszont pont a komplett linux-szal viszel bele olyan bonyolultságot, amire igazából szerintem nincs szükség, másrészt plusz potenciális hibaforrás.
    Nekem az említett feladatokra (relé kapcsolás, jelentél érzékelés) eddig az ESP-k tökéletesen beváltak. A Pi szerintem sok erre, még a Zero is.

    Pont ettől tartok :)
    Linuxnál magas szinten tudom kezelni a dolgokat. Van driver, legrosszabb esetben i2cset/get, stb.
    8 bites kontrollerekben általában emberileg átláthatóak a regiszterek, jók az adatlapok, és kényelmesen lehet benne dolgozni (de szerintem a PIC24 széria sem rossz, ami meg 16 bit).
    32 bites vezérlővel eddig találkoztam (STM32), ott viszont van egy jelentős komplexitás növekedés.

    Ez az amit nem tudok, mert nem programoztam még ESP8266-ot. Ha már programoztam volna, akkor valószínűleg nem zavarna. Eddig csak mint wifi "modem" használtam 8 bites vezérlőhöz, de a saját firmwaréhez nem nyúltam.
    Mindegy, meggyőztetek, hogy ez a jobb választás, neki fogok állni.

    "Ez az amit nem tudok, mert nem programoztam még ESP8266-ot."

    Attól még megnézhetnél néhány példaprogramot és hamar rájönnél, hogy ez nem alacsony szintű programozást igényel. :)

    "Mindegy, meggyőztetek, hogy ez a jobb választás, neki fogok állni."

    Feladattól függ, hogy mire jó és mire nem... feladathoz az eszközt. :)

    Hasznalhatod most is 8 bites uC melle wifi modulkent. Teljesen jo erre is.
    Arban egy kicsit dob rajta, meg ha ugyanugy hasznalod, akkor minimalisan fogyasztasban is. De ha olyan a felhasznalasod, hogy mindig az ESP-s eszkoz kezdemenyezi a kapcsolatot, akkor ha az ESP-t sleepbe kuldod (vagy leveszed a tapot) amig nem akarsz kommunkalni, es addig mindent a PIC-ed/Atmeled intez, akkor meg fogyasztasban is jobban jarhatsz. (mert az ESP elegge zabalja az aramot)

    --
    A strange game. The only winning move is not to play. How about a nice game of chess? - Wargames

    Nekem 2 hónappal ezelőttig közöm nem volt nemhogy a 32bit-eshez, de a 8bit-eshez se. Arduino IDE-ben meg már képes vagyok meglévő firmware-ben módosításokat végezni. Úgyhogy szerintem ettől felesleges félned. De ha mégis, nézd meg az EasyESP-t, ez egy már kész firmware, amit feltöltesz az ESP-s cuccra, és kapsz egy olyasmi WebUI-t, mint az egyszerűbb SOHO routereknél.

    Nemrég kérdeztem, hogy az Amazon Echo tud-e különbséget tenni, hogy ki beszél hozzá. Nem találom már, hogy hol kérdeztem, de ha jól emlékszem, valaki azt mondta, hogy nem tud. Most találtam egy cikket, ahol összehasonlítják a Google Home-ot és az Amazon Echo-t. Ebben azt írják, hogy a Google Home ezt tudja, igaz nem derül ki, hogy milyen szintig, mert példának csak azt hozzák fel, hogy a "mi van a naptáramban mára?" kérdésre annak a naptárát olvassa fel, aki szól hozzá.

    Használ esetleg Google Home-ot valaki? Érdekelnének az ilyen irányú tapasztalatok.

    Frissítettem a legújabb Home Assistantra és azóta a jól működő MQTT kommunikáció meghalt az eszközök között!
    Járt a közelmúltban más is így és esetleg tudja mi változott?
    Egyszerűen képtelen vagyok kideríteni mi a rákfene van, de őszintén már kicsit unom, hogy minden frissítés után van egy eszköz aminek a kezelése behal :S

    (HA beépített MQTT brókerét használom)

    Tudni tudok, csak nem történik semmi.

    Pl. ezzel kikapcsolnám a Sonoff kapcsolót:

    {"topic":"cmnd/sonoff_subw/POWER","payload":"OFF"}

    Configban így néz ki:

    platform: mqtt
    name: sonoff_subw
    state_topic: "stat/sonoff_subw/POWER"
    command_topic: "cmnd/sonoff_subw/POWER"
    qos: 1
    payload_on: "ON"
    payload_off: "OFF"
    retain: true

    Ez régen tökéletesen működöt, de már nem.. :S

    Nézegettem egy kis logot!

    Homeassistanban ez látszik, amikor áram alá helyezem a kapcsolót:

    INFO:hbmqtt.broker:Connection from 192.168.1.4:8395 on listener 'default'

    Azt mondjuk nem értem mi az a 8395-ös port, sehol nincs ilyen beállítva. Az MQTT 1883-on megy.
    A kapcsolón lévő SW is logol, ott ez látszik:

    00:00:10 mDNS: Initialized
    00:00:10 HTTP: Webserver active on sonoff-2.local with IP address 192.168.1.4
    00:00:12 MQTT: Attempting connection...
    00:00:13 MQTT: Connected
    00:00:13 MQTT: tele/sonoff2/LWT = Online (retained)
    00:00:13 MQTT: cmnd/sonoff2/POWER =
    00:00:13 MQTT: tele/sonoff2/INFO1 = {"Module":"Sonoff Basic", "Version":"3.9.22", "FallbackTopic":"home-assistant-2", "GroupTopic":"sonoffs"}
    00:00:13 MQTT: tele/sonoff2/INFO2 = {"WebserverMode":"Admin", "Hostname":"sonoff-2", "IPaddress":"192.168.1.4"}
    00:00:13 MQTT: tele/sonoff2/INFO3 = {"Started":"Power on"}
    21:33:06 MQTT: stat/sonoff2/RESULT = {"POWER":"ON"}
    21:33:06 MQTT: stat/sonoff2/POWER = ON
    21:33:13 MQTT: tele/sonoff2/STATE = {"Time":"2017-07-15T21:33:13", "Uptime":0, "POWER":"ON"}
    21:33:13 MQTT: tele/sonoff2/SENSOR = {"Time":"2017-07-15T21:33:13", "DHT11":{"Temperature":26.0, "Humidity":34.0}}

    Tehát csatlakozik a brókerhez, de Homeassistant paneljén mégsem változik a kapcsoló állása, a fentebb írt configgal.

    Haladás van!
    Beállítottam a config-ban a protokolt:

    mqtt:
    protocol: 3.1

    Noh, így már betudom kapcsolni az eszközöket!
    De az állapotukat nem kapom vissza, így kikapcsoltnak jelzi. Ezen oknál fogva kikapcsolni már nem tudom őket.

    Lehet teszek inkább egy próbát másik brókerrel, pl. mosquitto-val.

    Éééss működik újra!
    Kiderült, az hiba nem az én beálltásaimban van, hanem a homeassistantban.
    Tegnap este kijött a 0.49.0 -es verzió. Frissítettem rá, és azóta ismét jó az MQTT kommunikáció!
    A dühítő csak az, hogy én egy napot áldoztam a hiba kikutatására, és persze közben nálam minden rendben volt...

    Sziasztok,

    Home Assistant-tal használ valaki Amazon Echo-t vagy Echo Dot 2-est? Érdekelnének tapasztalatok. Bár ahogy nézem, most már a hass.io is képes magára hang-vezérelt asszisztenst húzni.

    https://www.facebook.com/groups/barkacsklub/permalink/371808553262965/

    No, bekopogott az ősz és ezzel együtt a fűtési szezon... :)

    A tavalyi szezon végén (áprilisban) a gázkazán termosztátját már lecseréltem saját vezérlésre, amely a ±0,5°C kapcsolási pontosságú szabályozás helyett ±0,05°C kapcsolási pontosságú lett (lásd első kép), így nincsenek akkora kilengések a fűtésben... :)

    Erről bővebben itt: https://www.facebook.com/groups/barkacsklub/permalink/302104016900086/

    Ugyanezt szerettem volna eljátszani a klíma vezérlésével is, mert a klíma még butább: ±1°C a kapcsolási pontossága, ami azért nem a legjobb dolog. Viszont eléggé nehéz volt információkat szerezni a lelkivilágáról, illetve garanciális időszakban se szerettem volna nagyon megbontani, szóval kénytelen voltam a vezérlésemnek megtanítani a távirányító jeleit és készíteni egy IR jeladót, amivel tudom vezérelni a klímát (ennek a prototípusát lásd a második képen).

    Az algoritmus egy sima arányos szabályozó, amely a limitek elérése esetén küld egy IR parancsot a klíma felé (mondjuk 22,5°C beállítása esetén így):
    22,30°C alatt: maximum ventilátor fokozat, turbó fűtés
    22,30°C - 22,35°C között: maximum ventilátor fokozat, fűtés
    22,35°C - 22,40°C között: közepes ventilátor fokozat, fűtés
    22,40°C - 22,45°C között: alacsony ventilátor fokozat, fűtés
    22,45°C - 22,60°C között: alacsony ventilátor fokozat
    22,60°C - 24,90°C között: kikapcsolt állapot
    24,90°C - 25,05°C között: alacsony ventilátor fokozat
    25,05°C - 25,10°C között: alacsony ventilátor fokozat, hűtés
    25,10°C - 25,15°C között: közepes ventilátor fokozat, hűtés
    25,15°C - 25,20°C között: maximum ventilátor fokozat, hűtés
    25,20°C felett: maximum ventilátor fokozat, turbó hűtés

    Így nagyjából 22,40°C és 25,10°C között van a ház hőmérséklete, a tartomány két vége szabadon állítható. A tegnap reggeli 22 fokról való felfűtés és a beállított hőfok tartása a harmadik képen:
    - a "Teszt-eszköz" az új prototípus, amelyik a klímát vezérli nagy szorgalommal,
    - a "Konyha" a gázkazánt vezérli,
    - a "Hálószoba" nagyjából a padlószint hőfoka és oda "becsorog" a meleg a fűtött helyiségekből,
    - a "Nappali-2mB" a nappali hőfoka két méter magasan.

    Előzmények: https://www.facebook.com/groups/barkacsklub/permalink/314588282318326/

    Ha nem valami nagyon erzekeny tropusi novenyt termesztesz, akkor celszerubb inkabb ugy beallitani, hogy ha a kulso homerseklet egy adott ertek felett van, akkor csak hut, ha egy adott ertek alatt, akkor meg csak fut. Igy elkerulod a felesleges villanypazarlast, ami abbol adodik, ha beleng a rendszered.
    Egyebkent milyen szenzor ad neked 0.05C pontossagot? En DS18B20-at hasznalok homeronek, az 1/16-od fokot ad vissza (4 bit a pont utan).

    szerk: Egyebkent teljesen korrekt rendszer. Mondjuk ha legyartatsz ennyi nyakot, akkor valamelyik ESP modult is direktben ratehetted volna, ennyinel mar erdemesebb kulso USB atalakiton keresztul mocorgatni.

    --
    Worrying about killer AI and the superintelligent robots is like worrying about overcrowding on Mars. - Garry Kasparov

    "Igy elkerulod a felesleges villanypazarlast, ami abbol adodik, ha beleng a rendszered."

    Nem leng be, több napos a hőkapacitása a háznak.

    "Egyebkent milyen szenzor ad neked 0.05C pontossagot? En DS18B20-at hasznalok homeronek, az 1/16-od fokot ad vissza (4 bit a pont utan)."

    BME-280

    "Mondjuk ha legyartatsz ennyi nyakot, akkor valamelyik ESP modult is direktben ratehetted volna, ennyinel mar erdemesebb kulso USB atalakiton keresztul mocorgatni."

    Egyrészt ez prototípus csak, másrészt OTA frissül.

    Az adatlap szerint a BME-280 pontossága:
    - 25°C-on +/-0,5°C
    - 0–65°C-os tartományban +/- 1,0°C

    De mindkettő tipikus pontosság, a maximum értékekről mélyen hallgatnak. (Egyébként ez majdnem minden hőmérséklet szenzor esetében így van.)

    Továbbá:
    „Temperature measured by the internal temperature sensor. This temperature value depends on the PCB temperature, sensor element self-heating and ambient temperature and is typically above ambient temperature.”

    A felbontás már egy másik kérdés. Az „API Output resolution” 0,01°C, de ettől még nem lesz ilyen pontos a mért érték.

    - 25°C-on +/-0,5°C
    - 0–65°C-os tartományban +/- 1,0°C

    Ez az abszolút pontossága, a relatív pontossága 0,01°C. Ha kalibrálod 25 fokon, akkor ezt tudod javítani. Egyébként van bennük gyári kalibráció is.

    Temperature measured by the internal temperature sensor. This temperature value depends on the PCB temperature, sensor element self-heating and ambient temperature and is typically above ambient temperature.

    Így van. Ezért mérek percenként néhány ezredmásodpercig és a mérések között nem kap tápfeszültséget a PCB, így nem melegszik ez miatt.

    de ettől még nem lesz ilyen pontos a mért érték

    A mérés pontossága mindig az abszolút és a relatív pontosságból jön ki... ilyen a fürdőszobai mérleg is, általában ±5% abszolút pontossággal rendelkeznek és ±0,1% relatív pontossággal. 100 kilós vagy és ráállsz több mérlegre, akkor 95 és 105 kg között mutathatnak mindenfélét. De ha egyet megvettél és azon szobahőmérsékleten 100 kilós vagy, akkor 100 gramm fogyást meg tudsz mérni rajta, az abszolút pontossághoz képest a relatív pontossággal tudod tartani a súlyodat.

    Jelen esetben engem nem érdekel különösebben, hogy a jelenlegi 22,5°C mért hőfok precíziós és kalibrált hőmérővel 22,2°C vagy 22,7°C, az érdekel, hogy a kapcsolási hiszterézis ne ±1°C legyen, hanem ±0.05°C és ezt tudja.

    Loxone-t hasznalt valaki erre mar?
    Nekem az egesz rendszer nagyon tetszik, de sajnos az ismeretsegi koromben nem ismerek senkit, aki ilyet hasznalna.

    Szeretnék egy kis felmérést Home Assistant vs. OpenHAB (vs. FHEM) kérdéskörben.
    Végre eljutottam odáig, hogy egy Home Assistant-ba belegyúrjam a jelenleg rendelkezésre álló online eszközeimet. Valóban szinte mindennel (talán még egy gereblyével is) képes együttműködni és - megfelelő tudással - bármilyen bonyolult logika beleprogramozható. DE - lehet hogy csak én kényelmesedtem el és nem vagyok már elég kocka - nekem eléggé hiányzik a frontendről egy "kattintgatós" config szerkesztő, hogy ne fejből kelljen már entity_id-ket meg state-eket configba hardcode-olni!
    Tehát érdekelne más felhasználók véleménye, hogy mi az, amiben az említett másik rendszer(ek) jobb, vagy rosszabb? Vagy milyen ötletek, javaslatok vannak a HA UI okosítására, barátságosabbá tételére (plugin-ek, alternatív frontend, mobil app, stb.)? Azt tudom, h open source - olyat írok, amilyet akarok, de kössz, frontend-et én nem írnék, azt sosem szerettem :/

    ----------------------------------^v--------------------------------------
    "Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

    Én Home Assistant-tal kezdtem, most is az van, illetve elkezdtem nézegetni a HassIO-t Nekem nem hiányzik belőle a kattintgatós UI, ami van a HA-ban, az nekem nagyon nem áll kézre, a yaml konfigok sokkal átláthatóbbak, legalábbis nekem.
    A HassIO-t szánták arra, hogy felteszted egy SD kártyára, bebootolod vele az RPi3-at, és a webes UI-n össze kattintgatsz mindent. Vannak hozzá pluginek, de ez a Dockeres őrület, amire a HassIO-t építették, nekem rettentő idegesítő.

    Én most a hassio-val ismerkedem, de a konfigurációs file-okat szigorúan text editorral módosítom. Mivel van olyan komponense, amellyel sambán lehet megosztani azokat, elég kényelmesen tudom szerkeszteni a gépemen.
    A Dockeres megoldást még szokom. Fura, de nem egyértelműen rossz.

    Ave, Saabi.

    Github-on találtam hozzá konfigurátor add-ont, azzal a HA felületébe beágyazott felületen tudod a konfigokat editálni, és elvileg az editor a yaml szintaktikájára is figyel.

    Sziasztok,

    szeretnék egy kis segítséget kérni. Elkezdtem villanykapcsolókat keresi, találtam is olyat, ami minden szempontból megfelelő lenne, mégpedig ezt.
    Sajnos EU verzió nincs belőle, csak UK, azt pedig a kommentekben többen írták, hogy az EU szabvány dobozokba ez nem fér bele. A kommentekben kb. minden 2. kérdés az, hogy mikor lesz EU verziója. 15 napja azt írták rá válaszként, hogy hát majd a jövőben... :D Így elkezdtem keresgélni, hátha van más gyártótól. Ami a leginkább hasonlít hozzá, az a Broadlink TC2 kapcsolója. De ebből meg nem találtam wifi-s verzió, csak RF-et.

    Tud valaki esetleg olyat ajánlani, ami EU szabványos, wifi-s, ESP8266 van benne, és 1 illetve 2 kapcsolós verziója is van (asszony tuti kivág a lakásból, ha nem egyforma a kapcsolók design-ja)? Meg persze CE minősítése. Jó tudom, túl sokat akarok. Pedig azt nem is írtam, hogy és dimmelhető is legyen. :)

    http://www.barkacsklub.hu/forum/hazautomatizalas-es-okos-eszkozok/rooma…

    Nos, elindult "éles" üzemben az első ESP8266 (WEMOS D1 Mini) alapú szoba-automatizálásom... :)

    (Előzmények: https://www.facebook.com/groups/barkacsklub/permalink/371808553262965/ )

    Kicsit több, mint egy év volt ez a "projekt", persze, nem folyamatosan és még nincs is vége, de most úgy érzem, hogy elértem egy mérföldkövet, amelynek örömére kicsit letisztogattam a forrást (ami még nem tökéletes) és feltettem publikusan elérhetően a GitHub-ra, meg lehet nézni, lehet belőle tanulni, illetve lehet benne hibákat javítani vagy akár új dolgokat belekérni... 

    https://github.com/gaborauth/RoomAutomation

    Mit tud?

    A leglátványosabb tudása az, hogy LED szalagot vezérel PWM kimenettel, a LED szalag fényerejét 512 lépésben tudja változtatni, a PWM frekvenciája 256 Hz (így nem igazán interferál semmivel). A két végállapot között nem átkapcsol, hanem néhány másodperc alatt folyamatosan változtatja a fényerőt, amíg el nem éri a beállított értéket.

    A LED szalag vezérléséhez van egy kapcsoló bemenete, ami célszerűen nyomógomb (csengőkapcsoló), mert ezzel lehet a legjobban többféle jelzést adni. Itt szoftveresen kezelem ugyan a pergést, illetve a rövidebb (<50 ms) zavarokat a vonalon, de hosszabb vezeték és/vagy nem megfelelő minőségű kapcsolók esetén érdemes hardveres zavarszűrést használni.

    A kapcsolóval több módon lehet kapcsolni a fényerőt:
    - 250 ms alatti kattintás esetén fel- vagy lekapcsolja a fényerőt fényátmenettel;
    - 250 ms feletti kattintás (lenyom-tart-elenged) esetén a fényerő növekedése vagy csökkenése megáll abban a pillanatban, amikor elengedem a nyomógombot, ezzel lehet éjjel halvány fényt csinálni például, így ha fel kell kelni a sötétben, nem vakít el a nagy fényerő, illetve nem zavarok másokat a fényárral;
    - 5000 ms feletti kattintás esetén felkapcsol a relé kimenet, amire rá lehet kötni mondjuk normál 230 VAC izzót, ha kell még plusz fényerő;
    - lekapcsolás esetén a felkapcsolt relé is lekapcsol.

    Az infravörös mozgásérzékelő engedélyezése esetén a felkapcsolt világítás 5 perc után fele fényerőre csökken, majd újabb 5 perc után teljesen lekapcsol - ha nincs mozgás. Ha ebben a 10 percben valaki visszamegy a szobába, akkor újra felfénylik az eredeti fényerővel... ha egyedi fényerő volt beállítva, akkor ahhoz igazodik.

    A szoftver szenzorok közül kezel:
    a, DS18B20 hőmérséklet szenzort, amiből lehet több is ugyanazon a buszon, ezeknek az értékét a beállított időközökben lekérdezi és elküldi a megadott REST URL felé.
    b, BME280 hőmérséklet-páratartalom-légnyomás szenzort, amiből egy lehet az SCL/SDA lábon, illetve ennek a szenzornak kapcsolgatja a tápját, mert folyamatos üzem esetén képes valamennyit csalni, mert kicsit melegszik.

    Ha engedélyezett a kazán vezérlése, akkor a szenzorok alapján képes a relé kimeneten tetszőleges kazánt vezérelni, a beállított hőfok felett kikapcsol, alatta bekapcsol. Opcionálisan le tudja kérdezni egy másik modul mért értékeit és annak megfelelően kapcsol ki-be.

    Ezen túl képes IR parancsokat venni, ha rákerül IR vevő, illetve képes a PWM kimeneten IR parancsokat adni, ha kerül rá IR LED megfelelő előtét ellenállással. Az IR parancsokkal lehet például klímát vezérelni PID szabályzón át, ilyenkor beolvasott IR parancsokat megadva lehet utasítani a klímát, hogy mennyire fűtsön vagy hűtsön.

    Minden modul képes frissítéseket keresni a beállított címen, ha van friss bináris, akkor letölti és frissíti magát, illetve lejelenti, hogy mikor kereste a frissítéseket, éppen milyen verzió fut rajta és mi az IP címe.

    A WiFi kapcsolathoz a paramétereket a WiFiParameters.h fájlból szedi, a modul paramétereket pedig a DeviceParameters.h fájlban adhatjuk meg.

    Képes deep sleep állapotra, ha ez meg van adva a paraméterek között...
    ...és amit még elfelejtettem esetleg, hogy tudja.

    És lett hozzá Android alkalmazás is: https://play.google.com/store/apps/details?id=live.iotguru

    Egyre több dolgot tud, az Arduino példák:
    https://github.com/IoTGuruLive/vcc_example - VCC küldése a felhőbe grafikonként (Android chart)
    https://github.com/IoTGuruLive/mqtt_example - MQTT On/Off kapcsoló (Android MQTT On/Off widget)
    https://github.com/IoTGuruLive/mqtt_pwm_example - MQTT érték küldés (Android Slider widget)
    https://github.com/IoTGuruLive/temperature_box - Hőmérő box (Doboz 3D modell, PCB gerber)
    https://github.com/IoTGuruLive/free_text_push_example - Android push notification
    https://github.com/IoTGuruLive/doorbell_notification_example - Android push notification

    Kérdések, ötletek, javaslatok és hibajegyek jöhetnek... :)

    --
    https://iotguru.live

    Én jelenleg google home alapon ügyeskedek :)
    Van egy "nagy" Home, egy home mini, egy chromecast (TV-n), 3 égős philips hue, és BT speaker. Ezek vannak összekötve.
    Most még szeretném az előszobai raspberry-s okos tükröt megcsinálni, ami IFTTT-vel kommunikál a home-al, és tervezek xiaomi légszűrőt és porszívót is felismertetni vele még az idén :)
    A rmeényeim szerint a raspberry-vel ha ellátom szenzorral az okos termosztát és ilyesmi kiváltóddik mivel arany áron vannak, és legalább a környezeti adatokat látja majd a home :)

    -42-

    ...sokkal drágább jól megcsinálni...

    Sajnos emiatt nem feltétlen a legpraktikusabb megoldások terjednek :( Kényszerűségből nálam is WiFi-n megy a legtöbb eszköz (mert azt tudják), pedig sz.gépek között is csak akkor használom, ha elkerülhetetlen (ahova lehet, inkább kábelt húzok). Sokkal stabilabb - és, mondjuk egy WiFi AP-tól független - kommunikációt lehetne kialakítani powerline-on.

    ----------------------------------^v--------------------------------------
    "Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

    Egyszerű oka vannak annak, hogy nem rádión szeretném vezérelni az egészet: tegyük fel, hogy valaki talál egy sérülékenységet a jelenlegi titkosításban. Ha kábelen megy minden, egy kulcsra zárt házban, akkor nagy eséllyel senki nem fogja a lámpáimat kapcsolgatni viccből. Rádiójelnél ez már nem olyan biztos. Abban pedig nem reménykedek, hogy minden gyártó szoftverfrissítéssel kezeli az ilyen helyzeteket, nem ez a tapasztalat.

    --
    Kum Gábor
    Linux póló | Ciprus | Matek korrepetálás

    Nézd, ha rákötöd a hálózatra, akkor adott és ideális esetben és érzékeny eszközökkel 1-5 kilométerről is tudják olvasni a kommunikációdat, hacsak nem titkosítod valamilyen módon... gondolom tudod, hogy a power line communication hálózaton semmilyen titkosítás nincs és a kommunikáció nem áll meg a ház falánál... ha meg titkosítod, azt megteheted over WiFi is.

    "Rádiójelnél ez már nem olyan biztos."

    Nem tudom, honnan ered ez a fajta security elv, hogy a kábel pusztán attól rohadtul biztonságos, hogy kábel, de ideje lenne elfelejteni.

    Egyébként ilyet keresel: https://www.alibaba.com/product-detail/Fully-integrated-power-line-carr…

    Én elég kis esélyét látom annak, hogy a rádióból komoly szívásod lenne. Van az X10, ami elvileg működik az erősáramú hálózaton, de talán itt a hup-on is voltak rá panaszok.

    Vannak rádiós busz rendszerek (például Gira), z-wave, zigbee, ezek körül keresgélj. Vezetékes busz rendszerek is vannak, a KNX szabványos, de van sok egyéb is kisebb-nagyobb gyártóktól.

    sub

    "I'd rather be hated for who I am, than loved for who I am not."

    http://iobroker.net/ ezt nem tudom ismeritek-e :)

    --

    "After successfully ignoring Google, FAQ's, the board search and leaving a undecipherable post in the wrong sub-forum don't expect an intelligent reply."

    Azokat is tudja (van hozzá adapter). Ez egy bróker szó szerint, egy interconnect platform a különböző rendszerek között.
    Itt jól leírja: https://github.com/ioBroker/ioBroker

    --

    "After successfully ignoring Google, FAQ's, the board search and leaving a undecipherable post in the wrong sub-forum don't expect an intelligent reply."

    Én találtam egy videót, ami a Node Red-ről értekezik. Ebből arra tippelek, hogy ez egy Node Red-re épülő valami. A videót nem néztem végig, csak az első két percet. Nem rémlik, hogy ott az ioBroker szóba került volna.

    Ha lenne egy példa, amiben összeraknak egy felületet szenzorokból és/vagy kapcsolókból álló rendszerhez, akkor talán lehetne sejteni, hogy kell-e ez nekem. Mert az jó, hogy az MQTT-hez van adapter. De nem ártana tudni, hogy bizonyos típusú MQTT-t használó eszközöket OOB tud kezelni, vagy minden eszközhöz kézzel kell „belefaragni” az eszköz által kezelt üzeneteket. De az is lehet, hogy félreértettem a dolgot, és ez teljesen másra való.

    Persze nem kizárt, hogy a Fórum tömve van okosságokkal, csak sajnos a német szókincsem kb. 20 szóban kimerül, így aztán nem merültem el az olvasgatásában.

    Engem az érdekelne konkrétan, hogy ha vannak olyan eszközök, amiket úgy hirdetnek, hogy megy Alexával, másokat meg úgy, hogy megy Samsung Smartthings-zel, harmadik meg IFTTT meg ez meg az, akkor lehet-e egy olyan rendszert összeraknom, aminek a közepén van mondjuk egy Raspberry pi valami home automation központis szoftverrel (mint pl. Home Assistant), ilyen-olyan rádió adókkal (mint pl. Z-wave, wifi, akármi), kiegészítő extra szoftverekkel, és kommunikáljon minddel, lássa mindet, stb.

    Nem szeretnék 4-5 féle központi egységet venni, darabját 100-200 fontos áron, speciális kapcsolókat amik aztán csak az egyikkel vagy csak a másikkal mennek, stb.

    Gondolom ehhez valami hasonló interconnect megoldás kellene. De mondjuk a leírás túl technikai, hogy értsem anélkül, hogy beleásnám magam, hogy ez megy-e alapból, vagy nekem kellene a különböző protokolokat kézzel implementálnom/konfigurálnom.

    És ha a kapucsengőm szól, hogy mozgást érzékelt, akkor egy felületen szeretném látni a riasztást, megnézni a kamera képét, és utasítást adni a zárnak, hogy nyíljék ki.
    Nem azt, hogy akkor kinyitom a ring appot, megnézem ki az és mit akar, aztán megnyitom a yale appot, és nyitási jelet küldök a zárnak, stb.
    Meg persze az audit logokat is egy helyen szeretném látni, ne az legyen, hogy az egyik ide logol, a másik oda, eltérő időpontot mutatva, stb.

    Öööö itt?

    ioBroker is an integration platform for the Internet of Things, focused on Building Automation, Smart Metering, Ambient Assisted Living, Process Automation, Visualization and Data Logging. It like a software f.e. fhem, OpenHAB or the thing system.

    Concept

    ioBroker is not just an application, it's more of a a concept, a database schema, and offers a very easy way for systems to interoperate.
    ioBroker defines some common rules for a pair of databases used to exchange data and publish events between different systems.

    Adapters
    Systems are attached to ioBrokers databases via so called adapters, technically processes running anywhere in the network and connecting all kinds of systems to ioBrokers databases.
    A connection to ioBrokers databases can be implemented in nearly any programming language on nearly any platform and an adapter can run on any host that is able to reach the databases via ip networking.

    A library module for fast and comfortable adapter development exists for Javascript/Node.js until now. Libraries for adapter development in other languages are planned (python, java, perl, ...).

    See actual list of adapters on iobroker.net http://download.iobroker.net/list.html

    --

    "After successfully ignoring Google, FAQ's, the board search and leaving a undecipherable post in the wrong sub-forum don't expect an intelligent reply."

    Szerintem a legjobb automatizálás egy David nevű android építése, mint amilyen az Alien Covenant legelején van. Zongorázik, teát főz. Persze a nemén változtatni kell, így a nevén is...

    -----------------
    10-féle lény van:
    -- aki ismeri a bináris számrendszert,
    -- és amelyik nem.

    Sziasztok!

    A fent említett megoldások közül rendelkezik valamelyik felhasználó kezeléssel és jogosultság menedzsmenttel?

    Köszönöm!

    Kicsit uppolom a témát, sok víz lefolyt azóta a Dunán:)

    - Központnak végül a domoticzot választottam egy gigabyte brix vason, ezzel sikerült összehoznom számomra a legjobb megvalósítást, van hozzá többféle app is a telefonra, tabletre.
    - Okoségők Philips Hue
    - Hő/pára/légnyomásmérésnek terveztem egy sajátot,wemos + bme280 alapon, saját nyomtatott házzal, 2000mah 18650 akksiról megy.
    - Van egy wemos + bme680 alapú levegőminőség (voc) szenzor is, hamarosan ez megkapja a nyomtatott házát.
    - Konnektornak végül a blitzwolf shp6-ot választottam, ma kaptam meg az első 2-t, hamarosan rárakom a tasmotat..
    - Van egy Broadlink rm mini3, ezzel kapcsolgatok mindent (tv, hifi, légkondi, stb)
    - Elkezdtem játszani a 433mhz door sensorokkal is, folyamatban..

    Kérdezni ér :)

    ---------------------------------------------------
    Hell is empty and all the devils are here.
    -- Wm. Shakespeare, "The Tempest"

    Home Assistant alatt próbákozom nagyjából ugyanezekkel. az aliexpressről rendelt RM mini 3-mal és RM Pro-val viszont nem nagyon akarnak összejönni a dolgok. néha ki- bekapcsolja, amit kell, néha nem, de inkább nem, nagyritkán igen. az ios appnál ugyanezt tapasztalom, hol kapcsol, hol nem. a led villan, a parancsot megkapja minden esetben.

    a kérdéseim, hogy tapasztaltál-e hasonlót domoticz alatt, ha igen, sikerült-e megoldanod, próbáltad-e ezeket az eszközöket HA alatt, ha igen, mi a tapasztalat.

    arra szeretnék rájönni, hogy az eszközök működnek ennyire megbízhatatlanul, vagy csak ügyesebben kéne tanítani a kódokat, vagy nem lát rá rendesen az infra vevőkre, vagy a HA kezeli ezeket ilyen bénán. korábban volt erről HA ticket, ott azt írták emlékeim szerint, hogy már kijavítottak minden broadlink hibát.

    Domoticz alá még nem próbáltam berakni eddig időhiány miatt :(.
    Viszont az appal tökéletesen működik minden IOS alól, rá van rakva egy iptv, lg oled, denon hifi, gree klíma, minden működik pöpecül.
    ---------------------------------------------------
    Hell is empty and all the devils are here.
    -- Wm. Shakespeare, "The Tempest"

    Nekem RM mini megy HA-val. Egyelőre csak 2 eszközre használom 1-2 parancsra, de azok nálam 100%-osan működnek. Szerintem a feltanított kódokban keresendő a probléma. Én a sniff-elt kódokat le szoktam tisztázni: próbálom szemre megkeresni benne az ismétlődéseket, a kódkezdetet és levágni csak 1 tiszta parancsra - eddig bevált. (persze, ha nincs letölthető kód az adott eszközhöz a neten)

    ----------------------------------^v--------------------------------------
    "Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

    továbbra sem vagyok elégedett a Broadlink Manager-rel. Parallels Windows 10, tökéletesen működő hálózat, pingelni tudom a minit, de a BM sem scannelés során nem talál semmit, sem kézzel (ip, mac) nem tudom hozzáadni az eszközt, semmki reakció, hiába nyomogatom az Add to Devices List gombot. a Rescan Wifi gombra sem történik semmi. miben tud ez többet, mint mondjuk a Home Assistant? mert Learn Command, Send Command ott is van. nekem második nekifutásra is hulladéknak tűnik.

    Van uj a nap alatt: https://iot.mozilla.org/
    Otletesnek tunik.

    ---------------------------------------------------
    Hell is empty and all the devils are here.
    -- Wm. Shakespeare, "The Tempest"

    Érdekelne a tapasztalatotok a SONOFF basic termékről. A feladat annyi lenne, hogy tasmota-val naplementekor felkapcsolja a kerti lámpát, 4 óra múlva meg kikapcsol, max 50W.

    - mennyire megbízható?
    - be lehet-e rakni fali szerelődobozba (a négyzet alakúba átlósan belefér, a kör alakúba gondolom csak a panel fér be)

    Igazából a 7/24 + tűzvédelemre lennék kíváncsi. Ti biztonsággal használjátok-e, mire kell figyelni?

    Ha otthont automatizáltok, hová dugjátok a kütyüket, hogy ne legyenek útban?

    Nekem eddig teljesen bevált, használható. Egyszerűen működik.
    Én saját firmware-t írtam hozzá, de ez lényegen nem változtat.

    Ha később olyan helyre szeretnéd ahol látszik, akkor van egy szép változata is. Sonoff S20. Ha a Basic-hez hozzáteszel egy dugvillát, meg egy konnektort, akkor az kb ugyanannyira jön ki, mint az S20. Csak ez nem lesz ilyen szép kompakt. :)

    http://www.redphoto.hu

    Köszi, egyelőre ismerkedem a cuccal.

    Vettem sonoff rf-et, rendeltem s20-at, meg shelly-t.

    Meglátom, melyik lesz a befutó.

    Az biztos, hogy ewelink nem lesz rajta. A permission-öknél minden kellett neki, épp hogy a feleségem telefonszámát nem kérte el.

    Igazából semmire nincs szüksége, csak egy web borzerre. Ha bármi mást kér, akkor kuka.

    Rá kell szoktatni őket. Én az egész okos otthont úgy csinálom, hogy transzparens legyen. Megmaradnak a hagyományos funkciók (pl villanykapcsoló), de ha kell Alexával is felkapcsoltatom. És egy idő után rájönnek a lényegére: "dejó, a kanapéról is fel tudom kapcsolni" és utána már azt használja.

    Három elvem van az építésnél:
    - ha lehet hagyományos módon is működjön
    - amit lehet automatizálok, főleg amit rendszeresen kell csinálni
    - ne kelljen hozzá okostelefon

    Utóbbi csak akkor, ha tényleg valami speckó dolog kell. Nem szeretem a telefont nyomkodni. Inkább kiteszek egy gombot az adott funkcióra. Túl sokat telefonozunk így is, nem kell az még otthon is.

    http://www.redphoto.hu

    Értem, amit mondasz, de sonoffal nem tudod egyszerűen megcsinálni, hogy párhuzamosan működjön a két megoldás (kapcsoló és app). Talán úgy lehetne megoldani, hogy a kapcsolókat ki kell cserélni nyomógombosra (ami pont úgy néz ki, mint a régi kapcsoló, de inkább csengő gomb (bocs, nem tudom a nevét)), és párhuzamosan ráforrasztani a sonoff nyomógombjához. Végül is nem lehetetlen kivitelezni.

    Az Alexához gondolom kellene egy HW is, ami 0-24-ben hallgatózik, én inkább ezt kerülöm, jó nekem az app :-)

    a hagyományos kapcsoló mögé be tudsz tenni Shelly reléket. Én ugyan még nem használtam, de aki igen, az azt mondja, hogy ezzel megmarad a hagyományos funkciója a fali kapcsolónak, és ugye ugyanaz a kapcsoló, amit megszoktak. De közben tudod a Shelly-n keresztül vezérelni a dolgokat.

    Én is alapvetően ebben az irányban indultam el, hozzátéve azt, hogy nem akartam egy darab "agyat" beépíteni, hanem lazán kapcsolódó decentralizált hálózatot építettem, ahol egy-egy node egy-egy feladatért felel és nem foglalkozik mással.

    Például van a világítás. Nálam ez úgy néz ki, hogy 12/24 voltos LED szalagok vannak, amelyeket PWM-el vezérlek, helyiségenként egy-egy vezérlővel. Vannak lépcsőházi nyomógombok, amelyekkel lehet vezérelni a világítást, van mozgásérzékelő, illetve MQTT-n is hallgatózik, ahol szintén be lehet állítani a fényerőt, illetve küldeni/lekérdezni állapotokat, nincs más dolga, nem csinál mást. Ha "kattintok" bármelyik gombon, akkor fade in vagy fade out van; ha megnyomom, nyomva tartom és elengedem, akkor fade in vagy fade out van addig a fényerőig, amikor elengedtem (ez éjjel hasznos); ha a mozgásérzékelő szerint nincs mozgás a beállított időn túl, akkor először felezi a fényerőt, ha arra nincs reakció, akkor a beállított időn túl kikapcsolja a világítást.

    Mivel nem kell hozzá semmit megtanulni pluszban, ezért nagyon jól használható, de opcionálisan az MQTT-n keresztül bármivel lehet integrálni, ha szükséges. És ha bármelyik eszköz döglődik valamiért, akkor nem az egész ház minden okossága áll meg, hanem egyetlen kis komponens.

    --
    https://iotguru.live

    Rossz a tapasztalat a mozgásérzékelőkkel.
    - breakelj ha fényt akarsz
    - a napsütéstől 1 év alatt game over a mozgásérzékelőnek, nálunk konkrétan szétmállott, látni a nyákot
    - 3 mozgásérzékelős lámpából 3-at kikötöttem, hogy legyen világítás, mert sosem kapcsolt fel

    Minden nap vonattal érek haza 19:20-kor és télen baromi sötét van. Nem kell mozgásérzékelő. 19:20-kor legyen világos, vagy ha felkapcsolom a villanyt.

    Nálunk az okos otthon projektem a család miatt nem fog elterjedni, mert nem vevők az újra :-)

    ugyanez volt a probléma. Rájöttem, hogy annyi a dolog nyitja, hogy lassabban kell adagolni a dolgokat, mint ahogy Te haladnál vele. Ma már a "Nem!!!"-től sikerült eljutni oda, hogy a párom hajlandó szólni Alexának, hogy a konyhában kapcsoljon lámpát, zenét, időzítőt, stb.
    A másik rászoktató opció szintén a világítás volt. Sokat kattogott az agyam, hogy hogyan lehetlen megoldani az "analóg" lámpakapcsoló megmaradjon, de okos is legyen. Nálunk az IKEA Tradfri termékcsalád lett a megoldás. Megmaradtak a kapcsolók és a régi lámpatestek, így lehetett kapcsolgatni kézzel. Be tudtam kötni Home Assistant-ba, azaz tudom automatizálni, vezérelni, stb. ami meg nekem fontos. Mikor a párom rájött, hogy ha a Tradfri saját távvezérlőjét használja, akkor van fényerőszabályzás is, akkor 1-2 hét alatt leszokott a régi fali kapcsoló kapcsolgatásáról, ma már a Trádfri app a telefonján is fent van. :) A HA-t továbbra is csak én használom, mert az neki sok, de eljutottunk a teljes elzárkózástól egy olyan szintre, amit már hajlandó használni, és amellett én is meg tudom valósítani azt, amit elképzelek. A gyerkőccel nincs gond, az egyenesen imádja, hogy a tabletjéről tudja a szobájában a lámpát kapcsolhgatni, meg a színét beállítani.

    Hosszú út volt, közel egy év, míg idáig jutottunk. De nem reménytelen! Menni fog, csak lassan.

    szerk: Most írták egy FB csoportban: "...this solution has a high WAF", néztem hülyén, hogy hogy kerül ide egy WAF és főleg minek. Aztán felvilágodsítottak, WAF=Wife Acceptance Factor :D

    Szerintem alapvetően rossz megoldás az Alexa, soha nem fogom felrakni, elvi okokból.

    Reggeltől estig ezt mondogatod: Alexa, kapcsold fel a villanyt! Alexa, kapcsold le a villanyt! Szépen lassan az egész emberi kommunikációdat meg fogja fertőzni az r=1 beszéd: Drágám, adj ebédet! Kislányom, menj iskolába! Peti, zárd be az ablakot! Marci, vidd ki a szemetet!

    Van egy baljós érzésem, hogy egyre jobban be fog szivárogni a köznyelvbe az Alexával folytatott "intelligens" kommunikáció, ami majom makogássá fogja degradálni az emberi beszédet. Ráadásul egyébként is utálok dumálni, szívesebben megyek oda a kapcsolóhoz, hogy megnyomjam.

    Ha már veszem a fáradtságot, hogy kinyissam a számat, akkor már lehetőleg értelmes partnerrel szeretnék beszélgetni.

    +1 Kíváncsiságból én is hozzáfaragtam a GAssistant-ot a HomeAssistant-omhoz, de hülyén érzem magam, hogy a telefonommal beszélgetek - ráadásul ritka, hogy megérti és meg is csinálja, amit szeretnék. Így én is inkább a praktikus helyekre elhelyezett, scene-ekre programozott gombokkal, kapcsolókkal, távirányítókkal és automatizmusokkal operálok - végső esetben a telefonos app-al.

    ----------------------------------^v--------------------------------------
    "Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

    van egy Wemos D1 mini (nem pro, nem light), összeforrasztva pár shield-del: OLED kijelzővel, relével, SHT30 hőmérővel, nyomógombbal (igen, termosztát lenne egyszer). tegnap nekiálltam tesztelni az Arduino-s példákkal. relé tökéletesen működött. gomb tökéletesen működött. kijelzőkhöz hiányolt több library-t, ezeket telepítgettem. majd egyszercsak espcomm_upload_mem failed hibával megállt az upload, és azóta mindenre ezt kapom, azokra a példákra is, amiket korábban sikeresen feltöltöttem és futtattam.

    elvileg csak Wemos D1 mini example-ket töltöttem fel, csak olyan include-okat telepítettem, amiket hiányolt az adott példa. forrasztás elvileg nem engedett el sehol. online tanácsokat követve próbáltam a D3-at (GPIO0-t) lehúzni GND-re jumper kábellel, nem segített. multiméterem van itthon, oszcilloszkópom nincs. szoftveres vagyok, hardveresnek elég laikus.

    SEGÍTSÉÉÉÉG!!!

    Nekem ugyanez történt egy kínai nodemcu-s ESP8266 lapkával, végül töröltem a flash memóriát az esptool-al:

    esptool.py --port COM12 erase_flash

    Ezt úgy tudtam (alapból ezzel is espcomm_upload_mem failed hibát kaptam), hogy az én lapkámon van egy boot gomb / reset, és ezek közül valamelyiket
    1. megnyomtam mielőtt rádugtam a lapkát az USB-re, majd
    2. elengedtem miután rádugtam a lapkát az USB-re.

    Végül ugyanígy fel tudtam rá újra tölteni a programomat (amin módosítottam időközben egy kicsit), és utána valamiért minden megjavult.

    Van ötletem, hogy a feltöltött programomban mi vitte félre a dolgokat, de ezekre csak gyanakszom.

    Jó próbálkozást :)

    Egyébként amikre gyanakszom, hogy nálam mi lehetett a gond:

    1. deepsleep-et használt a programom, és ha egyszer deepsleep-be ment, akkor a feltöltés nem tudta resetelni USB-n. (ez biztos)
    2. A Serial-al véletlen nagyon hülye sebességet választottam éppen, ami után a hiba jött.

    Egyikben sem vagyok biztos, mert a deepsleep elvileg csak 5 másodperc múlva következett be, a Serial-nál megadott sebességnek meg nem látom, hogy mi köze van a feltöltéskori reset-hez.

    köszi a tapasztalatokat. fél nap pihentetés után még egy utolsót rápróbáltam, és nagy meglepetésemre ezúttal felment a kód, pedig emlékeim szerint semmit nem tettem az utolsó sikertelen próbálkozás óta. hacsak nem a kábellel manuálisan flash mode-ba lökdösés tette meg a hatását, kiegészítve a teljes áramtalanítással. szóval egyelőre nem értem mi van, de örülök, és tovább kísérletezek.

    a további kísérletezés eredménye: fix 115200 baud upload, hol sikerül, hol a korábbi hibát dobja. ilyenkor resetelek, áramtalanítok, GPIO0-t húzok nullába, illetve ezek tetszőleges kombinációját alkalmazom, amíg egyszercsak sikerül az upload. nem vagyok róla meggyőződve, hogy összefüggnek a műveletek és a sikeres feltöltés, olyan is volt, hogy sikertelen után semmit nem csináltam, csak újra az uploadra nyomtam, és sikerült.

    ami még érdekes, hogy soros konzolon upload után megjelenik egy

    1384, room 16
    tail 8
    chksum

    szöveg, aminek utánakeresve

    load 0x4010f000, len 1384, room 16
    tail 8
    chksum 0x2d
    csum 0x2d
    v09f0c112
    ~ld

    a teljes verziója, és nem találtam rá kielégítő magyarázatot, hogy mit jelent és mi okozza.

    Akkor még úgy gondoltam, hogy üzemszerűen használod.

    Most már látom, hogy tulajdonképpen fogalmad nincs, hogy mit és miért csinálsz, ötletszerűen fel- és lehúzol lábakat, meg ilyesmi. Fogadd meg a saját tanácsod: "esetleg olvass utána a neten, de legalább ebben a topicban."

    --
    https://iotguru.live

    nem "ötletszerűen fel- és le, meg ilyesmi", hanem elfogadható magyarázattal ellátott leírásokat követve, tudatosan, több módszert is kipróbálva illetve kombinálva. nem hagynám a helyedben figyelmen kívül azt a körülményt sem, hogy a linkelt megoldások segítettek megoldani a problémát.

    a hozzáállásodból (nem megy elsőre papírforma szerint? dobd ki, vegyél újat, jobb ötletem nincs!) arra következtetek, te sem hardveres vagy :D

    "WEMOS D1 mini esetén nem kell neked semmit csinálni, rádugod USB-n, beállítod, hogy WEMOS D1 mini a board, és fel tudod tolni a firmware-t anélkül, hogy hozzányúlnál vagy bármit bármilyen jelszintre kellene húznod. Valamit rosszul csinálsz."

    "Most már látom, hogy tulajdonképpen fogalmad nincs, hogy mit és miért csinálsz, ötletszerűen fel- és lehúzol lábakat, meg ilyesmi."

    Gondolom pont azokat a lábakat húzza fel és le (és feltételezem, hogy nem ész nélkül, hanem amelyiket kell), amiknek a hatására a bootloader fog elindulni, ami valamiért nem tudott jól megtörténni automatikusan az USB-serial IC-vel (ha rádugod USB-n, pont az a gond, hogy ez nem megy). És az a nem biztos, hogy ez azért van, mert sz*r az USB-Serial IC, és ki kell dobni az eszközt, szerintem ez simán lehet a mikrokontrollerre feltöltött program miatt is, vagy az egyéb eszközök miatt, amit a lapkájára kötött. De lehet a kínai board miatt is, pl:

    https://github.com/espressif/esptool/wiki/ESP32-Boot-Mode-Selection (látom, hogy ez nem esp8266)

    "Some third party ESP32 development boards use an automatic reset circuit for EN & GPIO pins, but don't add a capacitor on the EN pin. This results in unreliable automatic reset, especially on Windows. Adding a 100nF (or higher) value capacitor between EN pin and GND may make automatic reset more reliable."

    Nézd, a WEMOS D1 mini az egyik legjobban sikerült board, egyszerűen tényleg az van, hogy ha üzemszerűen használod, akkor nem okoz gondot. El kell olvasni a doksikat és nem olyan oldalakról kell begyűjteni az információkat, amiket balfaszok írtak, akik szintén sötétben tapogatóznak. Sajnos ez a szakma is odáig süllyedt, hogy azzal már a felső 10 százalékba kerülhetsz, ha elolvasod a doksit.

    Az meg külön jó, hogy behozol egy noname ESP32 board issue-t, mint bizonyítékot... :)

    --
    https://iotguru.live

    Ezt csak példaként hoztam fel, de most megnéztem: A wemos.cc oldalról (About: Us WEMOS is a young Chinese company, we designed lots of cost-effective IoT products.) az aliexpress-re van az oldalon egy link: "LOLIN official store". Itt a wemos d1 mini 3,5 USD. Ha csak simán rákeresek az aliexpress-en, akkor wemos D1 mini-t már 1,6 USD-ért is lehet kapni. Felmerül bennem, hogy minden második kínai (árus, vagy egyetemista, vagy nagymama, nem tudom hogy megy ez arrafelé) gyártja a saját verzióját, amit nehezen tudok másnak tekinteni, mint egy noname board-nak. Lábkiosztásra egyezik, és jobb esetben méretre is.

    dlaszlo, szerintem fölöslegesen strapálod magad. ő még nem járt így minivel, tehát aki igen, az balfasz. ha pedig megoldást is talált - történetesen ugyanazt a metódust, mint a többi ESP8266 esetében - akkor nyilván világtalan is. tényekkel - a módszer megoldotta a problémát - nem foglalkozik.

    ha megfigyeled, egyetlen posztjában sem említ konkrétumot, mit lehet itt rosszul csinálni (azon túl, hogy nem azt a board-ot állítod be az IDE-ben, amit használsz, hát ehhez tényleg hardveresnek kell lenni...), milyen többlettudást adott neki a manual-ok kiolvasása, (hacsak nem azt, hogy probléma esetén dobd ki, vegyél újat), mit csinál ő másképp, mint a sok vak és világtalan, egyszerűen csak fikáz mindenkit a magas lóról.

    amit írsz az eszközökről, abban szerintem teljesen igazad van, igen sokféle D1 minit látni a neten, árban is viszonylag nagy szórással, sőt külsőre is akadnak különbségek, pl. maga a Wemos logo kinézete :D
    elég gyanús, hogy sok az utángyártott, másolt board, ki tudja milyen minőségű alkotóelemekből, sőt nekem van olyan button shield-em, amin meg kellett fordítani a gombot, mert rossz oldalra volt gyárilag beforrasztva. megfordítva tökéletesen működik :)

    @_Franko_ @phord Átment a vita személyeskedésbe, igazából akármi is lehet a probléma. Az én board-om most fél nap után kifagy, de csak azzal a tápegységgel, amit erre a célra akartam használni.

    Rendeltem WEMOS D1 mini-t, és WEMOS D1 mini pro-t is :) köszi a tippet.

    A pro-ra úgy látom, hogy lehet kötni aksit is, ugye jól értem, és tudja tölteni a 18650-eket, a TP4054 ezt megoldja, és alámeríteni sem engedi?

    https://wiki.wemos.cc/_media/products:d1:sch_d1_mini_pro_v2.0.0.pdf

    tápegység: nagyon fontos! a tapasztalatom (érteni továbbra sem értek hozzá jobban), hogy számít(hat), mekkora árammal hajtod. egyrészt van egy RF head-ként használt ESP8266-om (D1), és érezhetően romlik a vevőteljesítmény (közelebb kell menni ugyanazzal az adóval), ha nem az IDE-s mbp usb-jén van, hanem mondjuk RPI usb-jén, vagy usb töltőn. 2.4A töltővel jobb a vétel, mint 1A töltővel. másrészt olvastam olyan megfejtéseket a mini serial-os üzenetére, hogy a kevés áram okozhatja, letesztelni nem sikerült még.

    próbált meg egy nagyobb táppal, hátha az a gond.

    pro-val semennyi tapasztalatom nincs, de ha megosztod a tapasztalataidat (és azok pozitívak :), akkor lehet hogy én is beruházok egyre. tudni annyit tudok róla, amit a leírásban látok: Lithium battery interface, 500mA Max charging current. ez alapján igen, direktben tudsz rákötni akksit, és usb-ről max 500mA-rel tölti is. az "alámeríteni sem engedi"-t nem teljesen értem, hogyan tudná. lekapcsol?

    18650-ekkel óvatosan: https://www.youtube.com/watch?v=yaXKEusWtZc

    nincs itt olyan közöttünk, aki foglalkozik ilyenekkel, van tapasztalata a feldobott kérdésekkel kapcsolatban, és azokat szívesen meg is osztja? (nem olyanra gondolok, hogy nem tapasztalta a a leírt jelenségeket, tehát azok nem léteznek.)

    noname volt mindkettő, lipobol itthonról ezt rendeltem, mert mindenféle fúrás faragás nélkül megy: https://www.akku-elem.hu/18650-2000mah-li-ion-36v-ipari-akkumulator-cel…
    Nekem ami fura egyébként, hogy az egyik lap megy heteket, hónapokat akár, a másik meg 2 nap után kifagy, és resetelni kell.
    Nem tudtam még hova tenni a dolgot.
    Ugyanaz teljesen mindegyik.
    ---------------------------------------------------
    Hell is empty and all the devils are here.
    -- Wm. Shakespeare, "The Tempest"

    Sziasztok!

    Köszi. 18650-es aksival én most pórul jártam, kínából rendeltem 4 egyforma LG-t, és kaptam 2-2 különbözőt, három újnak nézett ki, egy pedig használtnak, és a négy aksiból az egyikre lehet azt mondani, hogy 2000 mAh körüli, a másik három 1000 mAh körül van (ahogy mértem). Eredetileg 2500 mAh-s aksik lennének, feltételezem hamisítvány mind a négy.

    Még egy kérdés: ha 1s cella védelmet teszek a 18650-es aksikra, akkor lehet őket sorba kapcsolni? Vagy vegyek egy 2s, vagy 3s BMS-t? A 18650-esek párhuzamos összekapcsolásával az lehet a baj, hogy ha az egyik tönkre megy, akkor az rövidre zárhatja a másikat.

    Tápegység: egy gyenge Microsoft telefonhoz adott tápegységgel fagy szét a board-om, és egy Blitzwolf tápegység, amiről viszont jól megy.

    Arra gondoltam, hogy mivel úgy is tápegységről megy, nem kell deep sleep (most van deep sleep a programjában), és érdemes a watchdog-ot bekapcsolni. Ha szétfagy véletlen, majd reset-el + a normális tápegységet használom majd a biztonság kedvéért.

    A legelsőben összehordanak mindenféle faszságot, mert nem olvassák el, hogy nem egy általános ESP8266 a téma, a lényeges hozzászólás: "OP's issue is resolved, and I personally can't reproduce on a Wemos D1 mini r2."

    A másodiknál a megoldás: "I simply reinstalled the USB-Drivers for the CH340 chip that does sthe USB to TTL conversion for the D1 mini!"

    A harmadiknál említve nincs a WEMOS D1 mini, nem releváns.

    A negyedik ugyan WEMOS, de nem D1 mini, hanem D1 Lite.

    Az ötödik egy NodeMCU és egy mezítlábas ESP8266 board.

    --

    Leírom még egyszer, utoljára: a WEMOS D1 mini esetén nem kell semmi varázslat, rá kell dugni USB-n, be kell állítani az Arduino IDE-ben, hogy WEMOS D1 mini a board és meg kell nyomni azt a nyomorult upload gombot. Eléggé sokszor csináltam, soha nem kellett semmilyen GPIO-t buzerálni, ha nem így működik, akkor valamit rosszul csinálsz, nézz meg egy friss tutorial-t a témában és lehetőleg ne olyan oldalt kövess, ahol vakok vezetnek világtalant vagy nem egzaktul azt a board-ot használják, amit te.

    --
    https://iotguru.live

    részemről is az utolsó hozzászólás a veled folyó vitában, mert teljesen értelmetlen, pusztán győztesen akarsz kikerülni belőle, amúgy teljesen parttalan:

    - a kiindulás az, hogy rá van dugva USB-n, be van állítva Arduino IDE-ben, hogy WEMOS D1 mini a board, és amikor megnyomom azt a nyomorult upload gombot, akkor hol sikerül a feltöltés, hol nem.

    - sok friss tutorial-t megnéztem és elolvastam a témában, nem is bántam meg, a probléma megoldódott.

    - egyetlen dolgot csinálok, ami nem szoftveres: bedugom az USB kábelt a boardba. viszonylag nehéz elrontani. (erre gondolom az lesz a válaszod, hogy akkor nyilván szoftveresen csinálok rosszul valamit. mivel erre a vázolt okokból már nem fogok válaszolni, így leírom előre: semmi nem változik szoftver oldalon egy sikertelen és egy sikeres feltöltés között.)

    - a jelek szerint nincs akkora szakadék ESP8266 és ESP8266 között.

    https://community.platformio.org/t/bricked-wemos-d1-mini-visual-studio-…

    egyetlen dolgot csinálok, ami nem szoftveres: bedugom az USB kábelt a boardba. viszonylag nehéz elrontani.

    Én pont a hétvégén küzdöttem egy NodeMCU 0.9-cel. elvileg az is ugyanez, hogy bedugod és megy, gombot se kell nyomni, a szoftver átbillenti flash mode-ba. De nem. aztán úgy egy óra múlva jöttem rá, hogy régi a laptop, sokat használtam az USB portjait (port replikátorok, egér, pendrvie, miegyéb), és egyszerűen kilazultak a portok, nem tartják már úgy a bedugott kábelt, mint új korukban.
    Azaz kontakthibásak, áramot ugyan kap a rádugott eszköz, de a kommunikáció problémás. Másik gépen ugyanaz a NodeMCU, ugyanazzal az USB kábellel tökéletesen működött.
    A kábel minősége sem mindegy. Van egy rakás kínából rendelt USB kábelem, aminek egy része szimplán fos. Ezért ilyen flash-eléseket most már valamelyik telefon töltőjéhez kapott normális minőségű MicroUSB kábellel csinálok.

    Simán lehet ez is probléma.

    igen, ez is lehet, bár nem hiszem, hogy nálam erről lenne szó, egy 6 éves, de jó állapotban lévő mbp-t használok flasheléshez, aminek sosem volt folyamatosan használva az usb portja semmire, csak alkalmilag, nem lötyög, nem dobja el a beledugott eszközöket. azért megvizsgálom, az ördög nem alszik.

    a kábelekkel én is elvoltam egy ideig, amíg megtaláltam a megfelelőt (töltőkábel vs. adatkábel...), de ez most jónak tűnik, és az is egy fontos körülmény, hogy csak a mini produkálja a jelenséget, egy sima D1 pl. sosem.

    ha esetleg van valakinek tapasztalata ezzel a soros konzolon megjelenő üzenettel flashelés után (ld. https://hup.hu/node/151803#comment-2341425 ), azt még szívesen megfejteném, mi okozza és mire utal, csak elveszett a kérdés a nagy szájtépésben.

    Sziasztok,

    A chameleon-smarthome.com rendszeréről mi a véleményetek?
    Használ valaki ilyet?

    Ezt írják a kábeles kiépítésről:

    "A Chameleon nem igényel speciális szaktudást a telepítés során. A rendszer kialakításához szükséges egyetlen, törpe feszültségű -J-Y(St)Y 2x2x0.8- vezeték a hagyományos villanyszerelési topológia szerint telepítendő."

    "A Smart Home Ready rendszer könnyedén beépíthető. Nem kell kilométer hosszú kábelekkel bajlódnia, elég egyetlen extra vezeték telepítése a hagyományos elektromos vezeték mellett. Az előkábelezett rendszerbe az okosotthon akár egy nap alatt beépíthető."

    "könnyen telepíthető: nincs szükség az okosotthonoknál megszokott kábelrengetegre, a rendszer működéséhez csak egyetlen BUS kábel beépítése szükséges"

    Ennek, hogy 1 kábelen megy az egész, van valami hátránya?
    Köszönöm.

    Sakk-matt,
    KaTT :)

    Értem, köszi az infót, ezt nem tudtam.
    Te melyik cégtől vásárolnál, ha ez a 2 közül választanál? Miért?

    Mit javasolnál, ami szerinted időtállóbb, kábeles megoldás, mint az egy buszos megoldás?

    A sebezhetőséget hogy érted? Ha 1 kábel megszakad, az egész nem megy? Vagy biztonságtechnikai szempontból?
    Tud valaki infót, hogy működik ez a körbe kötött 1 buszos megoldás? Ha 2 eszköz egyszerre akarna kommunikálni / adatot küldeni, akkor a második vár, amíg szabad lesz?

    Sakk-matt,
    KaTT :)

    Nem tudom melyiktől vennék, mert nem vennék. :)

    A csillagpontos kialakítás kevésbé sebezhető, mert a buszhoz elég elvágnod vagy rövidre zárnod a busz vezetékeit, már nem tudnak beszélni egymással.

    De én a vezeték nélküli kommunikációt tartom jobbnak, az amúgy is már van mindenhol.

    --
    https://iotguru.live

    Ahja. És összesen eddig hányszor sikerült véletlenül egy ilyen jammert elhelyezned otthon, hogy aztán órákig keresd a zavar helyét? Mert egy vezeték igen könnyen sebezhető véletlenül, elég egy rossz helyre felfúrt kép a kábelezés után 5-10 év múlva.

    Ha meg arra gondolsz, hogy majd jól zavarni fogják a kommunikációt, hogy ne tudd mobilról felkapcsolni a lámpát a budiban, csak a fali kapcsolóval, akkor aztán jól kibasztak veled, ahogy kinn álltak az utcán röhögve, esőben, szélben, tűző napon vagy jéghidegben, hogy ha hazaérsz, akkor majd zavarják a cuccaidat.

    Próbáljunk az életszerűség talaján maradni, számold össze, hogy most mennyi cuccod kommunikál vezeték nélkül...

    Nyilván az otthoni wifis lámpa senkit nem érdekel. De pl. autótolvajok sok éve használják a GPS/GSM jammereket autólopás közben, ennek mentén egy teljesen vezetéknélküli okosházat amiben már a "riasztó" is smarthome és sima WiFi-s ajtó/ablak érzékelőkkel dolgozik, a jövő szakemberei simán kirámolják egy jammerrel. :)

    De pl. autótolvajok sok éve használják a GPS/GSM jammereket autólopás közben, ...

    És ennek hatására sok éve már nincs ilyen egyik autóban sem. Ja, de, van ilyen továbbra is.

    ... ennek mentén egy teljesen vezetéknélküli okosházat amiben már a "riasztó" is smarthome és sima WiFi-s ajtó/ablak érzékelőkkel dolgozik, a jövő szakemberei simán kirámolják egy jammerrel

    Aham, ennek mentén nincs különbség abban, hogy az ajtóérzékelőd vezetékes-e vagy sem, mert ugye ugyanúgy szabotázs, ha elvágják a kábelt, mint ha zavarják a vezeték nélküli kommunikációt.

    Mindent meg lehet oldani balfaszul és jól is. Annak nem látom sok értelmét, hogy elkezdesz álmodozni és képzelegni arról, hogy egy balfaszul kivitelezett rendszer mennyivel szarabb egy jól kivitelezett rendszernél.

    Próbáljunk az életszerűség talaján maradni,

    Akkor tudhatnád, hogy normális vezetékezésnél (szakember által készített) pontosan tudod, hogy hol mennek a vezetékek. Akár mikor csinálták, akár milyen szakember csinálta, mindig lehet tudni.

    Egyébként nagyon vicces, hogy amit ahogyan éppen csinálsz csak az a jó, minden más rossz. Amikor vezetékkel csináltad, akkor csak úgy volt jó, amikor nem azzal, akkor meg csak úgy jó, amikor message broker nélkül akkor úgy, most azzal, központi egységgel vagy anélkül.
    Már nem is nagyon tudom követni, hogy szerinted éppen melyik a kizárólag jó megoldás.
    Lehet, hogy kicsit megengedőbbnek kellene lenned a más megoldások iránt.

    Boldog karácsonyt!

    Akkor tudhatnád, hogy normális vezetékezésnél (szakember által készített) pontosan tudod, hogy hol mennek a vezetékek. Akár mikor csinálták, akár milyen szakember csinálta, mindig lehet tudni.

    Na, akkor ismét leírom: próbáljunk az életszerűség talaján maradni, nem fogod tudni, hogy hol mennek a vezetékek, álomvilágban élsz, ha úgy gondolod, hogy mindig mindent a szabványok szerint kiviteleznek.

    Már nem is nagyon tudom követni, hogy szerinted éppen melyik a kizárólag jó megoldás.

    Sehol nem írtam kizárólagos megoldást. Előnyöket és hátrányokat írtam mindig és mindenhol. Itt ebben a szálrészben éppen azt, hogy a vezeték nélküli megoldásoknak is van előnyük, nem kell teljesen elvetni, főleg nem olyan hülye indokokkal, mint amelyek felmerültek.

    Lehet, hogy kicsit megengedőbbnek kellene lenned a más megoldások iránt.

    Ezt biztos nekem akartad írni és nem azoknak, akik szerint a vezeték nélküli megoldások abszolút elvetendőek?

    Nem tudom, hogy ki lehet az az egy! :)

    Nekem mindenhol, ahol kábeleztem, le volt fotózva és dokumentálva, hogy hol mi megy.

    Tudom, hogy X falon Y féle kábel van, és hol, képen is látom, össze is van írva.

    Mivel jelen voltam minden esetben, amikor a kábelt csövezték, vezették, arról is van kép, hogy, hol véstek, hol vannak a dobozok, mik vannak bennük.

    Esek több helyre el vannak mentve, így pár perc alatt elérem. Tudom, nem tipikus.

    Ha másnál kell kábelezni, vagy fúrni, az szívás, nem kérdés, én most a saját esetemről beszélek, hogy ezért én soha nem fúrtam bele kábelbe.

    A kábelezés nem való mindenkinek. A környezetemben a többségnek a vezeték nélküli az optimális, mert nem tudná kifizetni a szép falba vésés, kábelezés költségét, igazából bárminek örülnek, csak menjen, sőt, van aki nem is tudja, hogy mit akar, hát akkor miért kábelezne, ha igazából csak valamit akar, amiről nem is tudja, hogy lesz-e értelme, csak legyen okos a lakása, pipa, aztán kész. Engem elvből zavar, hogy vezeték nélkül kommunikálnának a szenzorok, kapcsolók, stb., ha meg tudom oldani észszerűen, hogy kábelben menjen. A többséget nem zavarja, hát ennyi.

    Csak hogy lássátok, hogy én sem mindent csak kábelen oldok meg: úgy néz ki, hogy pár helyiségben a radiátorokat valamilyen vezeték nélküli vezérléssel fogom megoldani, talán zwave alapú, de még ez arrébb van. Mivel nem nagyon láttam még jó kábeles radiátor vezérlést, ez például nem győzött meg. Ha tudtok ennek ellenére jó vezetékes radiátor termosztát vezérlést, várom... na jó, vezeték nélkülit is. Honeywell-t ajánljátok? Elvileg csak a radiátor tekergetését akarnám valami vezeték nélküli eszközre bízni, amit legjobb esetben API-n keresztül valahogy tudok lekérdezni/vezérelni, kevésbé optimális esetben csak lekérdezni tudom, legrosszabb esetben az sem lesz benne. Zwave vagy más?

    Sakk-matt,
    KaTT :)

    "szakember"... Ezen felröhögtem. Max akkor ha te vagy az és magadnak csinálod. Ma itthon még a neves cégek is "valamilyen" papírral rendelkező alvállalkozókkal dolgoznak, ahol jó esetben a csapatban 1, rossz esetben sok csapatra összesen 1 ember rendelkezik papírral. És hogy az az egy is mennyire ismeri a szabványt, és hogy azt a verziót, amikor suliba járt, vagy a mait, az csak hab a tortán.

    Vagy ismerik a Pitagorasz-tételt és tudják, hogy ha a konnektor 30 centi magasan van, a csövet a falban pedig függőlegesen fel és a plafon alatt 30 centire vízszintesen kellene vinni 2 és 5 métert, akkor pontosan 1,6 méter csövük és vezetékük marad meg maszek munkákra, ha inkább átlósan viszik, cserébe pedig ők se látnak semmi kivetni valót abban, ha a vízvezeték szerelők térnek el hasonlóan a tervektől, amúgy is egy a cégtulajdonos. És ez megtörtént eset új építésű lakásban, a lakástulaj meg úgy gondolta, hogy ott van a cső, ahol a terveken szerepel... hát nem ott volt. Ahhoz meg sok sikert, hogy 5 év távlatából bármelyik kivitelező céget megtalálod és rá tudod lőcsölni a keletkezett kárt.

    aki nem jar ki az epitekezesere, az meg is erdemli.

    Aki meg nem csinal fotot (ugy, hogy a telefonjan *ott a kamera*), az meg az "igy jartal" eset.

    Horrorsztorit mindenki tud.

    Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

    aki nem jar ki az epitekezesere, az meg is erdemli

    Ismét azt mondom, hogy próbáljunk az életszerűség talaján maradni, nem járnak ki a népek építkezésekre, pláne nem fotózzák le, hogy mi hol van a falban és pláne nem verik ki a balhét, ha nem ott van a vezeték, ahol a tervek szerint kellene. És az emberek többsége használt lakást vagy házat vesz, aminél pedig nem fogják elővenni a családi fotóalbumot, hogy a villanyszerelők hol vitték a vezetéket a falban.

    Horrorsztorit mindenki tud.

    Oszt? Ettől nem fordulhat elő, hogy amikor felfúrsz egy képet a falra, akkor pisálni kezd a fal? Vagy lemegy a redőny és úgy is marad? Értem én, hogy te különleges vagy és mindent precízen dokumentálsz, de legyél már realista és nézz körbe, hogy ezt rajtad kívül hányan teszik meg.

    Jaja. Régi belterületen (=kiépült infrastruktúra) ritka a szűz telek, azaz ha nem akarsz frissen belterületbe vont tanya vagy szántóföld helyén építeni, az felújítás lesz vagy egy korábbi építkezési boom közel új lakásának vagy házának vásárlása, azaz gyakorlatilag vakon futsz. Persze van vezeték kereső, hőérzékeny fólia, hőkamera, de azért mindig nagy sóhaj kíséretében áll neki az ember fúrni. 

    Ismét azt mondom, hogy próbáljunk az életszerűség talaján maradni, nem járnak ki a népek építkezésekre, pláne nem fotózzák le, hogy mi hol van a falban és pláne nem verik ki a balhét, ha nem ott van a vezeték, ahol a tervek szerint kellene. És az emberek többsége használt lakást vagy házat vesz, aminél pedig nem fogják elővenni a családi fotóalbumot, hogy a villanyszerelők hol vitték a vezetéket a falban.

    +1

    Én a fürdőszoba felújításkor lefényképeztem, hová véste be és tette be a csöveket a vízvezetékszerelő.

    Aztán amikor új építésű házat vettünk, amikor mondtam a kivitelezőnek, hogy megnézném, akkor gyakorlatilag azt mondta, hogy régebben csinálták ezt, de pár éve már nem. Építési területre nem mehet be csak úgy valaki, kell védőfelszerelés meg minden, ami macera, szóval nem.

    Hab a tortán, hogy természetesen semmilyen tervet nem kaptunk a ház alaprajzán és az azon feltüntetett részleteken (konnektor, csap, ajtó) kívül. Amikor az asszony mondta, hogy hát pedig amikor korábban új építésű lakást vett otthon, és kapott hozzá mindenféle tervet, akkor kb. annyival elintézték, hogy hát, ebben az országban ez nem szokás.

    Szóval fogalmam sincs, hogy hol mennek a vezetékek és a csövek, de még csak azt se tudom, hogy melyik fal miből van, és a gipszkarton felső réteg alatt mit találok. Jó móka, hogyha bármit fel akarok tenni a falra, akkor az úgy megy, hogy kis fúróval először átfúrom a gipszkartont, aztán tolómérővel megmérem, hogy mekkora hely van mögötte, aztán lámpával bevilágítva megpróbálom kitalálni, hogy milyen anyag lehet az, ami következik, aztán kitalálni, hogy a méretek és anyagok függvényében vajon mi lenne a jó rögzítési megoldás az adott helyre. És persze egy karnis 6 csavarjához 6-szor kell ezt elvégezni, és simán van úgy, hogy a 6 helyen mondjuk 2-3 különböző dolgot találok = 3 különböző rögzítési módszer lesz.

    Pedig mi is kijártunk az építkezésre, időnként megnéztük a kerítés mögül, hogy hol tart a házunk.

    disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

    Sziasztok!

    Senki nem futott bele abba, hogy Sonoff T1 EU-t akar felszerelni tégla falra (falba), amibe régi fajta doboz van begipszelve, amihez csavarral két "karmot" szétfeszítős kapcsoló való? A Sonoff T1 EU-n lévő lyukak és az abba dugott csavarok még simán beleesnek a dobozba, így megfúrtam a Sonoff T1 EU hátlapját fent (asszem) jobb oldalon, és lent bal oldalon, és felfúrtam a falra, a doboz mellett. Mivel kevés a hely, ahol a csavar feje van, oda szigetelőszalag került a nyákra. Minden jó, megoldottam, de úgy érzem, hogy nagyon nagyot gányoltam. A 0-t a fenti dobozból lehúztam, szuper, de ez a doboz dolog zavar.

    Találtam olyan (gipszkartonba való) dobozt, ahol megvan a két csavar helye, de nem akartam a falból kivésni a meglévő dobozt. (mehetnék is a háztól)

    Oldott meg már valaki ilyen problémát értelmesen?

    Köszönöm előre is.

    Ha a regi doboz gipszben, vagy valami vakolatanyagban van, akkor nem olyan nehez kiszedni. Nekem betonbol is sikerult.

    Ha a dobozba amugy rendesen befer (ugy tunik a leirasodbol, hogy igen), es tenyleg nem akarod kiszedni a falbol, akkor jobb lenne inkabb epiteni a epoxybol/fabol a gyari csavaroknak fogado oldalt.

    Én panelben jártam hasonlóan, de nekem pont sikerült behajtanom 4-ból, mondjuk 3 csavart a doboz és a gipsz/beton közé. Nem egy elegáns megoldás, de fogja.

    ----------------------------------^v--------------------------------------
    "Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

    Szerkesztve: 2020. 01. 09., cs – 19:31

    .

    Szerkesztve: 2020. 01. 09., cs – 19:23

    Csak úgy itt hagyom:

    Okos konnektort kerestem, normális API támogatással (nem akartam felhőn keresztül működőt, és Sonoff basic-kel nem voltak túl jók a tapasztalataim, + nem akartam firmwaret reszelni). Shelly Plug S lett belőle, működik szépen pár hónapja hiba nélkül, Kodi-val kapcsolgatja ki/be a (távirányító nélküli) sztereó erősítőt automatikusan, képernyő sleep alapján.

    Kodi Callbacks plugin:

    ScreensaverActivated: 

    curl -s http://$shelly_ip/relay/0?turn=off

    ScreensaverDeactivated: 

    curl -s http://$shelly_ip/relay/0?turn=on

    A legtöbb okos konnektoron kidobják a gyári firmware-t. A Shelly jóformán az egyedüli gyártó, amelyik biztosít átprogramozási lehetőséget.

     

    Én a vicc kedvéért szinte az összeset kipróbáltam, a Blitzwolf SHP2 jött be a legjobban. Elég randa, de 16A-ig lehet vele kapcsolni és teljesítményt mérni.

    A Blitzwolf SHP6 sem lenne rossz, ha lehetne rendesen szerelni. Azt átprogramozni a mágia határát súrolja.

     

    Ezeken a felhő alapú cuccokon kínai kémszoftverek futnak, nem érdemes használni őket. El kell távolítani.

    Hátha itt van jó helyen a kérdésem: milyen wifin irányítható izzók vannak, amelyek nem kommunikálnak mással, csak az őket irányító applikációval?

    Shellynél a felhő egy ingyenesen adott, ám alapértelmezetten kikapcsolt szolgáltatás. Kifejezetten tenned kell azért, hogy működésre bírd (regisztráció, eszköznek internetkapcsolat biztosítása, felhőbe léptetése, stb..). A bekapcsolás utáni default állapotban a local webguin, és a szintén local api-kon keresztül (http, mqtt) szólítható csak meg.

    Szerkesztve: 2020. 05. 17., v – 18:43

    Sziasztok!

    Mennyivel stabilabb szerintetek egy 1-wire hálózat (soros, kb. 80 m CAT6 UTP, kb. 20 eszköz) egy ilyennel?
    Az első stabilabb/megbízhatóbb ehhez képest? Vagy ehhez képest? Ezzel esetleg találkozott valaki?

    Az ESERA megoldásánál ez vajon mi? Egy ellenállás és ledek?

    Kum Gábor

    Semmivel nem stabilabb. I²C szerű koncepció. Mivel egy ilyen áráért legalább 10 db Fiber optic to RJ45 convertert lehet venni semmi értelme. Duplex optikai hálózatnál megbízhatóbb megoldás biztosan nem kell otthonra. Az RPi kiegészítő ára nincs elszállva, de ettől még nem nyer értelmet a 1-wire. Az erős áramú hálózatot használó megoldásoknak ott van haszna ahol nem megoldható a kábelezés. De ez nem az.

    Ha a maximális 100 méter nem jelent problémát legjobb ha maradsz a bevált és megbízható UTP kábeleknél.

    Szerkesztve: 2020. 06. 19., p – 10:07

    Sziasztok, 

    Arra van esetleg ötletetek, hogy miként lehetne mobilra (iOS) értesítést kapni, ha valaki becsenget egy analóg Panasonic kx t61610CE + KX-T30865 telefonközponton keresztül? Homeassistant és Shelly (vagy más kész relé) irányból közelíteném meg a dolgot. Az ajtó mágneszárral nyitható (a telefonközponton keresztül is) így nem volna rossz, ha ezt is esetlegesen meg tudnám tenni, de ez nem feltétlenül szükséges. 

    Ha szeretsz barkácsolni:
    Én úgy oldottam meg hasonlót, hogy az ajtócsengő panelján kerestem egy pontot, ahol feszültség jelenik meg csengetéskor. Erre kötöttem egy feszültségszabályzót, ami ezt a feszültséget 3.3V-ra lövi be. Az így kapott kimenetet pedig rákötöttem egy ESP01 egyk GPIO portjára.
    Az ESP01-en Tasmota firmware fut, amin be lehet állítani, hogy mi történjen ha az adott GPIO porton 0, vagy 1 (van áram, nincs áram) jelenik meg. Ha 1, akkor MQTT-n küldi az infót az MQTT kiszolgálónak. Ez nálam egy Raspberry-n fut, Homeassistanttal egyetemben, amiben látom logolva, mikor csengettek utoljára.

    Igen :) Én inkább megírom magamnak, az stabilan működik. Nem olyan nehéz egyébként. Van elég barátságos #include <PubSubClient.h> példányosítod pl: PubSubClient client(wifiespClient); client.setServer(10.11.12.13, 9999); client.setCallback(callback); innentől van client.subscribe(...) client.publish(...) meg minden ami kell.

    Szerkesztve: 2020. 08. 25., k – 22:38

    Vettem egy Shelly 2.5-ös redőnyvezérlőt, 2 csatornát tud kapcsolni, teljesítményméréssel. Ki is próbáltam 14W-os energiatakarékos égővel. Minden tökéletesen megy, csak meleg.

     

    Az ESP8266 belső hőmérséklet szenzora 80 fok körül mozog (hivatalosan 125-ig mehet, de inkább kösz nem). A régi Shelly 1PM 47 fokon éjjel-nappal eldöcög, pedig előfordul, hogy 2000W-on mennek alatta a klímák. Jó lett volna külön mérni a fogyasztásukat, de hősugárzót inkább nem teszek a fal mögé.

     

    A Shelly 1PM-hez képest érezhetően melegebb a Shelly 2.5 még minimális terhelés mellett is, bár kézzel meg lehet fogni. Ha elérné a 90 fokot, automatikusan kikapcsol a Tasmota.

     

    Ti beraknátok fal mögé, ahol nem is látjátok, hogy mit csinál? Normális a fűtés a Shelly 2.5-nél? Szerintem nagyon gáz.

    A shelly firmware csak akkor használ cloudot, ha komoly erőfeszítéseket teszel érte: regisztrálni kell, majd magán az eszközön is be kell kapcsolni a funkciót, és loginolni vele. Ha ezt nem teszed meg, akkor local http gui-t és api-t kapsz, illetve mqtt támogatást, cloud nincs. Azon ritka (vagy egyetlen?) ESP alapú eszközök egyike, amelyeken teljesen felesleges kicserélni a gyári firmwaret.

    Utánanéztem, visszaraktam az eredeti firmware-t. Elmegyek a boltba, megkérdezem, hogy visszaveszik-e, vagy cserélik.

     

    Bevallom, nem ismerem a Shelly firmware-t. Meg sem próbáltam használni. Van üzemben Blitzwolf SHP2, Blitzwolf SHP6, Sonoff S20, Shelly 1, Shelly 1PM.

    A Blitzwolfokat csak teljesítmény mérésre használom, egyébként a fiókomban hevernek.

     

    A Tasmota mindenen jól megy. Az Ewelink kritikán aluli volt, ezért nem kísérleteztem tovább, ott elakadtam. A Shelly firmware-ről eddig csak olvastam, de nem próbáltam ki.

    Nem tudom, hogy Shelly FW-t lehet-e Sonoffra, meg Blitzwolfra tenni.

    Eredeti firmware-rel futtattam egy napot. Nem gyulladt fel, a doboz estére is 40 fok közelében maradt.

     

    Nálad is felmegy ilyen melegre? Megfogod a shellyt és érzed, hogy melegebb nálad?

     

    Azért kérdezem, mert néha a gyártásnál az ellenállások értéke határon kívülre kerül, amitől az eszköz többlet hőt ad le, amitől megdöglik egy év múlva.

    Ezért fontos tudni, hogy más Shelly 2.5 is ugyanezt csinálja-e, vagy csak nekem volt szerencsém.

    Új vagyok az okosotthon témában. A kommersz SONOFF féle kapcsolókat, SpektrumSmart izzókat bekötöttem és kommunikálnak megfelelően a google home-al. Zenelejátszással kapcsolatban elakadtam. Fut itthon egy szerveren Ampache féle MP3 adatbázis zenelejátszási céllal. Be is rendeltem egy Chromecast Audio eszközt, hogy az analóg erősítőmmel össze tudjam hangolni a zene lejátszás hangkimenetét. A kérdésem az lenne, hogy offline MP3 lejátszásra milyen megoldás létezik? (balkánon lakok, nem szeretnék sem spotify, sem youtube premium, semmilyen előfizetést) továbbá nem szeretnék 200+ gigányi zenét feltölteni a Google Play szolgáltatására.

    Simán offline szeretnék zenét hallgatni a rendelkezésre álló MP3 garmadából hangutasítással. Nem találtam megoldást a fenti problémámra. Ampache serverhez nem ragaszkodok, bár eddig bevált.

    Sziasztok!

     

    Én is új vagyok ebben a témában. Tanácsot kérek, milyen eszközzel tudnám az alábbi egyszerű feladatot megoldani. Lehetőleg kész dolgot keresek, nem akarok fejleszteni.

    Szeretném mérni a szabadban a hőmérsékletet és a légköri nyomást (esetleg a relatív páratartalmat is), lehetőleg belső áramforrású szenzorral. A mért értéket valamilyen webes felületen szeretném leolvasni, az előzményekkel együtt (pl. elmúlt hét, elmúlt hónap, elmúlt negyedév, elmúlt év).

    Más eszközt egyelőre nem akarok a rendszerbe integrálni. A szenzor távolsága a lakástól 10 méteren belül van, wifi elérhető, van okostelefon SmartThings-szel, van egy Linux PC, amit erre a célra (adatgyűjtés, web szerver) tudnék használni.

    Hogyan, milyen eszközökből rakjam össze?

    "Lehetőleg kész dolgot keresek, nem akarok fejleszteni." vs "Hogyan, milyen eszközökből rakjam össze?"

    Ebben érzek némi ellentmondást... mi az a legkisebb legó kocka, amiből még építkezni szeretnél?

    Én egy WEMOS D1 mini, egy SDS011 és egy BME280 szenzorból rajtam össze ilyet, 3D nyomtatott dobozban van, esőtől védett helyen: https://blog.iotguru.cloud/2020/10/29/dust-box/